9 (не)идеальных product owner и как с ними работать. Из нашей практики.

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

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

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

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

Product Owner: введение

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

Можно долго рассуждать, каким он должен быть, а каким нет, но здесь главное одно — от действий владельца продукта напрямую зависит… всё :)

Рассмотрим ситуации, когда product owner так или иначе стопорил разработку и как мы решали те или иные вопросы.

Портрет 1 Вот вам задача, действуйте!

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

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

Портрет 2 Видите суслика? А он есть

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

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

Нашему проектному менеджеру приходилось постоянно напоминать о себе, о команде, о своих вопросах: еще одним письмом либо прямым обращением в мессенджере, что также мало чем спасало ситуацию. В лучшем случае владелец продукта отвечал: «Да-да, сегодня вы получите свои ответы». Немного драмы добавляла и разница часовых поясов: поскольку команда Заказчика находилась в США, то и «сегодня» автоматически превращалось в «завтра». Конечно, у нас случались совещания, но к тому моменту список вопросов становился таким огромным, что обсудить все было просто невозможно.

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

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

Выход 2 Делегирование. Надо сказать, общая загруженность на проекте довольно распространенное явление. И в схожей ситуации другой владелец продукта, с которым мы сотрудничали, принял решение делегировать часть своих обязанностей подчиненному. И это тоже неплохой вариант, кроме одного но — отсутствие у заместителя соответствующих полномочий (а где-то опыта, ведь на то он и зам, чтобы где-то в чем-то учиться у своего руководства) для принятия критически важных решений. Тем не менее, такой ход помог существенно снизить напряжение команды в процессе разработки: большинство вопросов решалось довольно оперативно, фичи кларифайлились, баги фиксились — и караван шел. А что еще нужно для счастья?..

Портрет 3 Хронический опоздун

Или вот похожая ситуация. Что если ваш product owner прекрасен спору нет: и общее видение проекта предоставляет, и всегда готов детализировать и приоритизировать задачи, и для диалога открыт, но… Давайте уже просыпаться и думать, что делать, если владелец продукта регулярно опаздывает на совещания, как, например, один из наших партнеров. Причин его бесконечных задержек было предостаточно и, надо признать, большая их часть была объективной. Так, нередкими были форс-мажорные обстоятельства, когда человек банально задерживался на каких-то предыдущих митингах, на которых тоже нужно было срочно дела делать. Что, тем не менее, не скрашивало нам ожидание.

Выход: В целом ситуация не была критичной. Всегда можно было сдвинуть что-то в расписании. Ну, и составление программы встречи (meeting agenda) сильно облегчало наше взаимодействие. Плюс какие-то вопросы мы могли обсудить в течение 20 минут ожидания и предоставить уже итоговый вариант.

Портрет 4 А вы точно работу работаете? А если проверить?

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

Выход: Чтобы ускорить этот процесс, с одним заказчиком нам пришлось релизиться по чуть-чуть каждую неделю: и ему спокойнее, и нам несложно. В другом случае очень помогла командировка в головной офис клиента. Сперва product owner еще поработал немного в режиме учительницы младших классов: прохаживаясь мимо наших ребят, пытался заглянуть в мониторы и убедиться в том, что они заняты дело. Но пара дней непрерывного общения и совместного хардворка сделали свое дело — и к вопросам доверия мы больше не возвращались.

Портрет 5 Я технически подкован и хочу за всем следить лично

Ни для кого не секрет, что грамотный владелец продукта должен разбираться в технической составляющей проекта. В идеале даже приветствуется его предыдущий опыт в разработке. Тем не менее основополагающим принципом работы любой команды есть разделение обязанностей. Грубо говоря, кодер кодит, бизнес аналитик анализирует, проектный менеджер управляет, а product owner… владеет :) Вас не должно смущать, что какие-то технические аспекты вам не по зубам, это ведь попросту не ваша часть Марлезонского балета.

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

Выход: В той ситуации мы, конечно, предоставили владельцу продукта доступ. Но. Вскоре после этого последовала череда вопросов «А это что?», «А это как работает?», «А здесь куда нажимать?», потому что база была довольно сложно устроена, в таблицах было огромное количество значений и, понятное дело, работать с ней было затруднительно без определенного бэкграунда.

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

Портрет 6 А вот мне так нравится

Иногда грань между объективными факторами, влияющими на развитие продукта, и субъективными предпочтениями заказчика размывается. Один product owner, с которым мы сотрудничали, был отличным специалистом — и хорошо описывал фичи, и давай четкие и подробные комментарии, и быстро реагировал на наши запросы. Но было одно но, которое серьезно мешало эффективности реализации задуманного плана: постепенно все фичи стали подстраиваться под вкусы и предпочтения конкретного человека, а не с учетом совместно выработанной и утвержденной стратегии реализации проекта. От него все чаще можно было услышать фразы типа «Вот мне здесь что-то неудобно», «А вот тут я бы хотел…», «А вот это мне как-то не нравится…»

Выход: Конечно, ваш проект — это ваше дитя и всегда хочется, чтобы он был именно таким, каким вы его представляете. Однако стоит учитывать мнение и других участников «воспитательного процесса». Согласитесь, если вашему ребенку удобнее из пункта А в пункт Б добраться не на самокате, а на велосипеде, при этом шлем у него на голове будет не синего, а красного цвета, а еще, возможно, стоит включить в маршрут пару остановок для повышение его выносливости (а это не учитывая того, что он, возможно, вообще не хочет идти по отцовским следам, а мечтает о балетных подмостках)… В общем, без командной работы здесь никак.

В случае с упомянутым выше владельцем продукта — через некоторое время Заказчик был вынужден делегировать эти полномочия более объективному кандидату.

Портрет 7 Поди туда — не знаю куда, принеси то — не знаю что

Бывает такая ситуация, что заказчик сам не может четко представить, как будет функционировать его система. В таких случаях на команду разработки возлагаются дополнительные чаяния — сформулировать четкую концепцию и стратегию ее реализации. Что совсем неплохо для компетентных специалистов. Но только в том случае, если клиент готов принять чужое видение проблемы.

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

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

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

Портрет 8 Моя твоя не понимать

Любая компания, работающая на аутсорс, рано или поздно нет-нет да и наступит на грабли культурных различий. И дело даже не в каких-то диаметрально противоположных менталитетах — подводные камни нередко скрываются за гладью казалось бы общего мировоззренческого бэкграунда. Например, извечный контраст: приветливый стиль американского дружелюбия и сдержанная славянская экспрессия — чем вам не повод для недопонимания. Так, ответив своему западному партнеру лаконичным (и таким профессионально нейтральным у нас) «Got it», минуя все small talks, знаки внимания и этикетные формулы, мы можем не только не подчеркнуть свою готовность к работе, но и даже обидеть собеседника.

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

Портрет 9 Задира

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

Однажды нам довелось сотрудничать с весьма непростым product owner. Можно долго говорить о его плюсах и минусах как человека и специалиста, но главная отличительная особенность, которая существенно влияла на процесс разработки, — это его вспыльчивый характер и бескомпромиссность. Особенно его тяга к конфликтам усиливалась во время митингов в разговорах, как ни странно, с другими представителями Заказчика из-за чего рабочие конференции нередко превращались в целые холивары, где нам оставалось только доставать попкорн и запасаться терпением.

Выход: конфликт то утихал, то разгорался с новой силой несколько месяцев, но затем наш «проблемный» владелец продукта продемонстрировал себя как настоящий профессионал. Он пошел на перемирие со своими коллегами, и они согласованно «выпилились» из наших митингов, назначив другого, более нейтрального product owner. После такого мудрого решения атмосфера в команде стала в целом намного спокойнее.



 

На этом наш сказ о непростом клиенте подходит к концу. Наверняка, у вас есть свои истории о том, как вы сталкивались с препятствиями и преодолевали их на пути к успешной командной работе. В чем мораль сей басни? Нет неразрешимых ситуаций. Мы сработаемся с вами даже там, где другие подают на развод, ссылаясь на «unmendable differences».