Comments 48
Бра-во! В принципе всем, кто прочитал этот пост, все понял и по каждому пункту смог вспомнить пример из своей реальной практики можно давать сертификат PMP.
> Определен ли состав задач проекта, есть ли план-график, достаточно подробный для выполнения этих задач?
> Есть ли в плане привязанные к задачам ответственные исполнители и сроки исполнения задач?
> В плане-графике не должно быть задач длительностью больше трех дней
Момент важный, но судя по формулировке вопроса, в кризисные ситуации попадают только waterfall проекты. :) В других полного графика вполне может и не быть.
> Есть ли в плане привязанные к задачам ответственные исполнители и сроки исполнения задач?
> В плане-графике не должно быть задач длительностью больше трех дней
Момент важный, но судя по формулировке вопроса, в кризисные ситуации попадают только waterfall проекты. :) В других полного графика вполне может и не быть.
На мой взгляд, даже если методика не waterfall, все равно план нужно иметь, хотя бы план на пару итераций. К сожалению, многие до сих пор думают, что agile переводится как «разгильдяйство» и стараются оправдать свое нежелание планировать дела гибкостью подхода управления. )) Я лично двумя руками за итерационные методологии, но если уж в них дела зашли в тупик, то дело не в плане, а в коммуникациях, политике или в чем-то еще.
>многие до сих пор думают, что agile переводится как «разгильдяйство» и стараются оправдать свое нежелание планировать дела гибкостью подхода управления. ))
Значит эти «многие» тупо не понимают смысла и принципов agile, только и всего. Планирование — одна из ключевых составляющих любой agile методики.
Кстати, если говорят «мы применяем agile», то скорее всего это как раз тот случай: ни ухом, ни рылом в том, что такое agile разработка, и ни хрена они на самом деле не применяют и в проекте полная анархия. Ибо нет такого подхода «agile». Agile — это тип подхода к управлению проектом. Группа подходов, если хотите. А дальше уже конретные реализации: XP, Scrum, FDD и так далее.
Значит эти «многие» тупо не понимают смысла и принципов agile, только и всего. Планирование — одна из ключевых составляющих любой agile методики.
Кстати, если говорят «мы применяем agile», то скорее всего это как раз тот случай: ни ухом, ни рылом в том, что такое agile разработка, и ни хрена они на самом деле не применяют и в проекте полная анархия. Ибо нет такого подхода «agile». Agile — это тип подхода к управлению проектом. Группа подходов, если хотите. А дальше уже конретные реализации: XP, Scrum, FDD и так далее.
Если мы говорим о кризисных проектах, то я бы ещё поставил пунктом 0 признание действующими лицами того, что проект в кризисе.
А то бывает так, что команда проекта думает, что всё плохо, а руководители предприятия — что всё просто замечательно и ничего спасать не надо. Или наооборот, руководство считает, что с проектом всё плохо, а команда — что всё идёт, как доктор прописал.
А то бывает так, что команда проекта думает, что всё плохо, а руководители предприятия — что всё просто замечательно и ничего спасать не надо. Или наооборот, руководство считает, что с проектом всё плохо, а команда — что всё идёт, как доктор прописал.
Всё понравилось. Реально так, с кризисными проектами. Только вот нету анализа почему он стал кризисным.
Конечно, если управлять хвостом так, как управлять проектом хорошо — дело выедет на рельсы. Но иногда полезно знать почему проект съехал с рельс, и не всегда дело в менеджере (или даже плане).
Конечно, если управлять хвостом так, как управлять проектом хорошо — дело выедет на рельсы. Но иногда полезно знать почему проект съехал с рельс, и не всегда дело в менеджере (или даже плане).
Полностью согласен, дело не обязательно в плане (о чем даже написал выше). Да, написать почему проекты становятся кризисными — хорошая идея, надо будет сделать.
Согласен. Найти причину кризисности надо обязательно. В частности, в веб-проекте: пожирающий время перфекционизм разработчиков и лидера; поток хотелок и отсутствие времени на них, что ведет к костыльным тупиковым решениям; экономия на квалификации разработчиков, дизайнеров или менеджеров в ключевых ролях проекта; недостаточное внимание рекламе и продвижению… Не уничтожив причину, из кризиса не выбраться.
>Какие бизнес-цели проект преследует, есть ли измеримые показатели этих бизнес-целей?
В этом случае необходимо составить таблицу (цель) — (существующая ситуация) — (необходимая ситуация) для каждого из «участков проекта». Да, выраженную в четких цифрах (условиях). Но необходимо именно описать «существующую ситуацию». Для приведенного примера — " На данный момент мы продаем 100 телевизоров" — «Надо продавать 110». В большинстве случаев, задача ставится «задача проста, мы должны увеличить продажи».
В этом случае необходимо составить таблицу (цель) — (существующая ситуация) — (необходимая ситуация) для каждого из «участков проекта». Да, выраженную в четких цифрах (условиях). Но необходимо именно описать «существующую ситуацию». Для приведенного примера — " На данный момент мы продаем 100 телевизоров" — «Надо продавать 110». В большинстве случаев, задача ставится «задача проста, мы должны увеличить продажи».
Согласен. Вообще, это еще хорошо, если пишут «задача проста, мы должны увеличить продажи». Бывает же что пишут «сделайте нам хорошо». )
Ну это равнозначные почти задания) Просто обязательно определять тот уровень с которого надо увеличивать продажи. После этого можно уже анализировать ситуацию, составлять некую воронку «продаж» и искать мешающий, узкий участок. После этого уже составить матрицу влияния на данный участок, ну и вести работу.
P.S. «обязательно» = ИМХО
P.S. «обязательно» = ИМХО
Не хотели это в виде схемки (или таблицы) со стрелочками оформить, и этапы тематически сгруппировать? Это, конечно, не очень просто, но если выйдет, то получилось бы очень наглядное руководство, на мой взгляд.
Круто. Очень чётко, конкретно, лаконично и всё по теме.
Хотя вопросы и кажутся простыми, но получить на них ответы от новой команды ну очень сложно.
Хотя вопросы и кажутся простыми, но получить на них ответы от новой команды ну очень сложно.
Спасибо. Я думаю, что время от времени надо забывать о сложных современных методах и инструментах управления и вспоминать о банальных вещах. Как сказал Сергей Довлатов, один из моих любимых писателей: «Я понимаю, что все мои рассуждения достаточно тривиальны. Недаром Вайль и Генис прозвали меня «Трубадуром отточенной банальности». Я не обижаюсь. Ведь прописные истины сейчас необычайно дефицитны.» ))
Осталось задать вопрос нескромный. Сколько вы спасли проектов?
За последние четыре года штук семь, наверное.
UFO just landed and posted this here
1 — проект создания системы обработки статистических данных (для нероссийской госструктуры)
2 — проект создания сети платежных терминалов (для нероссийского розничного банка)
3 — проект развития сервисов банкомата (для нероссийского розничного банка)
4 — проект модификации штрафной политики (для розничного банка)
5 — проект по созданию виртуальных карточных сервисов для банкомата (для нероссийского розничного банка)
6 — проект создания DWH на технологиях Sybase (для крупного российского банка)
7 — партнерский проект банка с сотовым оператором
На самом деле даже побольше семи будет, если еще мелочь учитывать. ))
2 — проект создания сети платежных терминалов (для нероссийского розничного банка)
3 — проект развития сервисов банкомата (для нероссийского розничного банка)
4 — проект модификации штрафной политики (для розничного банка)
5 — проект по созданию виртуальных карточных сервисов для банкомата (для нероссийского розничного банка)
6 — проект создания DWH на технологиях Sybase (для крупного российского банка)
7 — партнерский проект банка с сотовым оператором
На самом деле даже побольше семи будет, если еще мелочь учитывать. ))
«Способна ли команда справиться с задачей, можете ли вы повлиять на ее состав?»
Ответ — нет. Ваши действия?
Ответ — нет. Ваши действия?
Если руководителю проекта не дали полномочий на подбор и расширение команды — это не руководитель проекта, пусть не льстит себе.
Должно быть, вы никогда не работали в матричных структурах. ))
habrahabr.ru/blogs/pm/121828/
habrahabr.ru/blogs/pm/121828/
Я работаю руководителем отдела, в моём подчинении руководители проектов. Структура матричная. Разработчики не подчиняются непосредственно РП-шникам.
При матричной структуре проблема с ресурсами еще проще, РП ставит задачу начальнику разработчиков с указанием сроков. Если сроки не выполняются — это проблема начальника отдела разработки.
При матричной структуре проблема с ресурсами еще проще, РП ставит задачу начальнику разработчиков с указанием сроков. Если сроки не выполняются — это проблема начальника отдела разработки.
Все абсолютно верно, так и есть. А теперь представьте, как в таких ситуациях чувствует себя менеджер проекта. )
Тяжело, но никто не говорил, что управлять проектами легко, это только в глазах разработчиков РП-шники выглядят лентяями, которые только и могут, что письма писать, да деньги получать.
Реальный пример — руководитель проекта по внедрению крупной ИТ-системы (не мой подчиненный, там проект покрупней на порядок, и проектная группа вообще выведена из ИТ-департамента) свалился с приступом. Я прекрасно понимаю причину.
Реальный пример — руководитель проекта по внедрению крупной ИТ-системы (не мой подчиненный, там проект покрупней на порядок, и проектная группа вообще выведена из ИТ-департамента) свалился с приступом. Я прекрасно понимаю причину.
Плюс при отсутствии матричной структуры у тебя в команде при крупном ИТ-проекте должны быть свои сисадмины, поддержка, разработчики по всем системам, по которым идёт разработка в не зависимости от того, что по проекту может быть требуется на С библиотеку за пару дней написать.
Менять scope, например. До тех пор, пока хотелки и возможности хоть как-то не совпадут.
Не бывает в проектах, в которых нельзя поменять scope.
Не совсем понимаю: вот мы задались вопросами. А дальше-то что?
Требую продолжения статьи, как вытаскивать проект за уши из навоза
Требую продолжения статьи, как вытаскивать проект за уши из навоза
А дальше как раз начинается искусство воплощения в жизнь ответов на вышеописанные вопросы. )
Набора ответов на указанные вопросы обычно достаточно, чтобы либо соскочить с предложения спасать, либо чтобы затребовать сумму и при этом аргументированно не обещать результата. Чисто венчурная математика: «пан или пропал».
Жалко мысли в голове не выделяются жирным если они важные…
Длинные задачи имеют обыкновение не начинаться, их старт всегда откладывается из-за каких-то мелочей.
Очень хорошее замечание! Особенно, если эти длинные задачи сформулированы в 2-3 строки, представляющие собой мысль в виде — «У нас есть проблема поддержки нашего приложения на 10 разных СУБД. С этим надо срочно что-то делать!»
Еще я бы добавил такой пункт сюда. Боритесь с упадническими настрояниями в проекте, и боритесь за мотивацию. Если проект в такой ситуации, у половины разработчиков будет убеждение — «какой смысл тут упираться, если все равно эта херня будет тянуться, пока бюджет не кончится, или у кастомера терпение не лопнет, так смысл тут стараться?»
По поводу мотивации — большинство нормальных прагматичных программистов терпеть не может две вещи.
1) Писать фичи, по поводу которых никто не может толком объяснить, зачем они вообще нужны и кто и как их использует, и почему это должно работать именно так. Например — сказано, добавить поддержку для СУБД FoxPro. Зачем? Кому это надо? Не проще мигрировать на что-то другое?
2) Делать фичи, по котором нет четкого и понятного требования и критерия выполнения, на уровне фичи, не на уровне успеха проекта.
Очень хорошее замечание! Особенно, если эти длинные задачи сформулированы в 2-3 строки, представляющие собой мысль в виде — «У нас есть проблема поддержки нашего приложения на 10 разных СУБД. С этим надо срочно что-то делать!»
Еще я бы добавил такой пункт сюда. Боритесь с упадническими настрояниями в проекте, и боритесь за мотивацию. Если проект в такой ситуации, у половины разработчиков будет убеждение — «какой смысл тут упираться, если все равно эта херня будет тянуться, пока бюджет не кончится, или у кастомера терпение не лопнет, так смысл тут стараться?»
По поводу мотивации — большинство нормальных прагматичных программистов терпеть не может две вещи.
1) Писать фичи, по поводу которых никто не может толком объяснить, зачем они вообще нужны и кто и как их использует, и почему это должно работать именно так. Например — сказано, добавить поддержку для СУБД FoxPro. Зачем? Кому это надо? Не проще мигрировать на что-то другое?
2) Делать фичи, по котором нет четкого и понятного требования и критерия выполнения, на уровне фичи, не на уровне успеха проекта.
Мне что-то подсказывает, что если хотя бы на половину этих вопросов можно дать ответ, то проект очень даже позитивный и совсем не гиблый.
> Как говорят по ту сторону океана, a good beginning is half the battle.
А по эту сторону говорят «доброе начало — полдела откачало».
Терминов-англицизмов и без того целая куча, давайте хоть фольклор русским оставим…
А по эту сторону говорят «доброе начало — полдела откачало».
Терминов-англицизмов и без того целая куча, давайте хоть фольклор русским оставим…
Очень понравилось, спасибо большое за статью!
Sign up to leave a comment.
Спасти проект: самые важные вопросы