Тимлид и Scrum-мастер постоянно решает одни и те же задачи по оптимизации потока работы и обеспечению сроков поставки ценности. На это уходят часы. Мы подготовили для вас набор готовых запросов (промтов), чтобы ИИ работал как ваш аналитический партнер, который позволит автоматизировать часть рутины и высвободить время для более важных задач.
1. Оптимизация потока работы (Workflow) на основе данных
Задача: Поиск ограничений в потоке задач
Используйте этот промт для того, чтобы найти ограничение (bottleneck) в потоке задач, даже если данные разрознены и ранее подобный анализ проводился интуитивно. В основе промта техника Step-by-step Analysis, результат – конкретные гипотезы для экспериментов, а не общие советы.
Ты — консультант по оптимизации потоков создания ценности (Value Stream Mapping). У меня есть сырые данные о работе команды за последние 3 спринта: [ВСТАВЬТЕ ДАННЫЕ: список задач, дата создания, дата взятия в работу, дата завершения, тип задачи (фича/баг/долг), кто работал].
Проведи анализ в 4 строгих шага и оформи вывод в таблицы:
1. **Flow Analysis:** Рассчитай среднее время выполнения задачи (Lead Time) и время активной работы (Cycle Time) для каждого типа задачи. Выяви аномалии.
2. **WIP Analysis:** Смоделируй, как менялась нагрузка (Work in Progress) на каждого участника с течением времени. Определи периоды и людей с хронической перегрузкой (WIP > 3).
3. **Bottleneck Identification:** Используя данные из п.1 и п.2, определи этап процесса или роль, которые являются узким горлышком. Примени принцип «очереди»: где задачи ждут дольше всего?
4. **Simulation & Recommendation:** Смоделируй, какой эффект дадут два изменения: а) введение жесткого лимита WIP=2 для всех, б) выделение специализированного человека на этап-бутылочное горлышко. Спрогнозируй потенциальное влияние на средний Lead Time.
Представь результат кратко, с ключевыми метриками и визуализацией в виде графиков.
Задача: Анализ «невидимых» прерываний и их стоимости
Команда чувствует, что постоянные срочные задачи и вопросы «на минуту» съедают время, но это сложно измерить и представить в виде количественных аргументов и финансовых потерь. Используются техники «Cost of Delay» и «Activity Sampling», результат — конкретные обоснования изменения процессов для руководства.
Действуй как аналитик производительности, специализирующийся на измерении Cost of Delay (Стоимости задержки) и прерываний. Я хочу количественно оценить влияние контекстных переключений и срочных входящих задач на способность моей команды выполнять плановую работу.
Исходные данные: [Опишите контекст: примеры типичных прерываний (срочные баги, вопросы от Владельца продукта, помощь коллегам), примерную частоту, состав команды].
Проведи анализ по схеме:
1. **Классификация прерываний:** Раздели их на типы по источнику и срочности (например, “критичный баг”, “запрос на информацию”, “помощь коллеге”).
2. **Моделирование времени:** Для каждого типа оцени (даже гипотетически) среднее время на отклик + время на восстановление контекста (context switching). Используй модель, что одно прерывание = 15 мин. работы + 25 мин. на восстановление фокуса.
3. **Расчет Cost of Delay для плановой работы:** На основе п.2 рассчитай, сколько часов работы над плановым бэклогом теряется в неделю/спринт. Переведи это в эквивалент количества небольших пользовательских историй (например, 1 история = 3 часа), которые команда НЕ доделала.
4. **Рекомендации по политикам:** Предложи 3 конкретные политики (например, “тихие часы”, “дежурный по прерываниям”, SLA на ответы) и смоделируй, как каждая из них может сократить потери из п.3. Оформи итог в виде краткой презентации для стейкхолдеров с заголовком: “Сколько нам на самом деле стоят срочные вопросы: отчет о скрытой неэффективности”.
Задача: Расчет экономического эффекта от устранения «бутылочного горлышка»
Вы выявили слабое звено (например, долгое ревью кода или тестирование). И теперь нужно убедить бизнес инвестировать в его расшивку: добавить человека, докупить оборудование. С помощью техник «Business Case» и «Value vs. Effort» переводим техническую проблему на язык бизнес-решений и ROI, что критически важно для получения ресурсов на изменения.
Ты — бизнес-архитектор. Помоги построить обоснование (business case) для инвестиций в устранение ограничения процесса.
Ограничение: [Опишите ограничения, например, “один senior-инженер проводит ревью всего кода, создавая очередь”].
Данные: [Если есть, вставьте данные о времени ожидания/простоя].
Создай презентацию, которая включает:
1. **Текущие потери:** Рассчитай потери в единицах Lead Time (увеличение времени поставки) и потенциале команды (сколько story points “застревает” в неделю из-за ожидания).
2. **Сценарии улучшений:** Разработай 2-3 варианта решения (например, а) внедрение парного программирования для части задач, б) покупка статического анализатора кода, в) обучение и делегирование полномочий второму инженеру).
3. **Оценка выгоды (Benefit):** Для каждого варианта оцени потенциальное сокращение Lead Time (в %) и увеличение пропускной способности команды (в story points за спринт). Переведи это в бизнес-ценность, используя фразу: “Это эквивалентно возможности раньше начать/завершить проект [название] или реализовать X дополнительных фич для клиента в квартал”.
4. **Оценка усилий (Effort):** Оцени сложность внедрения каждого варианта по шкале от 1 до 10 (время, деньги, организационные изменения).
5. **Матрица принятия решения:** Представь варианты в виде матрицы Value vs. Effort и дай четкую рекомендацию. Закончи выводом: “Наибольший экономический эффект при наименьших издержках даст вариант Y, потому что…“.
2. Прогнозирование сроков поставки ценности
Задача: Построение вероятностного прогноза сроков поставки
Команда дает обещания на спринт, но не выдерживает их. Точечные оценки, например, в стори поинтах, не дают точных прогнозов фактической поставки ценности. Используйте этот промт, чтобы дать команде и стейкхолдерам научно обоснованные данные для реалистичного планирования.
Ты — аналитик по прогнозированию, применяющий статистические методы к agile-планированию. У меня есть исторические данные о производительности команды за последние 5 спринтов: [Вставьте данные: например, выполненные story points за каждый спринт: 35, 42, 28, 38, 45].
Твоя задача — уйти от точечного прогноза (“в следующий спринт сделаем 40 SP”) к вероятностному.
1. **Анализ распределения:** Проанализируй исторические данные. Рассчитай среднее, стандартное отклонение. Опиши, какова естественная вариативность скорости команды.
2. **Простая симуляция (Монте-Карло):** Смоделируй 1000 возможных исходов следующего спринта, основываясь на исторических данных. Не используй сложные формулы, объясни логику “случайного выбора из прошлых результатов”.
3. **Прогнозирующие интервалы:** На основе симуляции определи:
* С вероятностью 85% команда завершит от [X] до [Y] SP.
* С вероятностью 50% команда завершит не менее [Z] SP.
4. **Рекомендации для планирования:** Сформулируй три правила для обсуждения с продукт-оунером, например: “Планируйте в бэклог спринта только те задачи, чья оценка попадает в 50% прогнозный интервал ([Z] SP). Остальные — как бонус или в следующую итерацию”. Представь результат в виде наглядного дашборда с графиком распределения вероятностей.
Задача: Анализ цепочки зависимостей как причины срыва сроков
Если сроки поставки нарушаются из-за внешних зависимостей (ждем данные от другого отдела, согласование у стейкхоледра, лицензию), можно использовать промт на основе техник «Critical Path Method» и «Карта стейкхолдеров» для управления внешними рисками. В результате получаем готовый план действий и коммуникации для проактивной работы с зависимостями.
Ты — менеджер проектов, эксперт по управлению зависимостями и методом критического пути (Critical Path Method). Проанализируй наш план для следующей поставки ценности (релиза/квартала).
Контекст: Наша ключевая цель — [опишите цель, напр., “запустить платежный модуль к 1 декабря”]. У нас есть: [опишите основные задачи и известные зависимости, например, “Задача А (разработка ядра, 2 недели) -> Зависит от: предоставления API-спецификации от вендора В. Задача Б (интеграция, 1 неделя) -> Зависит от завершения А и результатов нагрузочного тестирования от команды QА”].
Проведи анализ:
1. **Построение сетевого графика (PERT):** Визуально изобрази цепочку задач и зависимостей. Выдели критический путь — последовательность задач, определяющую минимальное время до релиза.
2. **Идентификация рисков на критическом пути:** Для каждой задачи на критическом пути определи: тип зависимости (внутренняя/внешняя, жесткая/гибкая), ответственного стейкхолдера, вероятность задержки.
3. **План смягчения (Mitigation Plan):** Для 3 самых рискованных внешних зависимостей предложи конкретные действия:
- **До начала работы:** Как можно превратить “жесткую” зависимость в “гибкую” (напр., получить черновые данные вместо окончательных)?
- **Во время работы:** Какую промежуточную ценность можно проверить/поставить, не дожидаясь полного завершения зависимости?
- **В случае задержки:** Какой есть план Б (fallback option)?
4. **Генерация шаблонов коммуникации:** Создай черновики писем/сообщений для ключевых внешних стейкхолдеров с четкими запросами, дедлайнами и формулировкой взаимной выгоды.
Задача: Выравнивание ожиданий стейкхолдеров
Стейкхолдеры хотят всё, быстро и идеально. Команда чаще всего при фиксированных ресурсах может выбрать только два параметра из трех. Вооружаемся четкой структурой для трудного разговора, позволяющей уйти от дискуссии о «срыве сроков» в предметное обсуждение приоритетов и осознанных выборов.
Ты — переговорщик и фасилитатор, специализирующийся на управлении ожиданиями. Помоги подготовить и провести сессию с ключевым стейкхолдером (продукт-оунер, клиент), чтобы обсудить срыв сроков и пересмотреть обязательства.
Контекст: Мы не успеваем к [дата] выполнить весь изначально запланированный объем [опиши Scope]. Нужно пересмотреть договоренности.
Создай сценарий сессии (30 минут) на основе концепции «Железного треугольника» (Scope, Time, Cost/Resources):
1. **Подготовка данных:** Попроси меня ввести: а) что гарантированно будет сделано к дате (фикс), б) что находится под угрозой (риск), в) что точно не успеем (отказ).
2. **Визуализация Trade-off:** Предложи 3 четких, наглядных варианта на выбор, оформленные как “меню”:
* **Вариант А (Фиксируем время и качество):** Делаем к дате только фикс + часть из “риска”. Откладываем остальное. Качество высокое.
* **Вариант Б (Фиксируем объем и время):** Делаем все (“фикс” + “риск”), но сознательно снижаем качество по неприоритетным пунктам (техдолг, покрытие тестами) и фиксируем это как осознанный технический риск.
* **Вариант В (Фиксируем объем и качество):** Переносим дату релиза на [предложи новую дату на основе данных].
3. **Фрейминг решений:** Для каждого варианта сгенерируй по 2 сильных аргумента “за” (фокус на выгоде для бизнеса) и 1 честный аргумент “против” (явный компромисс).
4. **Фразы для сложных вопросов:** Дай 3 готовых формулировки, чтобы мягко, но уверенно сказать “нет” или отстоять границы, например: “Я понимаю важность этой фичи. Чтобы включить ее в этот релиз, нам придется исключить [другую важную фичу]. Вы как продукт-оунер, какой выбор сделаете?”
Важное примечание по безопасности данных
Постарайтесь не загружать в публичные чат-боты конфиденциальные коммерческие показатели, названия реальных проектов, брендов, продуктов и клиентов, имена и личные данные коллег.
Вместо этого можно обезличить данные:
- Заменить реальные названия на «Проект А», «Команда X», «Продукт Б».
- Использовать относительные цифры («скорость упала на 20%») вместо абсолютных.
- Тестировать логику, а не данные: можно ввести гипотетические или сильно обобщенные данные, чтобы понять структуру решения, а затем применить ее к своим реальным данным уже в защищенной среде.
Что дальше?
Эти промты — первый шаг к системной работе. Они экономят время, но настоящий прорыв в производительности команды происходит, когда вы создаете систему для оптимизации рабочих процессов, управления конфликтами и работы с групповой динамикой.
Именно этому мы учим на практическом тренинге «Создание высокоэффективных команд»:
- Системно устраняем «узкие горлышки».
- Профессионально фасилитируем любые события и разрешаем конфликты.
- Эффективно применяем ИИ и данные для роста, а не для микроменеджмента.
- Получаем международный сертификат ICAgile ICP-ATF.
Готовы перейти от точечных решений к системным улучшениям?
👉 Забронируйте участие в тренинге Создание высокоэффективных команд
Посмотреть программу и даты