Rockstar — эксперты горят, а проекты стоят на месте ч.2
Ранее в посте я разобрал кейс из своей недавней практики. Безусловно выглядит несколько голословно, поэтому поделюсь некоторыми результатами, исходя из предложенного мной решения.
Итак, мы помним, что в организационной структуре компании в кейсе отсутствует явно определённая точка принятия обязательств. Это приводит к перегрузке наиболее компетентных специалистов и остановке процессов принятия решений.
💊 В кейсе предложен фреймворк для решения проблемы:
1️⃣ Формализовать точку принятия обязательств. Зафиксировать в регламенте момент, когда запрос переходит из категории «к обсуждению» в категорию «к выполнению». Критерием перехода является назначение единственного ответственного лица и фиксация срока предоставления результата
2️⃣ Установить входные критерии. Любой запрос, поступающий на оценку, должен содержать исчерпывающую информацию: [формулировка проблемы] + [предпринятые самостоятельные шаги по её решению] + [чёткое описание ожидаемого outcome] ‼️Важно: Запросы, не соответствующие критериям, не допускаются к обработке
3️⃣ Закрепить зоны ответственности. Определить, какая роль (CTO, PO, тимлид) несёт окончательную ответственность за каждый тип решений. Делегирование должно быть явным и однозначным
4️⃣ Вести учёт метрик от точки обязательства. Измерять время выполнения задач исключительно с момента перехода через точку принятия обязательств. Это обеспечит объективную оценку эффективности процесса, исключив время, затраченное на предварительные неструктурированные обсуждения.
✅ Результаты на текущий момент
Операционные результаты:
1. Сократили время оценки проектов на 40%. Lead Time метрика уже отражает реальное время работы, исключая период неструктурированных обсуждений 2. Удалось почти на 80% исключить хаотичные запросы к Rockstar благодаря жёстким входным критериям. Это освободило почти 15-20 часов его рабочего времени еженедельно, а также команда тоже эффективно использует освободившиеся часы 3. Снижение количества переоценок и уточнений на 80% за счёт требования исчерпывающей информации на входе.
Качественные изменения:
1. Исчезновение "вакуума ответственности". Каждый тип решений закреплён за конкретной ролью (CTO - техническая архитектура и выбор технологии и подходов к разработке, PO - функциональные требования и бизнес-архитектура, тимлид - ресурсная оценка и исполнение) 2. Прекращение практики коллективных мозговых штурмов без определённого outcome. Вместо них - сейчас внедрены персональные обязательства с фиксированными сроками
Митигация некоторых рисков:
1. Удалось преодолеть сопротивление команды из-за жёстких регламентов 2. Уже сейчас цикл оценки сокращен как и временные затраты на это «упражнение». Потребовалось 2-3 цикла в рамках предложенного фреймворка 3. Да, я наблюдал некоторое увеличение нагрузки на CTO в переходный период. Но это компенсируется последующим высвобождением ресурсов за счёт устранения дублирующих обсуждений.
♻️ Ценность: сейчас изменения трансформируют процесс из реактивного хаоса в управляемый workflow с измеримыми результатами и чёткими зонами ответственности.
💡Ожидаемые результаты
Качественные изменения:
1. Я уверен, что будет объективный «выхлоп» от метрик эффективности —> показатели будут основываться на данных после точки принятия обязательств, а не на совокупном времени обсуждений
Бизнес-эффекты:
1. Я предполагаю увеличение конверсии входящих запросов в сделки на 25-40% благодаря:
- Сужению ценовых вилок до 15-20%
- Предоставлению клиентам альтернативных вариантов реализации
- Сокращению времени подготовки коммерческого предложения
2. Уверен в снижение репутационных потерь, потому как исчезнет ситуация с долгим представлением оценки и, как следствие, представление коммерческого предложения
3. Из моего опыта стандартизация процесса оценки позволит точно прогнозировать сроки и ресурсы, что сделает pipeline более предсказуемым