Привет!

Меня зовут Тимофей, и я продуктовый разработчик. О продуктовой разработке подробнее можно почитать тут. 

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

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

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

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

Чем плох дисбаланс

Рассмотрим одну из полярностей современного процесса разработки ПО с agile-based процессами: скорость и качество. Проведём мысленный эксперимент и представим, как изменится продукт, если эта полярность на достаточно продолжительное время свалится в одну из крайностей.

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

— Не успеваем выпустить фичу в срок?

— Давайте пожертвуем временем на написание тестов, чтобы успеть.

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

— Проект с нуля нужно выпустить на рынок в ближайшее время?

— Давайте не будем тратить время на предварительную проработку архитектуры. 

Результаты подобных решений могут быть примерно такие.

Уже в проде всплывает major баг, из-за которого у пользователей растёт недовольство продуктом. 

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

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

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

А что со второй крайностью — качество превыше всего? 

— Мы планируем выпустить простую фичу, у которой под капотом будут CRUD операции. 

— Давайте навернём туда микросервисы, и пусть они общаются через kafka, и всё это на реактивном API.

— Нужно разработать проект архитектуры под новую фичу/продукт. 

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

После запуска оказалось, что реальная нагрузка на сервис 10RPS. kafka, микросервисы и reactor стали бешеным оверхедом. И пока запиливали этот оверхед, конкуренты сделали то же самое, но в одном монолите с синхронным API и JPA. Получилось в 3 раза быстрее, и клиенты ушли к более быстрым конкурентам за новой фичей.

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

То есть в случае, когда разработчики перегнули палку, компания снова оказалась в минусе.

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

Ответственность разработчика

Качество

Говоря про качество, подразумеваю два его вида: внутреннее и внешнее. 

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

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

Time to market

Будем рассматривать time to market как отрезок времени между тем, как фича была придумана, и тем, как она достигла своего конечного потребителя. 

Существует  бизнес-составляющая времени: проработка задачи, исследования, аналитика. Но сейчас я бы хотел сфокусироваться на нескольких факторах, наиболее сильно, по моему мнению, влияющих на t2m в части разработки:

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

Инструменты разработки. Как устроен подход к работе, как пишем код и доставляем его до прода. Иными словами, Developer Experience.

Договоренности и шаблонные решения. Договоренности — это время, которое тратим в код-ревью на обсуждение одних и тех же вопросов, ответы на которые нигде не зафиксированы. А шаблонные решения — это когда бизнес приносит задачу, и вы понимаете, что для решения надо сделать yet another очередь на Postgres или Oracle, и начинаете эту очередь реализовывать, хотя могли бы уже вынести в подключаемую библиотеку.

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

Почему качество начало снижаться

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

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

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

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

Как тогда организовать такой процесс постоянной работы с качеством? Особенно когда речь идёт не о новом запускаемом продукте, а об уже существующем?

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

Продуктовый бэклог

Согласно Scrum guide, продуктовый бэклог — приоритезированный список того, что нужно сделать для улучшения продукта. За наполнение списка, его приоритизацию и стратегию развития продукта отвечает Product Owner (PO). 

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

Может ли разработчик самостоятельно принять решение о добавлении задачи в бэклог? Скорее нет, чем да. Product Owner отвечает за вектор развития продукта и наполнение бэклога, поэтому только он может принять решение, что задача действительно укладывается в текущее направления развития и несёт пользу продукту. 

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

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

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

• Скольких уникальных пользователей в день/месяц задевает проблема?

• Какие пользовательские сценарии проблема затрагивает?

• Сколько убытков мы несём в связи с проблемой в деньгах?

• Какие риски нам придётся принять, если не будем решать проблему? Какие последствия будут от реализации рисков? Какова вероятность реализации риска в ближайшие полгода/год

• и другие не менее важные вопросы, влияющие на основные продуктовые показатели: DAU, MAU, оборот, выручку и др.

В связи с этими вопросами у вас может возникнуть чувство непонимания, возмущения, отторжения. Могут появиться мысли: “от нас хотят отвязаться”, “мы же не аналитики, чтобы всё это посчитать”, “нами пренебрегают, не уважают нашу экспертизу”. Советую подавить в себе первую негативную реакцию и мысленно встать на место PO. Да, он действительно не может сравнить по важности задачу А и задачу Б без ответов на эти вопросы для каждой из них.

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

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

Проверь себя

Для того, чтобы не свалиться с полярности скорость/качество в одну из крайностей, советую проделать следующее.

• Перед разработкой уточните нефункциональные требования к фиче (предполагаемый RPS, необходимая скорость ответа на запросы, ожидаемый объём обрабатываемых данных). Это поможет добавить аргументов в пользу тех или иных технологий, технических решений.

• Уточните у бизнеса, не является ли новая фича необходимой для кратковременной проверки продуктовой гипотезы? Если да, не стоит строить архитектуру на века.

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

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

• Обсуждайте, какие долгоиграющие последствия может иметь каждое принимаемое вами решение.

• Задумайтесь, не занимаетесь ли вы оверинжинирингом, преждевременной оптимизацией, не придумываете ли несуществующие требования к продукту.

• Почелленжили ли вы представителя бизнеса, с порога кричащего о срочно-важности задачи? Может выясниться, что можно не брать дополнительную работу до завершения текущей итерации

• Не слишком ли много времени вы тратите на “прощупывание почвы”, планирование и проектирование? Возможно, пора уже начать разработку и столкнуться с первыми трудностями

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