Как хаос в требованиях блокировал разработку на 5 системах
Компания по разработке государственных ИТ систем ⚠️ Ситуация 5 городских систем, 3 заказчика, 2 команды (внутренняя + подряд) На уровне разработки всё выглядело «нормально», но проекты системно не двигались.
🔴 Проблема (как это ощущалось бизнесом) - согласование требований длилось месяцами - встречи с заказчиками проходили регулярно — "без результата" - одни и те же вопросы обсуждались по кругу - требования попадали в разработку неполными - сроки релизов стабильно срывались (до квартала)
💸 Цена проблемы - блокировка поставки изменений в 5 системах - постоянные задержки релизов - перегруз команд из-за переделок - рост напряжения со стороны заказчиков 👉 Фактически: "разработка шла, но ценность не поставлялась"
🧠 Реальная причина Проблема была не в разработке. 👉 В системе "отсутствовала функция бизнес-анализа как управляемый процесс" - никто не отвечал за финализацию требований - требования «жили» в обсуждениях - не было связки между заказчиком и разработкой - зоны ответственности были размыты
⚙️ Что было сделано Я зашла в проект как лидер трансформации (с функцией консалтинга и внедрения). И сфокусировалась не на “улучшениях”, а на "устранении системного разрыва"
Ключевые изменения: 1. Ввела функцию бизнес-анализа - закреплена ответственность за требования end-to-end - устранён “ничейный” участок 2. Остановила бесконечные обсуждения - внедрены критерии финализации требований - требования перестали «гулять» между встречами 3. Перестроила взаимодействие с подрядчиком - убран разрыв между аналитикой и разработкой - требования стали доходить до разработки в готовом виде 4. Преодолела сопротивление - через обучение и работу с мотивацией участников
📊 Результат За 10 месяцев: - ⏱ Согласование требований ускорилось в 2 раза - 📈 NPS заказчиков вырос на 20% - 📦 Разработка стала получать финализированные требования - 👥 Сформирована функция аналитики (рост команды до 3 человек) - 🚀 Запущена система развития (junior → middle за 6 месяцев)