Описание задач: блоки и принципы

С постановкой задач в компаниях сталкиваются все — независимо от уровня специалиста и профиля его работы. Что уж говорить, если даже котенок может поставить задачу: он мяукнул — ты его погладил. Но проблема в том, что даже в ситуации, когда задачи приходится ставить часто и неоднократно, далеко не все могут сделать описание понятным и интерпретируемым — вполне возможно котенок мяукал, чтобы попросить поесть, но в итоге остался непонятым и голодным.

Меня зовут Эдуард Аитов. Я Team Lead команд Токио и Берлин в медицинской компании “СберЗдоровье”. В этой статье я расскажу о частых проблемах в описаниях задачи, способе их решения и основных критериях качественной задачи.

Постановка задачи — только на первый взгляд простой процесс. На самом деле он часто напоминает игру в «Сапёра», где каждое неверное действие может привести к известному результату: неверно объяснил суть задачи исполнителю и получил тыкву вместо новой фичи для приложения.

На основе своего опыта работы в разных командах я выделяю несколько проблем в описании задачи, которые встречаются чаще остальных.

• Описание, основанное на текущем контексте. Часто при описании задачи заказчик исходит из того, что он погружен в процесс и знает все подводные камни. В итоге из описания выпадает все то, что кажется очевидным. На практике это часто приводит к тому, что ни исполнитель, ни сам заказчик через некоторое время уже не могут понять, что имелось ввиду и какие есть неочевидные нюансы.

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

• Задачу невозможно оценить. Еще до постановки должны быть понятны сроки и ресурсы, необходимые для выполнения задачи. Ситуации, когда в работу отдают крупный проект в надежде понять сроки по ходу выполнения, часто приводят к срыву дедлайнов и нерациональной загрузке команды. При этом оценить приоритетность таких задач часто невозможно.
• Выполнение задачи нельзя проверить. Бывают ситуации, когда в спешке ставят задачи, которые нельзя проверить до выкатки в прод. Например, когда написание кода вносят в одну задачу, а его тестирование — в другую. Это чревато риском завершения задачи с ошибками и багами.

В итоге сочетание таких ошибок приводит к созданию плохого описания, с которыми раньше нам приходилось сталкиваться и в СберЗдоровье.

Здесь на первый взгляд все понятно — надо реализовать API для новой карточки врачей. Но нет ни критериев приемки, ни шагов по реализации, ни бизнес-целей — в итоге задача напоминает выражение из сказки: «Поди туда — не знаю куда. Принеси то — не знаю что».

Описанные проблемы можно предупредить и исключить, внедрив в компании практику разделения описания задачи на логические блоки.

Причин сепарирования задачи на блоки несколько.

1. Каждый из блоков нужен в разном контексте. В зависимости от стадии работы с задачей, может быть важно узнать как бизнес цель, так и шаги по реализации или критерии приемки. Это упрощает работу специалистов и позволяет обращаться только к тем блокам, которые нужны сейчас, а не читать задачу целиком.

2. Разным ролям чаще нужны определенные блоки. Так:

• стейкхолдеру важнее понимать бизнес-ценность;

• разработчику в процессе реализации — нужно техническое описание шагов, которые следует сделать;

• тестировщику или ревьюверу — критерии приемки задачи.

3. Можно передать максимальный контекст. Заказчику значительно рациональнее и проще качественно описать задачу, а не отвечать потом в личных сообщениях на ряд вопросов по ней.

В своей команде я придерживаюсь разделения на три логических блока: Why, What, DoD.

• Первый блок — Why. Призван объяснить исполнителю, почему нужно сделать задачу — дает понимание, чего именно нужно добиться в рамках реализации. Например — «Для эффективной работы с Sentry, требуется провести ревизию ошибок». Такое краткое, но емкое объяснение поможет разработчику или другому специалисту учитывать контекст и зависимости, а также искать возможные способы реализации.

• Второй блок — What. Нужен, чтобы конкретизировать задачу и объяснить, что именно надо сделать. Как правило, в блоке What прописывают набор действий, необходимых для реализации. При этом важно, чтобы это был не строгий манифест, а просто перечень действий — в таком случае у исполнителя будет свобода «маневра» для выбора подходов, инструментов и вариантов решения.

  Помимо этого, блок What также можно использовать для последующей оценки задачи — посмотрев, что требовалось реализовать, проверяющий может понять, насколько результат соответствует ожиданиям.

• Третий блок — DoD (Definition of Done). Содержит критерии приемки, по которым можно понять, что задача завершена. Фактически Definition of Done — контракт между исполнителем, автором и проверяющим, который позволяет исключить дополнительные вопросы. DoD можно использовать в качестве чек-листа, с помощью которого исполнитель будет видеть, что от него требуется, а остальные — что сделано или что нужно проверить. Таким образом DoD уменьшает вероятность ошибки.

Приведение описания задачи к виду с тремя логическими блоками делает его предельно подробным и понятным, полезным на всех этапах выполнения, исключает разночтения и дополнительные вопросы со стороны исполнителя. Например, карточка задачи может иметь следующий вид.

Кроме этого, в описание можно добавлять опциональный блок, который прописывают уже после реализации — QA Notes. Фактически это небольшая заметка, в которой исполнитель, максимально погруженный в суть задачи и особенности реализации, может подсказать проверяющему, что стоит проверить тщательнее, как сделать тест быстрее и качественнее. QA Notes — необязательный, но полезный блок, который помогает ускорить проверку.

Наряду с разделением на логические блоки, также важно приводить описание задачи в соответствие критериям качества. Такие, например, декларирует набор принципов INVEST (INVEST — аббревиатура от названия шести принципов).

• Independent — задача должна быть независимой. Ее выполнение не влияет на другие процессы. При этом, если ряд задач являются тесно связанными, их следует объединить в одну. Например, написание тестов тесно связано задачей по реализации функционала.
• Negotiable — задача должна иметь пространство для маневра. Исполнитель должен иметь возможность обсуждать детали реализации во время выполнения. Он не должен быть в заранее установленных жестких рамках, а должен иметь возможность влиять на задачу.
  
• Valuable — задача должна приносить бизнес-ценность. Даже если сама по себе задача может не привести к созданию полноценной, готовой к выпуску функции, она должна быть измеримым шагом на пути к этой цели — быть наглядной и показывать, что прогресс был достигнут.
  
• Estimatable — должна быть возможность оценить задачу. Перед началом выполнения задачи должна быть возможность четко обозначить ее сроки. Если такой возможности нет — задача сформулирована неверно.
  

• Small — задача должна быть небольшой. В идеале любая задача не должна занимать более 50% времени итерации. Все, что выходит за пределы этого диапазона в 50% времени итерации, следует считать слишком большим, чтобы его можно было оценить с хорошей степенью уверенности — такие большие задачи стоит выносить в эпики и декомпозировать.

• Testable — задача должна быть тестируемой. Задачу следует считать завершенной, только если она прошла успешное тестирование. Если задачу невозможно протестировать из-за отсутствия информации или доступов, не следует включать ее в бэклог спринта.

Важно, что принцип INVEST применяется для описания задачи целиком.

• Попробуйте применить принцип Why - What - DoD при постановке задач. Простой подход с разделением описания на блоки позволит повысить качество задач с минимальным оверхедом. Мы приняли его в одной из команд и увидели улучшение качества.

• Если после реализации задачи вы можете помочь в ее тестировании, добавьте блок QA Notes в задачу с описанием проверок.

• Проверяйте качество поставленной задачи на соответствие принципам INVEST. Часто задача может не соответствовать некоторым пунктам из INVEST, но само понимание этих принципов поможет сделать задачи качественнее.