Основные риски в разработке

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

1. Изъяны планирования
2. Изменение требований
3. Кадры
4. Нарушение спецификации
5. Интеграционные риски
6. Технологические риски
7. Низкая производительность и квалификация

Как видно из приведенного списка, только последняя группа так или иначе связана с реализаций проекта. Остальные четыре практически совсем не зависят от того, насколько усердно будет трудиться команда и какова ее компетентность, а лежат в области планирования. Это стоит учитывать при желании отказаться от менеджмента внутри команды или при попытке возложить всю ответственность за исполнение сроков и заявленного функционала на разработчиков, скорее всего у них это просто не получится. Принятие разумных мер в отношении этих неконтролируемых событий — суть управления риском, в котором должны принимать участие все заинтересованные в нем участники. Такие меры не освободят от возможности неудачи, но создадут резерв на случай, если некоторые из этих неопределенностей случатся.

Изъяны планирования

Первый главный риск появляется из-за полной или частичной несостоятельности процесса планирования бюджета времени и средств на разработку, интеграции, security scan, тестирование и т.д. Он является следствием неправильного определения размеров проекта, его сложности, отсутствия полной документации, что ведет к его недооценке и включению в план задач, вырванных из общей логики, которые впоследствии потребуют значительных доработок. Ошибка планирования — не только реальный риск, но и самый крупный из пяти главных групп рисков по степени влияния на расхождение плана проекта и реального исполнения. Можно с уверенностью утверждать, что при наличии обстоятельств, способствовавших наступлению такого события, первоначальная оценка размера проекта вырастет как минимум на 30%, увеличив сроки сдачи и стоимость разработки.

Изменение требований

Электронная торговля очень динамичная область, которая постоянно совершенствуется. Можно быть уверенным, что в процессе разработки возникнет огромное количество необходимых доработок или изменений запланированного функционала в соответствии с темпом развития рынка, активности конкурентов и собственными темпами технологического развития компании. С точки зрения проекта, эти изменения всегда являются раздуванием. Даже вырезание функционала или его части, которые были созданы — своего рода раздувание, поскольку требует дополнительной работы. Несмотря на то, что эту группу рисков можно нивелировать путем внедрения инкрементности поставок, приоритизации отдельных частей проекта и ранжирования подзадач в каждой из частей, сохранить проект в заданных границах по стоимости и срокам с желаемым функционалом не получится. Обычно из-за обозначенных причин проекты растут от 5% до 12% в месяц от общего заявленного объема.

Кадры

Разработчики - основной ресурс любого проекта в электронной торговле и один из главных источников рисков. Отталкиваясь от их количества, квалификации и вовлеченности в проект производится оценка объема предстоящих работ и осуществляется планирование задач. Бывает так, что люди покидают проект, болеют, уходят в отпуск и т.д. По причине того, что в момент совершения оценки, время старта проекта обычно имеет плавающие значение, перечисленные выше нюансы не рассматривается в процессе оценки. Ограниченность этого ресурса приводит к срывам сроков реализации проекта, поэтому к моменту старта проекта крайне важно предусмотреть некий буфер по срокам сдачи, либо озаботиться расширением команды для сдерживания риска, если срок сдачи проекта не может быть сдвинут. Расширение команды достаточно трудоемкий процесс, затраты на который можно минимизировать в случае наличия «свободных» разработчиков, но и в этом случае потребуется значительное время на «вхождение» в проект и достижение должного уровня производительности. В среднем, по нашему опыту, «адаптация» новичков в существующем проекте занимает от 0,5 до 1,5 месяцев в зависимости от сложности проекта. Также совершенно очевидно, что участники проекта не смогут все своё время тратить на работу над проектом в силу объективных причин и, скорее всего, полезный коэффициент их рабочего времени составит 0.8 - 0.9, но никак не больше.

Нарушение утвержденной спецификаций

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

Интеграционные риски

Ecommerce проекты подразумевают непрерывный обмен данными с различными информационными системами. Наличие различных неопределенностей в процессе построения интеграций существуют практически в любом проекте, поскольку подразумевает встраивание решения в уже существующую инфраструктуру. Реализация обменов данными с ERP, CRM, PIM, WMS, Мультиканальными приложениями часто подразумевают внесения изменений в обе интегрируемые системы. С организационной и технической точек зрения такие работы находятся на границе ответственности участников проекта и требуют значительных организационных усилий для избежания рисков.

Технологические риски

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

Низкая производительность и квалификация

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