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