Привет, Хабр! Я Диана Баязитова, ведущий аналитик 1С. В моей практике — проектирование сквозных ИТ-ландшафтов, управление миллионными финансово-налоговыми рисками и регулярная защита долгосрочной ценности проектов перед C-level.

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

Я бы хотела ввести два определения: Объективную неопределенность и Субъективное отсутствие фокуса.

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

Что такое реальная неопределенность? Реальная неопределенность заключается в том, что никто и никогда в бизнесе не будет обладать полной, 100% картиной происходящего. Но это не значит, что картинки нет совсем. Психологи говорят что мозг сам строит картину мира, мы редко когда видим его как есть. В том числе, потому что наличие слишком много переменных создают информационный шум, дезориентирующий любого.

В 90% корпоративных задач вводные, контекст и осязаемые бизнес‑боли есть. Зачем‑то же бизнесу нужно пилить эту фичу, у процесса есть изначальный смысл. Но когда менеджмент разводит руками и говорит: «Мы не можем зафиксировать ТЗ и спроектировать архитектуру, потому что вокруг сплошная неопределенность», на языке фактов это означает расписку в некомпетентном управлении.

Вместо системного анализа и сборки той части картины, которая уже известна, команда получает приказ сверху: «Пилите прямо сейчас в режиме хакатона, делайте на коленке, через два дня в этом не будет смысла». Это легализация операционной суеты. Людей заставляют бежать спринты в тумане, сжигая ресурсы и мотивацию, просто потому что руководителю страшно взять ответственность, зафиксировать стабильные правила игры и определить вектор движения на основе тех вводных, которые уже есть на руках. Пока туман силен, можно бесконечно переписывать код, героически тушить пожары и оправдывать отсутствие продукта тем, что «вводные опять изменились». Команда жжёт ресурс и имитирует маневренность, а бизнес получает деградацию ИТ‑ландшафта и нулевой результат. А самое печальное, что все временное становится постоянным. У меня есть несколько кейсов.

Кейс 1: Когда «неопределенностью» прикрывают отсутствие компетенций

В команду приходит руководитель, который на любое требование зафиксировать дедлайны или ИТ‑архитектуру отвечает: «Мы живем в эпоху тотальной неопределенности рынка, мы должны быть гибкими, быстро меняться и постоянно перестраивать процессы».

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

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

Рынок может штормить, но у нашей автоматизации должен быть вектор. Например: всё, что мы проектируем, делается ради одной глобальной цели — снижения стоимости перевозок на х%. И я, как архитектор/аналитик, живу не в вакууме, я знаю про шторм на рынке. Но если фича не бьёт в эту цель или требует переписывания ядра каждые два месяца — мы её не делаем. Это не гибкость, это нецелесообразный слив ресурсов компании.

Кейс 2: Постановка задачи «Поди туда, не знаю куда».

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

У такого менеджмента в принципе отсутствует базовое понимание того, как устроены ИТ‑проекты, и чем стадия AS IS (анализ текущего хаоса) отличается от стадии TO BE (проектирование целевой архитектуры).

Чтобы сузить отбор, нужно иметь критерии отбора. Чтобы предложить решение, нужно понимать бизнес‑цель и проблему, которую это решение должно закрыть. Когда руководитель требует от аналитика «самой догадаться и сузить», он живет в иллюзии, что можно просто прийти к решению из наличия чего-то. У него нет фокуса, и о н надеется, что в ходе сбора информации вдруг станет очевидно решение, да притом единственно верное. Я выпускница юридической академии и живу с установкой, что правильных ответов нет. Ты задаешь цель и от нее строишь свою линию поведения. Когда тебя просят найти «правильное решение» это обычно манипуляция снятия ответственности с себя, чтобы кто-то дал решение, которое тебе нравится.

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

Кейс 3: Неготовность принять предложение, которое не предполагалось.

На абстрактный запрос «найди всё по сущности Х» аналитик не просто собирает срез AS IS, а находит корневой разрыв данных и предлагает фундаментальное TO BE решение — определить мастер‑систему по договорам, которые являются ключевой аналитикой в контуре.

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

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

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

Философия шторма

Рынок может быть хаотичным — да он и будет. Но у игрока рынка всегда есть цель, не может не быть.

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

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

Когда менеджмент в Enterprise‑бизнесе пытается оправдать отсутствие ИТ‑архитектуры и хаос в задачах «штормом на рынке» — это позиция испуганного пассажира, а не капитана. Капитану может быть сложно из‑за шторма, но он не бросает штурвал со словами «у меня нет запроса». Корабль имеет определенный курс, корабли не выплывают в никуда. Маневренность — это выбор наиболее эффективного пути к фиксированной цели, а не хаотичное метание по волнам.

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