1. Все решения влияют на результат. 2. Не все решения влияют на результат.
Самое желанное решение, которое хотел бы принимать уставший PM - “рыба или мясо” на высоте 10000. К сожалению, эта работа устроена чуть по-другому. Опытные проджекты (а еще управленцы и предприниматели) пользуются "ЧУЙКОЙ". Читаем и не осуждаем (ладно, хейтеру Денису можно и осуждать, что уж тут).
Проджектовская чуйка называется РАМКИ. Ну или ограничения, в которых принимаются решения.
Рамки — это пространство, внутри которого ваши решения работают. Они не отвечают за вас на вопрос “как именно сделать”, но они вычищают шум. Это набор правил, критериев и процессов, которые помогают сузить варианты выбора и сделать его обоснованным, а не случайным. Рамки бывают технические, продуктовые, процессные, этические, операционные, эмоциональные, в зависимости от уровня принятия решений - это все можно погуглить и это совершенно не является жестким must have для каждого проекта.
Примеры контекста, который определяет как именно команда IT-проекта будет выбирать между вариантами:
🍫Политика безопасности (что можно, а что нельзя делать с данными). 🍫Допустимый уровень риска (какие ошибки критичны, а какие можно исправить позже). 🍫Цель спринта (что реально имеет приоритет). 🍫Бюджет/сроки (определяют уровень амбиций).
В итоге PM не принимает каждое решение руками команды, а выстраивает рамку, внутри которой правильное решение почти самоочевидно.
Инструменты, которые помогают держать рамки: ✏️Decision log — журнал решений, чтобы фиксировать рамки и проверять, как они сработали. ✏️ADR (Architecture Decision Records) — в разработке: короткие записи «какую рамку мы приняли и почему» ✏️Decision tree — дерево решений: какие параметры влияют на выбор и где пределы. ✏️Working agreements — правила команды, которые задают рамки на уровне коммуникации и процессов.
Фреймворки, которые помогают определить рамки: ▪️Cynefin Framework (Дейв Сноуден) - чтобы понимать, где рамки нужно дать жёсткие, а где - наоборот, оставить пространство для поиска. -> Простая область: рамки очевидны, есть best practices. -> Сложная область: рамки выявляются через экспертизу. -> Запутанная область: рамки формируются через эксперименты и анализ паттернов. -> Хаос: рамки отсутствуют, сначала нужно создать порядок.
▪️Decision Rights (RAPID / RACI) - Помогают выявить кто имеет право принимать решение и где лежит ответственность.
RACI (Responsible, Accountable, Consulted, Informed). RAPID (Recommend, Agree, Perform, Input, Decide).
▪️ Мое любимое: Bounded Rationality (Герберт Саймон) - позволяет выявить какие именно ограничения реально действуют. Есть такая теория ограниченной рациональности: люди принимают решения в рамках доступной информации, времени и когнитивных ресурсов.
Есть еще фреймворки из agile, игра в провал проекта, выявления зависимостей и т.д. и т.п. И конечно же есть AI! Который будет (и уже это делает) забирать рутину: планирование, трекинг, отчётность. Но останется работа, где человеческий интеллект незаменим — это создание рамок для принятия решений в условиях неопределённости. Потому что тут нужно чувствовать, где заканчивается хаос и начинается система. Это навык опытного PM: задать правила игры так, чтобы команда сама находила решения. ИИ туда не дотянется, потому что у него нет ни опыта провалов, ни чуйки, ни нервов, прошитых десятками проектов.
❤️ - Лайк, если хоть раз замечали, как команда оживает, когда ей наконец-то дали не микроменеджмент, а пространство для манёвра.
