Создание новых продуктов может стоить очень дешево — час работы над лендингом и УТП и запуск MVP. Либо очень дорого, когда речь идет о крупных софтверных проектах (новая версия операционной системы для смартфонов, многопользовательская игра) с участием тысяч инженеров.
Но в обоих случаях организаторы проекта стремятся максимально эффективно предоставить ценность клиенту и удовлетворить его потребности. Как найти баланс между бюджетом проекта и «хотелками» клиента и с каким словом словом вероятнее всего столкнуться начинающие IT-шники?
В этой статье мы расскажем про итеративную разработку. Этот термин используется для описания подхода к разработке, при котором продукт улучшается поэтапно, учитывая обратную связь клиентов.
Что такое итеративная разработка
Как договариваться с заказчиком
Примеры итеративной разработки
Когда итеративная разработка не подходит
Что такое итеративная разработка
Слово итерация происходит от латинского iterum — снова и глагола iterare — “сделать снова, повторить”. В современном значении этот термин нередко является любимым у заказчиков, которые достаточно часто просят переделать. Но и в случае разработки собственного продукта зачастую предела совершенству нет.
Постоянный конфликт между желанием разработчиков закончить работу и сдать проект и нетехнических специалистов, которые достаточно часто хотят внести изменения в уже готовый продукт привел к появлению философии Agile. Одной из ценностей гибкой методологии является, что “готовность к изменениям важнее следования первоначальному плану”.
Один из оригинальных подписантов манифеста Agile разработчик Алистер Коберн определяет итеративную разработку как стратегию планирования доработок, в которой время выделяется на пересмотр и улучшение частей системы. Альтернативная стратегия — это планирование так, чтобы все было сделано правильно с первого раза.
Что такое жизненный цикл продукта
Он делает различие с инкрементальной стратегией — стратегия постановки и планирования, в которой различные части системы разрабатываются в разное время или с разной скоростью и интегрируются по мере завершения. Альтернативная стратегия пошаговой разработки — разработка всей системы с большой интеграцией в конце. При этом подчеркивается, что в разработке эффективнее всего будет применять оба подхода: искать баланс между инкрементальной и итеративной разработкой.
Как договариваться с заказчиком
Существуют две конкретные, специализированные стратегии доработки:
- Разработать систему как можно лучше, думая, что если она будет сделана достаточно хорошо, изменения будут относительно незначительными и могут быть быстро включены.
- Разработать наименьшее возможное количество перед отправкой на оценку, думая, что меньше работы будет потрачено впустую, когда поступит новая информация
Первая стратегия хороша для небольших проектов, если требования понятны и существует налаженный контакт с заказчиком. Например, художник имеет под рукой фотографию заказчика, который согласился не вносить множество правок, а просит сделать точную копию.
Второй подход поможет избежать недопониманий и дорогостоящих переделок.
Разбираем Wireframe «по косточкам»: что это такое?
В качестве примера можно привести работу над картиной. Так художник сначала рисует небольшой скетч, чтобы заказчик мог оценить направление работы. Затем, по итогам правок клиента, вносятся дополнительные изменения — на стадии скетча или прототипа внести изменения гораздо проще, чем в готовую картину. Собирая обратную связь заказчика по ходу работы над картиной художник создает финальный продукт.
Когда заказчик впервые сталкивается с итеративной разработкой, он может ожидать, что после каждой итерации получит полностью готовый продукт. Чтобы избежать недопонимания, важно сразу договориться о границах изменений и циклах обратной связи. Например, можно заранее определить, какие функциональности войдут в первую версию, какие задачи можно будет доработать в следующих итерациях, а какие изменения требуют отдельного обсуждения.
Не все идеи одинаково полезны: как тестировать продуктовые гипотезы
Также полезно объяснить заказчику, что итеративная разработка снижает риски, позволяя протестировать гипотезы на ранних этапах. Вместо того чтобы тратить месяцы на создание “идеального” продукта, который может не соответствовать реальным потребностям, команда разрабатывает MVP (минимально жизнеспособный продукт), получает обратную связь и постепенно улучшает его, основываясь на данных. Такой подход помогает экономить ресурсы и создавать действительно нужные пользователям решения.
Примеры итеративной разработки
Создание MVP — минимально жизнеспособного продукта является одним из примеров итеративной разработки.
Компания может выбрать разработку и выпуск минимально жизнеспособного продукта (MVP), потому что команда продукта хочет:
- Выпустить продукт на рынок как можно быстрее
- Протестировать идею на реальных пользователях до того, как выделять большой бюджет на полное развитие продукта
- Узнать, что находит отклик у целевой аудитории компании, а что нет
Проще говоря, такое мышление позволяет максимально подробно изучить рынок с минимальными инвестициями и сохранить средства на создание других, более успешных продуктов.
Деньги любят эксперименты: что такое MVP
Так, основатели сервиса бронирования Airbnb начали не с покупки зданий, а просто с собственной квартиры. Они хотели проверить идею бизнеса по краткосрочной аренде жилья без посредников (peer-to-peer). Для этого стартаперы создали минималистический вебсайт, опубликовали фотографии и другую информацию и нашли клиентов почти мгновенно.
Amazon Джефа Безоса начинался как книжный магазин, размещенный в гараже. Успех в продаже книг помог расширить бизнес до других продуктов, таких как электроника, одежда и обувь.
Всемирно известный Uber начинался даже без приложения. Гаррет Кэмп и Трэвис Каланик изначально запускали SMS-сервис для пользователей iPhone в Сан-Франциско под названием UberCab.
Примеры итеративных продуктов уходят и гораздо раньше в историю. Так еще в 1969 году сотрудник IBM и автор законов эволюции программного обеспечения Мэнни Леман рекомендовал такой подход для создания программ. По его словам, проектирование надо начинать с “первой исполнимой функциональной модели” (звучит как MVP (минимально жизнеспособный продукт). И даже Уинстон Ройс — автор легендарной модели каскадной разработки (Waterfall), которую часто противопоставляют Agile, выступал за создание пилотов и развитие итеративных методов.
Более того, итеративная модель применялась в 70-е годы XX века для очень крупных проектов. Так конкурент компания TRW использовала методику в работе над программным проектом стоимостью 100 миллионов долларов для управления баллистическими ракетами. Первая модель отслеживала один объект, а с выпуском пятой итерации несколькими годами позднее система была готова полностью. Итерации не были жестко ограничены по времени, и на первом этапе проектирования была проведена значительная работа по составлению спецификаций; разработчики вносили усовершенствования в каждую итерацию с учетом показателей предшествующей модели
Итерационная разработка используется в различных проектах по разработке программного обеспечения, включая:
- Веб-разработка: итерационная разработка часто используется в проектах по разработке веб-сайтов для быстрого и легкого внесения изменений в веб-сайт.
- Разработка мобильных приложений: итерационная разработка также часто используется в проектах по разработке мобильных приложений для быстрого и легкого обновления приложения.
- Разработка игр: итерационная разработка также используется в проектах по разработке игр для быстрого и легкого внесения изменений в игру.
Когда итеративная разработка не подходит
Итеративный подход отлично работает для быстрого тестирования идей и адаптации к меняющимся требованиям. Однако есть области, где он может быть неэффективным или даже рискованным. Например, в проектах с жесткими регуляторными требованиями, таких как разработка медицинского ПО, финансовые системы или авиационные технологии, каждая версия продукта должна соответствовать строгим стандартам и пройти сертификацию. В таких случаях изменения требуют длительных проверок, что делает быстрые итерации невозможными.
Еще один пример – проекты, где высока цена ошибки. В авиации или атомной энергетике недоработанный продукт может привести к катастрофическим последствиям, поэтому там чаще используется каскадная модель разработки (Waterfall) с тщательным планированием и тестированием на каждом этапе.
