О ежедневном использовании системы управления задачами: сводки с полей

Project management
Единственный интуитивно-понятный интерфейс — это женская грудь, всему остальному нужно учиться. Эта народная мудрость пришла ко мне сегодня утром, когда я в деталях и красках рассказывал третьему по счету коллеге, чем resolved отличается от closed и как делать log work, чтобы руководству не было потом мучительно больно. В этой статье я попробую на примере нескольких зарисовок обрисовать возможные варианты использования системы управления задачами на примере популярной Jira при ежедневной работе. Приемы, конечно, не единственно возможные — но они достаточно просты, универсальны и применимы не только к Jira, но и к большинству популярных систем управления задачами — Redmine, Trac, Bugzilla и прочим.

Внутренности задачи


Основополагающий кирпич, лежащий в основании управления задачами — это, собственно, задачи. Не считая собственно названия задачи и опционального описания, у любой задачи есть три основных свойства, вокруг которых все крутится и которые определяют ее судьбу:
  • Заказчик, он же Reporter — тот, кто инициировал задачу. Подразумевается, что это человек, для которого по тем или иным причинам важно выполнение этой задачи. Обратите внимание на размытость терминологии — «reporter» переводится с английского как «отрапортовавший», «тот кто сообщил». Исторически это свойство использовалось для багрепортов, и reporter'ом вполне очевидно был тот, кто баг нашел и не поленился о нем сообщить. Но эволюция систем управления задачами привела к тому, что их стали использовать не только для протоколирования починки багов, но и для работы с задачами вообще — «добавить новую функциональность», «написать статью на хабр», «провести standup meeting (ежедневно)». Область применения поменялась, а термин остался прежним — мало систем управления задачами разделяют «кто об этом сказал» и «кто сказал выполнять работу». В общем случае reporter — это тот человек, для которого работу надо выполнить, который будет проверять что она выполнена.
  • Исполнитель, он же Assignee — тот, кто будет выполнять задачу.
  • Состояние, оно же Status (почему-то мало где используется термин state) — что в данный момент происходит с этой задачей.

Эволюция задачи


Когда тот, кому нужна выполненная работа, осознает сей печальный факт, — он создает задачу. Действие вполне естественное, соответствующее здравому смыслу и одобренное Капитаном Очевидность. Чем характеризуется новорожденная задача? Assignee — кому надо выполнять работу и Status — текущее состояние, призванное отразить ее новорожденность. В большинстве систем только что созданная задача будет иметь состояние "Open". Данное состояние как бы говорит нам — «эта задача висит над кем-то дамокловым мечом и работы по ней либо уже ведутся, либо будут вестись в скором времени». Подразумевается, что исполнитель, увидев «на себе» задачу в состоянии «open», приступит через некоторое время к работе — в зависимости от текущих задач и их приоритета.
Предположим, у исполнителя дошли руки до выполнения задачи. Тут начинается самое интересное — в зависимости от задачи возможны варианты:
  1. Исполнителю все понятно. Он приступает к работе, некоторое количество времени (часы, дни, месяцы или годы) работает, после чего считает, что задача выполнена. Для того, чтобы об этом радостном событии узнал заказчик, исполнитель меняет состояние задачи, устанавливая его в «Resolved». В этом простом действии сокрыта масса забавных нюансов, на протяжении многих лет несущих счастье и радость как разработчикам, так и их руководителям. То, что работник считает задачу выполненной — нифига не означает что задача на самом деле выполнена. Выполненной ее может счесть только заказчик — тот, кто задачу ставил и обладает компетенцией проверить что то, что сделано — действительно то, что нужно было сделать. Поэтому состояние задачи «resolved» — это в первую очередь волейбольный мяч, брошенный от исполнителя заказчику. «Я со своей стороны сделал — проверяй». Соответственно, увидев задачу в состоянии «resolved», заказчик должен проверить что работа действительно выполнена и совершить одно из двух действий:
    1. Если работа действительно выполнена, то состояние задачи меняется на "Closed". Этим мы как бы «отправляем задачу в архив» — все сделано, отслеживать больше нечего.
    2. Но часто бывает иначе — посмотрев на сделанное, заказчик хватается за голову, бегает кругами, кричит букву «А» и другими способами выражает свое удивление. В таком случае исполнителю необходимо объяснить, что сделанное не совсем соответствует тому, что ожидает заказчик — для этого задаче снова устанавливает состояние "Open". В некоторых системах для этих же целей есть специальное состояние "Reopened" — но, как показывает практика, его наличие мало что меняет — редко когда действительно нужно различать первая это попытка или десятая — все равно это отображается в логе состояний задачи.

  2. Если есть случай когда исполнителю все понятно, то должен быть и обратный — когда исполнителю непонятно ничего. Неясные багрепорты, плохо сформулированные требования, пространные описания — все это редко добавляет оптимизма исполнителю и приводит к логичному желанию уточнить. Тут начинается самое интересное — если исполнитель задачу не выполнил, а хочет, чтобы заказчик уточнил, что надо делать — это все равно состояние "Resolved"! Достаточно контринтуитивная штука, об которую многие спотыкаются. Как я уже писал выше, «resolved» — это не выполненность задачи. Это признак того, что исполнитель что-то сделал. Например, посмотрел на задачу и решил, что неплохо бы заказчику ее уточнить :). Resolved — это пас волейбольного мяча заказчику, передача ему приоритета. Данное состояние задачи показывает, что «следующий шаг за заказчиком». Он может прочитать, что непонятно исполнителю, и решить, что задачу вообще не нужно выполнять — тогда состояние меняется на "Closed". Либо он может разъяснить, что было непонятно, и снова поменять состояние на "Open" («Reopened»).
    Внимательный читатель © здесь обязательно поинтересуется — а как же заказчик определит, что именно сделал исполнитель? Выполнил задачу или же хочет, чтобы ее ему уточнили? Дьявол, как всегда, надежно скрыт в деталях — у состояния задачи «Resolved» есть свойство — «Resolution». И именно в этом свойстве исполнитель указывает что именно он сделал или не сделал с задачей. Популярные варианты: «Fixed» (задача выполнена, тяжкое наследие багтрекеров), «Incomplete» (непонятно что делать — то, что я здесь описал), «Can't reproduce» (см. далее), «Won't Fix» (см. далее), «Duplicate» (см. далее). Корректное использование свойства «Resolution» — краеугольный камень использования систем управления задачами, о котором не все знают.
  3. Также есть менее распространенные реакции исполнителя на полученную задачу, определяемые значением свойства «Resolution». Если «Fixed» («Complete», «Done») и «Incomplete» («Need more info») есть практически во всех популярных системах управления задачами, то остальные свойства разнятся. Приведу наиболее популярные:
    1. Can't reproduce — Исполнитель не нашел чего-то, что указано в задаче. Чаще всего применяется в работе с ошибками, когда повторение ошибки разработчиком ошибки не выявляет. Но это свойство встречается и в текучке — например, если в задаче указано «копать до обеда, лопата в туалете» — а лопаты в туалете нету O_O.
    2. Won't Fix — Исполнитель не хочет выполнять работу. Название свойства, как вы уже наверное догадались — тяжкое наследие багтрекеров. Соответственно, при исправлении багов оно используется, если исполнитель уверен, что это и не баг вовсе. В багтрекерах популярных программ цепочки «Open»->«Won't Fix»->«Reopened»->«Won't Fix»->«Closed»->«Reopened»->… могут длиться годами и достигать изрядной длины.
    3. Duplicate — Исполнитель считает, что данное задание дублирует другое задание, которое он уже выполнил или только выполняет. Соответственно, заказчик может с этим согласиться — а может и не согласиться.
    4. Wait — Исполнитель что-то сделал и теперь необходимо дождаться наступления внешнего события — например, завершение работы фрилансером или возвращения бухгалтера из отпуска. Как правило, заказчику нет необходимости как-то реагировать на задачу с таким состоянием — исполнитель сам должен отследить наступление ожидаемого события и предпринять дальнейшие действия. Но контроль за такими задачами не помешает — а вдруг исполнитель забудет, что он чего-то ждет? :)


Принципиальная схема работы с задачей, надежно закопанная в глубине документации к Jira. Обратите внимание на состояние «In Progress» — оно часто используется, если у исполнителя много задач и руководству важно знать какую из них он выполняет именно сейчас. На практике, в большинстве ситуаций это состояние можно не использовать.


Фильтры — наше все


Если посмотреть на систему управления задачами какого-нибудь большого и серьезного проекта, то выглядеть она будет примерно так:

Обратите внимание на общее количество задач в этом линейном списке. Безусловно, сейчас Jira показывает все, но даже если установить фильтр «только открытые» — смена тридцати тысяч на шесть принципиально ничего не изменит. Многие разработчики, впервые воспользовавшись системой управления задачами и посмотрев на такие списки задач, начинают интересоваться «а как оно с древовидным представлением»? На первый взгляд, идея скопировать древовидную архитектуру с файловой системы кажется удачной — есть родительские задачи, есть подзадачи… Некоторые системы даже реализует такую иерархию, заявляя «неограниченную глубину подзадач» как одно из основных конкурентных преимуществ. А вот у популярных систем, таких как jira, redmine, trac — как правило есть только отношение «задача — подзадача», и то редко используемое? Почему так и как пользователи работают с километровыми списками задач?
Ответ на этот вопрос заключается в одном слове — Фильтр. Фильтры, реализованные в большинстве систем управления задачами, позволяют делать одну простую вещь — группировать задачи по определенному запросу. Например, если сделать фильтр «задачи, у которых reporter я, а состояние resolved» то мы сразу увидим задачи, по которым нам как заказчику отчитались исполнители и нужно предпринять какие-нибудь действия. Большой плюс фильтров заключается в том, что каждый пользователь системы управления задачами может сконфигурировать собственный набор фильтров, показывающий задачи в удобном для него виде. Например, фрагмент фильтра в Jira Client, показывающего работу сотрудников моего отдела:


Полезные советы


  • В вашей системе нет нужных свойств для состояния задачи «Resolved»? Не беда, большинство систем позволяют добавить собственные свойства. Например, Jira без проблем добавила свойство «Wait».
  • Для контроля выполнения задач удобно в конце дня делать «log work» — указывать, сколько примерно часов было потрачено на ту или иную задачу. Большинство систем управления задачами позволяют по этим логам составлять отчеты, так что «ежемесячный отчет чем мы занимались», которого многие боятся, составляется в два клика.
  • «Log work» можно и нужно делать даже если вы не являетесь ни заказчиком, ни исполнителем задачи. Многие системы не поддерживают назначение более одного исполнителя — но это не проблема, так как любой человек, фактически работавший над задачей, может сделать «log work».
  • При изменении состояния задачи не рекомендуется менять ни заказчика, ни исполнителя. Многие пользователи ошибочно устанавливают Assignee на того же человека, что и Reporter при установке состояния задачи в Resolve. Это рушит описанную выше логику работы и всячески препятствует «однокликовой» работы с задачами.
  • Надеюсь, по результатам обсуждения сюда чего-нибудь дописать :)


За сим закругляюсь. Если у кого есть что сказать по этой важной и не очень простой теме — с удовольствием выслушаю это в комментариях и постараюсь по возможности обсудить.
Tags:task managementjira
Hubs: Project management
+3
18.4k 73
Comments 9

Popular right now

Основы Jira Service Desk
March 22, 20216,900 ₽Luxoft Training
Профессия Product Manager
January 27, 2021108,500 ₽Нетология
Аналитика для руководителей
January 27, 202167,500 ₽Нетология
Product Manager IT-проектов
January 28, 202160,000 ₽OTUS
Team Lead 2.0
January 28, 202190,000 ₽OTUS