Реестр поручений: как простой инструмент помогает команде разработки контролировать поток задач

Меня зовут Павел Сергеев, я исполнительный директор ROBIN компании SL Soft. Расскажу подробнее, как упорядочить выполнение текущих задач с помощью реестра поручений.

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

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

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

Принципы создания реестра поручений

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

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

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

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

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

Каждая задача описана лаконично. Если для ее достижения требуется выполнение нескольких подзадач — всю подобную детализацию лучше вынести в комментарии.

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

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

Структура реестра поручений. Основные параметры

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

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

Колонка «Описание задачи» содержит лаконичную и четкую формулировку задания и ожидаемого результата.

В колонке «Исполнитель» проставляется выбранный ответственный специалист.

Колонка «Состояние» или «Статус» помогает отсортировать задачи по актуальности. Для этого важно вести единообразный, структурированный перечень, например: «в очереди», «ожидает подтверждения», «в работе», «отменена», «выполнена», «закрыта».

Пункт «Ожидает подтверждения» важен для команды разработки в случае, когда все задачи из бэклога перед началом работ обязаны получить одобрение заказчика.

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

Также не стоит настраивать статус задачи «отложена», так как это сразу лишает ее конкретики, и в итоге про нее можно просто забыть. Даже если существует объективная причина, которая мешает выполнению, лучше перенести ее на более поздний срок или, если это возможно, поставить статус «отменена».

Все задачи со статусом «выполнена» собираются за отчетный период и демонстрируются заказчику. После этого они переводятся в статус «закрыта».

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

Советы и лайфхаки по ведению реестра

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

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

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

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

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