Как разрабатывать продукты итерациями и зачем это нужно

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

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

1. Разбивать работу над продуктом на несколько этапов и подэтапов, чтобы быстро адаптироваться к изменяющимся требованиям рынка и потребностям заказчиков.
2. Искать и внедрять решения, которые закрывают настоящие боли пользователей и на которые у рынка есть запрос.
3. Минимизировать риски и потери бизнеса.

С помощью работы итерациями продукт можно постоянно улучшать в соответствии с реальными потребностями рынка. Не нужно писать одно общее техническое задание на проект на полгода вперёд и сразу пытаться строить космолёт.

Инструменты и подходы итерационного развития

1. HADI-циклы. Это методология Agile для проверки гипотез. HADI-циклы предполагают разбивку итерации на 4 этапа: формулирование гипотезы, её проверку, сбор данных, анализ и выводы. На основе полученных данных формулируют новую гипотезу, снова её проверяют и так по кругу. Подход позволяет понять, насколько эффективно и ценно то, что компания предлагает рынку, а также улучшать продукт постепенно.

Про HADI-циклы мы подробно рассказывали в другой нашей статье. 

2. Scrum — это фреймворк управления проектами, основанный на принципах Agile. В Scrum работу разбивают на короткие циклы — спринты. Каждый спринт длится от одной до четырёх недель и завершается демонстрацией результатов заказчикам. В Scrum много проектных ритуалов: планирование, приоритизация бэклога, дейли — короткие встречи на 15 минут, на которой команда обсуждает прогресс по задачам, а также ретро — сессия, на которой команда анализирует свою работу в спринте.

3. Lean startup — это методика создания и развития бизнеса, основанная на постоянном тестировании гипотез. Lean-подход состоит из трёх этапов: создание и запуск MVP, измерение его влияния на ключевые метрики и формирование выводов на основе обратной связи от пользователей. На каждом этапе команда получает новые знания о своём продукте, клиентах и рынке, и использует их для улучшения или изменения своей стратегии.

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

Когда подойдёт итеративный подход

• У вас есть идея продукта, но нет чёткого понимания, как он должен работать и выглядеть.
• У вас есть существующий продукт, но вы хотите добавить новые функции или улучшить его качество и производительность.
• Вы хотите проверить гипотезы о потребностях и предпочтениях вашей целевой аудитории или выйти на новую.
• Вы хотите получить обратную связь от реальных пользователей и клиентов о вашем продукте.
• Вы хотите сократить время и стоимость разработки продукта.
• У вас большой сложный high-load сервис, где невозможно быстро разработать функцию, зарелизить её и тут же откатить назад, если что-то пошло не по плану.

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

Плюсы итеративного развития продуктов

1. Быстрый выход на рынок с минимально жизнеспособным продуктом (MVP), который можно проверить на реальной аудитории и получить обратную связь.
2. Гибкость и адаптивность к изменяющимся требованиям и потребностям пользователей, а также к новым технологиям и конкурентам.
3. Повышение качества продукта за счёт постоянного устранения ошибок и разработки функциональности на основе данных и метрик.
4. Снижение рисков и издержек за счет разбиения большого проекта на маленькие итерации, которые легче контролировать и оценивать.

Минусы итеративного развития

1. Сложность управления проектами и командами. Итеративный подход требует от подрядчика знания гибких методологий и их инструментов, умения разбивать большие задачи на маленькие, приоритезировать их и ставить исполнителям.
2. Неопределенность сроков и бюджета. Гибкость в планировании и разработке проекта может приводить к неясности по поводу сроков его завершения и бюджета. Это может вызывать проблемы с контрактами, финансированием или ожиданиями заказчиков. 

Как работаем мы

В проектах по запуску MVP мы работаем по waterfall-модели. Разработка продукта проходит последовательно по этапам: анализ требований, проектирование, разработка, тестирование, запуск и поддержка. Но мы на старте формулируем гипотезу о структуре сервиса и выделяем функциональность, которая предположительно нужна пользователям и бизнесу — это часть методики Lean Startup. Дальше мы запускаем продукт и замеряем метрики, за которыми договорились следить. Получаем первые результаты и на их основе планируем работу дальше.

После запуска MVP мы вступаем в стадию развития и поддержки сервиса. Здесь меняется методология разработки и инструменты — мы строим всё по Scrum с соответствующими проектными ритуалами. Релизы двигаются по такому циклу: 

1. У нас есть бэклог с задачами, которые остались с этапа проектирования, но не вошли в MVP. Этот скоп работ дополняется после запуска MVP и получения первого отклика от пользователей. 
2. Все задачи в бэклоге приоритезируем, чтобы понять, что брать в работу первым.
3. Планируем работу на 2-3 спринта вперёд, чтобы у продакшн-команды всегда были задачи, если фидбэк от заказчика задерживается или случаются другие форс-мажоры. Во время планирования спринтов мы продумываем, как новые доработки повлияют на бизнес-цели заказчика и как будем измерять эффект.
4. Разрабатываем, тестируем, внедряем и смотрим, что получилось. И так по кругу.

Во время планирования спринта мы учитываем вводные данные: 

1. какие у нас есть условия и ограничения;
2. как работа будет проходить по документам;
3. как согласовывать работу с отделами безопасности и IT заказчика;
4. как новое решение будет влиять на пользовательское поведение внутри продукта. 

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

Итого

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