Инциденты против задач

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

Инциденты в большей части случаев имеют формулировки: "Ваш сайт не работает" , "Эта фича работает неправильно", "Всё сломалось" и другие похожие. И при разборе каждого инцидента нужно вникать в проблему , потому что при взгляде на заголовок понять, что нужно делать не так просто.

Наоборот к инциденту, правильно сформулированная задача позволяет с первого взгляда понять "Что надо делать?" и "Кто будет делать?". Например:

• Починить реагирование сайта на броузер Opera
• Исправить поведение фичи
• Починить работоспособность программы.
• Реализовать функционал ААА.
• Написать документ "Описание программы".
• Добавить кнопку вызова оператора на сайт.

Как видите, тут уже видно ЧТО надо сделать. Но заголовок задачи, это только часть правильной постановки. Задачи в отличии от инцидентов все-таки должны быть когда нибудь сделаны. Между созданием задачи и её выполнением может пройти много времени, может смениться команда, или вы просто забудете зачем вы хотели это сделать или что именно подразумевали под формулировкой "Починить", "Исправить" и тд.

Неправильные задачи

Неправильная задача это такая задача когда:

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

Правильные задачи

Правильная задача, это антоним к неправильной задаче.

• Её понятно что сделать при просмотре заголовка 2 секунды.
• Вы можете её делегировать другому сотруднику.
• Вы можете её сделать и через месяц и через год.
• Она не похожа на зарегистрированный инцидент.

Другими словами, идеальную задачу можно делегировать , и не забыть зачем её нужно было делать

Для формулирования идеальной постановки задачи я рекомендую простой алгоритм:

Заголовок задачи

1. Заголовок задачи самая важная часть, "как вы судно назовете так оно и поплывет". Заголовок должен за 2 секунды давать понимание что нужно сделать и кому это можно поручить.

Для того чтобы заголовок был правильным он должен содержать глагол, например:

• написать,
• реализовать,
• исправить,
• добавить,
• починить...

и другие.

Пример:

• Добавить кнопку на сайт.
• Починить работоспособность сайта

Цель задачи

2. Описание задачи следует начинать с раздела "Цель" отвечающего на вопросы:

• Зачем нужно делать эту задачу?
• Почему я должен инвестировать NNN дней на реализация YYY функционала?
• Нафига оно мне надо?

Даже если вам кажется "что тут писать и так понятно что надо исправить дефект", лучше всего все-равно указать причину, это поможет выбрать важные и срочные. Для дефектов это может быть:

• Улучшить эргономику сайта
• Повысить конверсию сайта
• Исправить дефект.

Всякое исправление или доработка может носить в себе отпечаток "был баг" или не носить, или баг не критичный, но нам это принципиально важно, поэтому Цель следует указывать.

Что сделать

3. Даже если краткое описание задачи содержит глагол, это не всегда является достаточным для понимания , "А что же на самом деле нужно сделать?" , Например: Мы указали "Исправить поведение сайта" а сделать то что надо? Это может быть :

• Исправить таблицу стилей
• Изменить формат блока
• Добавить выходной фильтр

и другие.

Даже если это "ЕЖу ПАнятно" , не экономьте на буквах, это позволит

• без труда делегировать задачу, не объясняя на пальца что требовалось сделать.
• рассказать "себе будущему" что имел ввиду когда придумывал.
• сделать работы высокоэффективным способом (не включая мозг)

Раздел "что сделать" также может называться "Требования" , обычно следует после "Цели" или описания проблемы и отвечает на вопрос: А что конкретно делать надо? По пунктам. (Сколько вешать в граммах)

Критерий завершения

4. Относительно спорная секция в описании задачи. Она не относится напрямую к "что сделать", и требует траты больше «патроно-решений», как их называет Макс Дорофеев, для формулировки задачи. И может быть похожа на секцию "Что сделать".

Похожа, но не совсем. В этой секции следует описать факты по которым вы или другой сотрудник сможете определить сделана задача или нет.

Пример критериев:

• Все тесты проходят успешно
• Сценарий А35 выполняется
• Фича А работает.
• Задачи до доработке записаны
• Документация в wiki обновлена.

Выводы

1. Инциденты это не задачи
2. Инциденты не годятся для управления проектами
3. Систему управления инцидентами можно использовать для проектной деятельности если правильно формулировать описание задачи.
4. Правильно сформированная задача позволяет её делегировать даже неопытному сотруднику.
5. Правильная созданная задача требует больше патроно-решений только один раз на создании, а не каждый раз когда вы на ней смотрите.

Что есть в BiPulse для задач

BiPulse никак не регламентирует формулировки и разделы, но у нас есть wiki разметка схожая с MediaWiki.

При работе с инструментом можно использовать шаблон:

= Цель =

(зачем делать)

= Что сделать =

(по пунктам, что сделать надо?)
#
#

= Критерий завершения =

(Что получим после выполнения? Какие артефакты, результаты)
#
#