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 более предсказуемым