Привет, Мегамозг!

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

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

И вы с коллегами (а может, даже и не вы, а кто-то до вас, как это было в моем случае) опираясь на богатый опыт, набрасываете план. План выглядит чудесно, и по нему все фичи ровно в срок, и 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!

Автор: DataArt

Источник