Промпт для плана онбординга и адаптации руководителя

Пример входных данных от пользователя

Контекст: Нанимаем Head of QA в финтех-стартап (команда 12 человек). Предыдущий лид ушел внезапно, процессы хаотичны. Факты: Релизный цикл затянут до 3 недель, много багов на проме (5+ критичных в месяц). Команда демотивирована отсутствием структуры. Бизнес-эффект: Снижение скорости выкатки фич на 40%, риск оттока клиентов из-за нестабильности сервиса. Ограничения: 90 дней испытательный срок, бюджет на инструменты ограничен $1k/мес, найм заморожен. Цель 90 дней: Сокращение Time-to-Market до 1 недели, 0 критичных багов на проде.

Ответ модели

1) Диагностика Точка роста — отсутствие прозрачного пайплайна тестирования и единых стандартов качества. Проблема не в людях, а в отсутствии формализованных критериев «Ready for QA» и «Ready for Release».

2) Скрипт разговора «Твоя приоритетная задача — стабилизировать продукт и ускорить поставку. Сейчас релиз занимает 3 недели, это критично для бизнеса. Жду от тебя через 2 недели аудит узких мест и план перехода на недельные спринты без потери качества. У тебя есть полный карт-бланш на пересмотр внутренних регламентов команды».

3) План развития

• Недели 1-2: Аудит. Анализ текущего цикла багов.

  • Эффект: Карта «бутылочных горлышек». Проверка: Презентация списка из 3-5 главных причин задержек.

• Недели 3-6: Стандартизация. Внедрение Definition of Done (DoD) и автоматизация части регресса.

  • Эффект: Снижение доли ручного труда. Проверка: Чек-листы внедрены в Jira.

• Недели 7-12: Оптимизация. Переход на недельные релизы.

  • Эффект: TTM = 1 неделя. Проверка: 4 успешных релиза подряд без откатов.

4) Метрики и контроль

• 30 дней: Сформирована стратегия качества. (Контроль: 15-е число месяца).

• 60 дней: Количество багов на проде < 2. (Контроль: отчет из Sentry). *

...