Не очевидные риски, которые нужно учесть при старте любого проекта

Есть стандартные риски в проектной работе: срыв сроков, выход за рамки бюджета и пр. Но что если я вам скажу что есть риски, которые почти никто не учитывает, но которые очень часто возникают при ведении крупных проектов (когда функционал реализует не одна команда в 5 чел, а задействованы десятки людей в разных направлениях).

Риск №1 - Отпуска

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

- если отпуск у заказчика: узнайте заранее кому он делегирует проект и заранее подключите этого человека (чтобы в отпуск он был вам полезен, а не говорил "давайте я уточню")

- если отпуск у IT: узнайте, заменимы ли те люди, кто вам делает каждый этап дизайн/аналитику/разработку/тест, если нет, постарайтесь заранее договориться, что может делать ваш проект будет кто-то другой? а не Вася, который через 2 недели уходит в отпуск

Риск 2 - Приоритетность в бэклоге

Речь идем о том, что если разработку делает не ваша команда, бэклогом которой вы сами управляете, а кто-то сторонний, то нужно узнать:

- после того как вы им принесете готовое ТЗ, через сколько они смогут стартовать? Например, это подрядчик, у которого ограниченное кол-во людей/мощностей, и сейчас они делают проект для др. кампании. Тогда вам нужно понимание, когда они освобождаются под ваш проект - в реальности это дата и будет стартом it-части, а та дата, когда вы на своей стороне были готовы (например согласовали ТЗ, бюджет и пр.)

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

Риск 3 - Обучение / Информирование пользователей

Когда вы выкатываете что-то в бой, нужно подумать со всех сторон про то - кто будет пользоваться тем, что вы поставили. Иногда даже нужно запланировать эти активность в скоупе работ по проекту. Для всех проектов это будет разная активность, ниже несколько примеров. Риск в том, что для информирования клиентов нужен доп.бюджет / доп.сроки, иначе клиенты даже могут не узнать об этой фиче. А для информирования пользователей (например сотрудников), нужно выделять ресурсы для обучения, правки методологии и пр., иначе может получится так, что вы выкатили что-то, а пользоваться этим никто не может / не знает / не умеет.

Информирование пользователей / клиентов:
- внедрение онлайн сервисов: в зависимости от сложности внедрения можно завесить фразу в AppStore/Google Play / вывести всплывающую плашку на сайте что у нас теперь есть такой-то раздел или кнопка / завести сторис / прислать email / прислать пуши и пр. или сделать погашовую инструкцию - обучить клиента как этим пользоваться / рассказать что это такое. Если внедряется что-то для пользователей (не клиентов), например доработки внутренней CRM, то нужно заранее готовить обучающие материалы, планировать обучения, проводить демо / править действующие инструкции и пр. чтобы к дате внедрения все были готовы.
- внедрение оффлайн сервиса: для клиентов можно использовать любой канал информирования пуш / смс / email / звонок / личное информирование когда клиент пришел. Сотрудников так же нужно обучать, давать инструкции, это тоже время и деньги.
Информирование тех, кто общается с пользователями (поддержка / горячая линия)
- внедрение онлайн сервисов: важно сообщить поддержке что такой сервис появился (речь про клиентскую поддержку, а не тех.поддержку), желательно вести какую-либо методичку, где со скринами и пошагово будет описано как и что работает. Если такое есть - то достаточно будет скинуть оповещение что фича в проде
- внедрение оффлайн сервисов: тут кроме непосредственного обучения может понадобиться отрисовка процесса / мини-инструкция, где так же пошагово будет описан сервис, чтобы когда пользователь объясняет что пошло не так, поддержка могла понять про что вообще речь.

Резюмируя: рисков в проектной работе может быть огромное количество, не забывайте что вы делаете проект не в вакууме идеального мира, все всегда может пойти не так. Старайтесь заранее подойти критично к каждому этапу проекта и тогда вы сможете перекрыть бОльшее количество рисков, и успешнее внедрить проект.