Срывы релизов часто начинаются в оргструктуре, а не в коде

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

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

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

Именно второй счетчик обычно и дает настоящий срыв.

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

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

Работа также стопорится, когда ломается ответственность на стыках. Разработка отвечает за код. QA — за покрытие тестами. Продукт — за решение. Операции — за выкладку. Если никто не отвечает за весь путь от идеи до релиза, каждая группа может сделать свою часть, а работа все равно остановится.

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

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

Циклы согласований, которые тормозят простую работу

Многие команды думают, что релиз ждет код. Чаще он ждет разрешения.

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

Начните с простого подсчета. После завершения code review сколько «да» нужно релизу, чтобы попасть в прод? В одних командах ответ — одно. В других — шесть или семь согласований от продукта, дизайна, безопасности, операций и менеджера, который подключился только в последний час.

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

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

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

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

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

Разделенная ответственность создает скрытое ожидание

Когда за весь релиз никто не отвечает целиком, работа все еще движется, но дата — нет. Разработка заканчивает код, QA ждет сигнала, продукт пересматривает объем, а маркетинг ждет финальный текст. Все заняты, но релиз все равно буксует.

Разделенная ответственность на схеме часто выглядит аккуратно. Разработка владеет кодом. QA владеет качеством. Продукт владеет объемом. Маркетинг владеет коммуникацией запуска. Проблемы начинаются, когда за саму дату релиза не отвечает никто. Нужен человек, который будет спрашивать: «Что блокирует это сегодня?» — и принимать решение, когда команды не согласны.

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

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

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

Небольшой пример это хорошо показывает. Стартап планирует выкатить изменение в биллинге в пятницу. Разработка заканчивает в среду. QA находит один крайний случай в четверг утром. Продукт хочет исправление. Продажи хотят релиз вовремя. Маркетинг уже подготовил объявление. К четвергу после обеда задача уже переходила из рук в руки три раза, и ни у кого нет четкого права обменять объем на скорость.

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

Цели, которые тянут команды в разные стороны

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

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

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

Знакомая схема выглядит так:

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

Никто не неправ. Релиз все равно ждет.

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

Бонусы тихо усугубляют это. Если менеджеров поощряют за стабильные системы, они добавляют лишние проверки. Если продукт оценивают по adoption, он продолжает наращивать объем. Если поддержку оценивают по числу тикетов, она сопротивляется запускам, которые выглядят сыровато. Никто не говорит: «Давайте задержим релиз». Это делают за них их метрики.

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

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

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

Один релиз, который сдвигается на две недели

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

Потом начинается ожидание.

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

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

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

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

Продукт владеет роадмапом. Разработка владеет кодом. Юристы владеют риском. Маркетинг владеет запуском. Поддержка владеет готовностью. Каждая команда защищает свою часть, и по отдельности это имеет смысл. Вместе это и создает задержку.

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

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

Как отследить задержку шаг за шагом

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

Затем соберите весь путь на одной странице. Включите планирование, согласование дизайна, разработку, ревью, QA, безопасность, контент, выкладку и любые согласования, которые могут заблокировать запуск. Многие задержки релиза выглядят как проблемы разработки, пока вы не увидите семь передач и трех людей, которые могут сказать «подождите», но только одного, кто может сказать «вперед».

Достаточно простой таблицы или доски. Для каждой передачи зафиксируйте пять вещей:

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

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

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

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

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

Ошибки, которые команды делают, когда чинят не то

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

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

Еще одна ошибка — добавлять встречи, чтобы ускорить медленные решения. Новый синк звучит безобидно, но часто создает еще одно место, где никто ничего не решает. Команды уходят с заметками, а не с ответами. Если релиз и так тормозят циклы согласований, лишние встречи обычно только удлиняют очередь.

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

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

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

Лучше сделать проще:

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

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

Короткая проверка перед тем, как обещать дату

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

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

• Есть ли один человек, который явно отвечает за дату релиза?
• Может ли команда выкатывать без дополнительного согласования от руководства?
• Подтвердила ли каждая команда объем на этой неделе?
• Ждет ли кто-то решение, которому больше 24 часов?
• Можете ли вы назвать самое медленное звено прямо сейчас?

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

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

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

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

Что делать дальше

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

Поместите весь процесс этого релиза на одну страницу. Запишите каждое согласование, каждую передачу, каждую проверку статуса и каждое утверждение — от «код готов» до «он в проде». Добавьте, кто отвечал за каждый шаг, сколько он там ждал и что его блокировало. Обычно это объясняет больше, чем очередной спор о скорости разработчиков.

Достаточно короткого разбора. Отметьте любой шаг, где работа ждала больше дня. Обведите места, где две команды думали, что решение принимает другая команда. Отметьте согласования, которые были «на всякий случай», но почти никогда не меняли итог. Посчитайте, сколько людей могли остановить релиз даже для небольшого изменения.

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

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

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