Почему «этапная» классификация процессов подводит команды — и что делать вместо неё
Продуктовые и управленческие команды часто описывают ситуацию через стадии: «мы на этапе роста», «сотрудник на стадии выгорания», «сделка на стадии охлаждения». Это удобный язык для отчётов, но плохой инструмент для принятия решений — потому что стадия ничего не говорит о том, что происходит на самом деле.
Проблема стадийных моделей не нова
Подобные фреймворки существуют почти в каждой дисциплине: жизненный цикл продукта в менеджменте, стадии кризиса в риск-менеджменте, этапы группового развития в психологии, воронка продаж в аналитике. Продавать ещё одну модель «процесс проходит через стадии X → Y → Z» бессмысленно — таких моделей и так избыток, и ценность самой идеи стадийности давно исчерпана.
Где вскрывается разрыв
На практике название стадии — это результат интерпретации, а не наблюдение. Два аналитика, глядя на одни и те же данные, могут поставить разные ярлыки, потому что стадия — абстракция верхнего уровня, скрывающая за собой десятки разнородных признаков. Хуже того: стадийные модели по определению линейны, а реальные процессы — нет. Проект может «зависнуть» между этапами, откатиться назад после регрессии или пройти сразу несколько стадий параллельно в разных частях команды.
Смещение фокуса: от этапов к сигналам
Более рабочая логика — не «процесс → этап», а «сигналы → процесс → этап»:
- Система (или аналитик) фиксирует наблюдаемые сигналы.
- По совокупности сигналов определяется, какой процесс разворачивается.
- Только затем оценивается текущий этап и риск.
- На основе этого показываются вероятные сценарии и рекомендации.
Ключевое отличие: этапы остаются каркасом для описания результата, но ядром системы становится база сигналов, а не список стадий.
Как устроена база сигналов
Сигналы описываются не списком, а карточками — по аналогии с тем, как в ИБ описывают индикаторы компрометации. Каждая карточка содержит:
- название и категорию сигнала;
- силу (насколько сигнал значим сам по себе);
- что сигнал может означать и чего он не гарантирует;
- какие другие сигналы его усиливают или ослабляют.
Пример: сигнал «снижение инициативы в коммуникации» в категории «отношения/команда» имеет среднюю силу, может означать потерю вовлечённости, но не означает автоматического ухода человека из проекта; усиливается сочетанием с избеганием встреч и формальными односложными ответами.
Категории и масштаб базы
Для старта достаточно 5–7 категорий: отношения, социальные группы, работа и карьера, манипуляции и мошенничество, личные и командные системы. Для проверки гипотезы хватает 150–300 сигналов, для рабочей версии продукта — 500–1000, для полноценной базы знаний — от 1000 и выше.
Почему рано делать приложение
Соблазн сразу превратить это в SaaS или GPT-обёртку понятен, но методологически неверен: пока нет проверенной методологии и наполненной базы сигналов, любое приложение будет упаковкой пустоты. Правильная последовательность: сначала документ и методология → каталог сигналов → тестирование на реальных кейсах → и только затем продуктовая обёртка.
Вывод
Стадийные модели хороши для отчётности, но плохи как инструмент анализа: они схлопывают множество разнородных наблюдений в один ярлык и создают иллюзию понимания там, где реально нужна работа с сигналами. Компаниям и командам, которые хотят снижать риск поспешных выводов — в продукте, в найме, в переговорах, — стоит инвестировать не в очередную «модель этапов», а в структурированную базу наблюдаемых признаков.