С влиянием трекера задач на работу все более-менее понятно. Теперь о том, как трекер правильно «готовить».

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

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

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

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

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

Трекер публичен. У команды должен быть доступ ко всем задачам проекта. Если в нем есть «секретные» задачи, то нельзя составить сколь-либо достоверный план работ, нельзя оценить сроки.

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

Скрывать при этом задачи по проекту ото всей остальной компании или нет — это решение зависит от самой команды и от корпоративной культуры. Если проект не касается вопросов безопасности или не посвящен работе над прорывным продуктом, то минусов у открытого на всю компанию списка задач практически нет.

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

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

Есть соблазн не записывать в трекер всякую мелочь (например, исправление орфографических ошибок в интерфейсе или в тексте на сайте), а работать только с крупными задачами. Но тогда будет непонятно, на что уходит заметная часть рабочего времени, и не будет пользы от параллельной работы над задачами: пока один фиксирует проблемы, второй может спокойно брать записанное и исправлять.

Одна задача — один тикет. Не стоит записывать в один тикет много работ сразу: разные задачи в проекте могут находиться в разных состояниях, у задач разные сроки, разный состав участников обсуждения и разные ответственные. Если большую задачу (решение которой займет больше одного дня работы) разбить на подзадачи, с ними можно будет работать параллельно.

Я видел полугодовой проект, работа над которым велась в одном единственном тикете. В его описании было сформулировано, что надо сделать, а в комментариях менеджер дописывал, что еще нужно поменять, доделать, исправить. Через полгода работы в таком тикете совершенно невозможно разобрать, что именно собирались сделать, что реализовали, что нет, почему принимались те или иные решения, какие вопросы обсуждались. В итоге проект шел в три раза дольше, чем предполагалось.

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

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

Читайте также о том, от чего зависит выбор багтрекера: «Интранет для компаний разного калибра»