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