Хорошо на заводе: есть конвейер, по которому движется продукт, и видно, как он «выращивается». Вот кузов, вот кузову добавили мотор, прикрутили колеса, добавили двери, — и вот у продукта горят фары, он бибикает и едет. Если где-то на конвейере проблема, то Канбан, или теория ограничений приходят на помощь, помогают выявить узкие места, избавиться от складских запасов. Хуже обстоят дела в информационных компаниях. Таких, чьи продукты нельзя пощупать, где место производства — головы сотрудников. При создании нематериального продукта никогда нельзя быть уверенным, на каком этапе находится работа над ним.

Программисты с такой проблемой справляются с помощью трекера задач — большой базы данных, где собирается информация о задачах, которые сделаны и которые надо сделать.

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

Внедрение трекера в повседневную работу ведет к нескольким эффектам.

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

Нормализованный процесс не обязательно будет интересен всем участникам. Хаотичный и непрозрачный процесс позволяет скрывать ошибки, низкую эффективность и злоупотребления.

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

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

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

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

Единственный нефальсифицируемый показатель — количество выпущенного продукта, или оказанных услуг.

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

На каком этапе скапливается больше всего задач? Какое время первой содержательной реакции на сообщение об ошибке? Какие задачи в работе дольше других? Что между ними общего?

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

Работа будет документироваться. Задачу, записанную в трекере, можно прокомментировать, задать вопросы, предложить варианты решения. Трекер фиксирует переход задачи между исполнителями, смену статуса и сроков, собирает историю изменения задачи и ее обсуждения.

Почему принято именно такое решение? Кто принял? Какие в ходе решения задачи были выявлены проблемы?

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

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

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

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

Читайте также: «Пять принципов работы с таск-трекером».