Как прошлый аврал становится следующим планом

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

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

Разберём учебный пример: команда закрыла 12 задач за две недели, работая в том числе за пределами обычного графика. Все числа ниже придуманы, это не отчёт о моей команде и не данные из чужой статьи. В команде четыре человека, период длится 10 рабочих дней. Для расчёта один человеко-день означает день работы одного человека в пределах его обычного графика. Это мера затраченного времени, а не готового результата.

Что стояло за 12 задачами

В первом периоде у команды было 40 рабочих человеко-дней по календарю. Два ушли на отсутствие одного из участников. Из оставшихся дней восемь заняла поддержка уже работающего продукта, ещё шесть пришлись на регулярные обсуждения и организационную работу. Эти категории не пересекаются.

На изменения продукта осталось 24 человеко-дня: 40 − 2 − 8 − 6. Но команда потратила на них 30. Недостающие шесть набрались из работы за пределами обычного графика.

В следующем периоде на отсутствия приходится уже восемь человеко-дней. Поддержка никуда не исчезла; для начала оставим на неё столько же времени. Сведём условия двух периодов в одну таблицу. Слева находится разобранный факт, справа пока только предположения о следующем плане.

Следующий план может опираться на 18 человеко-дней работы над изменениями. Это ещё ничего не говорит о числе задач, которые будут завершены. Но уже видно, почему прежние 30 нельзя молча перенести в новый период. Для них потребовались дополнительные дни, а теперь обычного времени стало ещё меньше.

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

Закрытая задача не равна отработанному дню

Допустим, из 30 дней первого периода 24 пришлись на 12 завершённых задач. Ещё шесть команда потратила на импорт данных, который так и не закончен. В списке готового этот импорт не виден, хотя люди им занимались и уже получили часть результата.

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

Нельзя и вычесть из 12 несколько задач, якобы сделанных сверхурочно, если мы не знаем, как именно они выполнялись. Часть одной задачи могла быть сделана днём, а оставшаяся часть вечером. Несколько закрытий могли зависеть от одной общей доработки. Если данные позволяют отделить работу в обычное время, это полезно для сравнения периодов. Если не позволяют, я бы сохранил это ограничение, а не подбирал удобное число.

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

Незавершённое уже заняло место

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

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

Мне здесь полезнее описание остатка, чем надпись «готово на 60%». Из процента непонятно, что именно не сделано. За оставшимися 40% может находиться знакомая работа или вопрос, на который пока вообще нет ответа. Для нашего расчёта четыре дня означают оценку названных действий, а не результат вычитания из прежней оценки.

Если часть уже написанного придётся переделать, это тоже новая работа. Она не исчезает из следующего периода из-за того, что первый вариант был оплачен раньше.

Какой результат теперь можно обещать

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

Все пять работ требуют 20 человеко-дней. Доступно 18, причём оценки ещё могут измениться. Даже без запаса вся подборка не помещается.

В нашем случае пользователи прежде всего ждут надёжный импорт и выгрузку. Команда предлагает закончить первые четыре работы, а массовое изменение оставить на следующий разговор о приоритетах. Получаются 14 человеко-дней и четыре дня запаса.

Это не универсальный размер запаса. В примере у импорта есть известный риск: подготовленные данные могут не покрывать все варианты повторной загрузки. Часть свободного времени оставили именно на выяснение этого вопроса. Если бы команда совсем не понимала, как устроен импорт, четыре дня не сделали бы обещание обоснованным. Сначала понадобилась бы отдельная проверка предположений.

С заказчиком теперь можно обсуждать конкретное изменение плана:

«В этот период заканчиваем импорт и выгрузку за выбранные даты. Исправляем часовой пояс и добавляем фильтр. Массовое изменение сейчас не обещаем: с ним весь набор требует 20 дней работы, а у нас 18 до учёта возможных осложнений. Если оно важнее, давай решим, что из выбранного переносим».

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

Время на поддержку уже занято

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

Если назвать поддержку «запасом», получается удобная ошибка. Например, можно пообещать изменения на все 18 доступных для них дней, считая восемь дней поддержки запасом на любые неожиданности. Затем придут обычные обращения и займут эти восемь дней. На сложности в новой разработке времени уже не оставлено: придётся либо сдвигать обещанное, либо работать вечером.

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

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

Теперь даже выбранный набор не помещается. К фильтру ещё не приступали, поэтому команда предлагает перенести все три дня его разработки и сохраняет остальные результаты. Арифметика снова сходится: 32 − 12 − 6 = 14 дней на изменения. Импорт требует семи; две оставшиеся работы укладываются ещё в семь: 2 + 5.

Запаса после этого не осталось. Это стоит сказать вместе с новым планом. Следующее заметное изменение потребует нового решения, а не молчаливого обещания «постараемся». Если фильтр нужен именно сейчас, разговор будет о том, какой другой результат переносится. Его важность не добавляет три дня к календарю.

Сумма дней ещё не расписание

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

Часть задач зависит друг от друга. Для выгрузки сначала нужно закончить изменение данных. Если разработчик, который знает этот участок и может провести ревью, будет отсутствовать в конце периода, работу нужно подготовить к проверке раньше. Свободное время другого разработчика не всегда заменяет его участие. В нашем учебном плане предполагается, что нужные участники доступны в подходящие дни; в настоящем плане это отдельная проверка.

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

Для такого плана достаточно знать, на что уходит время команды. Когда уже известно, что восемь дней уйдут на поддержку, поминутная отчётность сама по себе не превратит их в восемь дней новой разработки. А если поддержка регулярно оказывается вдвое больше ожиданий, нужно разобраться с её составом, прежде чем ещё раз вычитать привычное число.

Что останется в истории этого периода

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

Я бы сохранил рядом с результатом условия, при которых он получился. В нашем примере поддержку пересмотрели с восьми до 12 дней, а импорт потребовал ещё трёх. Фильтр перенесли по договорённости. Если при этом снова пришлось работать вечером, эти часы тоже остаются видимыми. Они не должны раствориться в удачном итоговом числе.

Следующий прогноз всё равно останется приблизительным, но теперь мы сможем объяснить, почему план изменился. Поддержка заняла больше времени, импорт оказался сложнее, фильтр пришлось отложить. Эти сведения пригодятся при выборе новой работы. А прошлые вечера и выходные больше не будут скрытым условием каждого следующего обещания.