Я не ускоряю продукт новой командой, пока решения ждут одной встречи

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

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

Когда дополнительная команда только увеличивает ожидание

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

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

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

Как я делаю очередь решений видимой

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

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

Полезно хранить вопрос рядом с задачей, а не в чате. Тогда видно, почему задача стоит, и через месяц не приходится восстанавливать решение по десяти сообщениям и памяти участников. Это тот же принцип, что и в разборе IT-аудита через точки решений: список программ мало говорит о том, где бизнес теряет время.

Временное решение тоже должно быть решением

Иногда информации действительно не хватает, а ждать нельзя. Тогда помогает не бесконечное «вернёмся позже», а временное правило с датой пересмотра. Например: в первой версии разрешаем только один вид возврата, потому что бухгалтерский контур ещё не готов к двум другим; через три недели проверяем реальные случаи и принимаем постоянное решение.

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

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

Не все решения должны попадать на одну встречу

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

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

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

Как не превратить видимость в бюрократию

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

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

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

Какие признаки говорят, что очередь стала опасной

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

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

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

Разговор с командой без поиска виноватых

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

Такой подход хорошо работает и между функциями. Продажи не обязаны понимать все детали архитектуры, а разработка — угадывать условия договора. Но обе стороны могут принести вопрос в форме, которая позволяет другой стороне принять решение. Когда это становится привычкой, скорость растёт без призывов «работать быстрее».

Что можно сделать в ближайшую неделю

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

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