За последние несколько лет мне довелось управлять не только командами разработки, но и более широкими контурами delivery: программами, портфелями инициатив, процессами поддержки, эскалациями и крупными изменениями в продукте.
И чем больше становился масштаб, тем чаще я сталкивался с одним парадоксом. Самые большие проблемы обычно возникали не там, где работали слабые команды.
Наоборот.
Чаще всего источником проблем становились сильные команды, которые были хорошо организованы, дисциплинированы и способны быстро выполнять поставленные задачи.
Звучит странно.
Но именно сильная команда может месяцами эффективно двигаться в неправильном направлении. И чем сильнее команда, тем дороже обходится такая ошибка.
Заблуждение, в которое я тоже верил
В начале своей управленческой карьеры я оценивал команды примерно так же, как и большинство руководителей. Я смотрел на загрузку людей, количество завершённых задач, скорость выполнения работы состояние backlog. Если команда была занята, задачи закрывались, а сроки выглядели реалистично, то мне казалось, что система работает нормально.
Со временем начали появляться вопросы, на которые эти показатели не давали ответа.
Почему при высокой загрузке команд руководство всё чаще недовольно скоростью изменений?
Почему важные инициативы постоянно переносятся?
Почему количество эскалаций растёт быстрее, чем объём разработки?
Почему спустя год активной работы продукт не демонстрирует сопоставимого роста бизнес-результатов?
В какой-то момент стало очевидно, что мы измеряем эффективность работы, но почти не измеряем полезность этой работы. Именно тогда я начал смотреть на backlog не как на список задач, а как на инвестиционный портфель компании.
Когда backlog становится финансовой проблемой
Каждая задача в backlog конкурирует за ограниченный ресурс. Обычно этот ресурс называют временем разработки. На практике всё значительно дороже.
Любая инициатива потребляет время аналитиков, инженеров, тестировщиков, менеджеров, поддержки и руководителей.
По сути каждая задача претендует на инвестиции компании. И здесь возникает интересная ситуация. Когда бизнес принимает финансовые решения, он почти всегда задаёт вопросы про ожидаемую отдачу. Но когда речь заходит о backlog, подобная дисциплина часто исчезает.
Задачи появляются значительно быстрее, чем исчезают. Новые инициативы накладываются на старые.
Приоритеты меняются.
Контекст теряется.
Через некоторое время backlog начинает напоминать архив решений, которые никто не решился окончательно принять.
В одной из организаций мы анализировали накопленный backlog, сформированный за несколько лет работы. Значительная часть задач имела возраст больше года. Некоторые инициативы пережили смену руководителей и несколько циклов планирования.
Тогда я задал простой вопрос.
Что произойдёт, если завтра исчезнет половина этих задач?
После обсуждения стало понятно, что большая часть бизнеса этого даже не заметит.
Это был важный момент.
Стало очевидно, что проблема заключается не в нехватке ресурсов. Проблема заключалась в качестве инвестиционных решений.
Почему сильные команды особенно опасны
Peter Drucker говорил The Effective Executive:
Нет ничего более бесполезного, чем эффективно делать то, что вообще не нужно делать.
На мой взгляд, именно эта мысль лучше всего описывает проблему современных инженерных организаций.
Слабая команда обычно заметна сразу. Она срывает сроки, создаёт проблемы качества, генерирует хаос.
Сильная команда выглядит совершенно иначе. Она выполняет обязательства, поддерживает высокий темп работы, закрывает задачи, показывает хорошие метрики.
Но если приоритеты выбраны неверно, компания получает гораздо более дорогую проблему. Она быстро инвестирует ресурсы в инициативы, которые не создают значимой ценности.
Именно поэтому вопрос эффективности разработки всегда вторичен по отношению к вопросу выбора правильных инвестиций.
Метрики, которые создают иллюзию контроля
В инженерной среде принято много говорить о метриках.
Velocity.
Lead Time.
Cycle Time.
Deployment Frequency.
MTTR.
Все они полезны.
Проблема начинается в тот момент, когда организация начинает воспринимать их как конечную цель.
В исследовании DORA неоднократно подчеркивается важная мысль: показатели доставки изменений помогают оценивать способность организации поставлять результат. Они не отвечают на вопрос, являются ли эти изменения правильными.
Другими словами, высокая скорость доставки и высокая бизнес-ценность — это не одно и то же.
За свою карьеру я видел организации, которые существенно улучшали инженерные метрики, но практически не меняли положение бизнеса. И видел обратные примеры, когда несколько правильно выбранных инициатив приносили эффект, который невозможно было получить за счет оптимизации процессов разработки.
Это напоминает закон Гудхарта:
Когда показатель становится целью, он перестает быть хорошим показателем.
Если команда начинает оптимизироваться под количество закрытых задач, она будет закрывать больше задач.
Если команда начинает оптимизироваться под velocity, она будет увеличивать velocity.
Но ни один из этих показателей автоматически не приводит к росту выручки, удержанию клиентов или снижению операционных расходов.
Именно поэтому вопрос создания ценности всегда начинается не с метрик исполнения, а с качества решений о том, над чем вообще стоит работать.
Эскалации как зеркало инвестиционных решений
Один из самых полезных источников информации о качестве приоритизации находится не в backlog и не в roadmap.
Он находится в эскалациях. Во многих компаниях эскалации воспринимаются как проблема поддержки, но со временем я начал смотреть на них иначе. Каждая серьезная эскалация является сигналом того, что организация недоинвестировала в какую-то область.
Иногда это технический долг.
Иногда качество.
Иногда наблюдаемость системы.
Иногда неудобный пользовательский сценарий.
Иногда организационная проблема между подразделениями.
Самое интересное, что во многих случаях информация о риске уже существует заранее. Поддержка сигнализирует о проблеме. Инженеры знают о слабом месте системы. В backlog есть соответствующая задача. На планировании она обсуждается. Затем откладывается. И так происходит несколько кварталов подряд. После этого возникает инцидент. Появляются недовольные клиенты. Подключается руководство. Находятся ресурсы. И работа, которую невозможно было начать в течение года, внезапно реализуется за несколько недель.
С точки зрения управления инвестициями это очень показательная ситуация.
Компания фактически оплачивает повышенный процент за отложенное решение.
Именно поэтому мне всегда была близка концепция Cost of Delay, описанная Donald Reinertsen в книге "The Principles of Product Development Flow". Стоимость разработки обычно видна сразу. Стоимость ожидания становится очевидной только после того, как последствия уже наступили.
Почему технический долг редко побеждает
Это особенно заметно на примере технического долга. Практически в каждой компании существует список известных технических проблем.
Устаревшие компоненты.
Слабые места архитектуры.
Ограничения инфраструктуры.
Нестабильные интеграции.
Почти всегда инженеры знают о них заранее, но технический долг редко выигрывает конкуренцию за ресурс. Причина проста. Его последствия находятся в будущем. А конкурирует он с задачами, которые обещают результат уже сегодня. В результате организация постепенно накапливает обязательства перед будущей версией самой себя.
Этот процесс может продолжаться достаточно долго. Пока однажды накопленный риск не материализуется в виде серьезного инцидента.
После этого происходит знакомая многим история. Руководство задает вопрос:
"Почему мы не исправили это раньше?"
Ответ обычно звучит одинаково.
"Мы знали о проблеме, но постоянно находились более важные задачи."
На самом деле это проблема не инженеров, а системы принятия решений.
Что изменилось в моем подходе к управлению backlog
Со временем я перестал обсуждать задачи исключительно через призму сложности реализации. Вместо этого появилась другая логика. Каждая инициатива должна была отвечать хотя бы на один из следующих вопросов:
Создает ли она новый доход?
Помогает ли удерживать клиентов?
Снижает ли операционные расходы?
Снижает ли риски для бизнеса?
Повышает ли устойчивость платформы?
На первый взгляд это выглядит очевидно, но на практике такой фильтр меняет очень многое. Оказывается, что значительная часть backlog существует потому, что когда-то казалась хорошей идеей.
Не потому, что сейчас создает ценность.
Дополнительно мы начали анализировать возраст задач. Сама по себе старая задача не является проблемой. Но задача, которая годами находится в backlog без принятия решения, почти всегда заслуживает отдельного разговора. Очень часто подобные элементы становятся индикатором организационной нерешительности. Компания не готова инвестировать в инициативу, но и отказаться от нее окончательно тоже не готова.
В результате backlog начинает выполнять роль склада отложенных решений.
Когда backlog начинает жить собственной жизнью
На определенном масштабе появляется еще одна интересная проблема.
Backlog начинает расти быстрее, чем способность организации принимать решения. Каждый новый квартал приносит новые идеи, запросы клиентов, риски, проекты.
При этом старые инициативы никуда не исчезают.
Если в этот момент не существует регулярного механизма пересмотра инвестиций, система постепенно теряет управляемость.
Я несколько раз наблюдал одинаковую картину. Команды искренне считают себя перегруженными. Руководители считают, что ресурсов недостаточно. При этом значительная часть накопленных задач уже давно не имеет стратегического значения.
Проблема оказывается не в нехватке людей. Проблема оказывается в отсутствии механизма отказа.
Уоррен Баффет однажды сказал:
Разница между успешными и очень успешными людьми заключается в том, что очень успешные люди говорят "нет" почти всему.
Эта мысль удивительно хорошо работает и для управления портфелем инициатив. Чем крупнее становится организация, тем важнее способность отказываться от работы.
От управления задачами к управлению инвестициями
Одна из самых полезных трансформаций, которые мне приходилось наблюдать, происходила тогда, когда организация переставала обсуждать задачи и начинала обсуждать инвестиции.
Разговор менялся.
Вместо вопроса:
"Когда мы сделаем эту задачу?"
Появлялся другой вопрос:
"Почему именно эта задача должна получить ресурс раньше остальных?"
Вместо споров между подразделениями появлялась необходимость объяснить ожидаемый эффект. А вместо бесконечного роста backlog появлялся механизм естественного отбора инициатив.
Именно в этот момент управление разработкой начинает постепенно превращаться в управление бизнесом. Потому что разработка никогда не была про код. Она всегда была про распределение ограниченного ресурса компании.
Когда backlog перестал помещаться в голову
Несколько лет назад я столкнулся с ситуацией, которая на первый взгляд выглядела вполне типично.
Дано:
Несколько продуктовых направлений.
Несколько команд разработки.
Поддержка.
Регулярные эскалации.
Большое количество инициатив от разных заинтересованных сторон.
В системе накопились сотни задач.
Новые запросы появлялись быстрее, чем команда успевала завершать старые.
Каждое планирование превращалось в дискуссию о том, что важнее именно сейчас.
Самое интересное заключалось в том, что никто не мог ответить на простой вопрос:
Сколько из текущих задач действительно влияют на стратегические цели компании?
Мы начали с анализа возраста backlog. Результаты оказались неожиданными. Значительная часть задач существовала более года. Некоторые элементы находились в системе два и более года. При этом они регулярно участвовали в обсуждениях и переприоритизации.
Фактически организация тратила управленческое внимание на инициативы, по которым уже давно не могла принять решение.
После этого мы внедрили возрастные корзины для контроля состояния backlog:
0–14 дней
15–45 дней
46–90 дней
91–180 дней
181–365 дней
более года
Сама по себе старая задача не считалась проблемой. Но каждая задача старше определенного возраста должна была получить ответ на вопрос: Почему она всё ещё существует?
Иногда задача возвращалась в активную работу. Иногда подтверждалась её стратегическая ценность. Но довольно часто лучшим решением оказывалось её закрытие.
Это был один из самых полезных уроков. Не каждая задача заслуживает реализации. Иногда наибольшую ценность создаёт отказ от работы.
Что изменилось после внедрения governance-подхода
Интересно, что после внедрения новых практик скорость разработки практически не изменилась. Инженеры не стали писать код быстрее. Команды не увеличились. Не появилось новых бюджетов. Но начали происходить другие изменения.
Во-первых, снизилось количество параллельных инициатив. Команды стали реже переключаться между контекстами.
Во-вторых, значительно проще стало объяснять причины приоритизации. Когда каждая инициатива относится к определённой инвестиционной категории, обсуждение становится гораздо менее эмоциональным.
Вместо:
"Моя задача важнее"
появляется разговор:
"Какой эффект для бизнеса создаёт эта инвестиция?"
В-третьих, улучшилась предсказуемость. Не потому что планы стали идеальными. А потому что организация стала принимать меньше случайных решений.
Отдельный эффект проявился в работе с эскалациями. Мы начали воспринимать их не как отдельные проблемы поддержки, а как сигналы о дисбалансе инвестиций. Если одна и та же область регулярно генерирует инциденты или обращения клиентов, значит система недополучает внимание организации. Это позволило использовать эскалации как один из источников данных для управления портфелем инициатив.
Со временем стало проще отвечать на вопрос, который руководители задают чаще всего:
"Куда на самом деле уходит ресурс команды?"
Именно этот вопрос, как мне кажется, намного важнее любого velocity или количества закрытых задач.
Что можно проверить уже завтра
Сколько задач в backlog старше года?
Какие из них напрямую связаны с бизнес-целями компании?
Какой процент ресурса команды идет на:
рост выручки;
удержание клиентов;
снижение рисков;
снижение затрат;
устойчивость платформы?
Какие эскалации повторяются последние 6 месяцев?
Какие известные технические риски откладываются больше года?
Какие задачи исчезнут без какого-либо влияния на бизнес?
Какие инициативы руководство продолжает обсуждать, но никогда не финансирует?
Заключение
За последние годы я всё реже задаю вопрос:
"Насколько загружена команда?"
И всё чаще задаю другой:
"Во что сейчас инвестирует организация?"
Разница между этими вопросами кажется небольшой. На практике она меняет практически всё. Хорошие команды способны эффективно выполнять работу, но ценность появляется не в момент выполнения работы, а в момент выбора правильной работы.
Поэтому сегодня мне кажется, что главная задача руководителя заключается не в том, чтобы ускорять команды, а в том чтобы создавать систему, которая помогает организации принимать более качественные инвестиционные решения.
Потому что сильная команда без правильных приоритетов является не преимуществом, а очень дорогим способом двигаться в неправильном направлении.