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

Цель гибких проектных команд – избежать «проклятия инструмента» и обеспечить проект нужными специалистами для создания конкретного цифрового продукта, в те моменты, когда это необходимо. Давайте разберемся, что это за «проклятие». Когда у вас в наличии несколько инструментов, вы не можете избежать искушения воспользоваться каждым из них, независимо от того, требует того задача или нет. Возможно, вы помните момент в сериале «Клиника», когда уборщик носил с собой электрический резак в поисках повода его применить весь эпизод, чтобы в конце распилить новый стол доктора Келсо! То же происходит, когда на момент запуска проекта у вас уже сформирована команда. Так бывает, когда одни и те же специалисты переключаются с одного проекта на другой. В результате у вас еще нет понимания кто из них нужен, но состав команды уже определяет образ будущего продукта. Это сработавшийся механизм с выработанными подходами, предпочтениями в технологиях и методами решения задач. У вас, кажется, были другие цели, но вы ведь не позволите простаивать каждому из участников, так?

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

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

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

«Метод параноика» предлагает подход, при котором проектирование используется для определения требований к участникам проектной команды. Суть идеи в том, что по мере создания модели продукта становится понятно, какие специалисты потребуются для его реализации. Поскольку проектирование охватывает все стадии проекта от первоначальной концепции до запуска продукта, то и определение требований к команде происходит на всем его протяжении. В главе о принципе проектирования говорилось, что все решения в проекте должны быть связаны. Это касается и выбора специалистов, требования к которым относятся к организационному уровню. На каждой контрольной точке в проекте мы делаем следующий шаг и определяем обновленный состав его участников. Таким образом, принцип гибких команд неразрывно связан с принципом проектирования.

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