На совещании руководители направлений снова обещают закончить «совсем скоро». Дата запуска прежняя, а показать цельный результат пока нельзя: данные не готовы, проверки впереди, согласующий занят. Чтобы понять, что делать, если проект не успевает в срок, проверьте оставшиеся работы и зависимости. Затем решите с заказчиком, какой результат нужен к назначенной дате и чем ради него можно поступиться.
Признаки, что прежняя дата уже под угрозой
Для проверки прогноза сравните обещания команды с результатами, которые заказчик уже может принять. Насторожиться стоит, если демонстрации переносят, выполненное возвращается на исправление, а новые требования попадают в работу без пересмотра плана. Проверьте прогноз, даже если просроченных этапов ещё нет.
Вместо «почти готово» попросите показать результат и назвать незаконченные проверки. Если ответ звучит как «осталось только согласовать», выясните, что именно согласуется, кто принимает решение и когда он доступен. Ожидание решения тоже занимает календарное время.
Как пересмотреть план проекта: найти то, что держит запуск
Соберите исполнителей и представителей заказчика, от которых зависит приёмка. Для каждой незавершённой работы запишите ожидаемый результат, оставшуюся трудоёмкость и длительность, доступность исполнителя, предшествующие задачи и условие готовности. В длительности учтите занятость людей и ожидание согласований. Включите сюда исправления, проверку совместной работы частей, подготовку пользователей и передачу результата в эксплуатацию, если они нужны для запуска.
Критический путь — цепочка зависимых работ, которая определяет ближайшую возможную дату завершения. У таких работ нет запаса времени, позволяющего задержаться без переноса финиша. Сокращать срок нужно через эту цепочку; ускорение задачи с достаточным запасом может ничего не изменить. После перестройки графика критическим способен стать другой путь.
Представим перенос данных в новую систему: после подготовки данных идут перенос, сверка и запуск. Параллельно готовят инструкции. Если дату определяет перенос со сверкой, досрочная готовность инструкций сама по себе запуск не приблизит. На схеме выделен именно такой условный случай; длина стрелок не обозначает длительность работ.
Отдельно проверьте загрузку людей: независимые по результату задачи не получится делать одновременно, если за них отвечает один занятый специалист. Попросите команду назвать условия каждой оценки. «Успеем при своевременном доступе к данным» нужно превратить в конкретное обязательство того, кто этот доступ предоставляет.
Что менять: объём, ресурсы или срок
Сравните варианты на одном перечне оставшихся работ: прогноз завершения, необходимые решения и последствия для бизнеса.
- Сократить первую очередь. Подходит, если к жёсткой дате можно получить полезный результат без части функций. Отложенные возможности нужно назвать явно и проверить, не зависят ли от них обязательные операции.
- Добавить ресурсы. Имеет смысл, когда конкретная работа на критическом пути делится между исполнителями или требует недостающего специалиста. Если все ждут согласования заказчика, дополнительные разработчики это ожидание не устранят.
- Перенести завершение. Рассмотрите этот вариант, если минимально пригодный результат не помещается в оставшееся время. Новую дату рассчитывают с учётом доступности команды и внешних зависимостей.
Например, компания планировала перевести весь учёт в новую систему к началу года, но полный запуск под угрозой. Тогда обсуждают поэтапный переход и временный порядок работы. Пошаговый план Б для перехода с 1С:УПП, включая поддержку прежней программы и очерёдность переноса участков учёта, разобран на dp-consulting.ru. Проверьте допустимость переходного варианта для своего проекта.
Ускорение тоже требует проверки. В материале PMI «Pressed for time» разобраны добавление ресурсов и частичное совмещение последовательных работ. Параллельный старт до готовности исходных решений создаёт риск переделок. Для своего варианта отдельно оцените время на подготовку новичков. Прежде чем менять команду или связи в графике, укажите, какую задержку это снимет и какую новую работу добавит.
Приоритизация задач проекта: что обязательно, а что потом
Для обсуждения объёма подойдёт MoSCoW — метод, описанный Agile Business Consortium. Разделяйте требования применительно к ближайшему запуску: если функция понадобится в будущем, это ещё не означает, что без неё нельзя начать работу сейчас.
- Must Have — обязательно. Без требования запуск лишён смысла, небезопасен, недопустим или результат непригоден к использованию.
- Should Have — важно. Отсутствие ощутимо, но есть приемлемый временный обходной способ.
- Could Have — желательно. Последствия отказа сравнительно невелики; это первые кандидаты на исключение при нехватке времени.
- Won’t Have this time — не в этот запуск. Требование явно исключено из текущей очереди, чтобы его не вернули в работу незаметно.
Ключевая проверка обязательности: состоится ли запуск без этого требования? Если да, обсудите другую категорию. Также проверьте зависимости: обязательное требование не может опираться на функцию, которую разрешено не выпускать. Если обязательным объявлено всё, попробуйте разделить крупные требования на части с разными приоритетами.
Разберём условную задачу: «автоматизировать управленческий отчёт». Получение нужных руководству данных может быть обязательным, автоматическая рассылка — желательной, оформление по новому шаблону — отложенным. Такое разделение допустимо, если согласованный ручной способ действительно обеспечивает нужный результат. Назначьте исполнителя временной операции, проверьте его загрузку и условие прекращения ручной работы.
Экономию времени считайте с учётом обходного способа: его тоже придётся подготовить и проверить. Не сокращайте необходимые проверки качества лишь потому, что убрали функции. В Scrum Guide объём работы допускается уточнять и пересогласовывать, а снижать качество в ходе спринта нельзя. Для плана восстановления полезно принять такое же ограничение и заранее согласовать критерии готовности первой очереди.
Как договориться с руководством и заказчиком
Пригласите того, кто вправе менять объём, ресурсы или дату. Подготовьте записку: что уже принято, что осталось, какая зависимость держит срок, какие варианты доступны. Для каждого варианта покажите результат для бизнеса, ограничения и решения, которые должны принять участники.
Можно построить разговор так: «При текущем составе работ прогноз выходит за согласованную дату. Её определяют перенос и проверка данных. Предлагаем сохранить дату для обязательных операций, а автоматическую рассылку отчётов исключить из этой очереди. Для этого заказчику нужно согласовать ручную выдачу отчёта и выделить сотрудника на проверку. Если эти условия невыполнимы, пересчитываем дату полного запуска».
В решении зафиксируйте границы первой очереди, критерии приёмки, оставшиеся риски, ответственных и срок предоставления данных или согласований. Укажите, кто утверждает новые требования и как оценивается их влияние. Такой порядок соответствует подходу Microsoft к контролю изменений: до одобрения оценивать необходимость, обходные решения, влияние на финансирование и завершение проекта.
Договоритесь и о следующей проверке прогноза: какой результат к ней покажут и при каком отклонении вопрос снова вынесут на руководство. Сохраните прежний план для сравнения, а утверждённые изменения внесите в рабочий график.
Ошибки, из-за которых пересборка плана не помогает
Убирать то, что легче согласовать. Отказ от оформления отчёта выглядит заметной уступкой, но может не сократить критический путь. После сокращения объёма пересчитайте дату завершения.
Назначать новую дату без внешних участников. Готовность команды не заменяет доступности принимающего результат сотрудника или поставщика данных. Подтвердите эти обязательства до утверждения графика.
Записывать всё исключённое как «сразу после запуска». Это создаёт ещё одно обещание без оценки. Составьте список оставшихся требований; срок следующей очереди определяйте после проверки её состава и ресурсов.
Пересобранный план должен отвечать на понятные вопросы: что бизнес получит, когда это возможно и от каких условий зависит. Если обязательный результат всё ещё не помещается в срок, это нужно вынести на решение руководства. Одного обновлённого графика для исправления ситуации недостаточно.
Вопросы и ответы
Поможет ли срочный найм, если проект не успевает?
Проверьте конкретную задержку. Дополнительный специалист полезен, если может сократить работу, определяющую дату запуска. Учтите время на знакомство с проектом и участие действующей команды в его подготовке.
Что делать, если заказчик считает обязательными все задачи?
Разделите крупные требования на части и обсудите последствия отказа от каждой именно к ближайшему запуску. Если весь объём действительно необходим, возвращайтесь к обсуждению ресурсов и срока: приоритизация сама по себе время не создаёт.
Можно ли объявить первую очередь готовой без части проверок?
Только уменьшения списка функций для этого недостаточно. Первая очередь должна пройти согласованные проверки своего состава и соответствовать критериям приёмки. Непроверенную обязательную операцию нельзя считать готовой из-за близкой даты.
Источники
- Microsoft Support. Manage your project’s critical path.
- Agile Business Consortium. What is MoSCoW Prioritization?
- Project Management Institute. Pressed for time.
- Microsoft Support. Как оценивать запросы на изменение проекта.
- Кен Швабер, Джефф Сазерленд. Scrum Guide, редакция ноября 2020 года: разделы The Sprint и Definition of Done.
