До оценки разработки: как зафиксировать границы продукта и критерии приёмки

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

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

Привет, я Антон Фокин — CEO Qtim

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

Начните со сценария пользователя

«Личный кабинет» — это ярлык. Он не отвечает, кто им пользуется, с какой задачей приходит и что должно измениться после действия.

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

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

Исследование 116 проектов связывает недостаточные ранние анализ и планирование с худшими результатами. Оно не позволяет посчитать потери конкретного проекта, но показывает роль раннего анализа. I&S.

Зафиксируйте первую поставку

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

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

Для того же поставщика граница первой поставки может выглядеть так:

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

Проверьте внешние условия

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

Поэтому зависимости и ограничения стоит обсудить отдельно. Достаточно перечислить известное и отметить неизвестное. Например: CRM отдаёт статусы через API — подтверждено; список ролей согласует служба безопасности — ждём ответ; документы хранятся в новом или существующем контуре — решение требуется.

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

Опишите проверяемый результат

Фраза «сделайте удобную загрузку» не позволяет одинаково проверить результат. Заказчик ждёт один сценарий, разработчик реализует другой, тестировщик составляет третий набор проверок.

Критерий приёмки отвечает на вопрос: что увидим, когда сценарий готов к передаче? В него можно вынести пять типов условий:

Я смотрю на критерии приёмки как на обещание, которое мы сможем проверить вместе с заказчиком. Чем меньше в нём слов вроде «удобно» и «быстро», тем меньше места для разных трактовок.

1. кто имеет право совершить действие;
2. какие данные или объекты допустимы на входе;
3. какой результат появляется после действия;
4. кто видит этот результат и может изменить его статус;
5. какое событие фиксируется для последующей проверки.

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

Отделите известное от допущений

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

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

Пять вопросов перед стартом

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

1. Сценарий и результат. Кто совершает действие, что делает и что меняется для него или бизнеса.

2. Первая поставка. Какие функции и платформы входят в релиз.

3. Исключения. Что сознательно отложено, чтобы первая версия не росла незаметно.

4. Зависимости и допущения. Внешние системы, роли, данные, доступы, правила и открытые решения.

5. Критерии приёмки. Наблюдаемые условия, по которым можно показать готовность сценария.

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

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

Нужна оценка без скрытых допущений? Разберём состав первой поставки до запроса сметы: сценарий, границу релиза, зависимости и критерии приёмки.