Все про развитие международной карьеры от резюме до устройства от опытного проджект менеджера (СберТех, Сбер, ВТБ, EPAM, G42)
Запись на консультацию: https://www.idagent.pro/
По вопросам сотрудничества: @AndreyChernyshovPM
Post #894
847

5 промтов, которые экономят мне несколько часов в неделю. И к каждому заметка, где модель врёт. Она важнее самого промта.
Вы в курсе, что обычный промт «подготовь мне RAG-статус проекта» не работает. Модель начинает гадать, и через минуту у вас зелёный статус, потому что «тестирование идёт по плану».
Рабочий промт выглядит иначе. В нём лежат пороги:
«Сроки Amber при сдвиге вехи на 6-15 дней или когда под риском платёжная веха. Red при сдвиге 16 дней и больше без поданного запроса на изменение. Бюджет Green при CPI 0,95 и выше, Amber 0,85-0,94, Red ниже. В каждой строке обоснование со ссылкой на факт: номер вехи, риска или дефекта. Без ссылки строка не засчитывается.»
Модель перестаёт оценивать и начинает считать.
Таких промтов у меня 5, под задачи, которые каждую неделю съедают у проджекта день. Собрал их в один документ и выложил целиком.
Бесплатно - скачивайте и пользуйтесь.
Что внутри документа и что это закрывает?
🔹 Протокол из заметок встречи. 4 таблицы: решения, действия с владельцами и датами, что закрыто, какие риски вылезли. Сырые заметки превращаются в готовый протокол за пару минут.
🔹 RAG-статус из фактов. Тот самый, с порогами. Статус перестаёт быть вашим ощущением в пятницу вечером.
🔹 Оценка запроса на изменение. Влияние на объём, сроки, стоимость и риски с расчётом. Три варианта решения плюс готовая формулировка для стирингкомитета.
🔹 Письмо заказчику о плохой новости. 5 абзацев с жёстким порядком, где сдвиг стоит в первом абзаце.
🔹 Ревизия RAID с матрицей эскалации. Что просрочено и на какой уровень это эскалировать, у каких рисков нет владельца, что пора закрыть.
И что самое важное. К каждому промту идут 2 строки: по чему узнать хороший ответ и где модель врёт. Вторая полезнее самого промта.
• В протоколе встречи она записывает в решения то, что обсуждали, но не решили.
• В оценке изменения сама переводит человеко-дни в календарные, не зная ёмкости команды, и выдаёт «примерно две недели» вместо умножения.
• В письме спонсору добавляет «по независящим от нас причинам».
• В ревизии RAID придумывает причины просрочек, которых в реестре нет.
Общий принцип, к которому я пришёл.
В промт надо класть критерий проверки: пороги, матрицу эскалации, формат, запрет додумывать. Плюс строку «чего нет во входных данных, того нет в ответе», иначе модель дополнит контекст сама, и заметите вы это уже после отправки.
Забирайте все 5 по ссылке - https://docs.google.com/document/d/1JoXF3Ty2FjCRDv6gHg2FlathYQXdJbXI7clgqmHBczU/edit?usp=sharing
Enjoy! 😉
Вы в курсе, что обычный промт «подготовь мне RAG-статус проекта» не работает. Модель начинает гадать, и через минуту у вас зелёный статус, потому что «тестирование идёт по плану».
Рабочий промт выглядит иначе. В нём лежат пороги:
«Сроки Amber при сдвиге вехи на 6-15 дней или когда под риском платёжная веха. Red при сдвиге 16 дней и больше без поданного запроса на изменение. Бюджет Green при CPI 0,95 и выше, Amber 0,85-0,94, Red ниже. В каждой строке обоснование со ссылкой на факт: номер вехи, риска или дефекта. Без ссылки строка не засчитывается.»
Модель перестаёт оценивать и начинает считать.
Таких промтов у меня 5, под задачи, которые каждую неделю съедают у проджекта день. Собрал их в один документ и выложил целиком.
Бесплатно - скачивайте и пользуйтесь.
Что внутри документа и что это закрывает?
🔹 Протокол из заметок встречи. 4 таблицы: решения, действия с владельцами и датами, что закрыто, какие риски вылезли. Сырые заметки превращаются в готовый протокол за пару минут.
🔹 RAG-статус из фактов. Тот самый, с порогами. Статус перестаёт быть вашим ощущением в пятницу вечером.
🔹 Оценка запроса на изменение. Влияние на объём, сроки, стоимость и риски с расчётом. Три варианта решения плюс готовая формулировка для стирингкомитета.
🔹 Письмо заказчику о плохой новости. 5 абзацев с жёстким порядком, где сдвиг стоит в первом абзаце.
🔹 Ревизия RAID с матрицей эскалации. Что просрочено и на какой уровень это эскалировать, у каких рисков нет владельца, что пора закрыть.
И что самое важное. К каждому промту идут 2 строки: по чему узнать хороший ответ и где модель врёт. Вторая полезнее самого промта.
• В протоколе встречи она записывает в решения то, что обсуждали, но не решили.
• В оценке изменения сама переводит человеко-дни в календарные, не зная ёмкости команды, и выдаёт «примерно две недели» вместо умножения.
• В письме спонсору добавляет «по независящим от нас причинам».
• В ревизии RAID придумывает причины просрочек, которых в реестре нет.
Общий принцип, к которому я пришёл.
В промт надо класть критерий проверки: пороги, матрицу эскалации, формат, запрет додумывать. Плюс строку «чего нет во входных данных, того нет в ответе», иначе модель дополнит контекст сама, и заметите вы это уже после отправки.
Забирайте все 5 по ссылке - https://docs.google.com/document/d/1JoXF3Ty2FjCRDv6gHg2FlathYQXdJbXI7clgqmHBczU/edit?usp=sharing
Enjoy! 😉
- 👍 17
- ❤ 10
- 🤩 5
- ❤🔥 2
- 🔥 1
- 🤗 1













