Недавно я разбирал весьма частый, но интересный кейс. Риски таких кейсов вполне часто встречаются и в корпорациях, развиваясь в глобальные проблемы… как опухоль

Представьте ситуацию: в компании есть звездный сотрудник. К нему идут за советом все — от стажеров до тимлидов. Его продажи бьют рекорды, а в сложных проектах он становится центром притяжения. Со стороны выглядит как идеальный HR-кейс. Но под поверхностью скрывается системный сбой, который медленно выводит из строя и сотрудника, и процессы вокруг него.

Кейс Специалист (назовем его Rockstar) работает в IT-компании, которая недавно перешла на продуктовую модель. Rockstar поручили нестандартные и кастомные проекты, включая направления с AI. Его результаты по тендерам и индивидуальным запросам существенно выше, чем у коллег, работающих с типовыми продуктами.

После реорганизации к Rockstar начали обращаться за решениями сотрудники всех уровней: product managers, backend-разработчики, тестировщики, даже тимлиды. Фактически Rockstar выполняет роль product owner’а для всех продуктов, хотя формально это не закреплено.

Переломный момент: до трех часов рабочего времени Rockstar мог потратить на встречу с CTO, PO и тимлидом. Например, не могли договориться по оценке проекта в части выбора между технологиями и подходами разработки для конкретного ТЗ. При этом для тендерных проектов аналогичные оценки делаются за пару часов с четким ценником.

📝 Диагноз: отсутствие точки принятия обязательств Проблема не в Rockstar, а в процессе. Команда работает в режиме перманентного мозгового штурма, где задачи зависают между «хотелками» и реальными обязательствами:

• CTO оценивает техническую часть, но не берет на себя ответственность за финальное решение
• PO знает требования, но не владеет процессом оценки
• Тимлид понимает ресурсы, но не имеет полномочий утверждать подход

В результате Rockstar становится неформальным арбитром — точкой аккумуляции для всех неопределенностей. Это классический пример системы, где Commitment Point (точка принятия обязательств) не выделен явно. Задачи свободно плавают между участниками, потребляя ресурсы, но не двигаясь к результату.

💊Предложенное решение:

Переход от хаоса к управляемому workflow

1️⃣ Необходимо определить границу обязательств. В системе управления проектами (да хоть на маркерной доске) должна появиться четкая линия между «запросами» и «обязательствами». Например, статус «Принято в работу» становится точкой, после которой:

• Назначен единственный ответственный
• Зафиксирован срок первой итерации
• Определены критерии приемки

2️⃣ Параллельно необходимо применить входной фильтр запросов, поступающих в Rockstar. Любой запрос должен содержать структуру: «У меня вопрос по [тема]. Я уже проверил [источники] и попробовал [решения]. Результат: [что получилось]. Что нужно: [ожидаемый outcome]»

3️⃣ После пп 1 и пп 2 можно вполне явно делегировать обязательства. В этом случае вполне легитимно, чтобы CTO принимал ответственность за техническую оценку проектов с фиксацией срока (например, 24 часа на базовый вариант). ‼️В этом случае Rockstar перестает участвовать в обсуждениях — только получает готовый результат.

4️⃣Наконец, можно ввести метрику Lead Time (время выполнения), которая измеряется только от момента перехода задачи в «обязательства» ❕ Это покажет реальную эффективность, а не время, потраченное на бесконечные дискуссии.

♻️ Общие выводы

Экспертность — это ресурс, который должен умножать эффективность системы, а не компенсировать ее провалы. Когда точка принятия обязательств не видна, самые компетентные сотрудники начинают работать за нескольких человек.

❓Такой подход, конечно, в краткосрочной перспективе дает результат — задачи все же решаются силами Rockstar… ❌ НО глобально это стратегический провал — процессы не улучшаются, а риски концентрации знаний растут.