Глава 8

Разработка продукта

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

Книга Эрика Райса The Lean Startup (Райс, 2011) вызвала всплеск интереса к облегченным подходам к изучению новых бизнес-моделей и продуктовых идей в условиях неопределенности. Работа Райса представляет собой синтез идей бережливого движения, дизайн-мышления и работы предпринимателя Стива Бланка (Бланк, 2013), который подчеркивает важность принятия экспериментального подхода к разработке продукта. Этот подход, основанный на наших исследованиях, включает в себя создание и проверку прототипов с самого начала, работу небольшими партиями, а также изменение или «поворот» продуктов и вслед за ними бизнес-моделей на ранней стадии и достаточно часто.

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

Методы разработки бережливого продукта

Мы рассмотрели четыре возможности, которые составляют нашу модель бережливого подхода к разработке продукта (см. также рис. 8.1).

1. Степень, с которой команды разделяют продукты и функции на небольшие партии, которые могут быть завершены менее чем за неделю и выпущены частыми релизами, включая использование минимально жизнеспособных продуктов (MVP — minimum viable product).
2. Есть ли у команд хорошее понимание всего потока работы от бизнеса до клиентов и есть ли у них прозрачность в этом потоке, включая статус продуктов и функций.
3. Занимаются ли организации активным и регулярным поиском обратной связи от клиентов и включают ли они эту обратную связь в разработку своих продуктов.
4. Есть ли у группы разработчиков полномочия создавать и изменять спецификации в рамках процесса разработки без необходимости утверждения.

Анализ показал, что эти факторы статистически значимы при прогнозировании более высокой эффективности доставки программного обеспечения и организационной эффективности, а также повышения организационной культуры и снижения выгорания.

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

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

Командные эксперименты

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

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

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

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

Эффективный продукт-менеджмент повышает эффективность

Мы вели анализ возможностей бережливого управления продуктами в течение двух лет, начиная с 2016–2017 годов. В нашей первой модели мы увидели, что методы бережливого управления продуктами положительно влияют на эффективность доставки программного обеспечения, стимулируют производительную культуру и уменьшают выгорание.

В следующем году мы перевернули модель и подтвердили, что эффективность доставки программного обеспечения определяет методы бережливого управления продуктом. Улучшение возможностей доставки ПО позволяет работать небольшими партиями и проводить исследования пользовательского мнения, что приводит к созданию лучших продуктов. Если мы объединяем модели, это становится обоюдной моделью или, проще говоря, замкнутым кругом благоприятных событий. Мы также обнаружили, что методы бережливого управления продуктами предсказывают эффективность организации, измеряемую с точки зрения производительности, прибыльности и доли рынка. Этот замкнутый круг, состоящий из повышенной эффективности доставки и методов бережливого продукт-менеджмента, обеспечивает достижение лучших результатов для вашей организации (см. рис. 8.2).

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