Меня зовут Дмитрий Волков. За время работы менеджером продуктов у меня накопилось много историй о победах и провалах, как правильно выстраивать коммуникацию между разработкой и бизнесом, и чего делать ни в коем случае нельзя. Сегодня я расскажу две таких истории.
Некоторые факапы я допустил ещё до перехода в Яндекс.Деньги. Сегодня я расскажу, как в одной сибирской компании мы потеряли сильного ПМ из-за взаимных недопониманий того, что на самом деле нужно бизнесу. Вторая история будет о том, как важно объяснять команде, что продукт нужен рынку, и как вместе с этим приходят скорость, эффективность и слаженная работа всех участников процесса. А ещё немного о том, как такие вещи работают в Яндекс.Деньгах.
От редактора: этот текст — результат доклада Дмитрия Волкова на митапе «Пиэмная» 28 февраля 2019 г. Мнение редакции по некоторым вопросам может не совпадать со мнением автора.
Пару лет назад я сменил своё небольшое дело на работу в большом сибирском энтерпрайзе, где строил сервис для денежных переводов онлайн. В тот момент я работал с пятью командами, в каждой из них был свой менеджер проекта, и это сильно мне помогало, потому что тогда мне было достаточно сложно общаться со всеми этими братьями-интровертами. Одну из команд собрали недавно и назначили туда ПМ с очень сильным бэкграундом. До этого она несколько лет работала аналитиком в большом банке, и для финансового продукта сложно было найти кого-то более подходящего.
Надо сказать, что эта ПМ действительно была ограненным алмазом — тверда в своих решениях и суждениях и подходила нам чуть более, чем полностью. В тот момент нам казалось, что мы жили по Agile, поэтому постоянно устраивали планирования, груминги, ретроспективы, и практически на каждой встрече ПМ давила авторитетом, своим суждением и пыталась доминировать над командой и над продактами.
Она подвергала сомнению всё — что эту фичу можно реализовать в архитектуре нашего продукта, оспаривала оценки команды и сомневалась в адекватности других продактов. Временами такое несогласие доходило до саботажа работы компании. Как это проявлялось?
Однажды мы провели коридорные тесты, пообщались с фокус-группой и вдруг поняли, что возможность добавления даты выпуска паспорта – не самая очевидная штука для пользователей. Мы попросили команду выпилить связку со стандартным календарем в Android и реализовать фичу с помощью простого барабана для выбора чисел, дат и месяцев года.
Но PM посчитала нашу идею абсурдной. Она была не согласна, что ерундой, которую мы сейчас предлагаем, вообще стоит заниматься. В тот момент я понял, что у нас не получается взаимодействовать — непонятно, что мы делаем, зачем и как учитываются интересы клиентов.
Однако проблема вскрылась довольно быстро. Всё дело было в предельно простой, легкой и непринужденной позиции бизнеса: «Я сказал — надо, поэтому делайте». И это вызывало внутренний конфликт у проджекта в решении сделать какую-то фичу, которую мы предлагаем.
У бизнеса такая формулировка сложилась исторически. Я понимаю, что с точки зрения продукта она не верна, но рост большой компании на 3500 человек был завязан на планах, квартальных проектах и финансовых показателях. Поэтому всё, что касалось денег, вызывало одну реакцию: «Надо делать». И каждый раз, когда нам задавали вопрос: «Зачем мы реализуем эту фичу?», – наш с коллегой ответ был одинаковым: «Просто потому что надо, потому что ради денег». Весь наш бизнес был ради денег. Отправка денежных переводов – это и есть про деньги. От денег зависело всё — наши заработные платы, бонусы и плюшки на кофепоинтах.
В какой-то момент все ссорились со всеми. Тестировщики ссорились с разработчиками, тестировщики ссорились с админами, админы ссорились с нами, потому что у них что-то не работало, мы на них наезжали, но это опять не работало, мы опять наезжали. Творился полнейший бедлам. Было непонятно, что делать, и для решения конфликта нам пришлось привлечь команду HR и технического директора компании. Через некоторое время мы решили, что команду надо распускать.
Мне было чертовски стыдно, но решение было принято – мы распустили команду, распределили коллег по оставшимся командам. Проджекту предложили перейти в другой продукт, который не был связан с денежными переводами, чтобы не пересекаться больше с такими молодцами, как я. Она, к сожалению, восприняла эту ситуацию очень близко к сердцу и уволилась в тот же день.
Так из-за некачественно выстроенных коммуникаций, а по большому счету из-за моих ошибок мы потеряли довольно сильного игрока в нашей команде, который мог принести огромную пользу компании, но не смог, потому что был исключен из наших рядов. С тех пор я не забываю о том, что концентрация на целях может привести к дичайшему факапу и развалить команду. И если такая ситуация сложится ещё раз, то я буду более подготовленным к решению такого конфликта.
Про коммуникации и отношения
Другой кейс, о котором я хочу рассказать, тоже про коммуникации и отношения, но про более высокие отношения, скорее даже про любовь.
Как только в голове складывается четкая картина того, что происходит в команде, это значит, что я что-то упускаю из вида. И чтобы больше не совершать факапов, подобных предыдущему, я всего лишь должен общаться со всей командой, с каждым по отдельности, и доносить до каждого те бизнес-ценности, которые мы преследуем, доносить их с такой тщательностью, как мы это делаем для наших клиентов.
У нас было десять команд из разных городов, и я старался участвовать почти во всех активностях, которые были с ними связаны. Я посещал все встречи и стендапы и рассказывал о том, как реализация той или иной фичи отразилась на доходности компании. Я рассказывал людям о цифрах, графиках, об изменениях с точки зрения роста или падения количества пользователей, показывал результаты аналитических отчетов. Ещё я рассказывал о факапах — как внедрение новых функций не приносило ожидаемого результата. Было важно открыто признавать ошибки бизнеса в расстановке приоритетов, что тоже было важно для того, чтобы команда начала доверять мне и второму менеджеру, который занимался этим продуктом.
Каждая команда была вовлечена в процесс обсуждения функций продукта на основе импактов, ценности и важности для клиента и компании. При этом мы почти полностью пересмотрели процесс постановки задачи в бэклоге, и теперь каждая фича записывалась в бэклог на основе четырех вопросов: зачем, для кого, как и что. Обычные импакты, которые описаны в книге Гойко Аджича. Это дало возможность вовлечь участников во все происходящие процессы, и все команды стали внимательнее относиться к тому, что они пилят, и к нашим требованиям. Но менялись не только мы. Для команд теперь стало абсолютно неправильным отмалчиваться либо прийти к нам и сказать, что наши идеи или сами мы отстой, поэтому делать мы это не будем. Появилась необходимость объяснить, почему мы не должны делать какую-то фичу или почему хотим делать что-то другое. Вдобавок командам предложили не только писать код, но и начать пользоваться этим продуктом самостоятельно. Поэтому мы провели эксперимент — каждый разработчик должен был выйти из уютного офиса, дойти до банка, пройти вообще все круги ада и печали, в итоге сделать денежный перевод, но понять, что чувствуют наши пользователи на каждом этапе. Надо сказать, что мы работали со сложной аудиторией. Тогда это были трудовые мигранты, выходцы из Средней Азии, что очень сильно накладывало свой отпечаток на пользовательские сценарии. Непосредственное участие команды в процессах, которые проходит пользователь, помогло понять, что нам не хватает отображения пользовательских персон и создания Customer Journey Map, и мы всё это сделали. А потом удивились, когда команды начали приходить со множеством новых идей и предложений. Они хотели рассказать о том, как им было неуютно в какой-то момент или, наоборот, как хорошо были сделаны уведомления, что денежный перевод успешно получен, и так далее. Они несли массу идей для нас и каждый раз улучшали наш продукт сами. Поэтому если вы понимаете, что менеджер продукта, с которым вы работаете ежедневно – из молчунов, из тех, кто не любит рассказывать о бизнесе, который вы делаете вместе с ним, то берите его за руку и ведите в темную комнату. Расскажите ему там всей командой, как распространение информации поможет каждому из вас быть полностью вовлеченным в процесс разработки. Расскажите ему о том, что необходимо пилить не только фичи, которые он хочет, что необходимо дорабатывать и legacy код, исправлять старые осколки костылей, потому что иногда исправление и таких задач открывает нам свои потоки полностью. Говорите открыто и с ним, и с командой о том, что происходит с вашим продуктом. Попросите его приходить на каждый стендап вашей команды и каждый раз рассказывать о том, чего удалось достичь за предыдущий день. Пусть он показывает цифры из аналитических отчетов, результаты фокус-групп и так далее. Это однозначно поможет и ему увидеть проблематику более широко, потому что ваши коллеги наверняка готовы делиться своим мнением с ним, но сейчас они ему не доверяют. Вообще разработчики не очень любят говорить что-нибудь о себе или о продукте, кроме разных странных слов, которые я пока не очень хорошо понимаю и за все это время не выучил, про код и много чего еще. Каждый разработчик хочет сделать качественный продукт и поделиться своим мнением, но многие боятся, что их не услышат. Если вы и ваш продакт будете открыты с командой (вы с продуктом), то люди будут рассказывать вам всё как на духу, и это тоже повлияет на развитие вашего проекта. Команды в Яндекс.Деньгах тоже работают так. Тесная связка проджекта и продакта позволяет нам развиваться сильно быстрее, чем раньше — мы регулярно чистим бэклог, удаляя морально устаревшие задачи, которые у нас могут быть, грумим, временами оценивая наши задачи в майках и сторипоинтах для того, чтобы облегчить время и ускорить процессы на планирование. Мы общаемся с нашей командой и рассказываем о том, как пользователь ведет себя на каждом из этапов CJM, что происходит в отчетах с цифрами и метриками. В заключение могу сказать, что если ваш продакт не делится тем, что происходит на рынке или в вашем продукте, то самое время попросить его сделать это. Как только вы рассказываете команде, что именно делаете и почему, вовлеченность всех участников сильно возрастает. Проверено на практике. UPD 10:20 Первый промокод был между строк до ката. Его активировали за 17 минут. А если вы не успели, то не расстраивайтесь — в следующих постах промокоды тоже будут. Подпишитесь на наш блог, чтобы всех обогнать в следующий раз. Текст подготовили:
Сюрприз для тех, кто дочитал — в этом посте спрятан промокод на приятный бонус от Яндекс.Денег. Его получит тот, кто первым найдёт и активирует.
Автор — Дмитрий Волков.
Редакторы — Евгений Шкляр, Денис Вонсаровский.
