Письмо стейкхолдерам
Ты — продуктовый менеджер, который отчитывается перед стейкхолдерами. Помоги собрать письмо о статусе проекта.
Входные данные: — проект: [вставьте описание проекта и зачем он бизнесу]; — статус: [вставьте текущий статус: что готово, что в работе, сроки]; — новости: [вставьте новости периода, включая плохие]; — риски: [вставьте риски и что с ними делают]; — запрос: [вставьте, что нужно от стейкхолдеров: решение, ресурс, информация].
Собери письмо по структуре:
- Главное сверху — 2–3 предложения: на каком этапе проект и что изменилось за период, включая плохие новости, если они есть.
- Прогресс — что сделано с прошлого статуса, короткими пунктами.
- Риски и проблемы — что может пойти не так, к какой дате это станет проблемой и какой вариант реакции предлагаешь.
- Что нужно от получателя — конкретный вопрос и срок, до которого нужно решение.
Письмо должно работать так, чтобы человек с двумя минутами понял состояние проекта уже по первому блоку, а читающий дольше нашёл детали в остальных.
Ограничения: — не сглаживай плохие новости и не прячь их в конец: просрочки, сдвиги сроков и проблемы формулируй прямо, с фактами из входных данных; — не выдумывай причины задержек, даты и обещания — используй только входные данные; — не назначай виноватых и не оценивай людей; — если данных не хватает, отметь это и напиши, что уточнить до отправки письма.
Пример данных
Данные вымышлены. Замени их информацией о своей задаче.
Проект: личный кабинет и заморозка абонемента в мобильном приложении сети фитнес-клубов «Форма». Сейчас заморозку оформляет только администратор клуба на стойке. Статус: дизайн-макеты согласованы; экран заморозки готов в разработке на 70%; бэкенд личного кабинета задерживается — интеграция с биллингом заняла на две недели больше плана и ещё не завершена. Плановый запуск — 15 октября, по срокам под угрозой. Новости периода: разработчики просили трёхдневную паузу на стабилизацию релиза приложения; контракт с подрядчиком по биллингу продлён до конца квартала. Риски: если интеграция с биллингом не завершится до 1 октября, запуск сдвинется минимум на месяц — следующий цикл релизов приложения в ноябре. Запрос: нужно решение — добавить ресурс разработчика на интеграцию или переносить запуск.
Пример ответа
Один из возможных результатов. Проверь факты и адаптируй текст перед использованием.
Письмо о статусе проекта «Личный кабинет и заморозка абонемента»
Главное. Запуск 15 октября под угрозой: интеграция с биллингом идёт на две недели дольше плана и ещё не завершена. Если она не будет готова до 1 октября, запуск сдвинется минимум на месяц — до ноябрьского цикла релизов. Нужно ваше решение: добавить разработчика на интеграцию или переносить запуск.
Прогресс с прошлого статуса:
- согласованы дизайн-макеты;
- экран заморозки готов в разработке на 70%;
- контракт с подрядчиком по биллингу продлён до конца квартала.
Риски и проблемы. Критический риск один — интеграция мобильного приложения с биллингом. Она заняла на две недели больше плана и пока не завершена. Дата, к которой риск становится проблемой, — 1 октября: после неё, по текущей оценке, сдвиг запуска минимум на месяц становится неизбежным, потому что следующий цикл релизов приложения — в ноябре. Варианты реакции: добавить ресурс разработчика на интеграцию или зафиксировать перенос запуска; рекомендую обсудить оба до крайнего срока, а не после него. Дополнительно по периоду: разработчики запросили трёхдневную паузу на стабилизацию релиза приложения; из входных данных не следует, согласована ли пауза и как она повлияет на сроки, — этот вопрос остаётся открытым.
Что нужно от вас. Выберите вариант: добавляем разработчика на интеграцию с биллингом или переносим запуск. Решение нужно до 1 октября — к дате, после которой вариант «успеть в текущий цикл» исчезает. Если удобнее обсудить голосом, скажите, когда удобно, — подготовлю детали по интеграции к разговору.
Проверьте факты
- Все даты (15 октября, 1 октября, ноябрьский цикл, конец квартала) взяты из входных данных, новых сроков в письме нет.
- Срок ответа «до 1 октября» выведен из описания риска, а не задан прямо — подтвердить у руководителя проекта до отправки.
- Причина задержки интеграции в письме не названа: во входных данных сказано только «заняла на две недели больше плана».
- «70% готовности экрана» — оценка из входных данных, а не измерение; при вопросах от стейкхолдеров уточнить у разработки.
- Пауза на стабилизацию упомянута как факт без выводов о влиянии на сроки: во входных данных такого вывода нет.
Из главы: Работа с командой и стейкхолдерами