Как сломать взаимодействие продуктовой команды: 5 вредных советов и антикейсов

Привет, Хабр! Я Женя, CPO в корпоративном мессенджере Compass. Собрались мы как-то в баре с 5 продактами, поделились друг с другом рабочими историями, и теперь у меня есть 5 антикейсов, которыми я, с разрешения ребят, поделюсь здесь.

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

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

Немного бэкграунда

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

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

5 способов разрушить продуктовую команду

1. Сломайте коммуникацию между специалистами

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

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

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

История из практики:

На одном из проектов была абсолютно сумасшедшая система согласования: нужно было РАСПЕЧАТЫВАТЬ все материалы, включая презентации, затем брать обходной лист и подписывать его у каждого ЛПРа. Их, кстати, было 9, — как кругов ада у Данте. 

Утвердить что-либо у такого количества людей — тот еще квест. Самая неожиданная причина для отказа на моей памяти: «‎Почему я стою в списке ниже, чем другой ЛПР?».

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

Новая фича проработала 2 дня. На третий к нам в ярости ворвался один из ЛПРов и потребовал «‎вернуть все, как было», потому что с ним ничего не согласовали.

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

2. В топку планирование и управление проектами

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

Можно действовать еще проще: любая задача срочная и важная, выполнить нужно немедленно, желательно еще вчера. Ставьте всему высокий приоритет и следите за тем, чтобы у сотрудников всегда было 5-6 таких задач.

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

История из практики:

Однажды в команде выдалась интересная неделя: за 5 дней к продакту обратились 3 ЛПРа с запросом на новые функции. Все срочные и важные, нужны «‎еще вчера», но, так и быть, можно сделать к завтра. Бессмертная классика.

Продакт принял все запросы и ушел думать. Сделать 3 фичи с дедлайном «‎завтра» — миссия заведомо невыполнимая, поэтому всех ЛПРов собрали на встречу и попросили решить, что приоритетнее. В итоге они начали ругаться между собой, и их конфликт, как и дедлайны растянулись еще на неделю. В это время команда спокойно доделала текущие задачи спринта.

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

3. Писать подробные ТЗ — слишком скучно

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

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

История из практики:

Нам нужно было сделать онбординг для новой фичи. В ТЗ от ЛПРа было только смутное понимание того, что онбординг просто нужен. Задаем уточняющие вопросы, тратим время на составление понимания задачи и бриф. Отправляем обратно, а в ответ тишина — ЛПР уехал в отпуск.

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

Через месяц состоялась классика тарантиновских диалогов:

— Где онбординг?

— Какой онбординг? Вы еще понимание задачи не посмотрели.

— Какое понимание задачи?

В итоге, конечно, синхронизировались, но на разработку онбординга оставалось всего несколько дней. 

4. Цепочки согласований длиною в жизнь

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

Ключевая деталь — у задачи не должно быть главного согласовывающего: такие люди только сокращают веселье и путь поисков Святого Грааля идеала. Объясняйте это тем, что все вы здесь вообще-то собрались, чтобы сделать отличный продукт, а значит может быть полезно абсолютно каждое мнение.

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

История из практики:

Эта история — продолжение эпопеи из предыдущего пункта. Кратко: нужно было сделать онбординг, ТЗ оказалось так себе, уточнения и бриф не могли посмотреть 1,5 месяца. Затем очнулись и с горящей головой побежали делать задачу.

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

Когда все уже двигалось к завершению, случился твист из турецкого сериала: в кадре появился потерянный брат-близнец — ЛПР смежного отдела, который решил, что ему тоже нужно присоединиться к задаче и все посмотреть. В итоге на согласования у команды ушло больше времени, чем на саму фичу.

5. Время команды бесценно. Ничего не стоит

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

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

История из практики:

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

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

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

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

Заключение

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

Было ли подобное на вашей работе? Или, может быть вы знаете более затейливые способы разрушить команду продукта? Поделитесь, пожалуйста, в комментариях.