Любой проект, даже на первый взгляд прозрачный и простой, имеет шанс провалиться. Из-за небольшой детали. Команда может не замечать этой детали до конца проекта и сорвать сроки. Задача руководителя проекта – способствовать выявлению возможных рисков еще на этапе планирования проекта, а также умение анализировать ошибки прошлых проектов и находить способы избежать их в дальнейшем.
Выявление рисков происходит в ходе обсуждения проекта и построения сценариев. Регулярные мозговые штурмы и постоянные вопросы «А что, если…» и их обсуждение командой способны выявить слабые места в вашем проекте. И теперь, когда вы имеете список возможных проблем, важно его правильно классифицировать и расставить приоритеты. Проще всего это сделать, присваивая каждому конкретному пункту оценку по двум параметрам:
-
Вероятность возникновения;
-
Угроза проекту/срокам.
Чем больше суммарных баллов наберет угроза, тем больше внимания и мониторинга в течение проекта ей стоит уделять. Незначительные риски с мизерной вероятностью возникновения и с незначительным влиянием на проект, наоборот, не стоит принимать во внимание, так как они могут отнять много ценного времени.
Пример — риск того, что разрабатываемая система может дать сбой при одновременной оплате одного и того же товара в интернет-магазине с десятью тысячами наименований. Учитывая невысокую посещаемость проекта, оцениваем вероятность возникновения как низкую. Насколько опасны последствия? Не опасны, в случае чего проблему сможет вручную разрешить администратор интернет-магазина. Таким образом, получаем риск с наименьшим приоритетом и кладем его в черный ящик, так как стоимость реализации решения, которое сможет предотвратить эту ситуацию, несоразмерно велика по отношению к серьезности/вероятности риска.
Не стоит обсуждать с заказчиком весь спектр выявленных рисков. Высоки шансы просто испугать заказчика, ведь он подумает, что его проект практически полностью состоит из ошибок и недочетов, заставит его сомневаться в целесообразности траты средств на разработку продукта. Тем не менее, имеет смысл привлечь заказчика к самому процессу выявления рисков, ведь он хорошо знает свой бизнес.
Важно, чтобы список наиболее опасных уязвимых мест проекта был на виду у всей команды, а не в виде надорванного листочка блокнота на столе технического директора или записи в excel-файлике где-то на компьютере руководителя проекта. Такой подход позволяет в прямом смысле видеть возможные проблемы, держать себя в тонусе, руководствоваться не домыслами, а конкретными рисками.
Без сомнений, невозможно предусмотреть все, и пройти в обход граблей вам не удастся. Поэтому по завершении проекта необходимо вынести список проблем на ретроспективу и проанализировать причины их возникновения. И тогда проблемы прошлого проекта могут перейти в стадию «рисков» для новых.