Люблю метафоры. Они работают как алгоритм архивации знаний: имя становится ключом, а распаковка происходит почти мгновенно.
Для разных устойчивых управленческих подходов я подобрал геометрические объекты. Так их удобнее держать в голове и применять в работе. Получилось четыре основных формы:
Точка — исследовательская работаОтрезок — проектная работаОкружность — процессная работаСпираль — продуктовая работа
Точка — это начало неопределённости. Есть вопрос, гипотеза, наблюдение, проблема, но ещё нет понятного маршрута. Исследовательская работа начинается именно здесь: нужно сфокусироваться, собрать факты, понять природу явления и определить, есть ли вообще предмет для дальнейшего действия.
Точка отвечает на вопрос: что мы обнаружили и стоит ли с этим работать дальше?
Отрезок — это движение из точки А в точку Б. Есть начальное состояние, целевое состояние, сроки, ресурсы, ограничения и команда. Это проектная логика: нужно пройти путь и получить конкретный результат.
И здесь есть важный момент, точка А — это оценка текущего состояния в тех категориях, которые нужно изменять. Точка Б — это точная координата, т.е. вся требуемая проектная документация, которая позволяет определить эту точку.
Отрезок отвечает на вопрос: как перейти из текущего состояния в целевое?
Окружность — это повторяемый контур. Вход, действие, результат, обратная связь, коррекция — и снова новый цикл. Это логика процесса: не разово добиться результата, а стабильно воспроизводить его с нужным качеством.
Окружность отвечает на вопрос: как получать результат регулярно и управляемо?
Спираль — это развитие через повторяющиеся циклы. Каждый виток похож на предыдущий, но система уже не возвращается в ту же точку. Появляются новые данные, пользователи, ограничения, версии, гипотезы, эффекты. Это продуктовая логика.
К слову, известное многим бережливое производство — это трансформация окружности в спираль, то есть привнесение продуктового подхода в процессную работу.
Спираль отвечает на вопрос: как развивать ценность, не теряя связь с реальностью?
Ошибка начинается там, где форму управления выбирают неправильно.
Исследование пытаются вести как проект.
Особенность R&D часто в том, что на старте не знаешь не только, как получится реализовать ту или иную функциональность, но порой и возможно ли реализовать её в принципе.
Но есть категория менеджеров, которые заранее называют срок и отчитываются, что команда всё сделает. Одна половина из них просто не понимает природы исследований, а вторая свято убеждена, что таким образом дисциплинирует ленивых исполнителей. В результате команда вместо поиска ответа начинает искать способ уложиться в обещание — даже если правильный ответ звучит как «это не работает».
Проект превращают в процесс.
Когда я работал в интеграторах, частой проблемой слабого менеджмента было следующее: по ходу проекта тебе начинают подсовывать дополнительную функциональность и просят сделать её «к какому-нибудь сроку». Обычно — очень важному и, конечно, ближайшему.
В итоге точка окончания проекта где-то далеко и никого особенно не волнует, а правки для важных людей нужно сделать прямо сейчас. Работа превращается в бесконечный цикл внесения комментариев: внёс за неделю — молодец, не внёс — уже не очень. А то, что эти комментарии слабо связаны со скоупом проекта, — неважно. Главное, что они важны.
Процесс ведут как исследование.
Наверное, это самый типовой сценарий из тех, с которыми я сталкивался в цифровизации. До процесса ни у кого не доходят руки: его не описывают, не формализуют и не закрепляют в системах компании. А дальше добавляется текучка кадров — или сам процесс происходит достаточно редко, чтобы все успели забыть, что и в какой последовательности делать.
В итоге каждый раз изобретаем велосипед. Иногда даже с квадратными колёсами, потому что человек, который знал правильный порядок действий, уволился полгода назад. Решение довольно прозаичное: описать процесс, определить роли и артефакты, а затем положить всё это в нормативные документы или рабочие системы компании.
Продукт ведут как проект.
Не самый очевидный, но крайне полезный опыт, на который я потратил много денег и времени. Каждый виток спирали определяется циклом обратной связи. Для продукта это прежде всего касание рынка: пользователи, их поведение, обратная связь, деньги — или отсутствие денег.
Запланировать «жирное» MVP и долго откладывать первый запуск — типичная болезнь проектного мышления. Кажется, что нужно сначала закончить всё важное, а уже потом показать результат рынку. Но без контакта с реальностью продукт не движется по спирали: команда просто строит длинный отрезок в направлении, которое выбрала сама. Иногда оказывается, что идти нужно было совсем в другую сторону.
Ну и еще раз про формы коротко:
Точка проверяет гипотезу.Отрезок доводит до результата.Окружность воспроизводит результат.Спираль развивает результат.
Мне кажется, это один из самых наглядных способов быстро понять, какая управленческая логика нужна в конкретной ситуации.
Отзывается? Или, может, у вас есть свои метафоры для управленческой базы?
