Я строю IT-план от рисков, которые нельзя оставить до следующего квартала

Когда в компании появляется IT-план, его часто начинают обсуждать с календаря: что внедрим в январе, что перенесём на весну, когда купим новую систему. Я начинаю с другого вопроса: какую неприятность бизнес уже не может спокойно перенести на следующий квартал?

План без этого вопроса легко превращается в аккуратный список работ. Он приятно выглядит в презентации, но не помогает выбрать, что делать, когда денег, людей и внимания на всё не хватает. А они почти всегда не хватает.

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

Почему календарь плохо расставляет приоритеты

Календарь любит ровные блоки. В первом квартале — аналитика, во втором — внедрение, в третьем — доработки. Но работа компании редко идёт ровно. У поставщика меняется формат обмена, уходит человек, который держал в голове половину процесса, продажи открывают новый канал, а старый отчёт внезапно становится основой для важного решения.

Если в этот момент план умеет отвечать только датами, команда начинает защищать уже обещанные пункты. Самая заметная задача получает время, а самая опасная ждёт следующего пересмотра. Это похоже на ремонт дома: можно по графику выбирать цвет стен, пока в подвале течёт труба. Красивый календарь не делает порядок разумным.

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

Риск — это не абстрактная «уязвимость»

Слово «риск» часто звучит так, будто его надо отдать юристам или службе безопасности. В рабочем IT-плане я называю риск простым предложением: «если произойдёт это, компания не сможет нормально сделать вот это».

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

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

Четыре вопроса к каждому пункту

Любую задачу в плане я стараюсь пропустить через четыре вопроса.

1. Что именно может пойти не так? Не «система устарела», а конкретное событие и его последствия.
2. Кто заметит проблему первым? Клиент, оператор, финансовый директор или технический специалист? Чем позже заметят, тем выше цена.
3. Какой рабочий день пострадает? Важно привязать риск к операции: отгрузке, закрытию периода, расчёту цены, приёму обращения.
4. Что станет иначе после шага? Нужен наблюдаемый результат: есть резервный владелец, сверка проходит до отправки, ошибка попадает в понятную очередь, восстановление проверено.

Эти вопросы быстро отсеивают декоративные пункты. Формулировка «обновить платформу» ещё не отвечает ни на один из них. Возможно, обновление действительно нужно. Но тогда план должен объяснить, какое ограничение оно снимает и как команда это увидит.

Не все риски одинаково срочные

Я не пытаюсь превратить выбор в математическую церемонию. Достаточно честно посмотреть на три вещи: насколько часто работа проходит через слабое место, насколько болезненна ошибка и можно ли её заметить до того, как она дошла до клиента или денег.

Редкая ошибка в служебном отчёте может быть неприятной, но не обязательно первой в плане. А ежедневная ручная правка цены — даже если каждый раз её «легко поправить» — постепенно становится дорогой привычкой. Она забирает время, создаёт разные версии правды и приучает людей обходить систему.

Особое внимание я уделяю тихим сбоям. Явная ошибка хотя бы останавливает человека. Хуже, когда интерфейс показывает успех, но часть данных не дошла дальше. В таком случае у компании нет ощущения аварии, зато есть цепочка неверных решений. Это одна из причин, почему для критичных операций нужно заранее договориться: что считается нормой, кто видит отклонение и что делает дальше.

План должен начинаться с владельца, а не с подрядчика

У пункта IT-плана должен быть владелец со стороны бизнеса. Не человек, которому «передали проект», а тот, кто может сказать, что рабочий результат действительно изменился. Если задача касается отгрузки, это не только разработчик. Если касается согласования договора, это не только администратор системы.

Без такого владельца команда обсуждает средство, а не результат. Подрядчик просит требования, бизнес ждёт готовую кнопку, и оба считают, что мяч на чужой стороне. Для крупных вложений полезно заранее пройтись по вопросам, которые я собрал в материале о пяти вопросах перед серьёзным IT-вложением. Они помогают не спутать покупку инструмента с решением задачи.

Владелец не обязан быть техническим специалистом. Его зона — назвать правило, принять рабочий результат и не дать задаче расползтись на всё сразу. Техническая команда отвечает за способ, ограничения и безопасное выполнение. Когда эти роли смешаны, план обычно выглядит подробным, но двигаться начинает только после очередного аврала.

Как выглядит один хороший пункт

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

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

Другой пример: «Убрать единственную точку знания о ежемесячном закрытии: описать последовательность на реальном цикле, назначить замену, провести один проход без основного исполнителя». Это не столько документирование, сколько проверка устойчивости процесса. Если второй человек не может повторить путь, проблема не исчезает от красивой папки с регламентами.

Сначала маленькая проверка, потом большой проект

Когда риск сформулирован, возникает соблазн сразу запускать большой проект. Я предпочитаю сначала выбрать короткую проверку. Она может занять несколько дней: пройти один заказ от сайта до учёта, восстановить копию на отдельном контуре, закрыть период на тестовой выборке, выдать и отозвать доступ по новому правилу.

Такая проверка не заменяет внедрение. Она делает разговор точнее. Иногда выясняется, что главная проблема не в системе, а в неоговорённом правиле. Иногда наоборот: люди уже договорились, но инструмент не умеет поддержать их договорённость. В обоих случаях следующий шаг становится меньше похож на ставку вслепую.

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

Не прячьте выбор в большой таблице

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

Мне нравится простой формат: название риска, затронутая операция, владелец, ближайшая проверка, следующий шаг. Например, «не видно зависший обмен заказами — отгрузка — руководитель продаж — остановить тестовый обмен и убедиться, что сигнал пришёл — настроить контроль и порядок разбора». Это не замена проектному управлению. Это общий язык, с которым можно войти в любую встречу.

Большая таблица часто создаёт обратный эффект. В ней двадцать колонок, десятки строк и формально всё учтено. Но никто не знает, что нужно сделать в понедельник. Одностраничный порядок не упрощает проблему искусственно; он заставляет честно назвать следующий ход. Детали остаются рядом, но не заслоняют причину.

Что не стоит тащить в ближайший цикл

Иногда в план попадает задача только потому, что для неё уже есть презентация, лицензия или заинтересованный подрядчик. Это слабая причина. Я бы отложил пункт, если он не уменьшает понятный риск, не открывает нужный рабочий результат и не проверяет важную гипотезу.

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

Отложить — не значит забыть. Для таких идей полезен отдельный список с причиной, при которой к ним стоит вернуться: рост числа клиентов, запуск нового направления, достижение определённой нагрузки, окончание поддержки старого решения. Тогда предложение не теряется, но и не конкурирует с тем, что горит сейчас.

Как понять, что риск действительно снят

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

Поэтому я заранее добавляю к пункту короткий приёмочный сценарий: кто делает первый шаг, какой результат ждём, что будет считаться отклонением, кто его увидит. Это не бюрократия. Это тот самый момент, когда IT-план перестаёт быть обещанием и становится защищённым изменением в реальной работе.

План, который можно пересмотреть без паники

План от рисков не высечен в камне. Раз в месяц или после важного изменения я бы пересмотрел короткий список: какой риск снят, какой вырос, что перестало быть актуальным, где появился новый владелец или новый канал продаж. Это не бесконечная перестройка приоритетов. Это нормальная уборка в навигаторе, когда дорога изменилась.

У каждого пункта полезно оставить одну строку: почему он сейчас в плане. Через два месяца она спасает от странной дискуссии «кто это вообще придумал». Если причина исчезла, пункт можно снять. Если риск усилился, его не приходится заново защищать красивыми слайдами.

Я строю IT-план не для того, чтобы он выглядел стратегическим. Он нужен, чтобы следующая важная поломка не стала сюрпризом, а следующая инвестиция не оказалась дорогим обходом старой проблемы. Когда порядок работ объясняется риском для живого процесса, у команды появляется не просто список задач, а понятная причина действовать.