Всё началось с конфликта. В мой трайб, где я работал Agile-коучем, пришёл новый технический лидер и стал разбираться в ситуации. Хотя команда показывала хорошие результаты в бизнесе, новый технический лидер трайба постоянно повторял: «У вас всё сделано на коленке». Я не согласился с этим утверждением, но не стал с ним спорить. Однако меня охватило желание поразмышлять о том, как Agile-подход и Scrum влияют на качество работы.

Если посмотреть на людей, которые входят в Scrum-команды, можно часто встретить мнение, что Agile и Scrum — это про быстрое достижение бизнес-показателей в ущерб качеству. Но так ли это на самом деле? 

MVP: минимальный жизнеспособный продукт и технический долг — как они связаны?

«Если вам не стыдно за первую версию продукта (MVP), значит, вы пришли на рынок слишком поздно», — писал Эрик Райс в своей книге «The Lean Startup».

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

Чтобы опровергнуть это утверждение, необходимо понять, как разрабатывается первая версия продукта (MVP — минимальный жизнеспособный продукт). Должны ли мы жертвовать качеством в погоне за скоростью? Конечно, да, но при этом мы также берём на себя ДОЛГ.

При создании стартапа мы берём кредит, создавая денежный долг перед инвесторами и банками, в надежде, что если продукт окажется успешным, мы сможем вернуть эти средства из прибыли. Аналогично, создавая MVP, мы берём на себя «технический долг», который обязуемся погасить, если продукт станет успешным.

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

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

Бюджет в виде ресурса команды или «квота», заложенная на каждый равный промежуток времени, может превратить первую версию продукта из объекта стыда в предмет гордости в течение нескольких десятков итераций. Этот бюджет может составлять 5% времени команды, 10% или даже все 50%. Но если долг существует, его необходимо зафиксировать и постепенно снижать.

Бюджеты для снижения долга появляются из уже запущенного продукта, который, пусть и не идеален, но всё же работает. Если же мы будем делать очень качественный, но очень долгий продукт, то можем увидеть, как рынок захватывают конкуренты с менее качественным, но выпущенным раньше продуктом. И тогда все эти вложенные часы в качество окажутся никому не нужными.

Но только ли в техническом долге дело?

Так что же такое качество?

Чтобы дальше рассуждать и углубляться в тему качества, его надо определить.

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

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

Качество продукта — это совокупность её наиболее важных свойств

Должны ли мы уделять внимание каждому свойству на этапе запуска продукта? Безусловно, да, но не менее важно как быстро мы сможем выпустить первый полностью рабочий экземпляр. Ведь машина с двигателем, но без колёс — это не более чем груда металла. А вот планер с крыльями, но без мотора может существовать как самостоятельный продукт.

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

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

MVP создан, что дальше? Непрерывный цикл улучшения!

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

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

Такой цикл заложен в Scrum и называется Спринт. Обратную связь по продукту в Scrum мы получаем на таком мероприятии как Демо (более правильное название Sprint Review). Обратную связь по командным процессам мы получаем на таком мероприятии как Ретро. 

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

C увеличением знаний о продукте и улучшением взаимодействия в команде, Scrum-команды могут достигать более высоких результатов, повышать качество продукта и увеличивать удовлетворенность клиентов.

Для непрерывного улучшения продукта необходим список улучшений. В Scrum такой список называется Бэклог. Бэклог - это список, в котором содержатся и тех. долг и всевозможные улучшения по ОДНОМУ продукту. Ограничение, что продукт один и означает переход в определенный режим шлифовки или цикла управления качеством, который когда-то описал Деминг. 

Scrum провоцирует качество?

Все элементы Scrum направлены на улучшение качества продукта. Спринт служит циклом, в котором мы оттачиваем продукт. Демо позволяет получать обратную связь, выявлять слабые места и накапливать знания о продукте. Ретроспектива помогает нам учиться на собственных ошибках и постоянно совершенствовать процессы внутри команды. Бэклог собирает все идеи по улучшению, которые мы хотели бы реализовать в рамках одного продукта. Владелец продукта активно общается с клиентами и знает все их болевые точки.

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

Согласно моему опыту, причиной этого является постоянное стремление к развитию нового. Создав первое минимально жизнеспособное решение (MVP), мы сразу переходим к созданию второго, не обращая внимания на технический долг, возникший в результате работы над первым MVP. Этот процесс повторяется снова и снова, и команда, работающая в Scrum, создает одно MVP за другим, накапливая такой объем технического долга, что его закрытие может занять несколько месяцев.

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

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

Кто является заказчиком Scrum-команды?

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

Но так ли это должно быть? Конечно, нет! Владелец продукта — это тот, кто сам принимает решения о развитии своего продукта, основываясь на бизнес-показателях, мнении клиентов и команды. Он близок к команде и знает все её проблемы, а также близок к клиентам и их ожиданиям. Исходя из этих двух часто не совпадающих точек зрения, он выбирает стратегию и формирует видение будущего продукта. Именно владелец продукта отвечает за P&L, то есть за рентабельность, прибыль и качество продукта.

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

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

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

Почему владельцу продукта выгодно заботиться о его качестве?

Если представить, что владелец продукта в конкретной команде или во множестве команд несет реальную ответственность за прибыль и убытки (P&L) своего продукта, то возникает вопрос: почему ему будет выгодно уделять внимание качеству?

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

Структура выручки

Выручка состоит из нескольких компонентов:

1. Себестоимость — затраты на разработку, обслуживание, материалы, из которых состоит продукт, аренду офиса и налоги.

2. Затраты на продажу — расходы на коммуникацию с клиентом до момента продажи.

3. Рентабельность на прибыль — соотношение между выручкой и затратами на производство и продажу

4. Маркетинг — расходы на привлечение и удержание клиентов.

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

Маркетинг и удержание клиентов

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

Один привлеченный клиент может пользоваться продуктом несколько раз. Зная это количество и средний чек, мы можем рассчитать LTV (пожизненную ценность клиента).

LTV (Lifetime Value) — это метрика, которая оценивает общую прибыль, которую бизнес получает от одного клиента за все время его взаимодействия с продуктом или услугой.

LTV является ключевым показателем для анализа рентабельности привлечения клиентов и стратегии удержания.

Связь качества с LTV

Чем выше качество продукта, тем дольше клиент будет им пользоваться. А значит и LTV будет больше.

Чем выше LTV, тем больше денег остается на маркетинг, и тем более агрессивно мы можем захватывать рынок и развивать продукт.

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

Различные стратегии развития в зависимости от ресурсов компании

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

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

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

Scrum-команда или объединение команд создают культуру стартапа в крупной организации. У такой команды всегда ограничено время на реальную разработку, поэтому ей необходимо тщательно выбирать свою нишу. Только после того, как она создаст действительно качественный продукт, она сможет масштабировать свой опыт на другие области. 

Вот примеры из практики известных стартапов которые работали долго над одним продуктом

1. Amazon:

   • Запустил свой первый продукт — онлайн-магазин книг — в 1995 году.

   • Расширился до продажи других товаров через 3–4 года и запустил Amazon Web Services (AWS) только через 10 лет (в 2006 году).

2. Facebook:

   • Начал с социальной сети для студентов в 2004 году.

   • Перешел к следующему значимому продукту (Messenger как отдельное приложение) спустя 8 лет, в 2012 году.

   • При этом постепенно добавлял функции в основной продукт (например, Marketplace, Ads).

3. Google:

   • Запустил свой поисковый движок в 1998 году.

   • В 2000 году добавил контекстную рекламу (AdWords), которая стала вторым важным продуктом.

   • Gmail появился только в 2004 году (6 лет спустя после запуска основного продукта).

4. Uber:

   • Начал с премиального сервиса (UberBlack) в 2009 году.

   • Запустил UberX (более массовый продукт) через 4 года, в 2013 году.

   • Дальнейшие продукты (UberEats, UberFreight) появились ещё через несколько лет.

Выводы:

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

2. Создать минимально жизнеспособный продукт (MVP).

3. Сосредоточиться на развитии этого продукта и сделать его действительно качественным.

4. Чтобы добиться успеха, необходимо анализировать P&L продукта, оценивать юнит-экономику и действительно решать проблемы клиентов, чтобы они продолжали пользоваться продуктом.

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

Негативный сценарий:

1. В попытке угодить широкой аудитории мы постоянно разрабатываем новые модули и версии продукта для разных групп клиентов. Каждая новая версия — это как мини-продукт внутри нашего основного продукта.

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

3. Решения, реализованные через MVP, не вызывают WOW-эффекта, и пользователи становятся недовольны или перестают пользоваться продуктом. Это приводит к сокращению бюджета, что делает невозможным дальнейшее улучшение качества и развитие смежных направлений.

P.S. В этой статье я описал лишь один из кейсов влияющий на управления качеством, хотя в этой области есть множество прикладных аспектов, о которых хотелось бы рассказать подробнее (например, о картах Шухарда). Однако, как и в любой другой области, важно начинать с основ. Невозможно добиться идеально ровной поверхности дерева, если каждый раз двигать шлифовальной машиной по разным брускам. Чтобы достичь качества, нужно сосредоточиться на одном бруске, в нашем случае продукте и планомерно, в течение длительного времени, работать над его улучшением. А какими инструментами это делать, я, возможно, расскажу в следующей статье. 

Если статья понравилась, подписывайтесь на мой канал «Путь Agile» в Telegram.