Материал входит в серию статей о build vs buy в HRTech.

Для меня в словосочетании «продуктовая команда» главное — именно команда. Мне повезло попасть в такую среду ещё до того, как продуктовый подход стал мейнстримом и оброс каноническим словарём. Формально это была проектная команда. По сути — продуктовая. При этом к этим принципам она пришла сама, скорее интуитивно.

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

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

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

У нас была и автономия — не декоративная, а рабочая. Значимую часть решений по системе мы принимали сами. Мы не существовали в логике простого исполнения внешних требований. Мы сами должны были понимать, что действительно стоит делать. Автономия в такой команде — не привилегия, а форма ответственности за результат.

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

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

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

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

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

Читайте полную версию https://dzen.ru/a/ae-ooaiLEzJN5gYz