Когда новый IT-руководитель приходит в компанию, от него почти всегда ждут быстрого результата. Причём ожидания обычно противоречивые: нужно и "разобраться", и "не сломать текущее", и "сразу всё ускорить". В такой обстановке очень легко наделать резких движений, которые выглядят энергично, но не дают устойчивого эффекта.
За последние годы мы видели много похожих ситуаций. Поэтому маршрут первых восьми недель у нас довольно приземлённый. Он не про героизм, а про то, чтобы сначала понять систему, потом задать рамку и только после этого усиливать изменения.
Недели 1–2. Не реформируйте то, чего ещё не поняли
Первые две недели — это не время для больших обещаний. В это время нужно собрать картину.
Что важно посмотреть:
- какие системы реально поддерживает команда;
- как выглядит входящий поток задач;
- кто принимает решения по приоритетам;
- где лежат критичные бизнес-процессы;
- какие обязательства уже есть перед руководством и пользователями;
- где накоплен технический и организационный долг.
Очень полезно провести короткие беседы 1:1 не только с сотрудниками IT, но и с ключевыми заказчиками из бизнеса. Обычно именно там слышно главное: где боль, где недоверие и где иллюзии.
Главная ошибка этого этапа — сразу начинать лечить симптомы. Например, ставить новую систему задач ещё до того, как понятно, почему старая не работает.
Недели 3–4. Зафиксируйте правила игры
После первичной диагностики нужно не "починить всё", а договориться о базовых правилах.
На этом этапе я бы сфокусировался на четырёх вещах:
1. Единый вход для задач
Пока задачи приходят из личных сообщений, звонков и встреч, управлять отделом невозможно. Неважно, используете вы Bitrix24, Jira или другой инструмент. Важно, чтобы появился один официальный канал входа.
2. Понятная классификация работ
Нужно отделить инциденты, мелкие пользовательские запросы, операционные задачи, проектную работу и улучшения. Пока всё лежит в одной куче, приоритизация будет политической, а не управленческой.
3. Видимый backlog
Руководитель должен видеть не только то, что уже взяли в работу, но и то, что стоит в очереди. Иначе невозможно обсуждать приоритеты честно.
4. Короткий набор метрик
Не надо сразу строить систему из двадцати показателей. Для начала достаточно видеть:
- объём входящих задач;
- текущий backlog;
- скорость реакции на разные типы запросов;
- долю задач с понятным владельцем и сроком.
Недели 5–6. Соберите рабочий ритм команды
Многие думают, что проблема IT-отдела решается наймом дополнительных людей. Иногда это правда. Но очень часто сначала нужно уменьшить хаос.
Здесь важен ритм. Команда должна жить не только реакцией на входящее, но и короткими циклами планирования. Формат может быть разным, но суть одна:
- регулярно пересматривать backlog;
- согласовывать приоритеты с бизнесом;
- фиксировать, что входит в ближайший цикл;
- обсуждать, что мешает работать нормально.
Я осторожно отношусь к словам "внедрим Scrum", потому что у компаний под этим бывает много ожиданий. Но если убрать термины, то руководителю нужны вполне понятные вещи: предсказуемость, обозримость работы и возможность не решать всё на эмоциях.
Недели 7–8. Покажите первый осмысленный результат
К восьмой неделе у руководства должен появиться ответ на вопрос: стало ли понятнее, как работает IT-функция.
Не обязательно к этому моменту запускать большую трансформацию. Но уже можно показать:
- из каких типов задач состоит поток;
- сколько задач входит и сколько реально можно переварить;
- какие процессы больше всего ломают управляемость;
- какие 2–3 изменения дали быстрый эффект;
- что нужно делать дальше и почему.
Это и есть взрослая управленческая коммуникация. Не "мы очень стараемся", а "вот текущее состояние, вот риски, вот план, вот первые результаты".
Какие быстрые победы обычно работают
За первые 8 недель чаще всего дают эффект не крупные проекты, а изменения в операционном контуре:
- единый приём заявок;
- приоритизация backlog;
- прозрачная доска работы;
- базовая автоматизация отчётности;
- убирание дублирующих ручных операций;
- инвентаризация систем и владельцев.
Это кажется не очень эффектным на презентации. Но именно такие шаги создают фундамент, без которого любые большие инициативы начинают буксовать.
Чего делать не стоит
Есть несколько ошибок, которые дорого обходятся новому руководителю:
Сразу обещать большой прорыв
Если вы ещё не понимаете глубину проблем, любые точные обещания — это ставка вслепую.
Делать ставку только на инструмент
Новый таск-трекер, новая wiki, новые шаблоны — всё это может помочь, но не заменяет управленческих правил.
Попытаться лично контролировать всё
В первые недели это особенно соблазнительно. Но если руководитель становится горлышком всех решений, отдел быстро упрётся в его личную пропускную способность.
Игнорировать политику и ожидания бизнеса
IT-отдел не живёт отдельно от компании. Нужно понимать, кто влияет на приоритеты, где чувствительные зоны, какие обещания уже даны и какие конфликты тянутся давно.
Как понять, что вы двигаетесь правильно
Хороший сигнал — когда через 6–8 недель становится меньше шума, а не больше. Это может проявляться в простых вещах:
- сотрудники реже жалуются на хаотичные переключения;
- бизнес лучше понимает, как подаются и приоритизируются задачи;
- руководителю проще объяснять ограничения и ресурсы;
- появляются данные вместо ощущений.
Если этого не происходит, значит вы либо слишком рано пошли в реформу, либо не задали базовую рамку.
Вывод
Первые восемь недель нового IT-руководителя — не про демонстрацию силы. Они про создание опоры. Нужно понять реальность, договориться о правилах, собрать ритм, убрать хаос во входящих и показать первый честный, измеримый результат.
Это не выглядит как революция. Зато именно так обычно и начинается нормальная зрелая IT-функция, которая потом уже может заниматься развитием, а не вечным спасением ситуации.
Читайте также: