Agile или Waterfall: методологии разработки в проектах e-commerce

Многие ритейлеры сейчас находятся в процессе внедрения инновационных технологий, кто-то уже благополучно завершил по запуску интернет-каналов торговли, кто-то только начинает этот путь, а кто-то модернизирует свои бизнес-процессы. При этом вопрос выбора методологии по-прежнему остается актуальным, а ее значимость – недооцененной. Часто выбор делает компания-подрядчик, но как понять, какая именно подходит ритейлеру?
Рассказывает Наталья Петухова, известный эксперт в области электронной коммерции и практикующий бизнес-тренер.

Итак, выбираем: гибкая методология разработки Agile или классическая последовательная модель Waterfall?

Плюсы и минусы каждого из подходов понятны, в открытом доступе много как отечественной, так и зарубежной аналитики. Однако, выбирая методологию для реализации проектов по электронной коммерции, я столкнулась с тем, что даже с учетом многочисленных исследований выбор не так очевиден. Предлагаю прикладное исследование по выбору методологии для создания интернет-магазина.
Позитивные стороны Agile применительно в разработке eCommerce проекта видятся мне следующим образом:
– возможность быстро приступить к разработке, ограничившись функциональными требований и бизнес-моделью, разрабатывая техтребования уже в ходе проекта;
– возможность оперативной корректировки требований, особенно если объем автоматизации функций и интеграции магазина с внутренними системами планируется определить в ходе первых итераций.

А вот минусы и риски данного подхода не ограничиваются пролонгированными сроками и непрогнозируемым бюджетом из-за растущих требований заказчика. В случае с электронной коммерцией, в частности, проектом запуска интернет-магазина, два вышеперечисленных фактора уже выглядят довольно пугающе.
Во-первых, проект коммерческий, – к нему может быть привязан бизнес-план торговой организации в целом, срыв сроков с выходом за рамки планового бюджета может оказать негативное влияние на коммерческую деятельность предприятия.
Такого не происходит в экспериментальных проектах ИТ-компаний. Например, в проекте по разработке продукта, который планируется вывести на рынок, отклонение в 6–8 месяцев не критично, при увеличении проработки вопроса и итоговом повышении качества продукта при Agile.
Во-вторых, Agile предполагает командную работу компании-разработчика и заказчика, а это ведет к существенному отвлечению ключевых сотрудников от их непосредственных обязанностей. Многие руководители пренебрегают учетом таких затрат, вдохновленные будущим успехом открытия нового канала продаж – интернет-магазина, однако этот показатель, при детальном рассмотрении, может качественно поменять финансовую картину проекта.
В-третьих, команда не всегда оказывается эффективной: не имея опыта формулирования требований и работы в условиях множественных приоритетов, заказчики не могут предоставить разработчикам системной информации, а разработчик эффективно закрыть итерацию. Распределение рисков в такой ситуации не в пользу заказчика. Если у исполнителя подписан акт на выполнение ряда предыдущих итераций, то срыв проекта для исполнителя, – это риск потери небольшой суммы. Для заказчика же риски качественно выше: финансовые убытки, опережение конкурентами по выпуску инновации из-за пролонгации сроков, если проект характера ноу-хау.

Да, многие внедряют по популярному сегодня Agile, а у кого этот выбор был осознанным?

В случае с методикой Waterfall этих рисков можно избежать, что является существенным плюсом.
Проект имеет фиксированные сроки и бюджет. При внедрении электронного канала продаж используется солидная методологическая база, создать магазин, который не сможет функционировать, или допустить критические ошибки, – довольно сложно, даже при наличии какой-либо отраслевой специфики.
Проект не предполагает активной вербальной коммуникации. Основная коммуникация ведется по статусу проекта. Основные ресурсы компании не будут отвлечены от бизнес-приоритетов, т.к. оперативное управление ведет менеджер проекта.
Конечный результат известен на этапе старта проекта. Даже если выяснится, что для получения результата, требуемый объем работ может быть превышен, риск финансовых и временных потерь управляем
Минусы каскадной модели – низкая оперативность внесения изменений.
На данном этапе анализирую, как найти максимальное совмещение методик для проектов электронной коммерции. Итерационная модель, когда каждый из этапов методологически идет как отдельный проект, видится мне наиболее оптимальной. Однако об этом я напишу в другой раз.