План-факт проекта: как пересобрать рабочий план при изменениях

Все заняты, задачи закрываются, а запуск не состоялся

К пятнице готовы тексты, дизайн и новая страница регистрации. Заодно команда устранила сбой отправки писем в другом проекте. Работы сделано много. Но приглашения на вебинар не отправлены: новую регистрацию ещё не проверили и не приняли.

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

Ниже — учебный пример на основе главы 7 книги «Как приготовить проект». В понедельник команда согласовала такую последовательность:

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

Как день срочной работы отодвинул запуск до вторника

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

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

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

Пятницу тоже нельзя целиком считать свободной: её оставляли для исправлений после проверки. Если занять её сборкой, время на исправления придётся найти заново. Иначе новый план сойдётся только при условии, что замечаний не будет. Никто этого не обещал.

Назвать аварию приоритетом — ещё не найти для неё время

Решение «аварию чиним срочно, вебинар тоже запускаем вовремя» пока не содержит способа выполнить оба обещания. Нужно выяснить, чем команда оплатит новую работу:

• Освободить четверг. Тогда переносится работа другого проекта. Его заказчик должен подтвердить новый срок. В примере он отказался: значит, четверг нельзя продолжать учитывать как доступный.
• Уменьшить сборку или добавить исполнителя. Здесь страница уже делается на минимальном готовом шаблоне, а подходящего свободного специалиста нет. Назвать эти варианты недостаточно — нужен подтверждённый выигрыш во времени.
• Перенести приглашения. После понедельничной приёмки ближайшее доступное время Марины для рассылки — вторник утром. Заказчик проверил, что это оставляет достаточно времени для набора участников, и согласовал перенос. Дата самого вебинара сохраняется.

Если свободного времени нет, нужно либо передвинуть прежнее обещание, либо подтвердить, за счёт чего оно всё-таки будет выполнено. В примере цена исправления аварии — более поздняя рассылка. Её принимает заказчик, а не разработчик в одиночку обещает «как-нибудь догнать».

Если рассылку переносить нельзя, существующий состав и объём работ не обеспечивают оба обещания.

Перенести задачу — значит заново договориться с теми, кто её ждёт

Поменять дату Илье недостаточно. Саша может быть занят в понедельник, Денис — недоступен для приёмки, Марина — назначить другую рассылку. Поэтому сначала участники подтверждают новые окна, затем они попадают в таблицу.

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

Звёздочки показывают перенос относительно первого обещания. В книге каждый перенос получает отметку: так видны задачи, которые кочуют из плана в план. Повторяющаяся отметка — повод выяснить причину, а не ещё раз заменить дату.

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

Ссылка на обновлённую таблицу не отменяет старое обещание

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

В главе 7 после встреч предусмотрено итоговое письмо всем заинтересованным участникам. Здесь достаточно назвать отменённое обещание, новые передачи работы и условие, при котором план потребуется пересмотреть:

Зафиксировать решения поможет конструктор протокола встречи. Перед отправкой важно проверить адресатов: чья работа изменилась из-за этого решения?

Если переписать прошлое, план всегда будет сходиться

К пятнице Илья собрал страницу. По новой договорённости он успел. По исходной — опоздал на два рабочих дня. Оба утверждения верны, но отвечают на разные вопросы.

• Исходный план: насколько надёжным оказалось обещание, данное в начале недели?
• Обновлённый план: выполняет ли команда договорённости после изменения условий?
• Факт: что действительно готово и кому уже можно передать результат?

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

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

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

Что изменить в следующем плане

У записи «перенос из-за срочной работы» должен быть следующий вопрос: что именно можно изменить, чтобы эта причина не повторялась?

• Сбой можно было обнаружить раньше? Назначить проверку отправки подтверждений или мониторинг, ответственного и срок. Просто «стать внимательнее» нельзя проверить.
• Внеплановая поддержка отнимает время каждую неделю? В следующем плане выделить ей время на основе фактической нагрузки. Если заранее распределить всё время на новые проекты, привычная поддержка снова вытеснит обещанное.
• Больше всего времени теряется в ожидании следующего этапа? Согласовывать окна проверки и приёмки вместе со сборкой. Сокращение самой сборки не всегда вернёт уже потерянное окно тестировщика.

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

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