Серия «История аналитика который много ошибался»

Начало. Снова всё правильно

В прошлый раз его подвела слепота к людям. В этот раз — методология.

Задача звучала знакомо: перевести офлайн-ритейлер в онлайн, спроектировать интернет-магазин. Постановка была короткой и на вид безупречной — «изучить всё как есть, спроектировать как должно быть».

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

Разве не молодец?

Первый звонок. TO BE рождается похожим

Началось проектирование TO BE. И оно стало обрастать знакомыми чертами.

Приём заказов проектировался по образу приёма заявок в офлайне. Информирование покупателя — как обзвон менеджером. Оплата — как касса на входе. Каждый новый процесс аналитик невольно лепил из уже описанного старого.

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

Смена угла зрения. AS IS — не для того, чтобы его описать

Аналитик остановился и задал вопрос, который стоило задать до, а не после: зачем вообще нужен AS IS?

Не чтобы задокументировать текущую систему во всей красе. AS IS нужен, чтобы понять, на каком фундаменте мы строим TO BE и что именно из старого TO BE наследует.

Интернет-магазин наследует у офлайна не всё. Ценообразование, сборку, перемещение, доставку — да, это фундамент. Но интерфейс покупателя, приём заказов, приём оплат, информирование о статусе — это новое, уникальное, и лепить его из старого нельзя.

Значит, «изучить всё» — не добродетель. Это крайность. Аналитик копал офлайн-кассу с той же глубиной, что и сборку, — и офлайн-касса протекла в дизайн онлайн-оплаты.

Ошибка. Почему «изучить всё» — это не глубина

Тут прячется ловушка, которую видно не сразу.

Кажется, что проблема в объёме — изучил слишком много, потратил время. Но настоящий вред тоньше: **чем детальнее описан старый процесс, тем труднее от него отказаться.** Подробный AS IS легитимизирует текущий порядок. Аналитик, вложивший неделю в схему офлайн-приёма заказов, бессознательно защищает её в TO BE. Он построил не фундамент. Он построил якорь.

И «изучить всё» проваливает не глубину. Оно проваливает **зонирование**. Оно заставляет копать то, что вообще не станет частью нового решения, так же тщательно, как то, что станет его спецификацией.

Карта. Четыре связи с AS IS, а не одна

Аналитик понял: наследование — не единственная нить между старым и новым. Их четыре, и глубина изучения зависит от того, какая именно связывает фрагмент с TO BE.

Наследуем. Процесс переходит в TO BE почти как есть — ценообразование, сборка, доставка. Его нужно описать полно: это готовая спецификация.

Заменяем. Приём оплат, интерфейс покупателя. Внутрь старого процесса лезть не нужно — но нужен контракт на его границе: что на входе, что на выходе, какие данные, какие бизнес-правила. Здесь же прячется коварство: «приём оплат» объявляют уникальным для онлайна — а он сидит в эквайринге, сверках и возвратах. Граница важнее внутренностей.

Не трогаем, но стыкуемся. Бухгалтерия, склад-система — их не переписываем, но TO BE обязан сохранить контракт с ними. Нужен только интерфейс.

Не трогаем и не стыкуемся. Всё остальное. Одна строка: «существует».

Противоречие. AS IS надо изучить полностью — и нельзя

Вот напряжение, которое аналитик наконец увидел ясно.

AS IS надо изучить полностью — иначе теряются скрытые ограничения и стыки. Странный шаг в старом процессе часто кодирует регуляторное или договорное требование; выбросишь его как «легаси» — переоткроешь в проде.

AS IS нельзя изучать полностью — это дорого, а главное, детальный AS IS легитимизирует старое. Чем подробнее описал — тем сильнее якорь.

Это и есть механизм, из-за которого TO BE становится копией AS IS. Не вопреки качественному AS IS. Из-за него.

Разрешение. Два прохода вместо одного

Противоречие снимается разделением во времени. Не один тщательный проход по всему — а два разных.

Проход 1 — широкий и мелкий. Карта всех процессов на один уровень, без деталей. Единственная цель — найти границы и стыки, разложить процессы по четырём зонам. Здесь же рождается гипотеза TO BE: что наследуем, что заменяем.

Проход 2 — узкий и глубокий. Только по зонам «наследуем» и «заменяем». Первый проход дал вход для гипотезы TO BE — гипотеза TO BE задала глубину второго прохода.

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

Что изменилось

Аналитик не стал изучать меньше из лени. Он стал изучать прицельно.

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

TO BE перестал быть копией AS IS. Не потому что команда стала смелее. Потому что аналитик перестал приносить якорь под видом фундамента.

Детальность AS IS — не добродетель, а риск. Аналитик, изучивший всё, построил не фундамент, а якорь. Задача — не описать текущую систему целиком. Задача — понять, что из неё переживёт переход, и изучить глубоко только это.

Любой проект — это про людей. История аналитика, который смотрел не туда

Начало. Всё идёт правильно

Он зашёл в проект как обычно. Изучил орг. структуру, прочитал ТЗ, выписал цели. Всё по методологии, всё правильно.

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

Первые встречи. Что-то царапает

На установочной встрече что-то начало царапать.

Участники несколько раз упомянули, что принимать результаты проекта будет главный бухгалтер — человек, которого в проектной команде нет. Первый red flag. Аналитик зафиксировал, промолчал.

Руководитель со стороны закупок — формально возглавляет часть команды — говорит правильные слова, но без огня. Никакой личной ставки на результат. Второй red flag.

Новый руководитель канала продаж только что нанят. Компанию изнутри не знает, канал в таком формате не запускал. Третий red flag.

Аналитик всё фиксирует. Выводов не делает — рано, нет доказательной базы.

Сбор требований. Хаос как сигнал

Дальше — интервью, открытые вопросы, протоколы. Требования сыплются хаотично, иногда противоречат друг другу.

Аналитик пытается свести их в связные бизнес-процессы. Получается с трудом.

Но именно в этом хаосе самое ценное: не что говорит человек, а что его беспокоит. Каждое требование — след чьего-то интереса, чьей-то зоны ответственности.

AS IS собран. Начинается проектирование TO BE. И тут — жара.

Проект встаёт

Новый руководитель канала не может принять решения. На каждом артефакте один ответ: давайте добавим варианты. Scope размывается. Время уходит.

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

Аналитик начинает раздражаться.

Я же вижу, как должно быть. Я изучил десятки таких запусков. Почему они тормозят?

И вот здесь он делает ошибку, которую делают многие. Смотрит на симптомы и принимает их за проблему.

Смена угла зрения. Почему каждый ведёт себя именно так

Аналитик останавливается. Убирает схемы. И смотрит на людей.

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

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

Главный бухгалтер не появляется на встречах, но его имя звучит постоянно. Реальное влияние на приёмку результата сосредоточено вне проектной команды. Игнорировать его — значит проиграть в финале.

Руководитель закупок без личной ставки не будет саботировать проект. Он просто не будет за него бороться, когда станет трудно. А трудно будет обязательно.

Карта игры. Как называть то, что происходит

Аналитик задал себе вопрос, который раньше не приходил в голову: а в какую игру мы вообще играем?

Он выписал четыре вещи по каждому участнику. Кто реально влияет на исход — не по оргструктуре, а по факту. Что каждый может сделать: затянуть, ограничить, сослаться, не прийти. Что для каждого является реальным выигрышем — не декларируемым, а защищаемым. Кто какой информацией владеет и использует ли это как щит.

Карта была готова. Картина сложилась быстро.

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

⚠️ Главный бухгалтер создавал моральный риск. Он принимает результат, но не участвует в процессе. Его ожидания никто не зафиксировал. Последствия несоответствия лягут на команду — не на него. Ключевой признак: влиятельный участник появляется только на финальной приёмке.

🧊 Руководитель закупок был отсутствующим игроком. Он не саботировал проект — у него просто не было личной ставки на победу. Не выбирал между зайцем и оленем. Ему было всё равно.

Три разных диагноза. Значит — три разных действия.

Стратегия. Менять условия, а не людей

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

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

Для рациональной самозащиты — сделать опытных сотрудников союзниками. Аналитик переформулировал задачу: не "придумайте новое", а "покажите, что точно нельзя потерять — и мы это защитим". Они стали определять границы, внутри которых проектировалось TO BE. Из блокировщиков изменений — в хранителей критических требований. Функционал перестал сжиматься до копии старого.

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

Для отсутствующего игрока — дать роль без лишней нагрузки. Руководитель закупок получил чёткую и необременительную ответственность: согласовывать финальный документ, а не вести каждую встречу. Человек перестал быть слабым звеном — стал предсказуемым элементом.

Что изменилось

Аналитик не стал умнее в предметной области. Он не продавил своё видение TO BE.

Он просто перестал воевать с сопротивлением и начал его читать. Изменил условия, при которых люди принимали решения. Сопротивление не исчезло — но оно перестало быть равновесием.

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

Задача аналитика — не продавить TO BE. Задача — найти точку, где интересы участников совпадают с целями проекта.

Любой проект — это сначала про людей. Процессы — потом.

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

Аналитик понял: он решил проблему игры. Но не решил проблему проектирования.

В следующей серии разберём, как он собирал требования — и почему правильно собранные требования это ещё не гарантия правильного TO BE.