Небольшое лирическое вступление. Когда-то я играл в баскетбол и тренер беспрестанно вбивал нам в голову — “если твой пас не приняли в этом твоя вина”, или если коротко — “Виноват отдающий”. Как ни странно, спустя годы я часто вспоминаю это утверждение в работе с разработчиками, коллегами или топ-менеджментом.
Были у вас такие ситуации что разработчик раз за разом приходит к вам с вопросами по задаче? Или наоборот, что не приходит но к уже готовой задаче появляются все новые и новые дополнения? И в первом и во втором случае увеличивается время цикла (cycle time) то есть, увеличивается время которое уходит на конкретную работу. Как правило такое увеличение времени влияет не только на разработчика но и на соседние производственные участки.
Как же сделать классную передачу задачу что бы принимающий был счастлив и ставил их в пример? Ответ — потратить на это время и использовать шаблон.
Блок 1: Описание (функциональные требования)
Это вероятно самая обширная часть описания задачи.
Как проще всего и логичнее составить такое описание? Описание может быть как в формате User stories так и другим описательным образом; Независимо от выбранного формата, будет здорово если будут сформулированы ответы на следующие вопросы:
В чем идея и/или проблема?
Что хотим сделать или улучшить?
Как должна работать система, и как должна реагировать на действия пользователя?
Какие действия доступны пользователю?
Тут пишем всю логику работы, прикладываем диаграммы, списки и таблицы.
Как я это понял?
Этот раздел поможет не только разработчику но и менеджеру. Так, например, можно встретить прямое или скрытое сопротивление со стороны разработки или руководства по задаче, а корректно указав факты и цифры, будет много проще завоевать доверие и сотрудничество всех участников.
Как измерить и охват?
Фактически это гипотеза, в которой указываем те метрики которые будут подвержены изменениям после релиза. Проработав этот раздел будет проще поставить приоритет для выполнения в backlog’е.
PR - рассказываем о фиче
Необязательный пункт. Но я верю, что умение рассказать о свое работе чрезвычайно важно как внутри организации так и снаружи.
Теперь закончив с описанием, нам нужно накачать разработчика менее объемными но важными деталями задачи.
Блок 2: Детали (нефункциональные требования)
Это простая и достаточно фомализованная часть, тут мы указываем весь контекст который необходим для выполнения задачи. В зависимости от типа команд и работ этот блок может меняться, например, вряд ли разработчику backend потребуются макеты интерфейса, хотя…
Технические требования и ограничения
Для каких платформ планируем релиз? Для каких браузеров? Регионов? Специальный фреймворк?
Требования к аналитике
Что отслеживаем как называем события, куда отправляем?
Спецификации дизайна
Макеты и руководства, ассеты.
Обработка ошибок
- Типы ошибок?
- Как на них должна реагировать система?
- Какие сообщения отображаются пользователю?
Локализация
- Нужна?
- Если да то где взять, или какие строки использовать?
Прочее
Все что не попало в предыдущие пункты:
- тестовые аккаунты, dev. окружение,
- контакты стейкхолдера,
- тестовые кейсы (но это уже высший уровень).
Как с этим жить?
На первый взгляд получился объемный чек-лист, который может просто отбить желание составлять задачи, но… Начните составлять классные задачи и ваша команда отблагодарит вас своей производительностью, а еще, разработчики будут хвастаться что у них есть классный менеджер.