Разработчики не стали писать код быстрее.
Компания просто перестала планировать работу так, будто у команды бесконечная емкость.
До изменений типовой бизнес-запрос мог идти от входа до приемки бизнесом до двух месяцев. Команда при этом не сидела без дела: люди писали код, чинили ошибки, отвечали на вопросы, переключались между срочными задачами, возвращались к старым доработкам и снова уточняли требования.
Снаружи это выглядело как работа.
Для бизнеса результат выглядел иначе: сроки непонятны, задачи двигаются рывками, приоритеты меняются по последнему сильному сигналу.
Это была крупная FMCG retail сеть: более 70 млрд рублей оборота и более 600 магазинов.
Проблема была не в скорости разработки. Проблема была в том, что компания планировала работы больше, чем команда могла реально закрыть.
Команда не была медленной. Ее разрывали приоритеты
Запросы приходили отовсюду. Оператор склада мог написать напрямую программисту. Директор по логистике мог поставить задачу руководителю разработки. Руководитель функции мог прийти со своим Excel. Если прилетала задача от CEO, все бросали то, что делали до этого.
Формально это выглядело как высокая вовлеченность.
На деле управляемость уже была потеряна.
У разных людей были разные списки задач. Часть жила в почте, часть - в мессенджерах, часть - в Excel. У одной задачи могли быть разные версии описания. Приоритеты менялись не по экономике и не по ресурсу, а по громкости запроса.
Каждый заказчик считал свою задачу главной. И был по-своему прав.
Логистика видела свои потери. Коммерция - свои. Розница - свои. Склад - свои. CEO видел общую картину, но не видел текущую загрузку команды и цену каждого переключения.
В такой системе команда работает не по плану. Она работает по последнему сильному сигналу.
Главная потеря была не только в очереди. Главная потеря была в незавершенной работе.
Разработчик уже вошел в контекст, разобрал часть логики, задал вопросы, начал решение - и бросил, потому что появилась новая срочная задача. Эти часы не видны в backlog как отдельная строка. Но они уже оплачены.
Для собственника это можно быстро проверить на своей экономике.
Возьмите полную стоимость месяца работы своего разработчика: зарплату, налоги, рабочее место, управление, инфраструктуру.
Если из-за постоянных переключений компания накопила хотя бы 250-300 часов незавершенной работы, это уже почти два месяца оплаченного времени одного разработчика.
Не отпуска. Не обучения. Не инвестиций в архитектуру.
Просто работы, которая была начата, остановлена, забыта, поднята заново и снова не дошла до бизнес-результата.
Потом к задаче нужно вернуться: снова вспомнить контекст, проверить, что изменилось, договориться с бизнесом и только потом продолжить.
Так команда может быть загружена на 100%, но бизнес все равно не получает предсказуемый результат.
Почему я не начал с найма
Первое желание в такой ситуации обычно простое: нанять еще разработчиков.
Backlog большой - значит, мало людей.
Логично, но только на первый взгляд.
Если входящий поток грязный, новые разработчики просто начнут быстрее перерабатывать хаос. Они получат те же неясные требования, те же срочные переключения, те же задачи без владельца, те же конфликты приоритетов.
Больше людей в такой системе не всегда дает больше результата. Часто растет другое: задач надо объяснять больше, решений согласовывать больше, релизов тестировать больше, кода поддерживать больше, людей переключать между срочными просьбами тоже больше.
Поэтому я начал не с найма.
Сначала нужно было понять, сколько результата команда реально может закрывать за неделю без постоянного срыва фокуса.
Посчитали реальную емкость
В команде было 8 разработчиков.
На бумаге это выглядело просто:
8 человек x 40 часов = 320 часов в неделю.
Но разработчик не тратит 100% времени на новое. Есть исправление ошибок, технический долг, уточнения, переключения, поддержка, обсуждения, проверка гипотез, разбор старого кода.
Для первого планирования мы взяли 50%.
Получилось:
8 разработчиков x 40 часов x 50% = 160 часов в неделю на новое.
Это было рабочее ограничение.
Если на новое реально есть 160 часов, нельзя планировать на 300. Нельзя брать в неделю 25 задач, если по оценке они требуют 500 часов. Нельзя обещать всем и сразу, а потом удивляться, что сроки не выполняются.
После этого разговор с бизнесом изменился.
Раньше он звучал так: "Почему вы не берете нашу задачу?"
Теперь иначе: "На эту неделю у команды есть 160 часов на новое. Вот задачи, которые помещаются в эту емкость. Если добавляем новую, нужно снять что-то из списка".
Разговор стал неприятнее. Зато честнее.
Пока емкость невидима, кажется, что ИТ просто сопротивляется. Когда емкость посчитана, спор становится предметным.
Нельзя бесконечно добавлять срочное, не снимая другое.
Первый недельный план
Дальше мы собрали недельный план. Не "занимаемся логистикой", не "в приоритете розница", не "постараемся закрыть важное", а конкретный список задач, который помещался в 160 часов.
В работу брали не все, что горит. В работу брали то, что команда реально может закрыть.
Для хаотичной системы это непривычно. Раньше план был формой надежды: все понимали, что он может поменяться завтра, сегодня после обеда или сразу после звонка сверху.
Теперь логика стала другой. Если задача входит в неделю, команда за нее отвечает. Если не входит, она не исчезает, но и не притворяется, что уже в работе.
Когда все "почти в работе", не управляется ничего.
На первой неделе это быстро перестало быть теорией. В план уже входили задачи логистики, коммерции и розницы. Потом пришел новый срочный запрос: его надо было сделать сейчас, потому что он влиял на операционный контур.
Раньше команда просто взяла бы его сверху. План стал бы больше, сроки - менее честными, а через неделю все снова обсуждали бы, почему часть задач не закрыта.
Мы сделали иначе: показали список и емкость.
Если новый запрос входит в неделю, из плана надо снять другую задачу на сопоставимые часы. Не перенести в голове. Не оставить "почти в работе". А официально убрать из недели и показать бизнесу, что именно вытеснено.
С этого момента приоритет приходилось выбирать руками.
85% недельного плана
Через неделю 85% задач из недельного плана было сделано.
Для зрелой delivery-команды это может звучать обычно. Для той ситуации это был перелом.
Раньше никто не мог предсказать почти ничего. Задача могла стартовать, остановиться, сменить приоритет, вернуться на уточнение, уступить место более срочной, потом снова всплыть через месяц.
Теперь впервые появился простой контур: что обещали, что вошло в емкость, что сделали, что не сделали, почему не сделали и что меняем в следующем плане.
Тогда это не называли методологией. Просто впервые стало видно, что обещали, что сделали и где сломался план.
Бизнес увидел, что сроки могут выполняться. Команда увидела, что план может быть реальным. Руководители увидели, что приоритет - это выбор внутри ограниченного ресурса.
После этого спор про "ИТ опять не делает" стал другим. Появилась фактура.
Прозрачность сняла обиды
До изменений обиды были. Не потому что кто-то специально кого-то игнорировал. Просто система выглядела несправедливой.
Одному подразделению что-то сделали быстро. Другому - нет. Чья-то задача попала в работу. Чья-то зависла. Кто-то достучался напрямую. Кто-то ждал в общем списке. У кого-то был доступ к руководителю разработки. У кого-то не было.
В такой ситуации люди начинают объяснять задержки не емкостью команды, а отношением к себе:
"Им делают, а нам нет".
"Их задачи важнее".
"Нас опять отодвинули".
Когда появилась прозрачная очередь, напряжение стало уходить. Не сразу, но быстро.
Люди увидели, что задачи не исчезают в черной дыре. Видно, что вошло в неделю. Видно, что не вошло. Видно, почему не вошло. Видно, когда задача возвращается в план. Видно, что сроки начали выполняться.
И тогда ожидание стало нормальным.
Если человек понимает свое место в очереди и видит, что очередь движется, он готов ждать.
Проблема была не только в сроках. Проблема была в недоверии к системе. Когда система стала прозрачной, доверие начало возвращаться.
Почему дальше стало быстрее
50% времени на новое было консервативной оценкой для старой модели. Раньше половина времени уходила не только на объективные технические вещи.
Огромную часть съедали переключения, возвраты, уточнения, конфликты приоритетов и задачи, которые вообще не должны были доходить до разработки.
Когда входящий поток стал чище, лишних переключений стало меньше. Команда перестала начинать десять задач одновременно. Бизнес-владелец стал отвечать за результат. Появился единый список. Появился недельный ритм.
После этого на новое можно было планировать уже ближе к 75% времени.
Не потому что людей заставили работать больше. А потому что меньше времени стало сгорать в хаосе.
Горизонт планирования расширился до месяца. Точность месячного плана стала выше 90%. Около 80% запросов начали закрываться примерно за 2 недели.
До изменений типовой бизнес-запрос мог идти от входа до приемки бизнесом до двух месяцев.
Разница была не в том, что разработчики внезапно стали писать код в четыре раза быстрее. Разница была в том, что команда перестала работать в режиме, где любой новый сигнал мог разорвать уже начатую работу.
Скорость начинается не в IDE
Многие компании пытаются ускорить разработку внутри разработки: добавляют контроль, статусы, встречи, давление на сроки и отчеты по задачам.
Но если задача плохо вошла, дальше ускорять почти нечего.
Нет владельца - разработчик ждет решения. Нет критерия приемки - команда угадывает. Бизнес не понимает, какой эффект нужен - задача расползается. Приоритет меняется каждые два дня - скорость превращается в имитацию. В работу попало то, что можно было закрыть настройкой - команда тратит код на то, что кодом не должно решаться.
Скорость разработки начинается до кода.
Но после входного фильтра появляется следующий вопрос: как управлять тем, что осталось?
В этом кейсе ответ был простым: реальная емкость, ограничение WIP, недельный план и прозрачный выбор, что входит в работу, а что нет.
Где эта модель ломается
У такого подхода есть цена.
Первая - нужно право отказа. Если команда не может сказать "это не помещается в емкость", недельный план превращается в фикцию. Все снова становится срочным, а значит, ничего не становится управляемым.
Вторая - нужна поддержка сверху. Если CEO или сильный руководитель может в любой момент обойти правила и поставить задачу напрямую, система начинает разрушаться. Не потому что задача сверху плохая. А потому что одно исключение быстро становится сигналом для всех остальных: правила необязательны.
Третья - бизнес должен принимать результат. Если владелец функции не готов отвечать за приемку, задача снова зависает в серой зоне. Код есть. Релиз есть. Результат не принят. Следующая задача уже пришла.
Четвертая - нужна прозрачность. Если очередь непрозрачна, ожидание быстро превращается в обиду. Люди начинают думать, что задачи двигаются не по приоритету, а по личному доступу, статусу или громкости.
Когда видно, что вошло в план, что не вошло и почему, ожидание становится управляемым. Люди готовы ждать своей очереди, если видят, что очередь действительно движется.
Для CEO вывод простой
Если команда постоянно занята, но сроки непредсказуемы, найм не должен быть первым ответом.
Сначала надо увидеть емкость: сколько часов реально есть на новое, сколько задач уже начато, сколько работы каждый день сгорает на переключениях, какая задача вытесняет другую, что можно обещать на неделю и что нельзя обещать без самообмана.
Разработка становится предсказуемой не от давления. Она становится предсказуемой, когда компания начинает выбирать: что входит в работу, что не входит, что снимается ради нового приоритета и за какой результат бизнес готов отвечать.
Пока компания не видит емкость команды, она не управляет разработкой.
Она управляет ожиданиями.