Риск №3. Эффект «Зловещей долины» в данных Это самый недооцененный риск. Мы загружаем остатки, переносим справочники, запускаем тестовую эксплуатацию, и в этот момент начинается ад. Руководитель смотрит на остатки товаров и говорит: «Этого не может быть». Почему у Заказчика паника: · Он больше не доверяет ни старым, ни новым данным. Раньше цифры в старой программе могли быть «мусором», но все знали, как этот мусор интерпретировать. В новой системе всё строго, но показатели не бьются с интуитивной картиной мира директора. Он думает: «Меня обманывают, просто теперь это выглядит красиво». · Разрыв картины мира: Выясняется, что реальная себестоимость товара не 100 рублей, как считали в Excel, а 120, если учесть все издержки. Для нас это правильный учет, для него — крах маржинальности и понимания «а на чем мы вообще зарабатываем?». Точка соприкосновения: Период сверки данных — это не техническая процедура выгрузки, а психоанализ бизнеса. Заказчику в этот момент нужно не доказательство нашей правоты через регистры, а помощь в пересборке его управленческой картины мира. Риск №4. Цифровой концлагерь для самого себя Заказчик платит деньги, чтобы вы построили систему, которая будет контролировать в первую очередь его подчиненных. Но в процессе он с ужасом осознает, что система начинает контролировать и его самого. · Лишение монополии на информацию: Раньше только гендиректор знал (или думал, что знает) всю маржинальность сделок. Теперь это видят менеджеры, финансисты, собственники. Прозрачность лишает его части аппаратного веса. · Необратимость действий: В жизни можно дать устное распоряжение, а потом сказать: «Я такого не говорил». В системе каждая проводка, каждое изменение цены подписывается цифровой подписью или, как минимум, фиксируется автор. Заказчик начинает понимать, что он строит инструмент, который не прощает импульсивных решений. Вывод для нас: Мы должны учитывать, что наша работа меняет политическую структуру компании. Иногда проект тормозится, потому что топ-менеджмент не хочет терять «серую зону». Как нам работать, зная всё это? Понимание страхов Заказчика не означает, что мы должны идти у него на поводу и кастомизировать систему до состояния старого зоопарка. Это значит, что управление рисками — это работа с ожиданиями, а не с кодом. 1. Говорить о потере контроля прямо: С самого начала объявлять: «Коллеги, будет период турбулентности. Месяц вам будет казаться, что мы всё сломали. Это нормально, это этап принятия». Когда страх назван по имени, с ним проще справляться. 2. Быть адвокатами ключевых пользователей, а не «погонщиками». Когда мы на стороне бухгалтера, защищаем его удобство перед его же начальником, мы снимаем страх увольнения и превращаем врага в союзника. Заказчик видит это и успокаивается за сохранность кадров. 3. Сверка данных как психотерапия. Не просто выдавать протоколы расхождений («Тут минус сто тонн»), а сидеть и разбираться: «Как вы считали раньше? Почему? Давайте новый учет строить на вашем здравом смысле, а не слепо переносить хаос». Коллеги, идеальных проектов не бывает. Но проекты умирают не из-за кривого кода типового решения, а из-за несовпадения картин мира. Если мы сможем смотреть на риски глазами того, кто платит и боится за свой бизнес, мы перестанем быть просто «программистами». Мы станем стратегическими партнерами, которым доверяют самое дорогое — пересборку управления компанией. Делитесь мыслями в комментариях, коллеги. Приходилось ли вам сталкиваться с тем, что технически простой проект вставал колом именно из-за таких «человеческих» страхов высшего руководства?