Упростите процесс доставки с пятью понятными ответственными

Почему 20 человек замедляют один поток доставки

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

Каждая передача добавляет ожидание. Появляется еще одна ветка в чате, еще одно место, где нужно проверить статус, и еще один момент, когда кто-то говорит: «Я думал, это у них». Поставьте 20 человек вокруг одного потока, и ответственность начнет размываться. Многие могут комментировать. Многие могут блокировать. Очень немногие чувствуют себя ответственными за финальное да или нет.

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

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

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

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

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

Найдите, где работа действительно ждет

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

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

Достаточно простой временной шкалы:

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

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

Когда отмечаете задержки, будьте точны. Вместо «ждали согласования» пишите «ждали 19 часов одобрения от продукта» или «лежало два дня, потому что разработка и QA искали одну и ту же acceptance detail в разных инструментах».

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

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

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

Уберите согласования, которые ничего не решают

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

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

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

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

Поставьте таймер на те согласования, что оставляете

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

Это правило важно. Молчание не должно блокировать рутинную работу.

Запрос на изменение продукта хорошо показывает, как это должно работать. QA может прокомментировать влияние на тесты. Security — риск утечки данных. Поддержка — влияние на сроки для клиентов. После этого один ответственный, обычно владелец продукта или инженерный ответственный, принимает финальное решение. Три команды дали вводные. Один человек решил.

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

Объединяйте инструменты по назначению

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

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

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

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

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

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

Статус должен жить в одном месте. Выберите то место, которое вся команда уже использует для отслеживания доставки, и сделайте его единым источником правды. Чат может объяснить, почему что-то изменилось, но чат не должен хранить официальный статус. Документы могут описывать работу, но документы не должны заменять доску задач.

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

Назначьте одного финального ответственного за каждый процесс

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

Дайте каждому повторяющемуся процессу одного человека, который принимает финальное решение и отвечает за результат. Сделайте область ответственности достаточно узкой, чтобы ее можно было использовать. «Отвечать за delivery» — слишком широко. «Отвечать за production-релизы для изменений на клиентском вебе» — уже подходит. «Отвечать за приоритет багов при live-инцидентах» — тоже подходит.

Несколько правил помогают сохранить порядок:

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

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

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

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

Когда релиз срывается, никто не должен спрашивать: «Кто принимал финальное решение?». Команда должна знать ответ за десять секунд.

Как перейти от 20 человек к пяти ответственным

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

У многих команд такой набор выглядит примерно так: входящие запросы, изменения объема и приоритета, передача в разработку, согласование релиза и инциденты в продакшене.

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

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

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

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

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

Простой пример из запроса на изменение продукта

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

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

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

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

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

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

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

Ошибки, из-за которых циклы возвращаются

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

Одна частая ошибка — оставлять в цепочке всех менеджеров «просто для прозрачности». Прозрачность — это нормально. Согласование — это другое. Если изменение продукта все еще ждет трех лидов, директора и кого-то из operations, задержка никуда не делась. Она просто получила новое имя.

Еще одна ошибка — держать старые инструменты открытыми «на случай, если новый поток что-то пропустит». Звучит безопасно, но создает двойную работу. Люди обновляют проектный инструмент, а потом копируют ту же заметку в чат, почту и таблицу, потому что один человек все еще больше доверяет старой системе. Через две недели никто уже не знает, какая версия правильная.

Назначить команду вместо одного человека — та же проблема. «За это отвечает engineering» — это не ответственность. Это общая зона без финального решения. Когда срывается срок или двое спорят, работа встает, потому что последнее слово сказать некому.

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

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

Последний пункт важнее, чем команды обычно признают. Если после изменений никто не смотрит на длительность цикла, петли тихо возвращаются. Запрос, который раньше занимал 14 дней, может упасть до 10 на месяц, а потом снова вырасти до 13, потому что дополнительные проверки возвращаются по одной.

Быстрые проверки перед тем, как закрепить новый процесс

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

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

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

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

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

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

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

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

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

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

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

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

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

Если процесс проходит через несколько команд и никто не может договориться об ответственных, внешняя помощь может сэкономить много времени. Oleg Sotnikov через oleg.is работает со стартапами и небольшими компаниями как Fractional CTO и advisor, в том числе по такой уборке ответственности и процесса. Свежий взгляд помогает, когда команда слишком близко стоит к собственным привычкам.

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