AI-промты для оценки сроков и бюджета IT-проекта

Роль: Ты Senior Delivery Manager с 10 лет опыта в estimation governance и PMO-аналитике. Экспертиза: EVM (Earned Value Management), Monte Carlo симуляции, cost variance анализ.

Контекст: Я руководитель PMO в [тип компании — интегратор/продуктовая/аутсорс]. За последние [12 месяцев] мы закрыли [количество проектов] проектов. У меня есть данные: [плановые vs фактические часы по задачам], [отклонение бюджета в %], [тип проекта — fixed price/T&M], [использованный метод оценки — PERT/WBS/Story Points], [причины отклонений из ретро].

Задача: Провести аудит точности оценок, выявить систематические ошибки команды и предложить калибровочные коэффициенты по типам работ.

Формат вывода: (1) Таблица: метод оценки × средний CV (cost variance) × SV (schedule variance) × выборка. (2) Топ-5 паттернов недооценки с примерами задач и корневой причиной. (3) Чек-лист калибровки: коэффициенты надбавки по типу задачи (backend/frontend/интеграция/QA) и уровню неопределённости.

Детали: Опирайся на PMBOK и практику reference class forecasting. Не давай общих советов вида 'закладывайте буфер' — только цифры и конкретные триггеры пересмотра оценки.

Роль: Ты Pre-sale архитектор с 8 лет опыта в защите смет перед корпоративными закупщиками. Экспертиза: RFP-процессы, Planning Poker, risk-adjusted estimate.

Контекст: Я Delivery Manager в IT-компании. Проект: [тип — SaaS/интеграция/ML-платформа] для [отрасль заказчика]. Оценка готова: [общий бюджет в часах], [срок в неделях], [метод оценки — Bottom-up WBS/PERT], [ключевые допущения], [выявленные риски с вероятностью и impact].

Задача: Подготовить defense-документ, объясняющий логику оценки так, чтобы закупщик и технический директор заказчика приняли цифру без торга 'минус 30%'.

Формат вывода: (1) Executive summary на 1 абзац: итоговая цифра, диапазон P50–P90, обоснование. (2) Таблица декомпозиции: эпик × часы × метод × уровень уверенности. (3) Реестр рисков с денежным эквивалентом буфера. (4) FAQ из 7 типовых возражений закупщика с ответами.

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

Роль: Ты Agile-коуч с 7 лет опыта в обучении PM и tech lead'ов техникам оценки. Экспертиза: PERT, Planning Poker, Wideband Delphi, фасилитация воркшопов.

Контекст: Я IT-директор в [размер компании — 50/200/500 человек]. В команде [количество PM и тимлидов] специалистов с разным уровнем: [распределение — джуны/миддлы/сеньоры]. Текущая проблема: [частые срывы сроков/конфликты оценок с заказчиком]. Доступное время: [4-часовой воркшоп].

Задача: Спроектировать сценарий воркшопа по Three-point PERT оценке с практикой на реальном кейсе команды.

Формат вывода: (1) Таймлайн воркшопа поминутно: теория, демо, практика, дебриф. (2) Учебный кейс с исходными данными для оценки (User Story, допущения). (3) Рабочий лист участника с формулой PERT и полями O/M/P. (4) Чек-лист фасилитатора: типовые ошибки участников и как их корректировать.

Детали: Опирайся на Kahneman о якорении и bias в оценках. Избегай чистой теории — 70% времени должна занимать практика.

Роль: Ты PMO-директор с 12 лет опыта внедрения estimation-стандартов в IT-компаниях. Экспертиза: PERT, Story Points, T-shirt sizing, reference class forecasting, Monte Carlo.

Контекст: Я Head of Delivery в [тип компании — продуктовая/аутсорс/системный интегратор]. Портфель проектов разнообразный: [процент fixed price], [процент T&M], [типы проектов — веб/мобайл/SaaS/ML/интеграции]. Текущий стандарт оценки: [единый метод или хаос]. Боль: [долго оцениваем pre-sale/низкая точность/команды спорят].

Задача: Построить матрицу выбора метода оценки по типу проекта и стадии, чтобы PM однозначно понимали, когда какой метод применять.

Формат вывода: (1) Матрица: тип проекта × стадия (pre-sale/discovery/sprint planning) × рекомендуемый метод × причина. (2) Сравнительная таблица 5 методов по критериям: скорость, точность, требуемые входные данные, применимость к fixed price. (3) Decision tree из 5–7 вопросов для PM. (4) Политика эскалации при расхождении оценок >30%.

Детали: Опирайся на PMBOK, SAFe и практику Steve McConnell (Software Estimation). Никаких 'универсальных' методов — каждая рекомендация должна иметь контекст применения.