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

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

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

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

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

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

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

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