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

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

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

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

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

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

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

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

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

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