http://www.ashmanov.com

Опыт проваленных проектов ничем не заменишь. Дело в том, что у неправильного хода проекта есть свои несомненные признаки. Если менеджер проекта или его босс уже имели опыт провальных проектов, они с легкостью узнают нехорошие симптомы.

Правило 15. Важно вовремя узнать "паттерн" неудачного проекта - симптомы надвигающейся болезни.

Как распознать заранее будущие проблемы проекта? Есть несколько типичных признаков.

Виртуальная реальность проекта

Очень часто проекта на самом деле не существует. Нет планов работ, практически нет руководителя, фиксации промежуточных состояний. Никто не оценивал денежные перспективы, объем рынка, трудоемкость. Однако ответственные лица изредка собираются на совещания, обсуждают классную идею, и компания числит проект в списке выполняемых. Программисты даже что-то там иногда программируют, деньги тратятся.

Относительно благополучный проект также может быть не целиком виртуальным, а частично, в некоторых своих кусочках. Чаще всего превращение благополучного проекта в проваленный - это и есть процесс постепенной "виртуализации" проекта.

Распознать такой виртуальный проект можно в первую очередь по сложившейся вокруг него мифологии.

Мифы и отсутствие информации

Мифы вокруг проекта - это набор общих высказываний и мнений о проекте, ложность которых постороннему ясна с первого взгляда.

Где руководитель? Например, может считаться, что у проекта есть руководитель, а на самом деле фактически его нет.

- Да есть как бы руководитель проекта, Петров. А, он не руководитель? А кто? Ну хорошо - как бы ответственный за проект, только он сейчас в командировке... Но его можно будет спросить, когда он приедет.

Когда он приезжает, выясняется, что за проект на самом деле отвечает кто-то другой, а Петров не в курсе. Точнее, перед поездкой вместо Петрова назначили другого, но тот пока всё еще занят в другом проекте.

Отсутствие ответов на самые простые вопросы. Никто не может ответить на вопросы, которые должны были бы быть прояснены в самом начале.

Например, считается, что по завершении проекта будет получена очень крутая штука, но никто не знает о том, что ровно это почти у всех есть:

- А на сайтах конкурентов что написано? Какие они основные функции своего продукта продвигают?
- Да, кстати, хорошая мысль! Ух ты! Сейчас скажу Сенькину, чтобы напряг там своих аналитиков - пусть посмотрят.

А где раньше был Сенькин и его аналитики? Да и сам босс тоже?

Коммерческая неясность. Зачем нужен проект и сколько на нем можно заработать - точно неизвестно. Когда выводим на рынок (запускаем, публикуем) - тоже.

Мутное состояние проекта. Диагноз подкрепляет неясность с состоянием проекта, когда никто толком ничего не знает. Боссу то и дело приходится вызывать то одного, то другого менеджера, чтобы разобраться в статусе проекта, все кивают на других, кто-то в командировке или болен, а кто-то вообще уволился.

Недостаток письменной информации. Отсутствие или негодность планов и других необходимых бумаг также очень подозрительны. Типичными признаками полуживого, полувиртуального проекта, вяло растущего на грядке, без присмотра, являются:

• План без фамилий исполнителей, СЃ устаревшими Рё РЅРµ обновленными датами, СЃ пропусками таких ключевых этапов, как тестирование Рё выпуск, обрывающийся РЅР° бета-версии.
• Десятистраничное "Техническое задание" годичной давности, содержащее перемешку СЂСѓСЃСЃРєРёС… Рё английских РєСѓСЃРєРѕРІ, незаметно переходящее РІ описание функций РЅР° языке РЎ++, запинающееся Рє концу Рё обрывающееся РЅР° полуслове.
• "Атомарные" недельные отчеты РёР· полутора десятков пунктов РІ стиле "крутили гайку номер 8 ключом РЅР° 13 РґРІР° рабочих РґРЅСЏ", которые абсолютно ничего РЅРµ РіРѕРІРѕСЂСЏС‚ РЅРё Рѕ месте Рё назначении гайки, РЅРё Рѕ цели кручения, РЅРё Рѕ состоянии проекта РІ целом.
• Устаревший РЅР° РґРІР°-три месяца план-график работ над столом руководителя.

Бесконечные совещания и "мозговые штурмы""

Особенно показательны многолюдные совещания, к которым никто не готовится и на которых не принимается решений по проекту. По неизвестной причине босс считает, что для исправления ситуации в проекте нужно собрать вече из пятнадцати сотрудников, часть из которых вообще не в курсе проекта.

"Чтобы разобраться - нужно собраться." То есть вызвать всех ответственных и устроить разбор полетов. Приглашается масса народу. Как ни странно, руководитель компании к такому собранию обычно не готовится интеллектуально - не пишет повестку собраний, не отбирает немногих ответственных лиц для участия, не задает очередность выступлений, не требует заранее отчетов, не ходит заранее "в народ", чтобы получить независимые мнения.

Однако, к собранию он обычно подготавливается эмоционально - накапливает запас начальственной воли и гнева.

Не готовятся обычно и подчиненные, уставшие от проекта и заваленные другими делами. Только самые хитрые и хладнокровные из них заготавливают список причин и оправданий - "отмазок".

На совещании разбор полетов довольно быстро переходит в кашу, разбивается на несколько независимых дискуссий, слышатся угрозы и упреки начальства, поток технических разъяснений, исторических экскурсов "как всё было". Естественно, рефреном со всех концов стола звучит "ресурсов же не хватало, мы же говорили!". Начальник надувается (ведь это претензия к нему, он же якобы не дал ресурсов).

В середине заседания возникает вдруг конструктивное течение - возникает вопрос "ну хорошо, что делаем дальше?", высказываются конструктивные предложения. Потом опять всё само собой тонет в пучине обсуждения вопроса "кто виноват и как же так вышло?".

Заканчивается собрание ничем уже поздним вечером - все расходятся уставшие, возбужденные и обиженные, руководитель вдогонку устало выкрикивает последние угрозы разобраться и наказать, и дает нечаянно задержавшимся в переговорной сотрудникам приказы дать бумаги с анализом ситуации и предложениями.

Как ни удивительно, иногда после собрания вдруг спонтанно возникает второе собрание в узком кругу задержавшихся, гораздо более конструктивное и результативное.

В результате собрания у босса все-таки появляется большая ясность, однако конструктивных решений не возникает.

Постоянный перенос сроков

Ну, здесь комментарии не требуются. Это всегда плохой признак. Однако указывать он может на разные проблемы, от чисто технических и преодолимых препятствий до полного развала управления в проекте. Тут нужно разбираться.

Очень часто перенос сроков является признаком очень опасной ситуации - петли загруженности.

Дурная петля загруженности

В разработке ПО очень часто воспроизводится известный случай с пилой:

- Почему вы пилите тупой пилой, так ведь очень долго и трудно?
- Да некогда точить, пилить надо!

Разработчик, да и руководитель проекта очень часто попадают в эту ловушку, когда кажется, что окончание проекта - за ближайшим поворотом. Поэтому разбираться, планировать и оценивать состояние проекта некогда. � они легко объясняют это начальству.

Обычно эта дурная петля возникает в условиях "небольшого срыва" сроков. Действительно, некогда и незачем писать оценки и планы, когда продукт выйдет вот-вот... Некогда оценить сроки и размер срыва.

Слово "небольшого" написано в кавычках не зря - я многократно видел ситуации, когда после принудительной остановки гонки высшим менеджером и трезвой оценки в тишине состояния проекта вдруг оказывалось, что срок на самом деле сорван не на дни, а на месяцы, и во многих частях прокта еще конь не валялся.

А иногда срок оказывается сорванным навсегда. Либо проект просто невыполним, либо инвесторы/хозяева не готовы платить такую цену или ждать столько.

Причем для получения этой ужасной правды руководителю проекта, как правило, достаточно дня спокойного размышления и написания электронного письма на страницу - то есть он мог бы это понять и раньше.

Более того, хоть это и выглядит дико в глазах вышестоящего руководителя, но обычно после получения подобной оценки состояния проекта, выданной наконец под давлением, менеджер проекта начинает утверждать, что полная неготовность проекта, огромный объем недоделок и необходимость потратить еще месяцы - совершенно очевидны, закономерны и давно известны. На вопрос "а что ж ты раньше-то молчал!" он обычно отвечает - "да я же говорил, а вы мне руки выкручивали". Босс-то помнит, что на самом деле менеджер проекта ничего не говорил, но доказать это уже невозможно.

Дело тут в том, что разработчики давно уже в глубине души сознавали, что всё плохо, но не признавались в этом даже сами себе, при том, что сумасшедший объем стоящих в очереди проблем позволял забыться "в борьбе за урожай".

Распознать петлю загруженности и скрытый срыв легко - после первого-второго переноса сроков или при первых признаках аврала нужно запросить от руководителя состояние проекта и уточненный план.

Разорвать петлю гораздо труднее - для этого требуется принятие решения об изменении хода проекта (добавлении ресурсов, усечении требований, переносе сроков), а это всегда нелегко.

Порочная логика разработки

Очень популярен перенос сроков и списывания долгов по причине спонтанного повышения требований к проекту. Наращивание функциональности очень легко находит сторонников и среди разработчиков, и среди менеджмента, потому что ведь так логично и увлекательно добавлять новые возможности.

- Смотрите, как логично всё получается - сначала простая версия, потом тяжелая, потом смежные продукты, потом новое ядро, потом продукты для всех сегментов, потом глобальные версии, потом локальные продукты для Венеры и Марса, потом...

Очень часто такая логика используется и для переноса срока выпуска проекта:

- Если мы еще добавим такую фичу, будет очень круто, ни у кого нет, все клиенты просят. А ведь нужен всего лишний месяц.
- Ну давай перенесем выпуск на май, только опиши подробнее новую функциональность.

� часто этот ход используется для переноса срока уже проваленного проекта.