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