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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итого

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