Когда требования — из головы, а не от пользователей

3 сентября 2024 г.

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

У них есть отдел продуктологов, которые замотивированы на "защиту" предложений по продуктам. Они что-то там придумывают, получают одобрение от руководства, пишут ТЗ, передают его подрядчику, и на этом их работа заканчивается.

Что получается на выходе?

Дорогой продукт, которым никто не пользуется.

Почему так получается?

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

Самый (для меня) прикол ещё в том, что у них есть свободный доступ к пользователям и экспертам. Продукт практически внутренний, то есть требования можно синтезировать достаточно легко, поговорив с ~50 пользователями за месяц-два.

Короче, дисфункция продуктовой команды 80-й уровень.

Корень проблемы лежит в двух составляющих:

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

  2. Классический водопадный подход — даже если работаешь с подрядчиками, перекидывать им через забор ТЗ и умывать руки - это практически 100% гарантия, что на выходе будет продукт, не удовлетворяющий "скрытым" требованиям, которые выявляются только когда пользователи начинают пользоваться продуктом.

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

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