Подводные камни проектов. Записки менеджера

от автора

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

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

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

Я тоже хотел бы поделиться опытом управления проектами. В ходе своей практической деятельности я был руководителем более 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


ссылка на оригинал статьи https://habr.com/ru/articles/849128/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *