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

Product vs Project

Для систем управления эффективностью свойственен определённый парадокс.

С одной стороны — большой объём обязательной и в целом понятной функциональности: начиная с интеграции с HR-системой для получения данных по оргструктуре, перемещениям и руководителям, типу и размеру бонуса, атрибутам должности и т.п. и заканчивая движком согласования целей и результатов оценки. Для этого больше подходит проектный подход.

С другой стороны — большая доля неопределённости и нежелание просто оцифровать excel-табличку с целями, а стремление построить новый цифровой процесс. Здесь уже предпочтительнее продуктовый подход.

Моё мнение: сделать такое решение по-настоящему классным только в рамках проекта будет сложно. Слишком много времени уйдёт на проектирование, и слишком высок будет риск ошибки: заложенный механизм на практике может оказаться неудобным или успеть устареть за время реализации под ключ в первоначальном виде.

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

К тому же у вас как у Product Owner будет больше полномочий для выстраивания процесса, чем у Project Manager — если говорить о классическом распределении ролей, а не о корпоративном новоязе, где названия должностей часто живут своей жизнью и могут означать что угодно.

Buy vs Build

Понятно, что давать такие рекомендации, не зная контекста конкретной компании, не очень профессионально, но я попробую.

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

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

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

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

Отдельно стоит упомянуть фактор масштаба. Такие решения обычно лицензируются по модели PEPM — Per Employee Per Month. Поэтому чем больше сотрудников, эффективностью которых вы планируете управлять, тем выше вероятность, что собственная разработка окажется экономически привлекательнее. Конечно, при условии, что компания готова к такому подходу — причём не только tech-команда, но и HR-функция, и бизнес в целом.

Развилка

Мой базовый ответ такой: buy & project — если нужно быстро закрыть потребность и запустить стандартный процесс. Build & product — если управление эффективностью должно стать частью управленческого преимущества компании, а путь сотрудника и руководителя должен быть точно выстроен под вашу модель управления.

В моём кейсе с учётом предстоящих задач, масштаба компании и контекста выбор был однозначен: build & product. Поэтому дальнейший опыт — а значит, и рассказ о нём — во многом был определён именно этим решением.