Презентация передачи проекта должна показывать, готова ли принимающая команда отвечать за результат, а не только завершила ли проектная команда его создание. Объясните, что принято, что принимающая сторона смогла выполнить на практике, какие вопросы остаются открытыми и кто будет помогать после передачи.
Разделяйте три решения: принять результат работы, разрешить его эксплуатацию и официально закрыть проект. Они могут приниматься в разное время. Когда доказательства готовности и предлагаемое распределение обязанностей ясны, превратите материалы передачи в редактируемый черновик презентации. Слайды помогают рассмотреть решения, но не принимают их за участников.
Точно определите, что передаётся
Фраза «Проект завершён» слишком расплывчата для следующей команды. Назовите передаваемый сервис, процесс или актив, его версию, ответственного со стороны принимающей команды и предполагаемый момент передачи. Отдельно обозначьте исключения: например, будущую функцию отчётности или прежний процесс, который не входит в текущий объём.
В исследовании APM о передаче проектов на английском языке передача рассматривается как переход, а не одна дата. Авторы подчёркивают ясность ответственности, передачу полезных знаний и участие будущих пользователей. На этом стоит строить и презентацию: показывать условия принятия ответственности, а не торжественную финишную черту.
Предположим, проект создал новый процесс заявок на оборудование для внутренней операционной команды. В объём входят форма заявки, правила маршрутизации, рабочая инструкция и порядок обработки исключений. Ответственным со стороны принимающей команды должен стать руководитель операционной команды. Это вымышленный пример для разбора презентации, а не внедрение Presenti и не описание функций автоматизации продукта.
Первый слайд может содержать такой вывод: «Передать процесс заявок после приёмки порядка обработки исключений, успешной проверки заместителя и согласования ответственности за поддержку». Он объясняет и предложение, и оставшиеся препятствия. Незакрытое условие не прячется за зелёной отметкой «готово».
Отделите принятые результаты от готовности к работе
До оформления слайдов подготовьте короткий реестр результатов. Для каждого важного элемента укажите версию, критерий приёмки и подтверждение. «Отправлено в операционную команду» — факт доставки, но не доказательство проверки или приёмки.
| Результат | Подтверждение в учебном проекте | Что осталось |
|---|---|---|
| Форма заявки v1.3 | Руководитель принимающей команды согласовал обязательные поля и отправил обычную тестовую заявку. | Открытых проблем с формой не зафиксировано. |
| Правила маршрутизации v1.2 | Во время теста обычные заявки поступили в нужную очередь. | Сценарий отсутствия основного ответственного не прошёл сквозную проверку. |
| Рабочая инструкция v1.0 | Основной ответственный выполнил стандартный порядок без пошаговых подсказок руководителя проекта. | Во время проверки заместитель не смог открыть инструкцию по исключениям. |
| Порядок обработки исключений v0.9 | В черновике указана предполагаемая роль для эскалации. | Принимающая команда не приняла порядок и не продемонстрировала его выполнение. |
Саму запись о приёмке храните в согласованной системе проекта: кто одобрил, когда и какую версию. На слайде дайте ссылку или указатель на запись. Краткая презентация не заменяет документы одобрения, предусмотренные договором или правилами организации.
Не превращайте таблицу в «готовность 75 %» только потому, что три строки выглядят почти завершёнными. Это не равнозначные единицы готовности, а один неработающий путь исключения может быть важнее нескольких готовых документов. Назовите оставшееся условие прямо.
Покажите, что принимающая команда умеет делать без вас
Самый полезный слайд передачи нередко появляется после практического прогона принимающей командой. Выберите действия, похожие на обычную работу, и правдоподобное исключение. Цель — обнаружить недостающие знания, доступы или ответственных, пока проектная команда ещё рядом.
В нашем примере попросите команду обработать обычную заявку, найти действующий порядок, провести заявку в отсутствие основного ответственного и показать, где регистрируется нерешённое исключение. Используйте разрешённые тестовые данные и согласованную среду.
В учебном прогоне обычная заявка обработана успешно. При отсутствии основного ответственного заявка приходит в очередь заместителя, но тот не может открыть инструкцию по исключениям. Это точнее и полезнее, чем «обучение не завершено»: обнаружен конкретный пробел в доступе и процедуре, который можно назначить ответственному и повторно проверить.
Исправление не сводится к отправке ещё одного документа. Ответственный должен оформить согласованный доступ, подтвердить актуальную версию инструкции и повторить тот же сценарий отсутствия. Зафиксируйте результат. Участие в обучении не доказывает, что именно эту задачу человек способен выполнить.
Если прогон нельзя закончить до плановой передачи, объясните причину и назовите, кто вправе принять возникающий риск. Не отмечайте невыполненную проверку как успешную. Когда оставшееся условие мешает безопасному или работоспособному использованию, предложите отложить соответствующую часть передачи, а не смягчить формулировку критерия приёмки.
Укажите ответственных и ограничения по каждому открытому вопросу
При передаче могут оставаться незавершённые работы, но для каждого такого пункта нужна явная договорённость. Покажите, кто устраняет проблему, кто тем временем отвечает за текущую эксплуатацию, какие действуют ограничения и кто уполномочен их принять. Это могут быть разные роли.
| Открытый вопрос | Предлагаемая договорённость | Условие закрытия |
|---|---|---|
| Заместитель не может открыть инструкцию по исключениям | Ответственный за доступы в проекте исправляет разрешение; руководитель принимающей команды организует повторную проверку. | Заместитель выполняет сценарий отсутствия по действующей инструкции. |
| Порядок обработки исключений не принят | Операционный руководитель рассматривает его с руководителем проекта; присутствие на встрече не считается одобрением. | В записи о приёмке указаны версия и ограничения, если они есть. |
| Ответственность за поддержку после передачи не согласована | Спонсор проекта и руководитель принимающей команды подтверждают контакты, период поддержки и путь эскалации. | Обе команды знают, какая роль обрабатывает каждый тип обращения. |
В этом примере предлагаемая передача по-прежнему зависит от первых двух пунктов. До изменения ответственности необходимо также согласовать поддержку. Таблица описывает предложения, а не уже взятые реальными людьми обязательства.
В другом проекте малозначительный визуальный дефект могут принять как последующую доработку. Из этого не следует, что любой дефект допустимо передать следующей команде. Используйте реальные критерии приёмки и полномочия; будущие операторы должны видеть каждое ограничение.
Объясните, как пройдёт первая неделя эксплуатации
Один слайд о поддержке должен отвечать на вопрос, что произойдёт, если после передачи понадобится помощь. Укажите основной операционный контакт, заместителя, контакт проектной команды на согласованный временный период и порядок обращения по срочному вопросу. Обозначьте окончание или пересмотр временной договорённости.
Не обещайте две недели поддержки только потому, что это удобно поместить на слайд. Если длительность или доступность ещё не согласованы, оставьте их как решения, которые предстоит принять. Запрос помощи и разрешение изменить принятый объём — разные вещи.
В примере руководитель принимающей команды предлагает в первую неделю рассмотреть незакрытые исключения. Такая встреча помогла бы проверить работу замещения на практике и необходимость исправлений в инструкции. Она не открывает заново завершённый объём проекта и не гарантирует, что проектная команда возьмёт все новые запросы.
Сделайте доступными текущую инструкцию, подтверждения приёмки и реестр проблем. Если изменение относится к более широкому операционному плану, свяжите его с ответственными и периодичностью проверок из руководства по операционному плану на английском, а не создавайте на слайдах противоречащие им обязанности.
Проведите обсуждение по шести слайдам
Встреча должна привести к решению об ответственности, а не только подтвердить, что кто-то показал презентацию.
- Предложение о передаче: процесс, версия, ответственный со стороны принимающей команды, предполагаемый момент и условия.
- Принятый объём: основные результаты, подтверждения приёмки и явные исключения.
- Практика принимающей команды: выполненные обычные и нестандартные задачи, фактические результаты и пробелы.
- Открытые пункты: блокирующие вопросы, согласованные последующие работы, ответственные и условия закрытия.
- Операционная поддержка: контакты, замещение, временная помощь проекта и границы эскалации.
- Запись решения: передать, передать в согласованных пределах или отложить; зафиксировать решение уполномоченного лица и следующую проверку.
Для незакрытых условий используйте узкую таблицу, для смены ответственности за поддержку — простую временную шкалу. Не уменьшайте весь план проекта до размеров одного слайда. Подробные процедуры должны оставаться в материалах по ссылкам, а презентация — нести подтверждения и выбор, который принимающей команде нужен сейчас.
Подготовьте черновик по фактам и запишите реальное решение
Используйте следующий запрос, заменив пример утверждённой информацией. Сохраните различие между выполненной задачей, принятым результатом и предлагаемым действием.
Создай шесть слайдов о передаче вымышленного процесса заявок на оборудование из примера выше. Аудитория — спонсор проекта и принимающая операционная команда. Покажи предложение о передаче, принятый объём, реальные результаты прогона, незакрытые условия, поддержку и требуемое решение. Обычная заявка прошла; заместитель не смог открыть инструкцию по исключениям, успешной повторной проверки пока нет; порядок обработки исключений не принят. Не отмечай проект как закрытый, не придумывай одобрения и не выдавай предлагаемую поддержку за согласованную. Явно оставь для заполнения неизвестных ответственных и даты.
Внимательно прочитайте сгенерированный вывод. «Готово к передаче» исказит исходные данные; «Готово после выполнения указанных условий» сохранит смысл предложения. Перед рассылкой сверьте последний слайд с реальным итогом встречи.
После решения уполномоченного лица обновите и исходную запись, и презентацию: ответственный со стороны принимающей команды, дата начала действия, принятые ограничения и оставшиеся действия. Затем можно рассматривать закрытие проекта по принятому в организации порядку. Полезная передача — та, по которой принимающая команда может работать, а не та, у которой самый уверенный заключительный слайд.
