Как я за 6 месяцев превратил ИТ-ад в конвейер: личный опыт в компании-единороге с 4 млрд пользователей

Привет, Хабр! Меня зовут Денис. Я CIO. И я хочу честно рассказать, о своем опыте, как привести к порядку хаос в крупной международной компании. Без команды консультантов, без покупки дорогих инструментов, просто засучив рукава.

Когда я пришел в эту компанию, она росла на 400% в год. 4 млрд пользователей, 180 IT-сотрудников, бюджет 140 млн руб. в месяц. Звучит как успех? На деле IT был «черной дырой»: бизнес не понимал, куда уходят деньги, задачи тонули, инциденты решались месяцами, а релизы срывались каждый спринт.

За полгода я спроектировал и внедрил новую архитектуру поддержки, перестроил процессы разработки, выстроил аналитику с нуля и доказал бизнесу, что IT – не расходы, а актив. В итоге бюджет вырос до 270 млн в месяц – пропорционально росту прибыли.

Я пишу это, чтобы вы увидели, как грамотный подход может изменить IT-ландшафт компании-гиганта. Поехали.

🧠 Диагноз: я провел аудит и нашел 5 смертельных проблем

Первые две недели я не трогал команду. Я просто слушал, смотрел и задавал вопросы. Вот что я выяснил лично:

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

2. Git Flow? Не слышали. Ветки назывались «fix_vasya_2», мержились когда попало, релизы – хаотично. Однажды мы откатили продакшен из-за того, что разработчик закоммитил в мастер пароль от продакшена.

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

4. Аналитика = ноль. На вопрос «сколько времени в среднем занимает задача?» мне пожимали плечами. Бизнес не верил ни одной оценке.

5. Бюджет 140 млн был черной дырой. Никто не мог объяснить, сколько стоит конкретный проект или фича. Для бизнеса ROI составлялся на основе предположений.

Я понял: нужно не «улучшить процессы», а пересобрать всю систему с нуля. И делать это буду я сам – как архитектор.

План изменений:

Единый канал поставки задач

Перенаправить все потоки поступления задач через одну систему. Сформировать Жизненный цикл задачи (ЖЦЗ). Реализовать подход оценки через скрам-покер и исторические данные пропускной способности отдела.  

Дежурства 

Организовать регламент по дежурным как от разработки, так и от системных администраторов.

Стандартизация задач

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

Выделение потоков ITIL

Организовать 3 линии технической поддержки. Выстроить процессы связи с клиентами, через автоматизацию оповещений с 3й линии на 1ю и до клиента. Жизненный цикл инцидента (ЖЦИ). Наполнение базы знаний, для увеличения скорости обработки заявлений на 1й линии. 

Создание 3 линии

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

Аналитика

Выстроить процессы анализа задач на входе, заполнение документации по проектам, актуализации информации после внесения изменений, хранение компетенций по проектам в едином месте со взаимозаменяемыми носителями знаний.

Метрики

После приведения к единому формату статусов и потоков задач, внедрить метрики и отчетность, за счет автоматизации через BI  аналитику задач.

Ключевые показатели

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

Код ревью и архитектура

Провести обновление php до новой версии, обновить ядро laravel, работать в сторону архитектуры DDD.

Внедрение шины данных

Переход на 1С Шина для интеграции всех сервисов между собой.

🏗️ Моя стратегия: Единый канал поставки задач

Сначала сконцентрировался на ключевых элементах, которые зафиксировал:

Я сел и нарисовал на коленке схему. Старую – хаотичную. И новую – как должно быть. Вот она:

Ключевая идея, которую я продал бизнесу на Совете директоров: «Вы даете задачу только через трекер. Зато вы видите её статус в реальном времени. Никаких «потерялось». В обмен мы гарантируем прозрачность и предсказуемость». Мне поверили. Но я знал, что слова ничего не стоят – нужны железные правила.

🔧 Что я внедрил

1. Именование веток

В компании не было даже внятного именования веток. Я сел и написал документ «Стандарт работы с Git для всех разработчиков» на 3 страницы. Без воды. Вот основные пункты:

• Мастерская ветка – только то, что уже в продакшене. Никаких прямых коммитов.

• Develop – интеграционная ветка для следующего релиза и постоянных автотестов.

• Feature/* – каждая новая фича. Название: feature/#ID-1234_kratkoeOpisanie и у каждой фичи может быть множество дочерних Task/* вливаемых в общую фичу, на прод идут все в виде одной фичи

• Bug/* – исправления багов, найденных в тесте.

• Hotfix/* – для продакшена, срочно.

• Release/* – подготовка релиза.

  

2. Перестройка Git Flow

Правило, которое я ввел жестко: Pull Request обязателен. Минимум один аппрув от senior-разработчика, а для изменений в ядре – от архитектора. Без этого мерж не проходил. Я лично проверил первые 50 PR, чтобы привычка закрепилась.

Кроме того, я настроил в CI автоматическую проверку: если в названии ветки нет номера задачи из Jira/Tracker – сборка падает. Это заставило всех связать код и задачи.

3. Жизненный цикл задач (t2m)

Каждый блок длительностью 2 недели

4. Три линии поддержки – я разделил зоны ответственности

Раньше разработчики и аналитики сами отвечали на звонки внутренних заказчиков. Я сказал: «Стоп. С этого дня – только через тикет-систему, и 3-я линия не трогает проблемы, пока они не прошли 2-ю».

• 1-я линия – операторы. Скрипты ответов, эскалация по шаблону.

• 2-я линия – аналитики (вырастил из синьоров поддержки). Они разбирают сложные кейсы, воспроизводят, дают решение для 1-й линии. Код не трогают.

• 3-я линия – разработка . Только баги, подтвержденные 2-й линией, составил из нанятых постоянных сотрудников, плюс дежурные поспринтово из команд разработчики, для получения межкомандного опыта.

  

Я лично обучил первую группу аналитиков, написал чек-листы эскалации. Через месяц время решения инцидентов упало в 3 раза.

3. Единый трекер – я выжал максимум из Yandex Tracker

Из-за санкций, я не мог использовать Jira + плагины для аналитики (вроде Flow Companion). Я решил: «Сделаем сами, на коленке, но сделаем». Я лично настроил в Tracker:

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

  

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

  

• Кастомные поля: «Исключить из Leadtime» (чекбокс), «Компонент» (продукт), «Сложность» (1-10).

• Виджеты дашборда:

  • График событий – показывает производительность команды. Измеряем числом закрытых SP за спринт. На основе этих данных планируем будущие спринты.Для измерения этого показателя используем виджет График событий. В качестве ключевого параметра используем дату завершения. Выбираем в источнике задач нужные типы задач: Задачи, Исследования и Ошибки, Epics нам здесь не нужны. Выбираем статус Закрыт, потому что для задач в статусе Отменен тоже есть дата завершения, но они нас не интересуют. Группировку лучше делать по размеру спринта, в нашем случае — это две недели.

    

    Время цикла –Для измерения этих показателей используем виджет Время цикла. Для Lead Time начальным является статус принятия обязательств — в нашем случае это Будем делать, а для Time To Market начальный статус Новый. Исключаем фильтрами Отмененные задачи, задачи с типом Epic и задачи, которые мы намеренно хотим исключить (например, заблокированные на долгое время). Инструмент Jira flow companion умеет делать такое из коробки, а в Yandex Tracker мне пришлось накостылять кастомное поле Исключить из Leadtime.

    

    

    Как читать статистику: 95% задач, взятых в работу, закрыты менее чем за 19 дней. 75% задач, взятых в работу, закрыты менее чем за 13 дней. В среднем задачи закрываются за 7 дней.

  • Поток – WIP (количество задач в работе).
    Этот показатель не рассчитывается в Yandex Tracker. Есть виджет Поток, но показатель эффективности потока он не рассчитывает. Зато можно видеть сколько задач одновременно у команды в работе. Если видим резкий подъем — скорее всего последует увеличение показателя Lead Time, нужно сосредоточиться на решении задач в работе и сократить количество новых задач.

    

    Создано/Решено – динамика бэклога.

    

Я сам написал инструкцию для команды: как проставлять резолюции, чтобы не засорять аналитику. Я сам настроил авто-переходы между статусами по коммитам (через webhook в Git). И когда я показал бизнесу первый отчет с цифрами – «95% задач закрыты менее чем за 19 дней» – они ахнули. До этого никто не видел цифр.

4. Культура метрик – я привязал KPI к бизнесу

Я разработал систему OKR для IT. Не просто «сделать 100 задач», а:

• Для разработки: Сократить Lead Time для критических багов с 5 дней до 2 дней за квартал.

• Для поддержки: Достичь SLA 95% инцидентов, решенных 2-й линией за 4 часа.

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

📈 Результаты через полгода

Вот цифры, которые я получил:

Важный момент: бюджет вырос не потому, что я просил. А потому что бизнес увидел: каждый рубль, вложенный в IT, возвращается в виде скорости вывода фич на рынок. Я лично строил эту финансовую модель на основе метрик Throughput и Lead Time.

📈 Итоги: что мы получили через полгода?

Результаты говорят сами за себя:

1. ИТ перестал быть «черным ящиком». Бизнес наконец увидел цифры: сколько задач делает ИТ, сколько времени это занимает, и во что это обходится.

2. Система стала предсказуемой. Внедрение единых правил (ITIL, Git Flow, единый канал поставки) резко снизило количество инцидентов и авралов.

3. Мы доказали ценность ИТ. Прозрачность и предсказуемость привели к тому, что бизнес перестал резать бюджеты, а наоборот — увеличил инвестиции. За год бюджет вырос с 140 до 270 млн рублей. Но главное: этот рост был пропорционален росту прибыли бизнеса. Мы стали не статьей расходов, а драйвером роста.

💎 Выводы: как повторить этот путь в вашей компании

Если вы вынесли из этого текста только одно, пусть это будет следующее:

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

2. Любая трансформация ИТ — это трансформация мышления. Самое сложное было не настроить Git Flow, а убедить команду, что «оно надо». Люди не любят изменения. Будьте к этому готовы и действуйте постепенно, объясняя выгоды.

3. Начните с малого. Не пытайтесь охватить необъятное. Вместо внедрения тяжелого ITSM-решения, начните с простой аналитики в том инструменте, который у вас уже есть (даже в Jira или Yandex Tracker). Настройте один виджет с Lead Time — и вы уже на полпути к успеху.

4. Не бойтесь костылей. Если готового инструмента нет — напишите скрипт, добавьте кастомное поле, используйте Excel. Главное — начать собирать данные. А совершенствовать инструменты вы будете потом, когда данные докажут их необходимость.

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

Скрытый текст

На основании большого опыта перестройки процессов, сделал отдельный курс, в каждой компании приходилось разжевывать одно и то же.
Проще оказалось — записать раз и потом показывать.
Не сочтите за рекламу, это для тех, кому реально это нужно и интересно. Пришлось в тему к статье, самоцель — не реклама курса.
https://stepik.org/a/253861