Привет, Хабр! Меня зовут Дмитрий, я руководитель проектов компании SimbirSoft. В этой статье расскажу, зачем в IT использовать BDC (burndown chart), почему участие команды ключевое в этом процессе и что делать после внедрения BDC.

1. Внедрить BDC на проекте = соблюдать процессы

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

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

Как это сделать? Например, вы можете намеренно использовать очевидно неактуальные данные на дейли-митинге для выводов и таким образом дадите понять, что вы реально пользуетесь инструментом и зафиксированной в нем информацией. Представим ситуацию: разработчик закончил задачу еще два дня назад, перестал списывать на нее время, не перевел в статус Done, а после вообще взял следующую задачу, не переведя из To Do в In Progress. Спросите его, почему он списывает время не на ту задачу и когда вообще уже наконец закончится работа по первой, дедлайн которой был два дня назад! Баланс тона между строгостью и иронией тут стоит подбирать от запущенности ситуации в конкретном случае :)

2. Оценка трудозатрат = шкала Y графика BDC

BDC является инструментом планфакторного анализа, поэтому подготовка к его использованию начинается еще до старта проекта — на этапе планирования работ и оценки трудозатрат. 

Есть два основных варианта оценки трудозатрат:

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

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

Оценка в сторипойнтах несколько сложнее и чаще служит дополнением к оценке и планированию проекта в часах. Однако при таком подходе, у вас не будет возникать ложного впечатления о прогрессе задач на основе списанных часов. Прогресс BDC при оценке в сторипойтах строится только на сгорании сторипойнтов закрытых (выполненных) задач. И тут опять важна декомпозиция. Разработчик может делать неделю одну задачу на 4 сторипойнта, или три задачи на 1+2+1 сторипойнта. В первом случае вы узнаете о возможных проблемах только в конце недели, во втором есть неплохие шансы узнать об этом в середине.

Промежуточный вывод: глубина декомпозиции задач при оценке проекта для BDC — это как разрешающая способность дисплея, либо вы смотрите на большие пиксели 640х480 и пытаетесь понять, собака это или слон, либо рассматриваете детали в 4к. 

3. Оценка сроков = шкала X графика BDC

Шкала Х BDC тоже закладывается на этапе планирования, будь это Waterfall проект или спринт по Scrum. Так или иначе, вам нужно распараллелить работы участников команды и заложить дополнительный срок на риски. Сложность обычно возникает с последним, но это, опять же, тема отдельной статьи. Если упросить, то тут важен баланс между риском не успеть в срок и излишней перестраховкой. Посмотрите, что для заказчика больнее, и принимайте решение.

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

Важный момент — в вашем проекте могут быть производственные и непроизводственные задачи. 

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

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

Закладывать в BDC непроизводственные задачи считаю нецелесообразным. Сколько бы вы ни провели совещаний с командой или клиентом, это не поможет написать код быстрее. Однако команда будет обязательно тратить часы на такие задачи поэтому вам необходимо учитывать время на них при планировании сроков спринта. Как правило, срок на непроизводственные задачи закладывается процентом от производственных, ориентиром может выступать цифра в 18%, однако она может варьироваться в зависимости от конкретных условий проекта.

4. Дисциплина в списании трудозатрат = прогресс графика

Итак, вы оценили задачи, запустили спринт, начали строить BDC и объяснили команде, что это и зачем. Но команда все равно забывает списывать время вовремя и не актуализирует статусы задач, а ваш график с самого начала отстает от планового. Что делать?

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

5. Что показывает график? (примеры графиков, что они значат, что с этим делать)

Равномерное снижение

Базовый, идеальный вариант, к которому стоит стремиться.

График плавно снижается от максимума до нуля, с незначительными отклонениями, что указывает на равномерный и сбалансированный темп выполнения задач. Команда последовательно работает над задачами, и всё идет по плану.

Рекомендации:

• Поддерживайте такой темп, продолжая следить за нагрузкой команды и прогрессом.

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

Слишком медленное снижение (плоский график)

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

Возможные причины:

• Много времени уходит на непроизводственные задачи.

• Команда сталкивается с непредвиденными блокировками.

• Оценка задач была неверной, и на них уходит больше времени.

• Не хватает ресурсов, или они некорректно распределены.

Рекомендации:

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

• Пересмотрите приоритеты задач, удалите блокировки, перераспределите работу или улучшите координацию.

• Возможно, стоит уменьшить объем задач для текущего спринта или пересмотреть оценки задач.

• Возможно команде необходимо немного времени на погружение и она только набирает темп.

Резкие скачки (нелинейное снижение)

График имеет скачки, где подолгу нет прогресса, а затем внезапно отмечается резкое снижение объема работы. Это может говорить о том, что задачи закрываются пакетами или списание времени производится несвоевременно — команда не дисциплинирована, а отчетность не отражает реальность.

Возможные причины:

• Задачи слишком большие (работу разбили на слишком крупные этапы).

• Задачи остаются «почти завершенными», но не закрываются вовремя из-за необходимости дополнительных проверок или связанностей.

• Команда списывает время на проект не регулярно (напр. раз в неделю), вместо ежедневного списания.

Рекомендации:

• Разбейте задачи на более мелкие части, чтобы прогресс был более равномерным.

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

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

График растет вместо снижения (возрастающая кривая)

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

Возможные причины:

• После старта спринта добавляются новые задачи.

• Переоценка задач приводит к увеличению объема работы.

Рекомендации:

• Пересмотрите план спринта или проекта, при необходимости перезапустите спринт.

• Следите за тем, чтобы задачи оставались реалистичными для завершения в заданные сроки.

Резкое снижение в последние дни (отложенная работа)

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

Возможные причины:

• Команда откладывала выполнение основных задач до последних дней.

• Сложности или блокировки в начале спринта замедлили процесс.

• Возможно, задачи были неправильно оценены.

Рекомендации:

• Отслеживайте прогресс на дейли-митингах по каждому разработчику.

• Пересмотрите процесс планирования задач — возможно, стоит уделить больше времени на детальное описание задач и оценку.

• Убедитесь, что работа равномерно распределяется по всей длине спринта.

График не достигает нуля (незавершенная работа)

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

Возможные причины:

• Команда взяла на себя слишком много задач на спринт.

• Оценки задач были неточными.

• В процессе возникли непредвиденные сложности.

Рекомендации:

• В следующем спринте более тщательно планируйте объем задач.

• Проведите ретроспективу, чтобы выяснить причины и внести коррективы в процесс.

• Возможно, стоит внедрить практику более детального анализа рисков в начале спринта.

Давайте обсудим! Ваши советы и вопросы могут помочь другим лучше понять, как работать с данным инструментом. Поделитесь, также, в комментариях интересными кейсами работы с burndown chart, обмен опытом и знаниями помогает всем нам наращивать экспертизу в управлении проектами.

Спасибо за внимание!

Больше авторских материалов для руководителей IT-проектов от моих коллег читайте в соцсетях SimbirSoft – ВКонтакте и Telegram.