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