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

Боль (первые три месяца — сплошной крик) Я пришел в международную компанию, где бизнес рос на 400% в год. Миллионы пользователей, 180 ИТ-инженеров, бюджет 140 млн руб./мес. Казалось бы — рай. Но на деле ИТ был черной дырой. В первую же неделю ко мне в кабинет влетел продакт и заорал: «Денис, почему фича Х не в проде уже две недели?!» Я открыл трекер и ничего не понял. Задачи летели отовсюду: из Telegram, из устных просьб в коридоре, из корпоративной почты. Ветки в Git назывались «fix_vasya_2», «test123», а однажды в мастер закоммитили пароль от продакшена (да, такое бывает). Самое страшное: на вопрос «сколько времени уходит на задачу?» никто не мог ответить. Ни я, ни тимлиды, ни бизнес. Инженеры тратили 60% времени на тушение непонятных пожаров вместо развития продукта. Третьей линии поддержки не существовало — критичные баги висели по две недели, клиенты уходили.

Анализ

Мы с командой провели недельный аудит. Выяснили пять смертельных проблем: 1. Нет единого окна входа задач — 7 каналов коммуникации. 2. Git Flow как миф — кто во что горазд. 3. Поддержка без эскалации — второй линии нет, третий сам тыкается в коде, стараясь понять - что делали соседи. 4. Ноль метрик — даже Lead Time не считали. 5. Бюджет — черный ящик. Деньги уходили, но ROI никто не отслеживал. Я понял: расширять штат бессмысленно. Сначала — процессы.

Действия · Месяц 1: закрыл все каналы, кроме одного — корпоративного трекера. Объявил: «Задача не в трекере — ее не существует». Было много крика, особенно от старых сеньоров. Перетерпел. · Месяц 2: внедрил жесткий Git Flow и чек-лист для описания задач. Ввел статусы: «на беклоге», «в аналитике», «в разработке», «в тесте», «готово». Настроил автоматические уведомления. · Месяц 3: разделил потоки. Критические баги — waterfall (фикс в течение дня). Бизнес-задачи — скрам с двухнедельными спринтами. Выделил третью линию поддержки — лучших инженеров, которых раньше дергали по каждому чиху, оставил только как ротируемых дежурных. · Месяц 4: сел с аналитиками и нарисовал дашборды в трекере. Метрики: Lead Time (время от задачи до релиза), WIP (сколько задач в работе), распределение времени по линиям. · Месяц 5: внедрил OKR. Например: «Сократить Lead Time для критических багов с 5 до 2 дней». И привязал это к бизнесу — каждый день простоя клиент теряет деньги. Контроль (как перестали верить на слово) Каждый понедельник в 10 утра — 15-минутный дашборд с продактами. Я показывал цифры: сколько багов упало, сколько закрыто, какой WIP, тренд по Lead Time. Если WIP превышал норму — стоп-кран, новые задачи не брали до разгрузки. Бизнес сначала злился, потом привык. А когда увидели, что критические баги перестали висеть неделями — сами начали требовать дашборды.

Результат Через полгода: · Время решения инцидента 3-й линией — с 14 дней до 2 дней. · Прозрачность для бизнеса — с 0% до 100% (любой продакт в любой момент видел статус своей задачи). · Бюджет ИТ — вырос с 140 до 270 млн руб. Потому что бизнес увидел: каждый вложенный рубль ускоряет вывод фич и снижает потерю клиентов. · Текучесть инженеров снизилась на 30% — они перестали гореть на бессмысленных тушняках. Выводы (чем готов поделиться) 1. Масштабирование начинается с процессов, а не с серверов. Можно купить бесконечно железа, но без правил коллапс наступит быстрее. 2. Боль — лучший катализатор. Без крика продакта в кабинете я бы еще полгода терпел хаос. 3. Метрики не для отчетов, а для управления. Если не можешь измерить — не сможешь улучшить. 4. Бюджет ИТ — это не затраты, а инвестиции. Но только когда есть визуальное обоснование.

Как я к этому пришел, картинки и подробности в статье: https://habr.com/ru/articles/1046796/