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

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

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

Я тоже хотел бы поделиться опытом управления проектами. В ходе своей практической деятельности я был руководителем более 20 проектов в ИТ и кое-чего повидал. Надеюсь, мой опыт будет полезен как начинающим менеджерам проектов, так и более опытным.

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

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

В первой статье предлагаю обсудить следующие темы:

• Определение объёма проекта. Точность ТЗ.

• Выбор методологии проектного управления.

• Чёртов фикс‑прайс. Как в гонке за низкую стоимость не остаться крайним.

И так, поехали!

Определение объёма проекта. Точность технического задания (ТЗ)

Результат каждого проекта (продукт ли что-то другое) должен обладать набором характеристик, решающих задачи Заказчика. И чем точнее на старте проекта мы определим параметры этого результата, тем успешнее проект. Вроде бы просто. Как говорил один мой руководитель: «Арифметика Пупкина с картинками». Нужно пообщаться с Заказчиком, понять, что ему нужно, задокументировать и согласовать с ним это понимание.

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

Посмотрим на каждый камень отдельно:

• Недостаточная зрелость Заказчика для чёткого формирования требований к новой системе;

• Противоречивые требования от разных подразделений и групп Заказчика;

• Нет времени на предпроектную работу (очень редко такая активность оформляется приказом, следовательно, время на неё тратится по остаточному принципу);

• В принципе новая система нужна только руководству, людям «на земле» она не нужна;

• Проектная команда не погружена в нюансы бизнеса, поэтому не может правильно зафиксировать требования;

• Реализация всех требований потребует гораздо большего бюджета, чем уже выделен;

• И т. п.

Если эти препятствия не преодолеть, то в результате может получиться достаточно нечёткое техническое задание (либо «мутный» lean canvas), реализовать которое сложно. Такие проекты сразу начинаются с уточнения ТЗ. Но вот беда, бюджет проекта часто уже определён и серьёзное изменение ТЗ может стать невозможным.

Проскочить эти камень помогут следующие шаги:

• Подбор в предпроектную команду экспертов, знакомых с бизнесом Заказчика, его потребностями и т. п. Или такие эксперты имеют опыт работы с аналогичными Заказчиками (желательно, чтобы это был именно проектный опыт);

• Поиск ключевых экспертов со стороны бизнеса Заказчика, заинтересованных в новой системе;

• Поиск владельцев бизнес-процессов Заказчика;

• Проведение интервью как с экспертами, так и с владельцами;

• Сбор и формализация требований к новому продукту (системе, сервису и т. д.);

• Эскалация всех открытых вопросов на владельцев бизнес-процессов и, при необходимости, на спонсора;

• Формирование образа нового продукта (например, т. н. Lean Canvas);

• Согласование документа, описывающего новый продукт (например, технического задания);

• Проактивный подход, разнообразное общение с Заказчиком, использование  всей имеющейся харизмы.

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

В итоге нужно получить максимально подробное описание результата проекта (продукта). Тут, как в забытой рекламе Билайна, точность лишней не бывает.

 Выбор методологии проектного управления

Казалось бы, до начала проекта далеко и пока не до методологии. Но это вредная иллюзия. Выбор способа управления проектом может повлиять на сроки проекта и качество продукта, а через это на бюджет проекта.

Пожелания к правильной методологии:

• Она должна быть знакома участникам проекта. В идеале – внедрена у Заказчика ещё до начала проекта.

• Не должна быть сложной и запутанной;

• Должен быть необходимый набор шаблонов и образцов документов;

• Должна учитывать особенности создаваемого продукта;

• Должна быть задокументирована.

Отдельное пожелание – автоматизация процесса управления проектом. Об этом часто забывают и обрекают руководителя проекта на бесконечные Excel-таблицы и нудное рисование в PowerPoint.

Для своих продуктов (сложных ИТ-систем) вендоры придумали свои методологии (ASAP, AIM, etc). Есть PMBoK, PRINCE2, и т. д. Главное – не увлечься инструментарием и помнить, что главное в проекте – результат, а не способ его достижения.

При выборе способа управления проектом можно наткнуться на следующие камушки:

• Отсутствие проектной зрелости у Заказчика;

• Отсутствие проектной зрелости у проектной команды (как это не странно звучит, но и это бывает);

• Отсутствие задокументированной методологии (точно не нужно внутри проекта запускать ещё и проект внедрения проектного менеджмента);

• Отсутствие твёрдого характера у проектного менеджера. Любителей кричать что «некогда планировать, работать нужно», «нам правила не нужны, нужен результат», «мы всё делаем по agile» (обычно те, кто это декларирует, имеют смутное представление о гибком подходе), «нечего думать, трясти нужно»… впрочем, последняя фраза из анекдота. Sorry! Так вот менеджер проекта должен этому всему противостоять и гнуть свою линию “Plan – Do – Check – Act”.

Поэтому:

• Если у Заказчика внедрена проектная методология и она подходит для продукта – берите её;

• Если подходящей нет – берите методологию вендора (если такая есть), или свою (должна быть);

• Новая методология должна быть проста и понятна и её внедрение должно занимать минимальное время (до недели).

Как-то так.

Чёртов фикс-прайс. Как в гонке за низкую стоимость не остаться крайним

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

Нужно помнить о том, что почти все большие проекты формируют свой бюджет по принципу fix price (фиксированная цена). То есть, оценка бюджета, выполненная перед (!) проектом, фиксируется и потом не меняется. Теоретически, конечно, можно изменить стоимость проекта через механизм запросов на изменение, но реально сделать это будет очень сложно (часто практически невозможно).

Камни:

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

• Часто вообще стоимость фиксирует Заказчик до оценки проекта. При этом объём проекта тоже фиксируется и не всегда соответствует спущенному бюджету.

• Изменить стоимость проекта очень трудно, как уже говорилось выше, даже если меняется его объем (особенно в случае большого количества т.н. мелких изменений).

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

Что делать:

• Чётко балансировать объём проекта и его стоимость.

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

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

• Если вы видите, что цена значительно не соответствует объему проекта и изменить это невозможно, отказывайтесь от проекта. Иначе вашу компанию  ждут убытки (а иногда и разорение), а вас - увольнение.

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

Заключение для первой части

Предпроектные активности очень важны, и чем тщательней вы проведёте формирование объёма проекта, оценку его стоимости и сроков, тем успешнее будет сам проект.

Конечно, не всегда есть время на предпроект, а иногда руководитель проекта появляется только на старте проекта, когда уже все параметры его определены (объём, время и деньги), и часто на эти документы без слёз не глянешь. Это не безнадёжная ситуация, но выправлять её гораздо труднее. Об этом расскажу в следующих выпусках.

И имейте мужество отказаться от проектов с заниженным бюджетом. Даже если вы его не просчитывали, то с момента перехода управления к вам вся ответственность перейдёт опять же к вам. Быстро все остальные участники проекта со стороны Заказчика (а часто и с Вашей стороны) забудут о том, что Вы в предпроекте не участвовали. Будете «виноваты за всё». Не портите себе карму!

В следующем выпуске (если меня не изгонят из Хабра) я изложу своё видение по следующим вопросам:

• Как собрать команду.

• Вовлечение бизнес-заказчика.

• Коммуникации. Kick-off meeting.

To be continued