Требования и границы задачи

Разобраться, какую проблему на самом деле решает запрос, где проходят её края и что делать не нужно. Всё это происходит до первой строки кода — и определяет, стоило ли вообще его писать.

Почему это важно. Самая дорогая инженерная ошибка — хорошо сделать не то. Такой код проходит code review, выходит в релиз, а через несколько месяцев выясняется, что им никто не пользуется. Никакое качество кода этого не исправит.

Что нужно понимать

• Какую проблему это решает, для кого и по чему будет видно, что получилось
• О чём попросили — и что при этом имели в виду
• Что здесь действительно необходимо, а что попало в требования как чьё-то допущение
• Что произойдёт в случаях, о которых никто не упомянул
• Что явно не входит в задачу — и это записано

Ключевые темы

Понять запрос

• Проблема, которая стоит за предложенным решением
• Кто пользователь и как он справлялся, пока этого не было
• Успех как наблюдаемая величина, а не «пользователям понравится»
• Настоящие ограничения и ограничения по привычке

Края

• Пусто, первый запуск, один элемент, десять тысяч элементов
• Сбои: нет сети, нет прав, сессия истекла
• Параллельность: два устройства, две вкладки, два человека
• Кому это разрешено — и что происходит, когда не разрешено
• Миграция данных, которые уже накоплены

Границы задачи

• Минимальная версия, которая уже приносит пользу
• Что сознательно не делается — и об этом сказано вслух
• Расползание задачи: заметить его по ходу, а не постфактум
• Когда срок фиксирован, урезать объём, а не качество

Записать

• Столько, чтобы по этому тексту сделал кто-то другой
• Критерии приёмки, которые можно проверить, а не только оценить взглядом
• Открытые вопросы помечены как открытые, а не закрыты догадкой
• Либо поддерживать документ в актуальном виде, либо удалить его

Возражать

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

Уровни

Уровень	Как это выглядит
Junior	Реализует то, что описано, и спрашивает, когда описание непонятно.
Middle	Находит проблему за запросом, продумывает крайние случаи до начала работы и аргументированно договаривается о границах.
Senior	Влияет на то, что вообще берётся в работу, формулирует измеримый критерий успеха и умеет отказать, не испортив отношений.

Практика

Для начала

• Спросите «зачем» ещё раз В следующей задаче найдите проблему за запросом, прежде чем писать код.

• Перечислите края До начала работы выпишите все крайние случаи. Потом сравните с теми, что всплыли по ходу.

• Определите, что значит «готово» Напишите критерии приёмки, которые сможет проверить кто-то другой.

Дальше

• Сократите объём вдвое Возьмите запланированную функциональность и найдите версию, которая стоит вдвое меньше усилий и даёт большую часть пользы.

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

• Предложите альтернативу Когда просят что-то дорогое, вернитесь с более дешёвым способом решить ту же исходную проблему.

Проверьте себя

• Какую проблему решает то, чем вы заняты прямо сейчас, и для кого?
• По чему через месяц будет видно, что получилось?
• Какие крайние случаи вы обнаружили только в процессе работы?
• Когда вы в последний раз сделали то, чем никто не воспользовался?
• Как отказать запросу, не отказывая человеку?
• Что на вашем текущем проекте явно вынесено за границы задачи?

Материалы

• Shape Up — бесплатно доступна онлайн, сильнее всего — часть про shaping: как описать проблему с нужной степенью детализации, прежде чем она станет работой, и как фиксировать срок, а не объём.
• Jobs to be Done — Кристенсен в HBR. Подход, который отделяет то, о чём человек попросил, от того, чего он пытается добиться.
• User Story Mapping — Джефф Паттон о том, почему сценарий сначала нужно увидеть целиком и только потом резать на части: иначе накапливается backlog из кусков, которые никогда не складываются в целое.
• Writing good acceptance criteria — механика проверяемых критериев, со стороны инструментов, выросших вокруг них.
• Inspired — Марти Каган о том, как на самом деле принимаются продуктовые решения. Читать стоит, даже если такой должности у вас никогда не будет.