Описание задач: блоки и принципы
С постановкой задач в компаниях сталкиваются все — независимо от уровня специалиста и профиля его работы. Что уж говорить, если даже котенок может поставить задачу: он мяукнул — ты его погладил. Но проблема в том, что даже в ситуации, когда задачи приходится ставить часто и неоднократно, далеко не все могут сделать описание понятным и интерпретируемым — вполне возможно котенок мяукал, чтобы попросить поесть, но в итоге остался непонятым и голодным.
Меня зовут Эдуард Аитов. Я Team Lead команд Токио и Берлин в медицинской компании “СберЗдоровье”. В этой статье я расскажу о частых проблемах в описаниях задачи, способе их решения и основных критериях качественной задачи.
Некоторые проблемы описания задачи
Постановка задачи — только на первый взгляд простой процесс. На самом деле он часто напоминает игру в «Сапёра», где каждое неверное действие может привести к известному результату: неверно объяснил суть задачи исполнителю и получил тыкву вместо новой фичи для приложения.
На основе своего опыта работы в разных командах я выделяю несколько проблем в описании задачи, которые встречаются чаще остальных.
Описание, основанное на текущем контексте. Часто при описании задачи заказчик исходит из того, что он погружен в процесс и знает все подводные камни. В итоге из описания выпадает все то, что кажется очевидным. На практике это часто приводит к тому, что ни исполнитель, ни сам заказчик через некоторое время уже не могут понять, что имелось ввиду и какие есть неочевидные нюансы.
Нет критериев приемки. Если в задаче не описано, что должно получиться в итоге, есть шанс получить не тот результат, который ожидается. Особенно это актуально для задач, которые выполняются «в вакууме», то есть без контекста.
- Задачу невозможно оценить. Еще до постановки должны быть понятны сроки и ресурсы, необходимые для выполнения задачи. Ситуации, когда в работу отдают крупный проект в надежде понять сроки по ходу выполнения, часто приводят к срыву дедлайнов и нерациональной загрузке команды. При этом оценить приоритетность таких задач часто невозможно.
- Выполнение задачи нельзя проверить. Бывают ситуации, когда в спешке ставят задачи, которые нельзя проверить до выкатки в прод. Например, когда написание кода вносят в одну задачу, а его тестирование — в другую. Это чревато риском завершения задачи с ошибками и багами.
В итоге сочетание таких ошибок приводит к созданию плохого описания, с которыми раньше нам приходилось сталкиваться и в СберЗдоровье.
Реализовать API для новой карточки врачей
Для фронта требуется отдавать новый список параметров для карточки врачей, который описан в задаче [...]
Здесь на первый взгляд все понятно — надо реализовать API для новой карточки врачей. Но нет ни критериев приемки, ни шагов по реализации, ни бизнес-целей — в итоге задача напоминает выражение из сказки: «Поди туда — не знаю куда. Принеси то — не знаю что».
Пути решения
Описанные проблемы можно предупредить и исключить, внедрив в компании практику разделения описания задачи на логические блоки.
Причин сепарирования задачи на блоки несколько.
1. Каждый из блоков нужен в разном контексте. В зависимости от стадии работы с задачей, может быть важно узнать как бизнес цель, так и шаги по реализации или критерии приемки. Это упрощает работу специалистов и позволяет обращаться только к тем блокам, которые нужны сейчас, а не читать задачу целиком.
2. Разным ролям чаще нужны определенные блоки. Так:
стейкхолдеру важнее понимать бизнес-ценность;
разработчику в процессе реализации — нужно техническое описание шагов, которые следует сделать;
тестировщику или ревьюверу — критерии приемки задачи.
3. Можно передать максимальный контекст. Заказчику значительно рациональнее и проще качественно описать задачу, а не отвечать потом в личных сообщениях на ряд вопросов по ней.
В своей команде я придерживаюсь разделения на три логических блока: Why, What, DoD.
- Первый блок — Why. Призван объяснить исполнителю, почему нужно сделать задачу — дает понимание, чего именно нужно добиться в рамках реализации. Например — «Для эффективной работы с Sentry, требуется провести ревизию ошибок». Такое краткое, но емкое объяснение поможет разработчику или другому специалисту учитывать контекст и зависимости, а также искать возможные способы реализации.
Второй блок — What. Нужен, чтобы конкретизировать задачу и объяснить, что именно надо сделать. Как правило, в блоке What прописывают набор действий, необходимых для реализации. При этом важно, чтобы это был не строгий манифест, а просто перечень действий — в таком случае у исполнителя будет свобода «маневра» для выбора подходов, инструментов и вариантов решения.
Помимо этого, блок What также можно использовать для последующей оценки задачи — посмотрев, что требовалось реализовать, проверяющий может понять, насколько результат соответствует ожиданиям.
- Третий блок — DoD (Definition of Done). Содержит критерии приемки, по которым можно понять, что задача завершена. Фактически Definition of Done — контракт между исполнителем, автором и проверяющим, который позволяет исключить дополнительные вопросы. DoD можно использовать в качестве чек-листа, с помощью которого исполнитель будет видеть, что от него требуется, а остальные — что сделано или что нужно проверить. Таким образом DoD уменьшает вероятность ошибки.
Приведение описания задачи к виду с тремя логическими блоками делает его предельно подробным и понятным, полезным на всех этапах выполнения, исключает разночтения и дополнительные вопросы со стороны исполнителя. Например, карточка задачи может иметь следующий вид.
Реализовать API для новой карточки врачей
Why
В рамках реализации нового дизайна карточки врачей, требуется подготовить API
What
1. URL итогового запроса: GET [...]
2. Входящие/возвращаемые параметры: [системный анализ]
3. Написать тесты: unit, api
4. Написать API документацию
DoD
Реализован новый метод API для карточки врачей, написаны тесты и документация
Кроме этого, в описание можно добавлять опциональный блок, который прописывают уже после реализации — QA Notes. Фактически это небольшая заметка, в которой исполнитель, максимально погруженный в суть задачи и особенности реализации, может подсказать проверяющему, что стоит проверить тщательнее, как сделать тест быстрее и качественнее. QA Notes — необязательный, но полезный блок, который помогает ускорить проверку.
Реализовать API для новой карточки врачей
Why ...
What ...
DoD ...
QA Notes
Протестировать URL:<...> с наборами параметров <...>, <...>, <...>, ожидаемое поведение: <...>
Документация API: <...>
Проверить негативные кейсы: <...>
Критерии качества задачи: INVEST
Наряду с разделением на логические блоки, также важно приводить описание задачи в соответствие критериям качества. Такие, например, декларирует набор принципов INVEST (INVEST — аббревиатура от названия шести принципов).
- Independent — задача должна быть независимой. Ее выполнение не влияет на другие процессы. При этом, если ряд задач являются тесно связанными, их следует объединить в одну. Например, написание тестов тесно связано задачей по реализации функционала.
- Negotiable — задача должна иметь пространство для маневра. Исполнитель должен иметь возможность обсуждать детали реализации во время выполнения. Он не должен быть в заранее установленных жестких рамках, а должен иметь возможность влиять на задачу.
- Valuable — задача должна приносить бизнес-ценность. Даже если сама по себе задача может не привести к созданию полноценной, готовой к выпуску функции, она должна быть измеримым шагом на пути к этой цели — быть наглядной и показывать, что прогресс был достигнут.
- Estimatable — должна быть возможность оценить задачу. Перед началом выполнения задачи должна быть возможность четко обозначить ее сроки. Если такой возможности нет — задача сформулирована неверно.
Small — задача должна быть небольшой. В идеале любая задача не должна занимать более 50% времени итерации. Все, что выходит за пределы этого диапазона в 50% времени итерации, следует считать слишком большим, чтобы его можно было оценить с хорошей степенью уверенности — такие большие задачи стоит выносить в эпики и декомпозировать.
- Testable — задача должна быть тестируемой. Задачу следует считать завершенной, только если она прошла успешное тестирование. Если задачу невозможно протестировать из-за отсутствия информации или доступов, не следует включать ее в бэклог спринта.
Важно, что принцип INVEST применяется для описания задачи целиком.
Рекомендации: action points на основе наших советов
Попробуйте применить принцип Why - What - DoD при постановке задач. Простой подход с разделением описания на блоки позволит повысить качество задач с минимальным оверхедом. Мы приняли его в одной из команд и увидели улучшение качества.
Если после реализации задачи вы можете помочь в ее тестировании, добавьте блок QA Notes в задачу с описанием проверок.
- Проверяйте качество поставленной задачи на соответствие принципам INVEST. Часто задача может не соответствовать некоторым пунктам из INVEST, но само понимание этих принципов поможет сделать задачи качественнее.