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

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

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

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

Это важно учитывать, особенно если возникает соблазн отказаться от менеджмента внутри команды или возложить всю ответственность за сроки и результат на разработчиков. Скорее всего, им просто не удастся справиться со всеми вызовами в одиночку.

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

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

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

Как правило, такой риск возникает из-за неправильной оценки масштаба и сложности проекта, отсутствия полной документации и некорректной детализации задач. В результате в план попадают разрозненные и не стыкующиеся между собой блоки, которые позже потребуют значительной переработки.

Если такие ошибки допустили, можно с уверенностью ожидать, что изначальная оценка проекта возрастёт как минимум на 30% и по срокам, и по бюджету.

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

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

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

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

Кадровые риски

Разработчики — ключевой ресурс любого проекта в электронной торговле и одновременно один из главных источников риска. Именно от их количества, квалификации и вовлечённости зависит оценка объёма работ и планирование задач.

На практике всё далеко от идеала: сотрудники могут покинуть проект, заболеть или уйти в отпуск. Поскольку старт проекта часто откладывается или переносится, эти нюансы редко учитываются на этапе первоначальной оценки, что впоследствии приводит к сдвигам сроков.

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

По нашему опыту, полноценное включение нового участника в существующий проект занимает от двух до шести недель, в зависимости от его сложности. При этом важно помнить, что никто из команды не может работать над проектом 100% времени: объективные ограничения снижают полезный коэффициент занятости до 0,8-0,9.

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

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

Исправление таких ошибок требует значительных ресурсов, времени и, в некоторых случаях, перезапуска проекта.

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

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

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

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

С технической и организационной точек зрения интеграционные задачи находятся на границе зон ответственности разных участников проекта. И именно поэтому они особенно уязвимы: любое несогласование может привести к задержкам или сбоям.

Для снижения рисков необходима высокая степень готовности к координации, прозрачные процессы взаимодействия и оперативное принятие решений со стороны всех вовлечённых сторон.

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

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

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

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

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

Эффективность разработки напрямую зависит от квалификации и производительности команды. В целом, уровень команды можно оценить ещё до старта проекта, особенно если она уже работала вместе. Однако индивидуальная производительность разработчиков — величина гораздо менее предсказуемая.

Она может меняться в процессе работы и зависит от множества факторов: от сложности конкретных задач до личной мотивации и временных ограничений.

Если на проекте работает слаженная и сбалансированная команда, такие риски, как правило, компенсируются. Более того, по мере устранения других рисков — организационных, интеграционных, планировочных — негативное влияние индивидуальных различий обычно снижается само по себе.