Открыть список
Как стать автором
Обновить

Комментарии 48

Бра-во! В принципе всем, кто прочитал этот пост, все понял и по каждому пункту смог вспомнить пример из своей реальной практики можно давать сертификат PMP.
Спасибо. ) Ну, про сертификат не уверен, но обеспечить вхождение в проект помогает, проверено. )
PMP даётся не за опыт, а только и исключительно за BOK.
Что верно, то верно.
> Определен ли состав задач проекта, есть ли план-график, достаточно подробный для выполнения этих задач?
> Есть ли в плане привязанные к задачам ответственные исполнители и сроки исполнения задач?

> В плане-графике не должно быть задач длительностью больше трех дней

Момент важный, но судя по формулировке вопроса, в кризисные ситуации попадают только waterfall проекты. :) В других полного графика вполне может и не быть.
На мой взгляд, даже если методика не waterfall, все равно план нужно иметь, хотя бы план на пару итераций. К сожалению, многие до сих пор думают, что agile переводится как «разгильдяйство» и стараются оправдать свое нежелание планировать дела гибкостью подхода управления. )) Я лично двумя руками за итерационные методологии, но если уж в них дела зашли в тупик, то дело не в плане, а в коммуникациях, политике или в чем-то еще.
>многие до сих пор думают, что agile переводится как «разгильдяйство» и стараются оправдать свое нежелание планировать дела гибкостью подхода управления. ))

Значит эти «многие» тупо не понимают смысла и принципов agile, только и всего. Планирование — одна из ключевых составляющих любой agile методики.

Кстати, если говорят «мы применяем agile», то скорее всего это как раз тот случай: ни ухом, ни рылом в том, что такое agile разработка, и ни хрена они на самом деле не применяют и в проекте полная анархия. Ибо нет такого подхода «agile». Agile — это тип подхода к управлению проектом. Группа подходов, если хотите. А дальше уже конретные реализации: XP, Scrum, FDD и так далее.
Если мы говорим о кризисных проектах, то я бы ещё поставил пунктом 0 признание действующими лицами того, что проект в кризисе.

А то бывает так, что команда проекта думает, что всё плохо, а руководители предприятия — что всё просто замечательно и ничего спасать не надо. Или наооборот, руководство считает, что с проектом всё плохо, а команда — что всё идёт, как доктор прописал.
По идее, это работа менеджера — собрать всех и рассказать горькую правду.
Так весь Ваш список — это работа менеджера. :)

Рассказать — это ещё не значит, что все согласны. А несогласные могут оказаться дополнительными трудностями на пути антикризисных действий. А их, трудностей, и так будет не мало.
Всё понравилось. Реально так, с кризисными проектами. Только вот нету анализа почему он стал кризисным.

Конечно, если управлять хвостом так, как управлять проектом хорошо — дело выедет на рельсы. Но иногда полезно знать почему проект съехал с рельс, и не всегда дело в менеджере (или даже плане).
Полностью согласен, дело не обязательно в плане (о чем даже написал выше). Да, написать почему проекты становятся кризисными — хорошая идея, надо будет сделать.
Согласен. Найти причину кризисности надо обязательно. В частности, в веб-проекте: пожирающий время перфекционизм разработчиков и лидера; поток хотелок и отсутствие времени на них, что ведет к костыльным тупиковым решениям; экономия на квалификации разработчиков, дизайнеров или менеджеров в ключевых ролях проекта; недостаточное внимание рекламе и продвижению… Не уничтожив причину, из кризиса не выбраться.
>Какие бизнес-цели проект преследует, есть ли измеримые показатели этих бизнес-целей?
В этом случае необходимо составить таблицу (цель) — (существующая ситуация) — (необходимая ситуация) для каждого из «участков проекта». Да, выраженную в четких цифрах (условиях). Но необходимо именно описать «существующую ситуацию». Для приведенного примера — " На данный момент мы продаем 100 телевизоров" — «Надо продавать 110». В большинстве случаев, задача ставится «задача проста, мы должны увеличить продажи».
Согласен. Вообще, это еще хорошо, если пишут «задача проста, мы должны увеличить продажи». Бывает же что пишут «сделайте нам хорошо». )
Ну это равнозначные почти задания) Просто обязательно определять тот уровень с которого надо увеличивать продажи. После этого можно уже анализировать ситуацию, составлять некую воронку «продаж» и искать мешающий, узкий участок. После этого уже составить матрицу влияния на данный участок, ну и вести работу.
P.S. «обязательно» = ИМХО
Не хотели это в виде схемки (или таблицы) со стрелочками оформить, и этапы тематически сгруппировать? Это, конечно, не очень просто, но если выйдет, то получилось бы очень наглядное руководство, на мой взгляд.
Хорошая идея, подумаю.
Круто. Очень чётко, конкретно, лаконично и всё по теме.

Хотя вопросы и кажутся простыми, но получить на них ответы от новой команды ну очень сложно.
Спасибо. Я думаю, что время от времени надо забывать о сложных современных методах и инструментах управления и вспоминать о банальных вещах. Как сказал Сергей Довлатов, один из моих любимых писателей: «Я понимаю, что все мои рассуждения достаточно тривиальны. Недаром Вайль и Генис прозвали меня «Трубадуром отточенной банальности». Я не обижаюсь. Ведь прописные истины сейчас необычайно дефицитны.» ))
Осталось задать вопрос нескромный. Сколько вы спасли проектов?
За последние четыре года штук семь, наверное.
НЛО прилетело и опубликовало эту надпись здесь
1 — проект создания системы обработки статистических данных (для нероссийской госструктуры)
2 — проект создания сети платежных терминалов (для нероссийского розничного банка)
3 — проект развития сервисов банкомата (для нероссийского розничного банка)
4 — проект модификации штрафной политики (для розничного банка)
5 — проект по созданию виртуальных карточных сервисов для банкомата (для нероссийского розничного банка)
6 — проект создания DWH на технологиях Sybase (для крупного российского банка)
7 — партнерский проект банка с сотовым оператором

На самом деле даже побольше семи будет, если еще мелочь учитывать. ))

«Способна ли команда справиться с задачей, можете ли вы повлиять на ее состав?»
Ответ — нет. Ваши действия?
Если руководителю проекта не дали полномочий на подбор и расширение команды — это не руководитель проекта, пусть не льстит себе.
Я работаю руководителем отдела, в моём подчинении руководители проектов. Структура матричная. Разработчики не подчиняются непосредственно РП-шникам.
При матричной структуре проблема с ресурсами еще проще, РП ставит задачу начальнику разработчиков с указанием сроков. Если сроки не выполняются — это проблема начальника отдела разработки.
Все абсолютно верно, так и есть. А теперь представьте, как в таких ситуациях чувствует себя менеджер проекта. )
Тяжело, но никто не говорил, что управлять проектами легко, это только в глазах разработчиков РП-шники выглядят лентяями, которые только и могут, что письма писать, да деньги получать.
Реальный пример — руководитель проекта по внедрению крупной ИТ-системы (не мой подчиненный, там проект покрупней на порядок, и проектная группа вообще выведена из ИТ-департамента) свалился с приступом. Я прекрасно понимаю причину.
Плюс при отсутствии матричной структуры у тебя в команде при крупном ИТ-проекте должны быть свои сисадмины, поддержка, разработчики по всем системам, по которым идёт разработка в не зависимости от того, что по проекту может быть требуется на С библиотеку за пару дней написать.
Менять scope, например. До тех пор, пока хотелки и возможности хоть как-то не совпадут.
Нельзя. Но проект должен быть сдан
?
Не бывает в проектах, в которых нельзя поменять scope.
Не совсем понимаю: вот мы задались вопросами. А дальше-то что?
Требую продолжения статьи, как вытаскивать проект за уши из навоза
А дальше как раз начинается искусство воплощения в жизнь ответов на вышеописанные вопросы. )
Набора ответов на указанные вопросы обычно достаточно, чтобы либо соскочить с предложения спасать, либо чтобы затребовать сумму и при этом аргументированно не обещать результата. Чисто венчурная математика: «пан или пропал».
Жалко мысли в голове не выделяются жирным если они важные…
Длинные задачи имеют обыкновение не начинаться, их старт всегда откладывается из-за каких-то мелочей.

Очень хорошее замечание! Особенно, если эти длинные задачи сформулированы в 2-3 строки, представляющие собой мысль в виде — «У нас есть проблема поддержки нашего приложения на 10 разных СУБД. С этим надо срочно что-то делать!»

Еще я бы добавил такой пункт сюда. Боритесь с упадническими настрояниями в проекте, и боритесь за мотивацию. Если проект в такой ситуации, у половины разработчиков будет убеждение — «какой смысл тут упираться, если все равно эта херня будет тянуться, пока бюджет не кончится, или у кастомера терпение не лопнет, так смысл тут стараться?»

По поводу мотивации — большинство нормальных прагматичных программистов терпеть не может две вещи.

1) Писать фичи, по поводу которых никто не может толком объяснить, зачем они вообще нужны и кто и как их использует, и почему это должно работать именно так. Например — сказано, добавить поддержку для СУБД FoxPro. Зачем? Кому это надо? Не проще мигрировать на что-то другое?

2) Делать фичи, по котором нет четкого и понятного требования и критерия выполнения, на уровне фичи, не на уровне успеха проекта.
Респект Вам, мне кажется ценность Вашего коммента выше ценности всей статьи. Сразу видно, что Вы прошли долгий последовательный путь программера, прежде чем стать менеджером :) Может напишете отдельную статью, например о том, чего не любят программеры? С удовольствием бы почитал!
Или статью, или подкаст — посмотрим :) Вообще надо, надо бы.
Один момент — я не перестал быть программером ;) Например, месяц назад я провел 3-4 восхитительных дня, портирую старую одну библиотеку на С++ с Win dll на unix .so, и это все под соусом JNI.
Мне что-то подсказывает, что если хотя бы на половину этих вопросов можно дать ответ, то проект очень даже позитивный и совсем не гиблый.
Это смотря какие ответы на эти вопросы можно дать. Никто не сказал, что ответы позитивные. )
Вот-вот. Главное, чтобы ответы были реальные
> Как говорят по ту сторону океана, a good beginning is half the battle.

А по эту сторону говорят «доброе начало — полдела откачало».
Терминов-англицизмов и без того целая куча, давайте хоть фольклор русским оставим…
Очень понравилось, спасибо большое за статью!
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.