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

4 центра силы

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

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

В связке с методологами работают операционные владельцы процесса — профессиональные пользователи, которые обеспечивают фактическое применение подходов на местах. В данном случае это сотрудники C&B соответствующих бизнес-единиц, отвечающие за переменную часть вознаграждения. Их задача — приземлить методологию на практику с учетом специфики бизнеса и потребностей внутренних клиентов: руководителей и сотрудников. Именно результат этого «приземления» во многом определит, каким получится итоговый процесс.

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

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

Так кто здесь главный?

Product Owner. Но не как «самый важный», а как тот, кто должен обеспечить баланс между всеми группами интересантов. Это не человек, который просто синхронизирует стейкхолдеров, собирает требования, а потом ведет backlog и проводит demo. Это роль интегральной ответственности за продукт. Именно за продукт как целое, а не за накопившийся вокруг него хаос. Для этого Product Owner нужны и полномочия, и внутренняя готовность взять ответственность за их применение. Готовность отвечать не только за процесс, но и за результат. Хороший Product Owner при этом не должен быть самоуверенным. Он должен уметь собирать интересы разных сторон, слышать аргументы, понимать ограничения и фасилитировать сложные обсуждения. Но этим его работа не заканчивается. Дальше он должен переработать всё это в продуктовую логику, принять решение и в некоторых случаях стать для своих стейкхолдеров даже не посредником, а ментором — человеком, который помогает увидеть, что полезно не только локально, но и для продукта в целом.

Именно поэтому он и главный.

И чтобы он не делал, с него всё равно в итоге спросят за всё. Поэтому лучше потратить это время на создание хорошего продукта, а не на поиск причин, почему он не удался.