Подводные камни проектов. Записки менеджера
Практически все проекты (настоящие, соответствующие классическому определению, когда в условиях временных и ресурсных ограничений создаётся уникальный результат) сложны и требуют серьёзного напряжения сил проектной команды для успешного их завершения. Причём сложность проектов проявляется не только в техническом и методологическом аспектах, но и в психологическом. По умолчанию положительный результат проекта ни разу не гарантирован, и не каждый готов взвалить на себя эту ношу.
Больше всего достаётся менеджерам проектов. Ведь они отвечают за результат проекта и, в глазах стейкхолдеров, да и остальных участников проекта виноваты во всём негативном, что на их проектах происходит.
Чтобы не выгореть на первых проектах, нужно не только изучать проектный и продуктовый менеджмент, предметные области и т. д., но и изучать опыт других проектных менеджеров, чтобы хотя бы части «шишек» и «синяков» избежать.
Я тоже хотел бы поделиться опытом управления проектами. В ходе своей практической деятельности я был руководителем более 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
