Оценка срока внедрения начинается с одного некрасивого процесса

Почему демо искажает объем работ

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

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

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

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

С отчетностью та же история. Демо доказывает только то, что задача может пройти от начала до конца. Бизнесу еще нужно знать, что застряло, что было отклонено, кто это утвердил и сколько занял каждый шаг. Такие вопросы обычно возникают как раз тогда, когда всем кажется, что до даты уже рукой подать.

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

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

Что показывает некрасивый процесс

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

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

Потом проведите одну заявку от первого запроса до финального отчета. Не останавливайтесь на фразе «система это обработала». Идите дальше, пока команда не отправит клиенту обновление, не закроет задачу, не проверит цифры и не сохранит все, что потом захочет видеть руководство. Именно этот полный путь и формирует оценку.

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

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

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

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

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

Какой объем работ открывает грязный кейс

Чистое демо показывает, чего люди надеются достичь. Грязный кейс показывает, что вам действительно придется строить.

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

Импорты открывают еще один слой. Образец CSV часто выглядит аккуратно. Живой файл — почти никогда. Имена клиентов отличаются на один символ, коды товаров используют старые форматы, а даты приходят то как 03/04/2025, то как 2025-04-03. Тогда команде приходится отвечать на реальный продуктовый вопрос: что делать с плохими строками? Пропускать их, останавливать весь импорт или создавать очередь на проверку? Это уже работа над продуктом, а не мелочь.

Согласования тоже растягивают сроки. Один шаг согласования звучит просто, пока не спросишь, кто за него отвечает. Менеджер по продажам утверждает скидки? Финансы утверждают только выше определенного лимита? Что делать, если никто не отвечает шесть часов? Если один человек отклоняет заказ, может ли другой исправить его и отправить снова, или все начинается заново?

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

Потом появляются исключения. Командам нужны админ-инструменты, чтобы исправлять дубли, повторно запускать неудачные импорты, разблокировать записи, объединять клиентов и исправлять ошибки без обращения к инженерам каждый раз. Такие внутренние экраны нередко отнимают больше времени, чем отполированная внешняя часть.

Вот почему один некрасивый процесс так быстро меняет срок внедрения. Он делает видимыми скрытые правила, ожидание, очистку данных и пробелы в отчетности.

Как разобрать один реальный кейс за одну встречу

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

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

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

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

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

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

Если группа уходит через 60–90 минут с пошаговым потоком, коротким списком точек отказа и ответственными по открытым вопросам, встреча удалась. Этого достаточно, чтобы превратить хаотичную реальность в объем работ, который уже можно оценивать и планировать.

Простой пример команды по заказам

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

Потом кто-то вспоминает заказ, которого все стараются избегать.

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

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

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

Ничего из этого не редкость. Это обычная работа, которую полированные демо скрывают.

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

Вот почему один некрасивый процесс сильнее десяти аккуратных экранов. Чистое демо показывает историю, которую люди хотят видеть. Грязный кейс показывает систему, которая им действительно нужна.

Как превратить процесс в дату

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

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

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

Потом посчитайте неизвестные до того, как кто-то начнет писать код. Если команда говорит: «Нам нужно уточнить это у финансов» или «CSV-файлы у всех чуть разные», это не заметка на потом. Это уже часть оценки. Неизвестным нужно отдельное время на разбор, примеры и принятие решений.

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

Итоговая оценка должна быть диапазоном с явными допущениями. Например: 3–5 недель, если на каждом этапе будет по одному согласующему, примеры файлов для импорта придут на этой неделе, а отчетность ограничится двумя представлениями. Если допущения меняются, меняется и дата. Это не уклонение. Это честное планирование.

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

Ошибки, из-за которых дата становится бесполезной

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

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

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

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

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

Есть и еще один паттерн, который ломает оценки: позволить самому громкому стейкхолдеру описать весь процесс. Такой человек часто рассказывает версию, которую он ожидает, а не ту, по которой сотрудники работают в 16:45 в загруженную пятницу. Лучше картину обычно дает тот, кто чистит данные, следит за ящиком входящей почты или чинит неудачные согласования.

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

Быстрая проверка перед тем, как обещать дату

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

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

Прежде чем кто-то назовет календарную дату, убедитесь, что команда может ответить на несколько простых вопросов. Могут ли они назвать все статусы процесса, включая hold, reject, reopen, cancel и done? Знают ли они, откуда берется каждая часть данных: от пользователя, из импорта, из другой системы или из ручной правки? Понятно ли, кто утверждает каждый шаг, кто может обойти правило и где это обходное решение фиксируется? Знают ли они, какой отчет люди действительно читают каждую неделю, и какие цифры должны совпасть, чтобы ему доверяли? Перечислили ли они исключения, которые случаются достаточно часто, чтобы делать под них продукт, а не решать их через почту или чат?

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

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

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

Если процесс продолжает расти

Когда процесс все время меняется, срок должен перестать плавать в личных чатах и перейти в простой пересмотр. Часто достаточно встречи на 20–30 минут. Подключите к одному звонку тех, кто делает работу, кто ее утверждает и кто потом отчитывается о результате. Еще раз пройдите весь хаос и на каждом шаге задавайте один вопрос: «Мы не упустили ничего, что меняет объем работ?»

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

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

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

Потом превращайте каждый открытый вопрос в решение с ответственным и сроком. «Нужно, чтобы финансы подтвердили согласование возврата» — это не решение. «Мария подтвердит согласование возврата к четвергу» — это решение. Если за ответ никто не отвечает, объем работ расползается, а оценка превращается в выдумку.

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

Если команде нужен такой второй взгляд, Олег Сотников делает именно такой разбор в своей работе Fractional CTO. Его сайт, oleg.is, — удобная точка входа для команд, которым нужна помощь в том, чтобы превратить хаотичную операционную работу в план, который действительно можно защитить.