// prompt 61 операционка

промпт: премортем проекта за 20 минут

премортем перед стартом проекта: представляем, что он провалился, и разбираем почему — топ-5 рисков с ранними сигналами и планом на каждый.

промпт

ты проводишь премортемы — упражнение, где проект разбирают как уже провалившийся до того, как он стартовал. механика важна: не «какие есть риски?» (на этот вопрос все отвечают вежливой ерундой), а «проект провалился, прошло полгода, мы разбираем обломки — что произошло?». прошедшее время развязывает язык.

проект:
[что делаем, зачем, срок, бюджет/ресурсы, кто участвует — включая подрядчиков и согласующих. на чём держится успех по-вашему]

контекст, который знаю только я:
[история: были ли похожие проекты и чем кончились, кто из участников перегружен или скептичен, какие внешние зависимости (поставщик, сезон, одобрение сверху). неловкие детали — самое ценное]

проведи премортем:

1. напиши некролог проекта: 5–7 сценариев провала, каждый — короткая история в прошедшем времени, конкретная и правдоподобная именно для моего проекта. смешай типы: люди (кто-то забил, выгорел, уволился), процесс (сроки поплыли на согласованиях), внешнее (подрядчик, рынок), и обязательно один сценарий «проект сделан, но оказался никому не нужен» — это самый частый провал, о котором не думают.
2. по каждому сценарию оцени: вероятность (низкая/средняя/высокая — с одной строкой почему) и цена (чем обернётся). отбери топ-5 по сочетанию.
3. для топ-5 — таблица: риск / ранний сигнал (что я замечу за недели до провала, наблюдаемое: «подрядчик отвечает через два дня вместо двух часов», а не «коммуникация ухудшилась») / действие сейчас, до старта / действие, если сигнал сработал.
4. отдельно: какие из рисков лечатся одним честным разговором до старта (с участником, заказчиком, подрядчиком) — и с кем именно. это самые дешёвые страховки, начни с них.
5. чего в списке нет: назови 1–2 категории рисков, которые ты не можешь оценить снаружи (юридические тонкости, личные отношения), — чтобы я не думал, что список исчерпывающий.

правила:
- не пиши generic-риски («нехватка ресурсов может привести к задержкам») — каждый сценарий должен опираться на детали моего описания. мало деталей — сначала спроси.
- не предлагай «усилить контроль» как универсальную заплатку. заплатка должна быть действием с исполнителем.

как использовать

  1. блок «контекст, который знаю только я» — решающий. премортем на официальной версии проекта даёт официальные риски. пишите то, что не сказали бы на общей встрече.
  2. если проект командный — сначала прогоните промпт сами, потом покажите некрологи команде и спросите «чего не хватает?». чужие сценарии провала критиковать легче, чем генерировать свои с нуля, — участники быстро добавят настоящее.
  3. ранние сигналы из п.3 занесите в календарь как контрольные точки: сигнал, который никто не отслеживает, не существует.
  4. повторите премортем в середине проекта на 10 минут: какие сценарии уже отпали, какие приблизились.

что получится

за 20 минут — то, что обычно всплывает на разборе полётов через полгода, когда уже поздно: пять правдоподобных сценариев смерти проекта, по каждому — за что дёргать сейчас и на что смотреть по ходу. премортем не делает проект безопасным и не предскажет чёрного лебедя — он убирает провалы категории «все всё видели, но никто не сказал вслух», а их в малом бизнесе большинство.

// следующий уровень

промпт решает задачу раз. агент — каждый раз, когда она повторяется

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