5 факторов риска на проектах: не очень приятно, но всё решаемо
Попросили наших проджект-менеджеров рассказать о рисковых аспектах на проектах. Почему они неприятны как для клиента, так и для управленца и как реагировать на них – в нашем сегодняшнем посте.

➡️ Фиксовый проект
Если стоимость проекта определена «раз и навсегда», а рынок потребует изменений уже по ходу проекта, внести их будет проблематично. При отсутствии гибкости и возможности воздействовать на продукт по факту можно получить то, что уже устарело.
Кажется, что «фикса» – это более предсказуемая модель работы, но на самом деле здесь большой риск несоответствия оценки и результата. Мы недавно рассказывали, как клиент недостаточно проинформировал команду на этапе аналитики и возникла необходимость непрерывной актуализации ТЗ. Это страшно и для клиента, и для PM, так как ограничения будут мешать развитию продукта.
Мы следуем правилу: обозначить риски сразу и «взвесить» другие подходящие модели работы, например, Time&Material с поэтапным планированием (по 2–4 недели).

➡️ Не согласованы критерии приёмки
Бывает так, что ожидания от «готового продукта» у клиента и команды разные. Например, в ТЗ допущены неточности, или имеются пункты, которые можно двояко истолковать. Соответственно, заказчик может планировать реализацию функционала, о котором команда даже не догадывается. Уже в финале проекта или итерации могут возникнуть серьезные противоречия и, как результат, не соответствующий ожиданиям продукт. Чтобы этого избежать, с клиентом до старта разработки должны быть согласованы тест-кейсы или чек-листы приёмки, при необходимости они могут быть дополнены пользовательскими инструкциями.

➡️ Команда из джунов – не хватает экспертизы
Всех в отрасли затрагивает дефицит кадров, но не всякая задача требует постоянного внимания сеньора. Как найти баланс? Один из примеров в нашей практике – это работа архитектурного комитета. В него входят специалисты с богатым опытом коммерческой разработки и даже с учёными степенями. Они формируют решение на старте, а также курируют разработку программного обеспечения – выполняют роль «ревьюерного органа». Таким образом удаётся грамотно распределять ресурсы: не подключать к элементарным моментам сеньоров, при этом процесс остаётся под присмотром.

➡️ Клиент, не заинтересованный в проекте и не включённый в процесс разработки
«Обязанность» клиента – согласовывать проектные артефакты самому или делегировать эту задачу. Иначе есть риски: не тот результат, что нужен, и конфликты. На митинге по целям перед стартом проекта важно обсудить такие моменты: например, при долгом отсутствии апрува, проект придется приостановить. А это деньги – придётся собирать команду заново и тратить время на погружение специалистов. Обсуждая «на берегу» риски и связанные с ними расходы, как правило, команда быстрее находит взаимопонимание с клиентом.

➡️ Немотивированная команда
Если разработчик не хотел подключаться к проекту, он будет работать через внутреннее сопротивление и показывать не лучшие результаты. При подборе команды важно учитывать этот момент и поискать альтернативу. Чтобы поддерживать мотивацию уже в ходе проекта, некоторые наши ПМ организуют посиделки онлайн или офлайн, где команда может поболтать о чём-то своём, высказаться.
Также мы просим клиента в случае разногласий обсуждать их с ПМ, аккаунтом – не распространять на всю команду сразу. Во-первых, проблема может затрагивать одного человека, а остальных это просто демотивирует. Во-вторых, с разработчиками надо общаться нежно, они люди чувствительные 💙 А вот управленцы готовы к негативу, подойдут к ситуации с холодным умом и примут взвешенное решение.
А вообще подрядчика, конечно, лучше выбирать с устоявшейся корпоративной культурой, чтобы на клиенте этот фактор никак не сказывался, а всё решалось внутри компании (не на правах рекламы 🙂).