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

Некоторые факапы я допустил ещё до перехода в Яндекс.Деньги. Сегодня я расскажу, как в одной сибирской компании мы потеряли сильного ПМ из-за взаимных недопониманий того, что на самом деле нужно бизнесу. Вторая история будет о том, как важно объяснять команде, что продукт нужен рынку, и как вместе с этим приходят скорость, эффективность и слаженная работа всех участников процесса. А ещё немного о том, как такие вещи работают в Яндекс.Деньгах.


От редактора: этот текст — результат доклада Дмитрия Волкова на митапе «Пиэмная» 28 февраля 2019 г. Мнение редакции по некоторым вопросам может не совпадать со мнением автора.


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


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


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


Однажды мы провели коридорные тесты, пообщались с фокус-группой и вдруг поняли, что возможность добавления даты выпуска паспорта – не самая очевидная штука для пользователей. Мы попросили команду выпилить связку со стандартным календарем в Android и реализовать фичу с помощью простого барабана для выбора чисел, дат и месяцев года.


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


Однако проблема вскрылась довольно быстро. Всё дело было в предельно простой, легкой и непринужденной позиции бизнеса: «Я сказал — надо, поэтому делайте». И это вызывало внутренний конфликт у проджекта в решении сделать какую-то фичу, которую мы предлагаем.


image


У бизнеса такая формулировка сложилась исторически. Я понимаю, что с точки зрения продукта она не верна, но рост большой компании на 3500 человек был завязан на планах, квартальных проектах и финансовых показателях. Поэтому всё, что касалось денег, вызывало одну реакцию: «Надо делать». И каждый раз, когда нам задавали вопрос: «Зачем мы реализуем эту фичу?», – наш с коллегой ответ был одинаковым: «Просто потому что надо, потому что ради денег». Весь наш бизнес был ради денег. Отправка денежных переводов – это и есть про деньги. От денег зависело всё — наши заработные платы, бонусы и плюшки на кофепоинтах.


В какой-то момент все ссорились со всеми. Тестировщики ссорились с разработчиками, тестировщики ссорились с админами, админы ссорились с нами, потому что у них что-то не работало, мы на них наезжали, но это опять не работало, мы опять наезжали. Творился полнейший бедлам. Было непонятно, что делать, и для решения конфликта нам пришлось привлечь команду HR и технического директора компании. Через некоторое время мы решили, что команду надо распускать.


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


image


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


Про коммуникации и отношения


image


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


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


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


image


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

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


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


image


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


Надо сказать, что мы работали со сложной аудиторией. Тогда это были трудовые мигранты, выходцы из Средней Азии, что очень сильно накладывало свой отпечаток на пользовательские сценарии. Непосредственное участие команды в процессах, которые проходит пользователь, помогло понять, что нам не хватает отображения пользовательских персон и создания Customer Journey Map, и мы всё это сделали.


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


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


image


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


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


Вообще разработчики не очень любят говорить что-нибудь о себе или о продукте, кроме разных странных слов, которые я пока не очень хорошо понимаю и за все это время не выучил, про код и много чего еще. Каждый разработчик хочет сделать качественный продукт и поделиться своим мнением, но многие боятся, что их не услышат. Если вы и ваш продакт будете открыты с командой (вы с продуктом), то люди будут рассказывать вам всё как на духу, и это тоже повлияет на развитие вашего проекта.


image


Команды в Яндекс.Деньгах тоже работают так. Тесная связка проджекта и продакта позволяет нам развиваться сильно быстрее, чем раньше — мы регулярно чистим бэклог, удаляя морально устаревшие задачи, которые у нас могут быть, грумим, временами оценивая наши задачи в майках и сторипоинтах для того, чтобы облегчить время и ускорить процессы на планирование. Мы общаемся с нашей командой и рассказываем о том, как пользователь ведет себя на каждом из этапов CJM, что происходит в отчетах с цифрами и метриками.


В заключение могу сказать, что если ваш продакт не делится тем, что происходит на рынке или в вашем продукте, то самое время попросить его сделать это. Как только вы рассказываете команде, что именно делаете и почему, вовлеченность всех участников сильно возрастает. Проверено на практике.


image




Сюрприз для тех, кто дочитал — в этом посте спрятан промокод на приятный бонус от Яндекс.Денег. Его получит тот, кто первым найдёт и активирует.


UPD 10:20 Первый промокод был между строк до ката. Его активировали за 17 минут.


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


Текст подготовили:
Автор — Дмитрий Волков.
Редакторы — Евгений Шкляр, Денис Вонсаровский.

Комментарии (13)


  1. brick_btv
    07.05.2019 10:20

    Если сотрудник сопротивляется каждому изменению, то, вероятно, от перевода на другой проект ничего не изменится.

    PS: по промокоду был полтинник, не расстраивайтесь


    1. Fox_exe
      07.05.2019 10:28

      А, так он одноразовый?
      А я тут форму мучию — не могу понять, чего ему не нравится (Там нолик или буква «О»?)


      1. evil_me Автор
        07.05.2019 10:32

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


        А вот форма ни в чем не виновата :)


      1. brick_btv
        07.05.2019 10:33

        буква «О», шрифт похож на consolas, там ноль перечёркнутый


  1. bvn13
    07.05.2019 10:26
    -1

    У вас не работает сервис перевода гифтов в деньги. И теперь:

    Вернитесь завтра
    Слишком много попыток на сегодня. Попробуйте ещё раз завтра.


    мда.


  1. Manguss
    07.05.2019 10:33

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


  1. vassabi
    07.05.2019 11:31

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


  1. triton
    07.05.2019 11:38

    Сюрприз для тех, кто дочитал — в этом посте спрятан промокод

    Главное не переборщить со стимуляцией!

    «В нескольких футах от входа дымился небольшой ростбиф, рядом
    красовались четыре крупных бриллианта и бутылка виски.

    Теперь он знал, в чем допустил ошибку. Он излишнего рвения он
    переборщил с наживкой.»
    (с) Роберт Шекли. Охота


  1. kapash
    07.05.2019 13:07

    опять это слово «факап» в заголовке


  1. InChaos
    07.05.2019 14:27

    и теперь каждая фича записывалась в бэклог на основе четырех вопросов: зачем, для кого, как и что.

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


    1. kapash
      07.05.2019 17:15
      -1

      И если бизнес не может объяснить для чего нужна фича, то надо донести до бизнеса, что он сам тратит свои деньги

      2-3 дня работы программиста в деньгах это такая пыль для бизнеса…


      1. InChaos
        08.05.2019 09:41

        Стоп, статья не об одном программисте, а о команде где даже ПМ есть. И предположить что на команду из ПМ + 5-6 программеров — это минимум лям в месяц. То 2-3 дня из рабочих 22, это извините 100 тыс. И каждый раз делая плюшки которые бизнесу не нужны, уже через 5 таких плюшек потеряли полляма. Многие крупные конторы за 5-10 тыс бюджета ИТ удавятся.


        1. kapash
          08.05.2019 11:24

          То 2-3 дня из рабочих 22, это извините 100 тыс
          Да хоть 200 тысяч. Эти деньги премией кто-то из программистов получит? — Нет. А если эти часы\цифры можно продать\перевыставить заказчику внутреннему или внешнему — так вообще красота. Ну а если за рамки бюджета проекта вылезли — то тут вопрос к тому, кто этот бюджет делал.

          И каждый раз делая плюшки которые бизнесу не нужны, уже через 5 таких плюшек потеряли полляма.

          а ЗП все получили, что не так то? Зачем считать чужие деньги? Все считают свою личную прибыль и пытаются увеличить только её, ну или не пытаются. Остальное лишь инструменты достижения этой цели.

          Многие крупные конторы за 5-10 тыс бюджета ИТ удавятся.

          Следить за бюджетами и экономить «на спичках» — это задача СЕО, CIO, CDO… но никак не проектной команды. Про бюджет проекта писал выше.