Лайфхаки 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 ввечері.

Плюси:

  • Наочність інформації.
  • Зручність навігації.
  • Генерація звітності.
  • Аналіз трендів і прогнозування.

Сподіваюся, система стане вам у пригоді.