Когда требования — из головы, а не от пользователей
Друг рассказал про работу продактов в одной очень большой организации, у которой очень много денег и мало компетенции.
У них есть отдел продуктологов, которые замотивированы на "защиту" предложений по продуктам. Они что-то там придумывают, получают одобрение от руководства, пишут ТЗ, передают его подрядчику, и на этом их работа заканчивается.
Что получается на выходе?
Дорогой продукт, которым никто не пользуется.
Почему так получается?
У них нет мотивации принести пользу пользователям. Они даже не разговаривают с пользователями, они придумывают требования сами из головы, хотя при этом не являются экспертами. К тому времени, когда разработка закончена, продуктолога, защитившего предложение, уже может и не быть в организации.
Самый (для меня) прикол ещё в том, что у них есть свободный доступ к пользователям и экспертам. Продукт практически внутренний, то есть требования можно синтезировать достаточно легко, поговорив с ~50 пользователями за месяц-два.
Короче, дисфункция продуктовой команды 80-й уровень.
Корень проблемы лежит в двух составляющих:
-
Неправильная мотивация — система бонусов и продвижений должна быть выстроена таким образом, чтобы продакт получал плюшки, когда достигнуты KPI, ради которых продукт изначально создаётся. Тогда они будут работать долго и париться о качестве.
-
Классический водопадный подход — даже если работаешь с подрядчиками, перекидывать им через забор ТЗ и умывать руки - это практически 100% гарантия, что на выходе будет продукт, не удовлетворяющий "скрытым" требованиям, которые выявляются только когда пользователи начинают пользоваться продуктом.
Любые требования по умолчанию являются неполными и нужно планировать исходя из этой правды жизни. В идеале, даже при работе с подрядчиками, должен быть выстроен около-аджайльный процесс, в котором сотрудники подрядчика не просто какая-то сторонняя организация, а часть твоей команды. Ты арендуешь людей на время проекта, платишь им по часам, весь HR и гемор на аутсорсе, а руководство проектом — на тебе (заказчике).
В такой системе может быть выстроен процесс agile и организовано тестирование с альфа и бета пользователями на ранних этапах, что позволяет выявлять скрытые требования раньше и создавать более качественный продукт.