Баланс фокусов команды

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

Знакомая ситуация? ☝️

В определённой степени она встречается во всех командах, что обычно происходит по одной из 3-х причин:

1. 🤷 Мы не задумываемся о реальной стоимости каждой фичи, которую привносим в наш продукт.
2. 🌁 Работа команды по поддержанию качественного уровня сервиса для пользователя сокрыта от бизнеса.
3. 🙏 “Техдолг” не имеет понятного влияния на ценность продукта и постулируется для бизнеса, как необходимая активность.

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

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

Фреймворк баланса позволяет:

1. 💵 Понимать реальную стоимость разработки и содержания каждой новой фичи.
2. 🤩 Прозрачно рассказывать бизнесу, чем занята команда кроме создания новых фичей.
3. 🧑‍🚒 Контролируемо и комфортно выстроить работу по срочным проблемам в системе.
4. 📉 Снизить объём ручных действий по поддержке системы.
5. 📈 Начать на регулярной основе решать “техдолг” ещё более полезный, чем прежде.

Для начала поговорим про реальную стоимость всех новых фичей и невидимую работу команды 👇

💰 Реальная стоимость новых фичей

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

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

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

На этой иллюстрации объём каждой фичи выражен в её длине на временно́й шкале, а “поддержка” отмечена просто как постоянное направление работы команды. Такой формат немного искажает реальность, и мы начинаем считать, что на содержание системы всегда необходимо один и тот же объём времени и фокуса команды.

Однако, привнеся в систему новую фичу, дальше нам необходимо:

• 🌱 Развивать эту новую часть продукта и системы для наших клиентов с т.з. удобства, пользы, качества работы и пр.
• ❤️ Поддерживать её работоспособность и стабильность как в части “техники”, так и адаптируя фичу к изменениям внешнего мира (например, ключевой источник данных перестал с нами сотрудничать или сменил набор доступных для нас данных).
• 🪢 Интегрировать и вплетать её в наш продукт, а также учитывать в будущих фичах.

В каждом пункте речь как про технику, так и про продукт. Они представляют собой единое целое.

Что в реальности выглядит примерно таким образом:

(идея иллюстрации взята из закрытой публикации в блоге refactoring.fm)

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

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

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

🐝 Невидимое, но жизненно необходимое

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

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

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

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

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

Все эти работы идеально гармонизуются вместе с созданием новых фичей в фокусах команды благодаря фреймворку баланса 👇

⚖️ Фреймворк баланса

Некоторое время назад Мэт Экклстоун ex-VP of Engineering and Growth в компании Dropbox предложил (прим. ссылка на Medium – недоступно из РФ) делить всю работу на 2 основные категории:

• 🔴 Обязательные инвестиции в поддержание уровня сервиса, которые он назвал «keep the lights on» (KTLO) по аналогии с работой смотрителя маяка — его задача поддерживать свет, чтобы мореплаватели не заблудились.
• 🟢 Избирательные инвестиции, которые уже подлежат полноценной приоритизации и планированию (в оригинале «elective investments»).

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

KTLO активности обычно включают:

• 🧑‍🚒 Поддержание системы в рабочем состоянии и реагирование на инциденты (on-call дежурства).
• 🙏 Помощь пользователям по проблемам, которые эскалируются в команду.
• 🐞 Работа по багам с продакшена, которые необходимо исправить для восстановления качественного уровня сервиса.
• 🔂 Обновление зависимостей, версий ПО, проведение плановых инфраструктурных работ и пр.

При этом избирательные инвестиции также делятся на три типа задач:

• 🌱 Создание новой ценности для пользователей
• 🪄 Развитие существующей ценности для пользователей
• 🚀 Повышение продуктивности команды (не видно для пользователей)

Разберём, что относится к каждому из этих трёх типов 👇

🌱 Создание новой ценности для пользователей

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

• 🛥️ Создание новых продуктов
• 🎣 Создание новых фичей в существующем продукте
• 🐠 Добавление функционала в существующие фичи
• ⛵️ Интеграции с новыми вендорами и платформами (например, запуск Android приложения если есть версия под iOS, подключение резервного эквайринга и пр.)

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

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

🪄 Развитие существующей ценности для пользователей

Привнеся в систему что-то новое, дальше нужно это развивать – увеличивать ценность для клиентов и повышать техническое качество фичи.

К последнему можно отнести такие работы, как:

• 🕵️ Анализ и улучшение производительности и безопасности системы.
• 🚨 Повышение наблюдаемости и стабильности системы, для более быстрой реакции на инциденты и последующего восстановления.
• 🧹 Удаление фича-флагов, которые ранее использовались при релизе фичи, а также “мёртвого” кода от частей, которые более не используются.
• 👌 Замена технических сообщений об ошибках на человеко-читаемые – понятные для клиентов.
• 🪮 Минорный рефакторинг кода, каждый шаг которого позволяет понемногу повышать качество кодовой базы проекта.

🚀 Повышение продуктивности команды

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

Например, сюда можно отнести такие работы, как:

• 🧑‍✈️ Анализ метрик процессов команды, их развитие.
• 👨‍⚕️ Всё, что необходимо для уменьшения объёма работ в рамках KTLO (например, автоматизация ручных операций, на которые команда тратит время).
• 📜 Написание runbook’ов (инструкций) по поддержке системы и наших пользователей.
• 🖍️ Занесение новых линтеров и инструментов для упрощения Code Review и тестирования.
• 👮 Допокрытие функционала автотестами, чтобы раньше отлавливать влияние будущих правок на то, что мы создали ранее.
• 🏗️ Реструктуризация кода, которая позволит лучше и быстрее сделать будущие фичи.

🤩 Плюсы, которые фреймворк привносит в работу

Итого у нас есть 4 категории активностей:

1. 🔴 Обязательные инвестиции в поддержание уровня сервиса (KTLO)
2. 🌱 Создание новой ценности для пользователей
3. 🪄 Развитие существующей ценности для пользователей
4. 🚀 Повышение продуктивности команды (не видно для пользователей)

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

Это позволяет нам, как руководителям:

• ⚖️ Сбалансировать все виды работ в развивающемся продукте и особенно быстрорастущей компании – нельзя постоянно делать только новые фичи и не думать про всё остальное.
• 🤗 Говорить с бизнесом и продуктом на одном языке о содержании системы и работах, которые для этого необходимы – говорим не про абстрактный “техдолг”, а про эффект от конкретных активностей на пользователей и команду (используем рефрейминг).
• 🫧 Выстроить прозрачную и понятную систему работы по срочным задачам для всех ваших заказчиков за счёт KTLO бакета – тем самым снизить уровень горячки и стресса в команде от разных срочных залётов и саппорта.
• ⏱️ Проще коммуницировать бизнесу о том, почему новая фича “на 2 дня” займёт “неделю” – т.к. у вас будет чёткое понимание возможностей команды и выложенный на бумагу перечень “невидимой работы”, что станет фактурой для обоснования озвученных сроков.

🔢 Определяем KTLO активности

Единственный бакет, который по своей сути неприкосновенен – это KTLO (обязательные инвестиции в поддержание уровня сервиса). Вытягивая время из него, мы вредим операционной деятельности компании.

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

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

Этот нюанс может привести к манипулированию фреймворком и в KTLO попадут важные задачи для кого-то определённого, но не имеющие значимости для поддержания операционной деятельности компании.

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

При определении относится ли работа к KTLO можно воспользоваться простым правилом:

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

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

🧑‍✈️ Примеры применения фреймворка баланса

Мэт Экклстоун, про которого мы говорили ранее, описывал деление в рамках Dropbox. Важный нюанс – во время работы Мэта в компании, она активно росла.

В среднем все команды имели такое соотношение:

• 🔴 KTLO: 1 человек, который ничем более не занят
• 🌱 Создание нового: ~60%
• 🪄 Развитие существующей ценности: ~20%
• 🚀 Продуктивность: ~20%

Но каждая команда сама определяла соотношение между категориями исходя из реального положения дел.

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

Сейчас у меня работают следующие 3 бакета:

1. 🌱 Создание нового: 60%.
2. 🪄 + 🚀 Развитие системы и команды: 20% – всё из «развитие существующей ценности для пользователей», о которой говорили ранее, плюс часть «повышения продуктивности команды» связанная с развитием процессов команды и кодовой базой проекта.
3. 🔴 + 🚀 Саппорт и ad-hoc активности: 20% – это неприкосновенный бакет, который вобрал в себя KTLO и часть продуктивности, связанную с уменьшением объёма KTLO в команде.

При этом на бакет «Саппорт и ad-hoc активности» обычно выделено 1 или 2 человека из команды (общее число инженеров в командах 4–9 чел.), которые не занимаются ничем другим. Потому что практически невозможно сфокусировано делать что-то ещё, когда тебя в любой момент могут выдернуть по важному вопросу или тебе нужно “впрыгивать” в инцидент и поднимать продакшен.

Такая схема сложилась благодаря 3-м факторам:

• 🤷 Отсутствие нагрузки по KTLO активностям на 1 человека на постоянную основу.
• 📜 Политика компании по балансу фокусов.
• 👌 Подход 60-20-20 значительно понятнее бизнесу, чем “1 человек + 60-20-20”.

🏄🏻‍♂️ С чего начать

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

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

Шаги, чтобы начать применять фреймворк баланса:

1. 🔢 Выпишите всё, что делает команда от недели к неделе в удобном для вас формате – это может быть список в заметках, доска в Miro или что-то другое. Не стремитесь всё структурировать на этом шаге, просто выгрузите максимум из головы.
2. ⚖️ Распределите все работы внутри команды по предложенным в статье 4-м категориям – используйте примеры, чтобы лучше понять, что и в какую категорию отнести.
3. 🍰 Прикиньте в процентном соотношении время на каждый бакет – это будет ваша точка для старта. Можно посмотреть, как для вас прошли последние 3–4 недели.
4. 🗣️ Поговорите с командой – расскажите им про инструмент и как он может помочь команде в работе, а также поделитесь своим видением процентного соотношения всех категорий работ. Обязательно соберите обратную связь и идеи.
5. 🖼️ Расскажите бизнесу, какие активности делает команда от недели к неделе и предложите зафиксировать конкретные проценты для каждого из бакетов. Помните, что нужно говорить про эффект на компанию и клиентов, а не про процесс.
6. 🚴‍♂️ Попробуйте поработать в таком формате, постепенно подбирая более оптимальное соотношение между всеми категориями.
7. 🧘‍♂️ Не забывайте, что баланс нужно регулярно калибровать о текущую реальность – всё меняется в нашем мире.

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

Также не стремитесь найти точные проценты, которые будут работать каждую неделю, спринт и т.д.

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

Но если вы заложите 20% на KTLO, а работ будет больше, то у вас уже будет выделенный капаситет внутри команды, который позволит закрыть бо́льшую часть проблем. Под оставшуюся часть можно вынуть фокус из других бакетов значительно менее болезненно, чем когда надо искать ещё 20% и попадать во все коммиты.

Тебя заинтересовали идеи из статьи и ты хочешь попробовать их в своей работе?

Я с радостью помогу применить всё в работе. Бесплатно. Просто напиши мне 👇

Хочу консультацию!

🤔 Где ещё фреймворк может пригодиться

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

Подобное изменение привнесёт в команду не только новые фичи в бэклог, а ещё и значимый объём работ по остальным 3-м бакетам.

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

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

💎 Послесловие

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

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

Работая в таком формате, у вас и вашей команды от недели к неделе будет гарантированное время на все важные работы.

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

Удачи 🚀