Нередко конфликты возникают не из-за локальных проблем в коммуникациях или ошибок конкретного сотрудника, а из-за серьезных культурных различный или различий в мотивации на уровне команд. Как возникают такие конфликты и в чем их причина?
Игорь Алексеенко, консультант и ментор, автор блога о принятии решений, рассказал, в чем фундаментальный конфликт между продуктовыми командами с одной стороны и маркетингом и продажами — с другой, а также наметил возможные пути разрешения этого конфликта.
Посмотрим на гипотетическую, но довольно типичную ситуацию:
— Привет, слушай, включи, пожалуйста, в следующий спринт вот эту новую штуку.
— Оу, это очень большая штука и она займет весь спринт разработки, мы не сможем сделать ничего другого кроме нее.
— Это очень важная для нас штука.
— Почему я узнаю об этом только сейчас? Мы же на планировании обсудили совсем другие вещи.
— Потому что мы только что закрыли продажу с важным клиентом…
— ???
— В договоре прописано, что мы обязаны предоставить в функционале эту штуку…
— ???
— Это важно, понимаешь
— Скажи, а почему ты думаешь, что это важно, сколько нам принес этот договор?
— <Math.random()> рублей.
— А ты в курсе, что ровно столько стоит один спринт нашей разработки? Это ровно столько, сколько мы тратим на зарплату дизайнера, разработчиков и тестировщиков за спринт и это не учитывая еще девайсы, сервера, дата-центр и прочие штуки.
— ?
— Погоди, тебе же еще положен KPI за продажу, правильно?
— ?
— Получается, что из-за твоей продажи, компания по деньгам в минусе на твой KPI.
— Компания в минусе по деньгам из-за того, что вы по две недели пилите обычные задачки, которые можно сделать за пять минут, а мы вынуждены затыкать дыры в бюджете новыми продажами сырого продукта!
*Подобно дерущимся котам превращаются в шипящий и рычащий клубок из мелькающих конечностей, который, поднимая пыль и роняя предметы по пути, укатывается куда-то из виду.
Этот диалог — не фантазия, такое может произойти в любой компании. Обычно разные отделы находятся друг от друга за большой непроницаемой стеной, преодолевать которую обучены только директоры, бизнес- и системные аналитики, проектные менеджеры и менеджеры продуктов (и, как правило, только для того, чтобы собрать информацию, а не передать ее) — и то им приходится платить за это большую сцену.
Разные отделы — разная культура. В мире продажников процветают KPI: больше продал — больше денег заработал. При этом базовая зарплата несколько меньше норм здравого смысла, так что приходится продавать и продавать, иначе просто не хватит на очередной взнос по ипотеке.
В мире продуктовиков и разработчиков все наоборот — у тебя есть гарантированный и довольно солидный фикс, благодаря которому ты, сидя за удобным креслом и поедая печеньки, думаешь о высоком: о ценности для пользователя, удобном Developer Experience и о том, как бы сделать красивую библиотеку готовых компонент, чтобы снизить Time-to-Market.
Если вспомнить о том, что мы все — люди, а не просто функции, то эта разница в культурах приобретает еще более удивительный разрез: продажники и разработчики каждый день удовлетворяют еще и различные личностные потребности.
Наверняка, вы слышали о «Пирамиде Маслоу». Это популярный подход, который помогает донести две простых мысли:
- Все, что мы делаем, содержит более глубокий смысл. Мы не просто работаем в компании, мы самоидентифицируемся и самореализуемся. Мы не просто получаем зарплату, мы обеспечиваем свою безопасность.
- Смыслы двух разных людей, даже если они делают одно и то же, могут быть разными.
☝ На самом деле, в научных кругах концепцию пирамиды достаточно часто критикуют, но критикуют не саму мысль о том, что у нас есть разные базовые потребности, а именно их иерархию. И это оправданно, ведь если бы наши потребности располагались строго иерархически, Анна Ахматова в голодном Ленинграде между стоянием в очереди для передачи сыну посылки в тюрьму и собственным выживанием не писала бы стихи. Но тем не менее, никто не спорит, что для нас важны некоторые базовые вещи, и вещи эти делятся на некие смысловые группы.
Ряд исследователей выделяют следующие группы потребностей:
- любовь,
- самореализация,
- самоидентификация,
- безопасность физическая,
- безопасность психологическая.
Кажется, для нашей ситуации этого достаточно. Важно не то, у кого потребности «выше по пирамиде», важно то, что разработчики и продуктовики удовлетворяют одни потребности, а продажники и маркетологи — другие.
Если пользоваться нашей классификацией, получится, что разработчики и продуктовики работают для самореализации (может даже любви, если они читают фидбек от пользователей). Продажники и маркетологи же, в силу наличия у них жесткой структуры и KPI, удовлетворяют потребность в физической безопасности (способность оплачивать покупки в конце месяца). Даже если убрать пирамиду, люди внутри одной компании, которые должны вроде бы должны фокусироваться на одних и тех же ценностях, начинают говорить на разных языках, потому что для них становятся важны совершенно не связанные между собой вещи.
А теперь в дело вступает руководство компании, которое уже выстроило стены между разными отделами и вкидывает козырь, который еще больше усиливает эту разницу. За счет того, что в каждом из отделов совершенно разная культура, люди начинают самоидентифицироваться не как сотрудники всей компании, а как сотрудники «последнего оплота „нормальности”» в компании — в то время как «эти раздолбаи из соседнего отдела» неделями двигают свои маленькие задачки / вкидывают в бэклог какой-то непоследовательный бред (ненужное зачеркнуть).
Попытаемся спасти ситуацию и для начала призовем на помощь Элияху Голдратта и его теорию ограничений, которая описана в книге «Цель». Основная мысль книги в том, что всю компанию стоит рассматривать как единый конвейер поставки ценности, а скорость этого конвейера не может быть выше, чем скорость самого узкого звена.
Например, мы работаем в большом и сложном продукте и продажи даются нам относительно быстро, но разработка любой новой фичи занимает много времени. Да, может быть кода у это самой фичи — на пять минут посидеть в IDE, но у нас большое приложение со сложными связями и одно маленькое изменение может по цепочке затронуть много других блоков, так что после пяти минут кодинга идёт две недели проверок, не отвалилось ли чего.
Руководитель, который ставит в таком продукте KPI на продажи, вынуждает отдел продаж работать быстрее и больше: хлеб на столе, детсад и ипотека зависят от того, сколько я продам, а еще всё это зависит от скорости большой махины разработки, которой я не управляю и могу только бессильно злиться на них. Но узкое горлышко разработки никто не отменял, и в итоге продукте скапливается бэклог на 600 входящих записей, надежность продукта падает, а ценность размывается.
Другая ситуация. Продукт небольшой, разработка не раздута и не перегружена, но продажи идут чрезвычайно медленно. Разработчики в этой системе смогут напилить такое качество системы и такое количество фич, что просто залюбуешься, разглядывая продукт. Однако продажники понимают, что сделка заключается из-за одной единственной штучки, которая понравилась клиенту, или вообще из-за того, что менеджер по продажам приятный и душевный человек. Разработчик же в этой ситуации понимает, что делает ненужную работу «в стол», выгорает и вообще не понимает, зачем ему следить за качеством продукта.
Обе эти компании спасет одно и то же решение: единое планирование и синхронизация планов между отделами. Как продажам, так и продукту нужно выложить на стол свои ограничения и возможности, без обиняков определить, кто из них будет бутылочным горлышком и построить процесс вокруг самого медленного звена. Пункт про отсутствие обиняков важен, потому что если сотрудники будут определять, кто лучше, начнется головоломный спор о том, крокодил больше длинный или больше зеленый.
Роль руководителя в этой ситуации — объединять разрозненные культуры вокруг общих целей и общих ограничений, а не разгонять культуру повышения своей самооценки за счет другого. И только после объединения отделов вокруг общей цели стоит начать подбирать подходящую систему мотивации.
Если у вас медленные продажи, можно разгрузить отдел разработки от новых фичей и занять их неспешной поддержкой существующей версии приложения — или даже замкнуть бэклог входящих задач на отчеты от техподдержки. Пока продажники работают в своем темпе, разработчики получают комплименты от существующих пользователей и допиливают продукт до блеска.
Если у вас продажи быстрее разработки, вам нужно замедлить их и научить говорить потенциальным клиентам «Вы знаете, наш продукт, к сожалению вам не подходит, у нас нет нужной вам функциональности».
Интересно, что в обоих случаях поможет снижение доли KPI и повышение доли оклада для отдела продаж. В первом случае они смогут вести себя более рискованно с потенциальными клиентами и не будут бояться неизбежных отказов, а во втором случае сами смогут смелее форсировать отказы тех клиентов, которым явно не подходит продукт (или которые сами не подходят продукту).
Если вернуться на уровень биологии, то все становится на свои места. Нам нужно через централизованное планирование снизить натяжение между разными отделами. А значит, нам нужно сделать так, чтобы ценности у разных направлений максимально сблизились и сотрудники смогли бы говорить на одном языке. Причем, если рассуждать с этой позиции, то вариантов становится больше одного:
- Уже рассмотренный сценарий, со снижением доли KPI и повышением оклада, в котором менее напуганные потенциальным «отсутствием еды на столе» продажники могут услышать, о чем говорят продуктовики.
- Введение горизонтальных продуктовых команд, которые включают в себя сразу все роли, без распределения специалистов по разным отделам. Отдел по продукту включает в себя помимо разработчиков маркетолога и продажника, которые вместе участвуют в планировании и разработке продукта. В такой системе, конечно же, правила игры должны быть одинаковыми и один участник такой команды не может сидеть на KPI, в то время как остальные на чистом окладе.
- Развернутый на 180º пункт 2. А что, если все сотрудники, причастные к продукту, могут сидеть на KPI, в том числе разработчики? Тогда все еще сохранится мотивация к сотрудничеству, потому что появится общий интерес — превратить результат своей работы в деньги. Кстати, на этом фоне можно вместо индивидуальных бонусов ввести один большой бонус на всю команду.
☝ Этот сценарий неортодоксален, потому что на рынке редко кто рискует пугать потенциальным отсутствием еды на столе не продажников, а разработчиков. Видимо, причина в том, что разработчики в любой момент могут отчалить в другую компанию, где им будут платить гарантированную денежку. В этом случае разработчики должны быть очень лояльны компании и верить в то, что она делает. И природе такие случаи известны: например, тот же Яндекс с системой опционов на покупку акций для сотрудников, которые давно работают в компании.
- Объяснение, почему пункт 3 — не окончательный бред. В идеальном мире существует система OKR, которая как раз снимает разницу между разными отделами за счет единого планирования и общих показателей на всю компанию, декомпозируемых по отделам. Единственная (но существенная) разница у OKR с KPI состоит в том, что OKR — это не прямой финансовый показатель, а косвенная метрика. Это решает вопрос с доступом к деликатной и сложной финансовой информации и, заодно, дает возможность отделам прогнозировать свои показатели самостоятельно.
К сожалению, мы живем в сложном мире. Существует очень много теоретически красивых и полных систем, которые, если их внедрять в сразу на всю компанию, снимают все проблемы и разночтения. Но реальность напоминает нам, что жизнь гораздо сложнее и найти компанию, которая внедрила бы единую и прозрачную для всех систему мотивации, невозможно. OKR, как правило, разбивается об отдел продаж, который продолжает жить на финансовых бонусах. KPI, как правило, не докатывается до технарей, которые совершенно не понимают как их работа конвертируется в деньги (максимум, что им понятно, так это как снизить затраты отдела).
Однако, продолжать поиски и задавать вопросы полезно. Это всегда движет нас вперед. И, может быть, если размышлять на эту тему сквозь призму ценностей тех людей, которые работают в компании, то в итоге это приведет нас к какому-то новому и обнадеживающему ответу.
