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