Метод параноика. Принципы создания цифровых продуктов для бизнеса в условиях неопределенности

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

По этой логике, если ключевой участник проекта, будучи специалистом в технических вопросах и отвечающий за определенную систему или подсистему в продукте, может координировать группу, то вы избегаете конфликта между управлением и компетенциями. Поэтому в «Методе параноика» нет менеджеров в привычном понимании, т. е. участников проекта, чья единственная задача – управление командой. Вместо этого управление происходит одновременно на разных уровнях: на самом верхнем уровне лидером выступает проджект-раннер, на всех остальных – ключевые участники проекта.

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

Общий состав проектной команды образует небольшие группы, сконцентрированные вокруг ключевых участников, что позволяет локализовать полномочия принятия решений на каждом уровне. У каждой группы есть цели, вытекающие из требований к их части системы. В результате у людей появляется пространство, где они могут ощутить себя полноправными хозяевами. Это чертовски важно для мотивации, ведь нет ничего хуже, чем когда твои усилия теряются на фоне большого коллектива.

Еще одним плюсом такого подхода является то, что локализация ответственности позволяет снизить силу воздействия закона Прайса. Закон гласит, что 50 % работы выполняется числом людей, равным квадратному корню из общего числа занятых в работе. Если говорить более конкретно, то в группе из трех человек половину работы делают двое, в группе из пяти – тоже двое! В команде из десяти человек половину работы выполнят трое. Представьте, какие цифры вы получите, например, для коллектива из пятидесяти человек! Поэтому, структурируя большую команду в виде небольших групп, мы не даем слабым игрокам спрятаться за спинами более сильных, и повышаем производительность всей команды.

Коммуникации между участниками

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

Я хочу начать с повторения идеи, что часть ключевых участников команды являются «несущей конструкцией» для создаваемого продукта, а часть – и тут внимание – для проекта. Это важно понимать, иначе может показаться, будто бы проект, выполняемый гибкой командой, сохраняет свои параметры сам по себе. Конечно, это не так, ведь, как уже было сказано, суть проектной работы – человеческое мышление, и каждый волен думать так, как он хочет. Поэтому нужны те, кто задает вектор и границы этого процесса. Одним из таких участников, неразрывно связанных с проектом на всем его протяжении, выступает проджект-раннер. Его задача, как и остальных аналогичных по своему значению людей в команде, – сохранение производственной культуры проекта и заложенных в самом начале принципов и целей, на которых строится цифровой продукт.

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

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