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

Начнем вообще не с ПО и команд, а с крупных компаний и процесса целеполагания (постановки целей). Понятно, что когда в компании огромный штат, который по сути состоит из десятка полу, а то и независимых компаний, то топ менеджмент физически не может отслеживать все релизы и задачи, и даже помнить все тонкости стратегии развития каждой компании/подразделения (название зависит от структуры). Естественно, что цели и стратегия развития принимаются очень верхнеуровнево. Обычно это набор показателей (увеличили конверсию в покупки на 3% и т.д.) или бинарных шагов (сделал/не сделал, выкатил фичу А вовремя или нет). Достигнув показатели, ты конечно же получаешь премии и повышения, а не достигнув в целом можно и работу потерять (премию так уж точно). Не хочу сейчас останавливаться на том какой это дает эффект к концам оценочных периодов, продолжим с целеполаганием. В компании есть проекты, которые вообще не на виду у топ менеджмента. В таких проекта наблюдается относительная свобода мысли и размах идей. Те же проекты, которые являются лицом каких-то продуктов (и находятся на передовой амбиций) имеют больше ограничений ввиду повышенных репутационных рисков и высокой доли контроля. В любом случае, любой проект получает свой набор показателей, которые должен достигнуть (придуманных самим ПО с корректировками от руководства или вообще спущенных сверху).

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

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

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

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

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

Если же ПО находится вне команды, то к разным подходам и целям люди относятся абсолютно адекватно. В худшем случае можно свести коммуникации и торги в тимлида или руководителя отдела, главное чтоб задачи были готовы в срок. Команда получит возможность самой работать с тех долгом и качеством, при условии гарантии выставленных ею сроков. Если говорить прямее, команда объединяется вокруг “общего врага” и единым фронтом двигается как к целям так и к выбиванию определенных отступлений от указанных целей.

На практике это тоже работает. В одной из компаний мы убрали кучу конфликтов и споров именно выносом ПО из команды. Мы немного изменили правила игры и теперь команда (либо я, как ее представитель) которая будет делать и реально понимает свои ресурсы и возможности, участвует в постановке сроков и выборе реальных целей (как верхнеуровневых так и уже непосредственно в деталях). Да, команды и CTO становятся ответственными за сроки единолично, но по моему опыту все равно спросят с СТО, как бы структура принятия решений не выглядела. ПО, с которых снят груз ответственности за сроки, чаще всего не заинтересованы в напихивании задач, потому что у них больше нет на это метрик и целей. Конфликтов и споров стало значительно меньше. Уровень вовлечения команды стал выше.

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

PS. Если ваша команда правда сделана по классике Agile, где ПО заинтересован в том чтобы итеративно выпускать КАЧЕСТВЕННЫЙ продукт, уважает свою команду, нацелен на совместный рост с командой, то проблем не будет. Но возможно мне и моим коллегам не везло на такую синергию.