Люблю метафоры. Они работают как алгоритм архивации знаний: имя становится ключом, а распаковка происходит почти мгновенно.

Для разных устойчивых управленческих подходов я подобрал геометрические объекты. Так их удобнее держать в голове и применять в работе. Получилось четыре основных формы:

Точка — исследовательская работа
Отрезок — проектная работа
Окружность — процессная работа
Спираль — продуктовая работа

Точка — это начало неопределённости. Есть вопрос, гипотеза, наблюдение, проблема, но ещё нет понятного маршрута. Исследовательская работа начинается именно здесь: нужно сфокусироваться, собрать факты, понять природу явления и определить, есть ли вообще предмет для дальнейшего действия.

Точка отвечает на вопрос: что мы обнаружили и стоит ли с этим работать дальше?

Отрезок — это движение из точки А в точку Б. Есть начальное состояние, целевое состояние, сроки, ресурсы, ограничения и команда. Это проектная логика: нужно пройти путь и получить конкретный результат.

И здесь есть важный момент, точка А — это оценка текущего состояния в тех категориях, которые нужно изменять. Точка Б — это точная координата, т.е. вся требуемая проектная документация, которая позволяет определить эту точку.

Отрезок отвечает на вопрос: как перейти из текущего состояния в целевое?

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

Окружность отвечает на вопрос: как получать результат регулярно и управляемо?

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

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

Спираль отвечает на вопрос: как развивать ценность, не теряя связь с реальностью?

Ошибка начинается там, где форму управления выбирают неправильно.

Исследование пытаются вести как проект.

Особенность R&D часто в том, что на старте не знаешь не только, как получится реализовать ту или иную функциональность, но порой и возможно ли реализовать её в принципе.

Но есть категория менеджеров, которые заранее называют срок и отчитываются, что команда всё сделает. Одна половина из них просто не понимает природы исследований, а вторая свято убеждена, что таким образом дисциплинирует ленивых исполнителей. В результате команда вместо поиска ответа начинает искать способ уложиться в обещание — даже если правильный ответ звучит как «это не работает».

Проект превращают в процесс.

Когда я работал в интеграторах, частой проблемой слабого менеджмента было следующее: по ходу проекта тебе начинают подсовывать дополнительную функциональность и просят сделать её «к какому-нибудь сроку». Обычно — очень важному и, конечно, ближайшему.

В итоге точка окончания проекта где-то далеко и никого особенно не волнует, а правки для важных людей нужно сделать прямо сейчас. Работа превращается в бесконечный цикл внесения комментариев: внёс за неделю — молодец, не внёс — уже не очень. А то, что эти комментарии слабо связаны со скоупом проекта, — неважно. Главное, что они важны.

Процесс ведут как исследование.

Наверное, это самый типовой сценарий из тех, с которыми я сталкивался в цифровизации. До процесса ни у кого не доходят руки: его не описывают, не формализуют и не закрепляют в системах компании. А дальше добавляется текучка кадров — или сам процесс происходит достаточно редко, чтобы все успели забыть, что и в какой последовательности делать.

В итоге каждый раз изобретаем велосипед. Иногда даже с квадратными колёсами, потому что человек, который знал правильный порядок действий, уволился полгода назад. Решение довольно прозаичное: описать процесс, определить роли и артефакты, а затем положить всё это в нормативные документы или рабочие системы компании.

Продукт ведут как проект.

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

Запланировать «жирное» MVP и долго откладывать первый запуск — типичная болезнь проектного мышления. Кажется, что нужно сначала закончить всё важное, а уже потом показать результат рынку. Но без контакта с реальностью продукт не движется по спирали: команда просто строит длинный отрезок в направлении, которое выбрала сама. Иногда оказывается, что идти нужно было совсем в другую сторону.

Ну и еще раз про формы коротко:

Точка проверяет гипотезу.
Отрезок доводит до результата.
Окружность воспроизводит результат.
Спираль развивает результат.

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

Отзывается? Или, может, у вас есть свои метафоры для управленческой базы?