Что такое хорошая [продуктовая] задача.

2 мин на чтение

Небольшое лирическое вступление. Когда-то я играл в баскетбол и тренер беспрестанно вбивал нам в голову — “если твой пас не приняли в этом твоя вина”, или если коротко — “Виноват отдающий”. Как ни странно, спустя годы я часто вспоминаю это утверждение в работе с разработчиками, коллегами или топ-менеджментом.

Были у вас такие ситуации что разработчик раз за разом приходит к вам с вопросами по задаче? Или наоборот, что не приходит но к уже готовой задаче появляются все новые и новые дополнения? И в первом и во втором случае увеличивается время цикла (cycle time) то есть, увеличивается время которое уходит на конкретную работу. Как правило такое увеличение времени влият не только на разработчика но и на соседние производственные участки. cycle time

Как же сделать классную передачу задачу что бы принимающий был счастлив и ставил их в пример?

Блок 1: Описание (функциональные требования)

Это вероятно самая обширная часть описания задачи . Как проще всего и логичнее составить такое описание?
Описание может быть как в формате User stories так и другим описательным образом; Независимо от выбранного формата, будет здорово если будут сформулированы ответы на следущие вопросы:

В чем идея и/или проблема?

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

Как я это понял?

Этот раздел поможет не только разработчику но и менеджеру. Так, например, можно встретить прямое или скрытое сопростивление со стороны разработки или руковдства по задаче, а корректно указав факты и цифры, будет много проще завоевать доверие и сотрудничество ото всех участников.

Как измерить и охват?

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

Pr - рассказываем о фиче

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

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

Блок 2: Детали (нефункциональные требования)

Это простая и достаточно фомализованная часть, тут мы указываем весь контекст который необходим для выполнения задачи. В зависимости от типа команд и работ этот блок может меняться, например, вряд ли разработчику backend потребуются макеты интерфейса, хотя…

Технические требования и ограничения

Для каких плтформ планируем релиз? Для каких браузеров? Регионов? Специальный фреймворк?

Требования к аналитике

Что отслеживаем как называем события, куда отправляем?

Спецификации дизайна

Макеты и руководства, ассеты.

Обработка ошибок

Типы ошибок? Как на них должна реагировать система? Какие сообщения отображаются пользователю?

Локализация

Нужна? Если да то где взять, или какие строки использовать?

Прочее

Все что не попало в предыдущие пункты: тестовые аккаунты, dev. окружение, контакты стейкхолдера, тестовые кейсы (но это уже высший уровень).

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

Метки:

Дата изменения: