Это означает, что специалисты в инженерных и креативных компаниях не должны быть «подчиненными» управленцам, выступая в роли исполнителей. Право принятия решений не должно быть обусловлено лишь наличием полномочий, не подкрепленных компетенциями. Вообще, как только в такой компании побеждают менеджеры, бизнес начинает стагнировать, теряя клиентов, либо упрощается до уровня «чистых» управленцев, переходя на понятную им торговлю «ресурсами», о чем я подробно писал во второй главе. Любимое их выражение «Я не хочу знать, как вы это сделаете, но чтобы было готово к завтрашнему дню». Уважающие себя специалисты такого не терпят и уходят, а вместе с ними утрачивается способность компании создавать сложные продукты. В качестве примера можно вспомнить тех же Nokia или Disney до начала сотрудничества с Pixar.
Сейчас, когда бизнес строится не с использованием, а на основе цифровых инструментов, знание технологий окончательно перестает быть вспомогательной компетенцией. Вдумайтесь, если бизнес-модель компании невозможна без сложных технологических продуктов, возможно ли их создать и управлять ими без их понимания? Если вы что-то не понимаете, то для вас это превращается в магию. А там, где магия, там возможно и чудо, например, такое, чтобы за короткий срок и без четких требований разработать цифровой сервис, который начнет приносить прибыль. Но чудес, как известно, не бывает.
Именно поэтому «Метод параноика» рассматривает управление проектами не как отдельную активность, а как часть технологического процесса создания цифровых продуктов для бизнеса. Так появляется потребность в стиле управления, отличном от административного или директивного подхода. Как будет показано в следующей главе, эту задачу решает продюсерская модель в целом и роль проджект-раннера в частности.
Принимая во внимание факт, что проектируемые системы многоуровневые, и их компоненты связаны сложной логикой, такой подход исключает наличие плоского списка задач или «беклога», из которого разработчики последовательно берут задачи. Так же при таком подходе нет и менеджера проекта, занимающегося администрированием этого процесса. Если бы так работали, например, над космическими программами, вряд ли бы люди высадились на Луне. Или вы из тех, кто в это не верит?
Глядя на управление с такой точки зрения, мы возвращаем ему его истинное значение, и происходит это благодаря тому, что пропадает разделение решений на управленческие и технические. Все связано, и каждый вопрос рассматривается на своем уровне компетенции, абстракции и ответственности. В таком случае выбор участников проекта перестает быть организационной задачей, и становится вопросом проектирования команды. То же касается и остальных традиционно административных аспектов проекта, таких как учет целей бизнеса, определение бюджета и планирование.
По этой логике, если ключевой участник проекта, будучи специалистом в технических вопросах и отвечающий за определенную систему или подсистему в продукте, может координировать группу, то вы избегаете конфликта между управлением и компетенциями. Поэтому в «Методе параноика» нет менеджеров в привычном понимании, т. е. участников проекта, чья единственная задача – управление командой. Вместо этого управление происходит одновременно на разных уровнях: на самом верхнем уровне лидером выступает проджект-раннер, на всех остальных – ключевые участники проекта.
Конечно, я далек от иллюзий самоорганизации. Опыт показывает, что даже в группе из двух человек всегда есть тот, кто задает правила работы. Координация усилий для достижения целей проекта обязательно должна быть, но исходить она должна от людей, глубоко погруженных в то, чем они управляют. Выражаясь на системном жаргоне, можно сказать, что субъект должен понимать объект управления.
Общий состав проектной команды образует небольшие группы, сконцентрированные вокруг ключевых участников, что позволяет локализовать полномочия принятия решений на каждом уровне. У каждой группы есть цели, вытекающие из требований к их части системы. В результате у людей появляется пространство, где они могут ощутить себя полноправными хозяевами. Это чертовски важно для мотивации, ведь нет ничего хуже, чем когда твои усилия теряются на фоне большого коллектива.
Еще одним плюсом такого подхода является то, что локализация ответственности позволяет снизить силу воздействия закона Прайса. Закон гласит, что 50 % работы выполняется числом людей, равным квадратному корню из общего числа занятых в работе. Если говорить более конкретно, то в группе из трех человек половину работы делают двое, в группе из пяти – тоже двое! В команде из десяти человек половину работы выполнят трое. Представьте, какие цифры вы получите, например, для коллектива из пятидесяти человек! Поэтому, структурируя большую команду в виде небольших групп, мы не даем слабым игрокам спрятаться за спинами более сильных, и повышаем производительность всей команды.
Коммуникации между участниками
В отличие от фиксированных команд, где время остановилось и действуют установленные за долгий период работы негласные правила, разделяющие сферы влияния участников и определяющие порядок их действий, в гибких командах нет такого постоянства. Нужны другие исполнительные механизмы, способы коммуникации и инструменты накопления знаний о проекте и продукте. Настал момент с этим разобраться.
Я хочу начать с повторения идеи, что часть ключевых участников команды являются «несущей конструкцией» для создаваемого продукта, а часть – и тут внимание – для проекта. Это важно понимать, иначе может показаться, будто бы проект, выполняемый гибкой командой, сохраняет свои параметры сам по себе. Конечно, это не так, ведь, как уже было сказано, суть проектной работы – человеческое мышление, и каждый волен думать так, как он хочет. Поэтому нужны те, кто задает вектор и границы этого процесса. Одним из таких участников, неразрывно связанных с проектом на всем его протяжении, выступает проджект-раннер. Его задача, как и остальных аналогичных по своему значению людей в команде, – сохранение производственной культуры проекта и заложенных в самом начале принципов и целей, на которых строится цифровой продукт.
Однако не стоит рассматривать ключевых участников как хранителей информации о принятых в процессе проектирования и разработки решениях. У этого есть описанные выше ограничения и негативные последствия: уход любого участника проекта приводит к потере знаний о продукте, которые и без того фрагментарно распределены среди членов команды, что не позволяет системно работать с информацией при принятии решений.
Существуют более эффективные способы накопления и работы с информацией о создаваемом цифровом продукте. Поскольку гибкая команда все время обновляется, функцию сохранения знаний необходимо перенести с участников на более стабильную среду. Такой средой является модель продукта, или, говоря более точно, артефакты проектирования – спецификации, макеты, схемы и прочее. Что же здесь оригинального? Разве обычно так не поступают? К сожалению, нет, и на то есть причина.
В наши дни документирование рассматривается как избыточная задача. Основная претензия его противников в том, что помимо самой технической работы нужно потратить усилия на описание результата. При таком подходе, когда документирование выполняется постфактум и является формальной процедурой, объективно не существует причин выполнять его качественно. Получается замкнутый круг: документация не является объективной информацией о продукте, на которую можно рассчитывать, а значит, нет смысла ее читать, и как следствие, нет смысла тщательно подходить к ее подготовке.
«Метод параноика» меняет порядок и рассматривает документацию как описание не того, что уже сделано, а того, что только предстоит сделать. При таком подходе артефакты проектирования превращаются в модель будущего продукта и средство коммуникации между участниками проекта. При переводе описания решений из формальной процедуры в инструмент ежедневного использования петля работы с документацией получает положительное подтверждение. Как следствие, документация становится еще и местом накопления актуальной информации, которой доверяют.
Неважно, какие технологии для описания модели продукта вы будете использовать – классические UML-диаграммы, смесь текстовых спецификаций, алгоритмических схем и графических макетов интерфейса. Важно, какой у них жизненный цикл, и как они структурированы. Об этом будет подробнее рассказано в «Черной книге» метода. Сейчас я остановлюсь на принципиальных аспектах подхода.
Прежде всего проектная документация, а не списки задач или мессенджеры, должны быть основным средством общения между участниками. Звучит странно, но я покажу на примере, что это значит. Вам, наверно, знакомо выражение «живой документ», смысл которого в том, что схема, спецификация или макет интерфейса не рождается сразу в своем конечном состоянии, а видоизменяется в процессе работы, постепенно уточняется и наполняется необходимыми деталями. Документ служит пространством для общения, где с одной стороны предлагаются решения, а с другой – дается обратная связь. При таком взаимодействии проектировщиков и разработчиков легко отслеживать контекст обсуждения вопросов, чего трудно добиться в текстовом канале.
Мы в своей практике для подготовки спецификаций часто используем Google-документы. Например, проектировщик формирует документ, описывает решения для частей будущего продукта. У тех, кто будет участвовать непосредственно в реализации, есть возможность обсудить детали решения еще до их передачи в разработку, что часто позволяет найти более удачные решения или разобраться с непонятными моментами. Идея в том, что автор документа обладает полными правами на редактирование, а участники обсуждения могут только комментировать. Таким образом изменения в документ вносятся одним человеком, но по итогам общего обсуждения. То же может происходить в дальнейшем и на этапе разработки.