Привет, Мегамозг!
Сегодня небольшим лайфхаком для проджект-менеджеров поделится наш коллега Илларион Остапов. Надеемся, кому-то изложенное пригодится и сделает трудовые будни чуточку продуктивнее.
Уверен, у вас такое тоже бывает: приходит интересный проект, наполненный нетривиальной логикой, интеграциями с разными закрытыми системами и ожиданиями клиента через полгода начать использовать его в продакшне.
И вы с коллегами (а может, даже и не вы, а кто-то до вас, как это было в моем случае) опираясь на богатый опыт, набрасываете план. План выглядит чудесно, и по нему все фичи ровно в срок, и burn rate в пределах клиентских ожиданий. Одним словом, не проект, а сказка, но проходит kick-off — и сказка начинает плавно превращаться в жизнь.
Что происходит дальше, вы тоже прекрасно знаете: ошибки в оценке задач, изменения требований, непредвиденные вылеты членов команды, неучтенные технические задачи, необходимость рефакторинга, увеличение времени на коммуникацию в связи с ростом команды — перечислять можно долго. Что самое печальное — избежать этих моментов крайне и крайне сложно.
Признаюсь, мне не хотелось потерять бразды правления проектом и ожиданиями клиента. Поиски своего пути начались с отслеживания статуса через msproject-план с дальнейшим переносом затраченных и оставшихся часов в монстроподобную таблицу, сопровождаемую не менее громоздким письмом. Вот пример такого послания после одного из спринтов, когда отставание уже наметилось:
Подобные отчеты было интересно смотреть клиенту, но для меня они стали сущим адом, ведь на подготовку уходил, как правило, день. Учитывая, что реальный фронт работ и изначальный план с каждым спринтом все меньше походили друг на друга, метод стал совсем не эффективным.
Стоило мне отчаяться, как на выручку пришли коллеги, подсказавшие, что в Jira Agile появились замечательные отчеты — Release Burndown и Epic Burndown. Они позволяют не только оценить текущую ситуацию в разрезе релиза и эпиков, но и после трех спринтов прогнозировать количество оставшихся итераций на основе средней производительности. Выглядят они замечательно, но есть нюанс: JIRA должна быть в полном порядке, а значит, следует выполнять правила:
- Все issues должны быть привязаны к Epic и версиям (fix version).
- Отчет не может оперировать эстимейтами саб-тасок, значит, если вы бьете юзер стори на саб-таски, надо проставлять и эстимейты для каждой, и общий суммарный эстимейт для стори. При этом снимать галочку include subtasks в Time tracking-секции настроек тикета и не забывать при актуализации эстимейта саб-тасок актуализировать эстимейт для стори.
- Во время завершения спринта переводить все реализованные и проверенные QA тикеты в статус closed. Если что-то зависнет в resolved, время, потраченное на эти тикеты не спишется в отчете текущего спринта и, соответственно, испортит статистику.
- И, конечно, ежедневно внимательно записывать затраченное время и актуализировать эстимейты. Чтобы картинка была прозрачной, рекомендую установить плагин Tempo Timesheets (спасибо Игорю Масленникову за наводку). Так вы всегда наглядно сможете понять, кто забыл залогать время, или кто главный стахановец в команде :)
Делая эти простые ежедневные процедуры, в любой момент вы сможете получить картину происходящего в проекте и в краткосрочной, и в долгосрочной перспективе. Дополнив эту картинку небольшими комментариями, сможете сделать отличный отчет всего за 30 минут. Вот так это выглядело у нас:
Enjoy your projects!
