Лайфхаки DM, или Как не утонуть в потоке задач

20 января
Дмитрий Зота, Delivery Manager, DataArt
Лайфхаки DM, или Как не утонуть в потоке задач
Работа деливери менеджера (DM) состоит из двух основных направлений: проекты и opportunity (потенциальные проекты).

Управление портфелем проектов включает в себя:

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

При обработке потенциальных проектов DM отвечает за:

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

Есть рекомендации, шаблоны и передовой опыт (best practice), но полностью стандартизировать эти активности не всегда возможно. Их количество, ожидаемые результаты, сроки выполнения и составы рабочих групп различаются от проекта к проекту. Дело в том, что каждый проект разный. Прямо как по PMBOK — разными их делает уже то, что заказчики разные. Разный скоуп, разные технологии, разные графики, разные формы и частота отчетности, разные ожидания и подходы к решению проблем…

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

Общие шаги кратко сводятся к простому сценарию:

  1. К нам приходит opportunity.
  2. Мы пишем наше предложение.
  3. Клиент соглашается и подписывает с нами договор.
  4. Запускаем проект.
  5. Ведем проект.
  6. Закрываем проект.

Но все, что внутри этих пунктов, — пространство для творчества.

Иной раз ты работаешь с десятком команд и должен помнить, кто чем занимается, насколько выполнена та или иная задача, кому и что обещал ты, кто и что обещал тебе.

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

Мы работаем в сверхтехнологичной области. Пусть же технологии помогут нам сделать контроль легче и результаты прозрачнее.

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

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

Хочу поделиться простой и эффективной системой в JIRA, которая позволяет ничего не забывать (или почти ничего) и успевать вовремя (или вовремя предупреждать, если не успеваем).

Структура

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

  1. Под каждую opportunity создается эпик.
  2. Если opportunity выиграна, название эпика переименовывается в _prj.
  3. Каждая требующая контроля задача заводится как User Story в соответствующий Epic.

Так же есть две борды: Main и Epics:

  • Epics — тут можно отследить в каком статусе находится тот или иной проект;
  • Main — тут все задачи сгруппированные в swimlines по эпикам.

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

Так выглядит Epics.

Борда Main сгруппирована по эпикам. Развернем один из потенциальных проектов. Одного взгляда достаточно, чтобы понять, что сделано, что в работе, а что еще предстоит.

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

Для задач с конкретным дедлайном я использую поле Due Date. Тогда задача появится на календаре на дашборде.

Как этим пользоваться?

Система максимально проста. Развернуть и настроить проект в JIRA займет 20‑30 минут. Используются только стандартные и установленные по умолчанию Issue types и workflows. Но при простой структуре система дает данным много полезного контекста и удобства. Каждый день, приходя на работу, я прохожусь по списку задач в in progress. Митинг ноуты тоже записываю в соответствующие задачи и высылаю по почте участникам.

Хорошая практика — составление и отправка статус-репортов коллегам раз в неделю. Теперь мне достаточно отфильтровать все issues по полю updated. Все, что имеет апдейты за эту неделю, попадет в репорт о проделанной работе. Все что не имеет апдейтов, тоже попадет в репорт с пометкой Stuck.

Из каждого issue можно перейти в эпик проекта (просто нажав на него) и сразу увидеть картину в целом.

Если вы используете Confluence, статус проекта легко отобразить и там. Нажимаем Ctl+Shift+J и добавляем нужный фильтр в страницу.

Dashboard

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

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

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

PieChart

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

Учитывается не количество затраченного времени, а именно количество задач, ассоциированных с проектом, как косвенное свидетельство сложности именно этого проекта. Можно также вести учет времени, но тогда вместо комментариев надо будет использовать Log Work.

Created vs. Resolved

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

Issue Calendar

Тут все просто: календарь задач, у которых есть точная дата выполнения. При желании этот календарь можно синхронизировать со своим аутлуком, чтоб Issues сами появлялись в нем как аппоинтменты.

Резюме

Из минусов:

  • На настройку системы понадобится 20–30 минут.
  • На поддержание в актуальном состоянии — 5 минут утром, 5 минут вечером.

Из плюсов:

  • Наглядность информации.
  • Удобство навигации.
  • Генерация отчетности.
  • Анализ трендов и прогнозирование.

Надеюсь, система вам пригодится.