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

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

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

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

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

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

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

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

Выбор участников гибких команд