Первые недели с новой IT-командой часто оценивают по числу закрытых заявок. Это полезно, но не главное. В начале сотрудничества среда почти всегда содержит неизвестные устройства, старые договорённости, незафиксированные зависимости и накопленные решения. Требовать, чтобы всё было исправлено за тридцать дней, значит подменить управляемый переход красивым обещанием.
Разумное ожидание другое: к концу первого месяца руководитель должен понимать исходную картину, порядок обращений, главные риски и список решений, которые нельзя принять без компании. Ни один из этих результатов не требует раскрывать технические секреты в отчёте; важно, чтобы они были проверяемы.
Что считается хорошим результатом первого месяца
| Результат | Зачем он нужен | Что не следует обещать |
|---|---|---|
| Исходная картина | Показывает известные системы, внешние зависимости и зоны, которые ещё требуют проверки | Полный и окончательный каталог всего за несколько дней |
| Единый порядок обращений | Сотрудники знают, куда обратиться и как узнать статус | Мгновенное решение любого вопроса без приоритета |
| Первичная сортировка рисков | Отделяет срочные угрозы непрерывности работы от плановых улучшений | Устранение всех накопленных недостатков без бюджета и согласований |
| План ближайших действий | Связывает технические наблюдения с ответственными и сроком пересмотра | Гарантированный эффект там, где решение зависит от третьих сторон |
Неделя 1: договориться о границах и канале связи
Команда и компания должны назвать критичные для работы процессы, контактных лиц, допустимый порядок эскалации и известные внешние зависимости: провайдеров, разработчиков учётной системы, поставщиков оборудования. Это не формальность. Без общего языка даже быстрый инженер будет решать локальные симптомы, а руководитель — узнавать о проблеме случайно.
Полезно сразу разделить три потока: срочные сбои, регулярная эксплуатация и отдельные изменения. Тогда плановые улучшения не маскируются под аварии, а аварии не исчезают в общей очереди.
Недели 2–3: получить исходную картину, а не изображать полный аудит
На этом этапе важно зафиксировать, что известно, что подтверждено и что пока остаётся предположением. Для руководителя достаточно увидеть критичные сервисы, основные рабочие группы, внешние зависимости, повторяющиеся обращения и список неизвестных зон. Хорошая команда не делает вид, что нашла всё сразу: она объясняет, как и в каком порядке будет закрывать пробелы.
В стандарте управления контрактами GOV.UK при передаче сервиса отдельно выделены план перехода, распределение ответственности, передача знаний и данных, а также меры на случай срыва перехода. Этот источник описывает государственные закупки, а не малый бизнес; его нельзя механически переносить в договор. Но управленческий принцип применим: передача работы должна оставлять компании знания, ясные роли и непрерывность, а не зависимость от памяти отдельных людей.
Неделя 4: превратить наблюдения в решения
К финальному обзору нужен не перечень технических терминов, а короткая картина выбора. По каждой значимой находке полезно указать:
- какой процесс или сервис затронут;
- что подтверждено, а что ещё проверяется;
- каково последствие без действий;
- какие есть варианты и от кого зависит решение;
- какой следующий факт покажет, что ситуация улучшилась.
Например, сообщение «оборудование старое» не помогает руководителю. Полезнее: «в такой-то рабочей группе нет резерва; при отказе восстановление займёт больше времени; есть два варианта замены; нужно выбрать приоритет до следующего месяца». Это не обещание избежать всех сбоев, а основание для решения.
Чего не стоит принимать как итог перехода
- Отчёт только из количества часов и закрытых тикетов без картины причин и открытых вопросов.
- Список покупок без приоритета, последствий и ответственного за решение.
- Фраза «всё под контролем», если неизвестно, какие системы проверены.
- Ситуация, в которой документация, история решений и контакты остаются только у внешней команды.
- Обещание исправить всё до того, как согласованы объём работ, доступные окна и бюджет.
Первый месяц — это начало управляемости, а не приёмка идеальной инфраструктуры. Если после него видны исходная ситуация, порядок взаимодействия, список приоритетов и следующий совместный план, переход имеет основу. Если нет — разумно начать с сервисного обзора или IT-аудита, чтобы отделить реальные факты от ожиданий.
Итог: за первые 30 дней руководитель должен получить не обещание «всё исправить», а прозрачную точку старта: известные и неизвестные зоны, порядок обращений, приоритеты, владельцев решений и дату следующей проверки. Именно это превращает смену исполнителя в управляемый переход.