Виноват ли Продакт в том, что команда делает х**ню?

Обычно пишу о том, какая я молодец и как все здорово, но сегодня хочу поговорить о темной стороне. Есть у меня проблема. Бывает, что от идеи новой фичи до конечной реализации что-то происходит и она перестает решать первоначальную задачу. Магия из разряда «…за время пути собака могла подрасти».

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

Head of sales говорит «Мне нужны вкладки в админке». «Зачем тебе вкладки?», - спрашивает Продакт. «Чтобы разделить заявки по статусам». Продакт, который не очень-то любит вкладки, т.к. это еще один уровень навигации, выражает скептицизм. Head of sales говорит «Норм, мы так работали в прошлой компании – было круто». Ок, вроде работы немного, проект – внутренний, да и вообще продажникам виднее, как им работать – хотят разделить заявки, пусть делят. Продакт берет задачку в спринт и расписывает для программистов, что и как нужно разделить.

На обсуждении спринта программисты говорят «Давай вместо вкладок прикрутим фильтр, который у нас уже есть – результат будет тот же, продажники смогут фильтровать заявки по статусам, а разработка займет 2 часа вместо 8-ми». Отлично, так и делаем, все довольны, задача решена.

Фича выходит в продакшен, Head of sales видит фильтр вместо вкладок и недоумевает:

– Че за фигня, где вкладки? О_о
– Зачем вкладки, чем тебя не устраивает фильтр?
– Да блин, ничем не устраивает. Проблема в том, что когда менеджер приходит утром на работу – он видит длинный список заявок, которые надо обработать. Заявки свалены в кучу, и ему надо выбирать, на чем сфокусироваться. Менеджер пропускает важные заявки и тратит время на менее приоритетные. Плюс, список ощущается бесконечным и у менеджера никогда нет ощущения, что он хоть что-то закончил. Это демотивирует. Фильтр проблемы не решает.

Ага, вот оно что! Идем переделывать. Head of sales считает, что мы – идиоты, программисты демотивированы :(

Потому, что изначально не было раскопано, в чем собственно, проблема и команда ориентировалась на неправильную цель. Надо было еще пару раз спросить «Зачем?» или хотя бы сходить к Head of sales перед запуском задачи в разработку и проговорить с ним альтернативное решение с фильтром.

Почему этого не сделали? Причин множество:

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

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

Продакт приходит к программистам с проработанной фичей, т.е. описанием, что надо сделать и как это должно работать. Если нужен дизайн, то и с дизайном.

Программисты кивают головой, начинают реализовывать и по дороге выясняется, что в одном из кейсов так, как хочет Продакт сделать нельзя или сложно. В этот момент либо программисты сами принимают решение срезать угол, либо зовут Продакта и говорят ему «Смотри, если сделать так, как написано – это займет 3 недели, а если так, как мы предлагаем – пол-дня. Как нам быть?».

Надо решить да или нет. Казалось бы ну а че сложного-то? Предложенное решение либо согласуется с постановкой, либо нет. Но! Именно в этот момент первоначальная цель – зачем мы затеяли фичу – куда-то ускользает, и ты скатываешься до обсуждения реализаций и принимаешь неправильное решение. Это как пошел в магазин за хлебом, а вернулся с ящиком мороженого потому, что оптом дешевле.

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

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

Пример

Добавляем новые фильтры на лендинг. Я говорю «Ребята, фильтры надо протестировать. Можем сделать А/Б тест с двумя вариантами – один с новыми фильтрами, другой без?». Мне отвечают «Да, конечно, можем решить это через get-параметры».

Я в полной уверенности, что все ОК, даю добро. А оказывается, что меня поняли неправильно. Я хочу протестировать конверсию лендинга с фильтрами и конверсию лендинга без фильтров (т.е. добавить параметр в URL при заходе на страницу), а ребята поняли, что надо протестировать, кто взаимодействует с фильтром, а кто - нет, и добавляют параметр в момент жмакания на фильтр.

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

По субъективным ощущениям – работает, хотя и не всегда. Формальных замеров не делала, так что точно сказать не могу.

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

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

Уф... Ребят, расскажите, как вы с этим справляетесь?