Что важно не забыть при планировании проекта

Процесс разработки. Сюда относится и пресловутый Waterfall / Agile и дополнительные требования по документированию, например. У каждого процесса есть особенности в планировании, но план нужен всегда. Встречал мнение, что "а зачем нам план, у нас Agile". Мнение достаточно популярное, но, на мой взгляд, в корне неверное. План нужен всегда, чтобы мы могли управлять ожиданиями заказчика, команды, и вообще понимали куда мы идем. И при планировании важно "прокрутить" в голове как проект будет делаться в реальности, возникают ли какие-то дополнительные отвлечения команды на какие-то процессные активности (банально, как мы планируем отчитываться клиенту о результатах, кто проводит демо), есть ли какие-то неочевидные зависимости и т. д.

Саму поставку. Что является результатом проекта? Правильно (и полно) ли мы понимаем требования к конечному результату проекта? Сюда входит как скоуп продукта, который мы разрабатываем, так и скоуп проекта. Если с первым всё обычно более-менее понятно, то про второй забываем. Простой пример: разрабатывая мобильное приложение должны ли мы будем отправлять его в сторы, или завершаем проект на моменте приемки клиентом через TestFlight? Ну и если говорим про скоуп- сразу надо понимать как будем управлять изменениями, насколько они вероятны (100% вероятны, вопрос в предполагаемом объеме), понимает ли это клиент.

Качество оценки. Тут бывает оооочень много разночтений с техническими специалистами, начиная от значит ли оценка в 8 часов - это рабочий день, или это чистые часы при планируемых рабочих в день - 6? А с учетом какого уровня специалиста сделана оценка (чаще делают "под себя")? А эксперт достаточно погрузился в задачу и достаточно подробно (на необходимо достаточном уровне) декомпозировал задачу, чтобы её адекватно оценить, или просто оценка состоит из 10 пунктов по 160 человеко-часов? Ещё важно не забывать, что бывают пессимистичные и оптимистичные оценки, и тут оценка по PERT обычно помогает.

График проекта. Чаще всего мы не можем просто взять оценку от команды, разделить его на планируемое количество людей в команде и накидать график. Обычно проект стартует с маленькой командой, после добавляются люди, после часть людей выводится из проекта первыми (такое нормальное распределение людей в проекте от этапа проекта). Поэтому очень важно при построении графика хорошо вникнуть в специфику задач, понять что надо делать в первую очередь, что позволит в дальнейшем распараллелить работу (и добавить новых людей), кто это будет делать и т. д. В наше нелегкое время постоянного дефицита кадров добавляется ещё вопрос возможности своевременного добавления людей (здесь тоже могут быть задержки и соответствующие риски нужно учитывать), а если даже и добавим вовремя - не забываем время на онбординг и опять же риск "не своего" человека. И на фоне всего этого думаем о том как всё же план можно оптимизировать (клиенты очень не любят длительные проекты, Time-to-Market как никогда сейчас важен).

Бюджет проекта. Часто при оценке проекта стараются на чем-то сэкономить, чтобы показать конкурентную цену и получить проект. И это правильно, рынок есть рынок. Иногда оптимизация более чем оправданна, например, когда не пытаемся делать проект одними сеньорами, а планируем сбалансированную команду. Но иногда мы стреляем себе в ногу при этом и экономим даже на том, на чем клиент никогда и не хотел бы экономить, а при сдаче проекта, когда это вскрывается - получаем испорченные отношения с клиентом, тщетные попытки выправить ситуацию за счет маржи и т. д. Намного лучше работает прозрачный диалог с клиентом на старте, когда показываем, сколько такой проект может выйти, если делать "по фен-шую", и на чем можно сэкономить, вместе с клиентом "отщипывая" лишнее и договариваясь об этом на берегу. Что это может быть? Уровень детализации ТЗ и дизайнов, объем (и качество) тестирование (т. е. на сколько клиент может быть лоялен к некоторым пропущенным в прод багам), покрытие автотестами, кол-во часов руководителя проектов (какие отчеты строим, что делаем) и т. п.

Стейкхолдеры. Мы точно понимаем кто спонсор проекта, кто его пользователи, кто любые другие заинтересованные в проекте люди, которые в итоге могут повлиять на ход проекта? Бывает так, что начинаем проект с одними, а потом приходит другой человек и начинает "принимать" проект. Очень неприятная ситуация :) Или вдруг на последнем demo проекта появляется пользователь, который оказывается очень важным и влиятельным. Надо постараться по максимуму узнать всех стейкхолдеров проекта и держать их в курсе хода проекта, получать от них необходимые согласования (даже если они не всего горят желанием вовлекаться). Для этого на старте важноописать всех стейхолдеров и построить план коммуникаций с ними (когда какие отчеты и встречи, какие решения кто принимает и т.д.).

Риски. Last but not least. Именно хорошо проработанный на старте и согласованный с клиентом реестр рисков и допущений позволит выполнить проект максимально гладко. Всегда что-то случается, но если на старте принимают меры по минимизации вероятности события/ущерба, или, когда всё же случается, заказчик к этому готов и есть план действий - значит у руководителя проекта всё схвачено и проект управляем. Если же постоянно возникают какие-то "неожиданности" и что делать не ясно, как это влияет на проект не ясно, сроки постоянно едут, клиент постоянно слышит о всё новых и новых проблемах - тут хороших отношений с заказчиком (и в проекте) и успешного завершения проекта ждать не приходится.