Я не прошу оценку разработки, пока не понимаю цену неверного решения
Я не прошу оценку разработки, пока не понимаю цену неверного решения. Вопрос «сколько часов займёт?» звучит делово, но очень часто появляется раньше нужного разговора. Команда ещё не договорилась, что именно меняет бизнес, а календарь уже пытаются заполнить датами.
Такая оценка похожа на попытку назвать стоимость ремонта, когда известно только «хочу, чтобы дома стало удобнее». Можно назвать число. Но в нём будет не план, а предположение о десятке вещей, которые никто вслух не обсудил.
Почему точное число иногда создаёт лишний риск
Собственнику нужна определённость — это нормально. Деньги и люди не бесконечны. Но ложная точность дороже честной неопределённости. Если разработчики оценивают экран до того, как понятно правило за ним, они вынуждены сами принять бизнес-решение. Потом оно проявится как «неучтённый случай», новая доработка и спор о том, кто должен был догадаться.
Я разделяю два вопроса. Первый: что мы хотим изменить в работе компании или пользователя? Второй: какой технический путь и объём нужны для этого изменения? Второй вопрос нельзя качественно ответить, пока первый остаётся расплывчатым.
Начать с дорогого неправильного выбора
До оценки я ищу решение, которое будет самым дорогим для переделки. Не обязательно самое большое. Иногда это выбор, где хранить данные. Иногда — момент, когда заказ считается подтверждённым. Иногда — право сотрудника менять цену или удалять документ.
Представим сервис для работы с заявками. Можно быстро сделать форму и статусы. Но сначала важно решить: одна заявка может превратиться в несколько заказов или нет? Если ответ появится после запуска, затронет карточки, отчёты, интеграции и права. Это не «маленькая правка поля». Это несущая конструкция, которую пытались построить без чертежа.
Поэтому вместо списка экранов я прошу назвать три вещи: какую ошибку нельзя допустить, какое решение почти невозможно откатить и кто вправе его принять. Уже после этого техническая команда может говорить о вариантах и их цене.
Оценка — это диапазон с условиями
Хорошая оценка не прячется за одним числом. В ней есть объём, диапазон и условия. Например: базовый сценарий займёт столько-то работы, если данные приходят из одной системы, правила согласования остаются едиными, а перенос старого архива не входит в первый этап. Это не уход от ответственности. Это способ честно показать, на чём держится план.
Когда условия меняются, меняется и оценка. В этом нет провала. Провал — делать вид, что новая интеграция, дополнительные роли и особые правила клиента «уже были включены». В статье об архитектуре как цене будущих изменений речь именно об этом: решение важно не красотой схемы, а тем, насколько спокойно его можно поменять позже.
Разные неизвестности требуют разных следующих шагов
Полезно назвать тип неопределённости, а не складывать всё в слово «сложно». Если неизвестна потребность пользователя, нужен разговор с пользователями или небольшой тест. Если неизвестно правило бизнеса, решение должен принять руководитель процесса. Если неясна техническая граница, команде может понадобиться короткая исследовательская работа. Если не хватает данных, сначала надо собрать их из текущих систем.
У этих ситуаций разная цена и разный результат. Нельзя решить вопрос о владельце согласования дополнительным часом разработки. И наоборот, нельзя считать бизнес-решение принятым только потому, что программист сказал «сделать можно». Чем точнее команда называет неизвестность, тем честнее становится план.
Иногда лучшая первая оценка — оценка исследования. Не «сделаем весь модуль за две недели», а «за три дня проверим два способа обмена данными и вернёмся с границами, рисками и вариантом запуска». Это особенно полезно там, где внешняя система, старые данные или доступы могут изменить объём в несколько раз.
У первого этапа должна быть самостоятельная польза
Разбить работу на этапы — не значит красиво переименовать бесконечный проект. Первый этап должен дать результат, который можно использовать: обработать один тип заказа, собрать фактические данные, заменить одну ручную сверку, проверить роль на небольшой группе. Если он заканчивается только презентацией будущего, риск никуда не делся.
Я выбираю границу первого этапа так, чтобы она уменьшала самый опасный вопрос. Если сомнение в том, будут ли сотрудники пользоваться новым путём, запускаем ограниченный сценарий с реальными людьми. Если риск в качестве данных, сначала строим проверку и исправление источника. Если трудно интегрироваться, не рисуем сразу весь контур, а проверяем один обмен на реальном объекте.
Так появляется не просто дата окончания, а основание для следующей оценки. После первого этапа часть предположений исчезает, и диапазон становится уже. Это нормальный путь к точности, а не признак того, что команда «не умеет планировать».
Что обычно забывают включить в оценку
Разработка интерфейса заметна, поэтому её легко обсуждать. А вот миграция старых данных, настройка прав, проверка исключений, обучение сотрудников, наблюдение после запуска и обратимый план на случай ошибки часто остаются за скобками. Потом именно они превращают «готовый модуль» в ещё не готовую работу.
Я не предлагаю раздувать смету на всякий случай. Я предлагаю отдельно назвать такие части. Тогда собственник может решить: переносим только активные данные, запускаем одну роль, оставляем старый путь на две недели или берём обучение на себя. Любой из этих выборов меняет реальный объём. Важно, чтобы он был сделан до обещания даты, а не после.
Три плохих вопроса и чем их заменить
Первый плохой вопрос: «Сколько займёт сделать как у конкурента?» Правильнее: «какую работу пользователя мы хотим сделать проще и какие ограничения нельзя потерять?» Второй: «Почему оценка не точная?» Лучше спросить: «какие допущения сильнее всего меняют срок и как их проверить?» Третий: «Можно ли добавить ещё одну мелочь?» Лучше: «какой сценарий она меняет, какой текущий риск убирает и что вытеснит из ближайшего этапа?»
Такие формулировки не делают разговор медленнее. Они меняют его с торга о часах на выбор о результате. Команде легче предложить вариант, руководителю — принять решение, а проекту — не накапливать невидимые обязательства.
Что я хочу увидеть до вопроса о сроках
Мне достаточно короткого, но проверяемого описания. Кто выполняет действие? С каким объектом? Что происходит до и после? Что считается ошибкой? Как выглядит нормальный рабочий день и что случается в редком, но дорогом исключении?
Это не обязательно документ на сто страниц. Иногда хватает одной страницы с примерами и границами. Техническое задание само по себе не спасает проект, если все по-разному понимают задачу бизнеса. Перед крупным вложением полезно пройти пять вопросов, которые помогают увидеть важные решения заранее.
После такого разговора у команды появляется выбор. Можно сделать небольшой первый этап и проверить гипотезу. Можно отложить рискованную часть. Можно признать, что сначала нужна работа с процессом, а не разработка. Все три ответа полезнее, чем уверенная дата, которая развалится после первой встречи с пользователями.
Не заставлять разработчиков угадывать владельца
Есть особый вид неопределённости: решения нет, но от команды ждут оценки. Например, руководители не договорились, кто утверждает исключение. Разработчик может добавить переключатель, маршрут, дополнительную роль. Но он не должен выбирать, как устроена ответственность в компании.
Когда у решения нет владельца, проект превращается в спор: технически можно сделать несколько вариантов, но ни один не становится «правильным» без бизнес-выбора. Это уже видно на стадии архитектуры; отдельный разбор есть в статье о выборе без владельца.
Я считаю полезным прямо помечать такие пункты в плане. Не маскировать их под задачу «на уточнении», а писать: «нужно решение директора по продажам», «нужно правило финансового контроля», «нужен владелец данных». Это снимает с разработки чужую обязанность и показывает руководству, где на самом деле стоит очередь.
Простой формат для карточки решения
Для важных точек не нужна тяжёлая методология. Достаточно записать: контекст, варианты, выбранное решение, владельца, дату и то, что придётся пересмотреть при изменении условий. Такая заметка защищает не от всех ошибок, но от потери памяти. Через несколько месяцев команда понимает, почему граница была проведена именно здесь, а не придумывает объяснение задним числом.
Это особенно ценно, когда проект проходит через несколько людей или паузу. Новая команда получает не загадочный набор ограничений, а следы сделанного выбора. А руководитель может вернуться к решению, если бизнес действительно поменялся, вместо того чтобы требовать «срочно поправить» то, что было заложено осознанно.
Как сказать «пока не знаю» профессионально
Иногда от исполнителя ждут цифру к концу встречи. В такой момент полезно не уходить в абстрактное «надо подумать», а назвать конкретный пробел: «мы не знаем объём старых данных», «не зафиксировано правило отмены», «нужно проверить ограничения внешней системы». Затем предложить действие, срок и ожидаемый результат проверки.
Это совсем другой разговор. Вместо впечатления, что команда избегает ответственности, у заказчика появляется план снижения риска. Он видит, что неопределённость не прячут, а превращают в управляемую задачу.
Такую же честность стоит сохранять и после старта. Если тест обнаружил условие, которое меняет выбранный путь, его нужно вынести на решение, а не пытаться незаметно «впитать» в прежнюю смету. Иногда правильный ответ — поменять границу этапа. Это дешевле, чем выполнить устаревший план только потому, что он когда-то был согласован.
Цена задержки тоже часть выбора
Бывает, что ждать полной ясности действительно дороже, чем идти небольшим риском. Например, ручной процесс уже мешает обслуживать клиентов, а базовый сценарий понятен. Тогда первый этап стоит запускать, но с явным ограничением: что именно не автоматизируем сейчас, какие данные проверяем вручную и кто принимает исключения. Быстрое решение не обязано быть необдуманным.
Главное — не выдавать временную границу за окончательную архитектуру. В плане должно быть видно, что отложено, почему это отложено и по какому сигналу к вопросу вернутся. Тогда скорость не превращается в долг, который потом придётся раскапывать по переписке.
Так оценка становится не ритуалом перед стартом, а частью управления: она помогает увидеть следующий разумный шаг, его стоимость и условия, при которых этот шаг остаётся верным.
Как провести разговор об оценке
- Сформулируйте изменение в работе, а не желаемую функцию.
- Назовите самый дорогой риск, если решение окажется неверным.
- Зафиксируйте владельца каждого бизнес-правила.
- Опишите базовый сценарий и одно неприятное исключение.
- Попросите команду назвать варианты, диапазон и условия каждого варианта.
Такой порядок не замедляет проект. Он сокращает круги, которые обычно появляются после обещанной даты. Команда получает не набор догадок, а границы для решения. Собственник получает не красивую цифру, а способ управлять тем, что эту цифру меняет.
В крупных IT-вложениях я бы всегда возвращался к простому вопросу: что должно стать понятнее или надёжнее в рабочем дне после этой работы? Если ответа нет, оценивать пока нечего. Если ответ есть, разговор о сроках становится намного спокойнее и честнее.
Обсудим?