Технические встречи по сбору требований, которые защищают дорожную карту продукта

Почему кастомные сделки срывают дорожную карту

Кастомные сделки редко ломают дорожную карту потому, что запрос кажется огромным. Чаще они рушат её потому, что запрос кажется маленьким.

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

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

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

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

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

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

Спрашивайте про рабочие процессы

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

Во время технических discovery‑звонков попросите команду пройти один реальный рабочий пример от начала до конца так, как они делают это сейчас, а не как хотели бы. Выберите обычную задачу: создание заказа, утверждение возврата, онбординг клиента или отправка ежемесячного отчёта. Начните с вопроса «Что это запускает?» и идите дальше, пока работа полностью не завершится.

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

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

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

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

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

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

Спрашивайте про источники данных

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

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

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

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

Затем проверьте сами данные. Спросите, в каком формате они приходят, насколько они чисты и как часто меняются. Таблица в PostgreSQL — одно. Смесь JSON‑полей, PDF‑вложений и вручную правимых столбцов в таблице — другое. Если имена, идентификаторы или метки времени не совпадают между системами, кто‑то должен это исправить до того, как продукт сможет безопасно использовать данные.

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

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

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

Спрашивайте про требования безопасности

Вопросы безопасности кажутся медленными, пока не добавят три недели работы.

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

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

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

Четыре вопроса обычно выявляют скрытую работу:

• Какие данные требуют дополнительной защиты и почему?
• Кто может просматривать, редактировать, экспортировать, утверждать или удалять записи?
• Нужен ли журнал аудита, показывающий, кто что и когда изменил?
• Как долго надо хранить данные и что происходит, когда кто‑то просит их удалить?

После правил доступа спросите про внешние проверки. Некоторым компаниям требуется одобрение юридического отдела, комплаенса, IT или службы безопасности перед запуском. Это может повлиять на график больше, чем код. Анкета по безопасности, тест на проникновение, требование single sign‑on или соглашение об обработке данных могут появиться поздно, если вы не спросите заранее.

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

Ведите звонок по порядку

Хорошие технические discovery‑звонки остаются узкими. Начните с бизнес‑цели в одном простом предложении. Если в комнате не могут сформулировать её, весь звонок скатится в догадки, хотелки и неправильную оценку.

Хорошая цель звучит так: сократить ручной ввод заказов, сократить время ответа поддержки или дать менеджерам единое место для утверждений. Коротко — лучше. Это даёт всем одинаковую цель.

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

Практическая последовательность работает так:

1. Запишите бизнес‑результат и как команда будет оценивать успех.
2. Пройдите текущий процесс от начала до конца на реальном примере.
3. Назовите каждую систему, группу пользователей и исключение, которые меняют обычный поток.
4. Поставьте паузу и подытожьте риски, неизвестности и дополнительную работу перед обсуждением сроков или цены.
5. Завершите списком открытых вопросов, кто отвечает за каждый и когда ждать ответ.

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

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

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

До конца звонка повторите риски простым языком. Если осталось три вопроса без ответа, назовите все три и назначьте ответственных. Эта маленькая привычка экономит недели переделок.

Простой пример скрытой работы

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

Но при звонке маленькая задача перестаёт быть маленькой.

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

Этап с документами добавляет работу. Клиент хочет, чтобы загружали ID, подтверждение адреса и подписанный договор. Некоторые файлы требуют ручной проверки. Для других нужны проверки типа файла, ограничений размера и совпадения имени в ID с именем в форме. Если файл отсутствует или нечёткий, система должна запросить новый загруз, а не переводить карточку дальше.

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

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

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

Первая смета — 30 часов. После звонка реальный объём ближе к 120 часам плюс тестирование крайних случаев и ролей. Именно этот разрыв показывает, почему важны технические discovery‑звонки: скрытая работа всегда была там, звонок лишь выявил её до того, как цена зафиксировала плохую сделку.

Ошибки, которые скрывают объём

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

Ещё одна частая ошибка — просить одного человека объяснить всю операцию. Менеджеры описывают задуманную процедуру. Люди, выполняющие работу, знают ярлыки, задержки и временные костыли. Продажи могут сказать, что заказы приходят через CRM, а операционная команда тихо достаёт недостающие данные из почты, таблиц и чатов. Если вы оцениваете с одной точки зрения, вы оцениваете идеальный путь и пропускаете реальный.

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

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

Последняя ошибка — уйти с открытыми вопросами, но без ответственных. Тогда все предполагают, что кто‑то другой проверит лимиты API, подтянет правила хранения или узнает, кто даёт доступ. Расплывчатая заметка не решит этого.

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

Такой дисциплинированный обзор — то место, где может помочь опытный внешний технический лидер. Oleg Sotnikov делает эту работу со стартапами и растущими командами через oleg.is, особенно когда скрытые зависимости вокруг инфраструктуры, прав доступа или дизайна процесса постоянно всплывают в сделках.

Проверьте перед тем, как оценивать

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

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

• Можете ли вы описать полный рабочий процесс от первого действия до конечного результата, включая передачи и типичные исключения?
• Перечислили ли вы все вовлечённые системы, даже «грязные», вроде таблиц, общих почтовых ящиков и ручных экспортов?
• Знаете ли вы, кто может просматривать, редактировать, утверждать и отклонять на каждом шаге?
• Знаете ли вы, какие данные требуют дополнительной защиты, например записи клиентов, финансовые данные или внутренние заметки?
• Можете ли вы перечислить открытые вопросы и назвать ответственных за каждый?

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

Небольшой пример показывает, почему это важно. Компания просит «простой дашборд» статуса заказов. После проверки вы узнаёте, что экран должен тянуть данные из CRM, старой базы складирования и финансового инструмента. Некоторые статусы должны утверждать менеджеры. Сотрудники поддержки могут просматривать заказы, но только финансы видит возвраты. Адреса клиентов требуют более строгой защиты. Это уже не маленькая доработка.

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

Что делать дальше

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

Многие технические discovery‑звонки кажутся доскональными, а потом разваливаются, потому что оценка скрывает предположения команды. Поместите эти предположения рядом с цифрой, а не в отдельный документ, который никто не проверяет. Если вы предполагаете чистый доступ по API, один поток утверждения или отсутствие миграций — скажите это явно.

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

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

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

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