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

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

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

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

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

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

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

Управление гибкими командами

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

Я считаю, что в современном мире абсурдна сама мысль такого разделения, и более того, подобный подход и привел в результате к социально-экономическому кризису, который мы сейчас переживаем. Почему же это произошло только сейчас, не создав проблемы в прошлом? Все дело в сложности технологий, на которых базируется бизнес. Смотрите, до тех пор, пока уровень их сложности был относительно прост, знаний обычного человека хватало, чтобы в них разобраться. Административная иерархия совпадала с иерархией компетенций. Будучи руководителем, вы были способны как минимум разобраться в результатах работы своих подчиненных, а значит, принять решения на их основе.