Почему модель «MVP + развитие» лучше, чем классическая водопадная

Водопадная модель разработки проектов возникла больше полувека назад и успела показать свою эффективность. Правда, со временем стало ясно, что этот метод работает не для всех сфер и, тем более, не подходит для малобюджетных проектов. Мы в «5 УГЛОВ» считаем, что при разработке любого цифрового проекта нужно тесное взаимодействие с заказчиком, а также тестирование разных идей, поэтому часто выбираем модель «MVP + развитие».

Водопадная (каскадная) модель: делаем все целиком и полностью

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

Пройдемся по конкретным минусам модели:

1. Нет никакой гибкости. Модель неудобна тем, что невозможно все продумать до мельчайших подробностей с самого начала. Все проблемы могут «расцвести» только в конце проекта. Тогда придется все начинать заново, а заказчику оплачивать дополнительные часы разработки.
2. Заказчик участвует в проекте только на уровне согласования, например, дизайна.
3. Так как проект не тестируется на реальных пользователях, то по окончании разработки продукт может не соответствовать требованиям потребителя.
4. Вероятно, будут конфликтные ситуации, когда заказчик хочет получить больше за меньшие деньги, а подрядчик хочет сделать меньше, чтобы получить запланированную прибыль.

Плюсы «водопада»:

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

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

Наш выбор — «MVP + развитие»

Сначала введем в курс дела и расскажем, что такое MVP. Возможно, вы могли слышать термин, если изучали тему стартапов. MVP или Minimum Viable Product — это минимально-жизнеспособный продукт, который позволяет во-первых, проверить работу гипотез на пользователях, а во-вторых, исследовать целевую аудиторию запущенного продукта. MVP пришел из концепций Lean Startup и Customer Development.

Для понимания можно использовать аналогию еды (все ведь такое любят:). Представим бургер, который состоит из двух булочек и котлеты. Съедобно? В целом — да. Но не хватает соусов, листика салата, огурчиков-помидорчиков.

Так и мы, когда создаем MVP, дальше продолжаем с ним работать в формате спринтов и развиваем. Добавляем те самые ингредиенты, которые по итогу дадут вкусный результат.

Если говорить про сайты, то даже имея MVP сайта, уже можно наполнить его контентом и рассказать о продукте, дать форму для контактов и предложить выйти на взаимодействие с менеджерами.

Плюсы подхода:

1. Слона едим по частям. Весь проект разбиваем на кучу маленьких спринтов и проверяем множество гипотез.
2. Изменения можно внести на любом этапе и ничего не посыпется.
3. Продукт может тестироваться на ранних этапах, причем самими же пользователями.
4. Клиент, который представляет услуги или товары на создаваемом сайте, уже может начать продавать.
5. Команда меньше устает за счет постоянной демонстрации конечного небольшого понятного результата.
   

Минусы подхода:

1. Невозможно точно предсказать, сколько денег в итоге уйдет на проект. Развитие может быть бесконечным, но в рамках оговоренных ежемесячных трат.
2. Можно увлечься в доработках и не прийти к какой-то конечной точке при разработке, все время откладывая релиз продукта.

Мы придерживаемся мнения, что проще через пару месяцев получить начальную, но рабочую версию продукта, чем через 8 получить классный проект, но который уже никому не нужен. За это время бизнес уже мог закрыться, владелец обанкротиться, ведь сайт не был готов и, соответственно, продажи не шли или шли плохо. Если бы выбрали подход «MVP+развитие», то за этот период можно было протестировать 20 различных гипотез.

Выводы напрашиваются сами

Не будем совсем принижать водопадную модель, она подходит в следующих случаях:

1. Заказчик знает, что он хочет получить в самом конце.
2. Заказчику известны все сроки и решения, которые будут приняты на каждом этапе.
3. Команде заранее известно, какими инструментами они будут пользоваться в процессе разработки.
4. У клиента нет желания постоянно взаимодействовать с командой, согласен только в редких случаях.
5. Проект долгий, сложный и дорогостоящий.

В остальных случаях больше подходит концепция «MVP + развитие», особенно, если это молодой бизнес (стартап), на начальных этапах которого необходимо проверять заинтересованность пользователей и клиентов.