Бизнес, продукт, разработка: откуда берется межролевая токсичность и как с ней бороться (Александр Зиза)

Александр Зиза, Co-Founder, Aletheia-Digital Скажу пару слов о себе. У меня три образования. Вообще я физик-теоретик, а по последнему образованию я психотерапевт, который еще обучен интерпретировать сны. И это правда. Сегодня наш разговор пойдет про межролевую токсичность, которая была впервые описана Робертом Бейлсом 70 лет назад, аккурат в 1951 году. Наблюдая за командами, он увидел, что в любой проектной работе, в любой командной работе можно увидеть такие не всегда приятные вещи, которые мы сегодня называем токсичными, а именно: выражает пассивное отвержение, формален, отказывает в помощи, выражает антагонизм, подрывает статус другого, защищает или утверждает себя. Сегодня нам предстоит разобраться, что с этим делать, и как в командной работе как можно быстрее преодолеть эти ограничения, связанные с эмоциями, с проявлением негативных эмоций, с расхождением, и перейти к той части, которая называется интеграция — интегрировать для того, чтобы найти решение, которое будет лучшим, которое будет способствовать лучшему нахождению продукта. Всё это становится сейчас актуальным. Есть теория стиральных динамик Клэра Грейвза — наверное, многие об этом слышали. В свое время он разделил культуру организации на разные типы, и указывал на то, что существуют организации такого жесткого авторитарного типа, организации, которые находятся на уровне «выживания». Например, большинство сегодняшних производственных корпораций, которые мы можем наблюдать, находятся в так называемом синем уровне «организации правил». Может быть, кто-то из них авторитарный. Если говорить про цифровые организации, где находимся мы с вами, то это, скорее, зеленый уровень, там, где возникает холакратия, там, где возникает аджайл, там, где возникает продуктивность, там, где возникают кросс-функциональные команды, и в целом такое понятие, как командность. До этого в более низкостоящих слоях, которые указывал Грейвз, таких вещей не наблюдается. Они крайне редки и, скорее, являются исключением, чем правилом. У нас это правило. Но в соответствии с теории Клэра Грейвза у нас встречаются другие проявления, в том числе авторитарные, те самые негативные эмоции, про которые мы сегодня говорим. Наша задача — найти, как интегрировать. Переход от зеленых команд на следующий виток развития, на седьмой уровень (желтый уровень), который называется «синергия», говорит о том, что для каждого типа взаимодействия есть свое место. Крайне важно понимать, где, с кем, как разговаривать. Где-то потребуется авторитарность, где-то потребуются правила, где-то потребуется демократия, где-то потребуется командность. Это тот переходный момент, где большинство из нас находится. Сегодняшняя тема как раз отвечает на вопрос, как это сделать наиболее мягко, понятно, без антагонизма, без проявления тех самых негативных эмоций, про которые мы говорим. Как это всё происходит, если говорить из теории команд, из теории принятия решений? Мы все с вами знаем, что в нашей работе есть три типа сотрудников, то, что мы относим к бизнесу, к технологам (разработчикам), и то, что относим к нам, к продуктам. Это решение наиболее лучшее не там, где оно правильное, не там, где она лучше, а там, где в командной работе договорятся три человека. Такая интересная история. Где они договорятся, там это решение и случается. Продакт, особенно когда он вырастает в позицию Chief (CPO), он как внутренний предприниматель как раз предназначен для того, чтобы интегрировать и постоянно искать это решение, эту точку сборки, точку договоренности между бизнесом, разработкой и продуктом, который нам нужен. В жизни всё случается совсем по-другому. Вернемся к первому слайду про коммуникации, про командность, про договоренности. Оказывается, что на начальном этапе, когда сотрудники из разных сторон встречаются друг с другом, коммуникация оказывается достаточно сложным элементом, где возникает этот самый антагонизм. Бизнес проявляет превосходство в отношении всех. Он говорит: «Я главный, поскольку это деньги, мы все ориентированы на деньги». Фактически это превосходство всегда происходит через такое эмоциональное понятие, как обесценивание. Он пытается преподнести себя через обесценивание других. В психологии эта штука называется другими словами, критический идеализм — критикует всех, идеализирует себя, по большому счёту всё то же самое. Технолог по-своему обесценивает других и превозносит себя, он говорит: «Я самый умный. Я же всё знаю, как это делать». Никто, кроме меня, не сделает. Я делаю тот самый продукт, который всем нам приносит деньги. Я делаю это руками. Я кодю. У меня такие сложные схемы. У меня такие сложные технологии, которые вам никогда не понять». У него свое превосходство, о котором мы все знаем. Думаю, что кто-то из вас встречался. У продукта своя история. Он говорит: «Я-то являюсь глашатаем желаний заказчика. Все ваши желания заработать, все ваши желания как-то это сделать, по большому счету, ничто, если заказчик не будет это покупать, если это ему не нужно». Он проявляет таким образом свое превосходство. Как итог, это всё превращается в то, что тот продуктолог, тот CPO, который должен это всё собирать, ему это сложно найти точку сборки в этой коммуникации. Он начинает разговаривать с каждым по отдельности на его языке. Он думает, что он разговаривает на его языке. Он пытается говорить с бизнесом, говоря: «Да, ты — главный. Деньги — это главное. Давай найдем решение». Отдельно приходит к технологу, к разработчику говорит: «Ты самый умный, давай ты скажи, что нам делать. Давай будем ориентироваться на тебя». Он как бы поддерживает их в их желании быть главным, быть умным, быть героем, если говорить про себя. В итоге мы превращаемся в манипуляторов, где это решение находится совсем не там, где хотелось бы. Здесь встречается как раз та ситуация, как известная в народных присказках, как лебедь, рак и щука, которые тянут нас в разные стороны. Главное, что не хотелось бы делать в такой истории, это фокусироваться, когда мы работаем как продуктолог, как CPO, когда мы пытаемся всё это объединить, не работать с каждым по отдельности, потворствуя их желаниям показаться такими главными и умными героями, потому что это всё не приводит к делу. Это приводит к какому-то другому месту в этой сборке. В итоге страдает продукт, страдает заказчик, страдает дело. Что можно делать в этой ситуации? Первый тезис, который хотел бы ввести, это достаточно изученная история об эффективности командной работы и об эффективности того, насколько нам нужно с кем договариваться. Здесь представлен график зависимости времени и ресурсов, которые надо потратить на задачу и сложные задачи. Понятно, что в командной работе, когда нас три или больше человек, мы можем решать более сложную задачу. Если это один или двое человек, сложная задача достаточно ограничена. Она ограничена, если говорить про командную работу, такими вещами, как коммуникация, потому что с каждым надо поговорить, каждого вовлечь, объединить, найти время на те самые эмоции, которые для нас являются стоп факторами и сжигают нашу энергию, время. На искажение восприятия, потому что пока это донесешь, пока человек поймет, о чём говорит, а у него свое мнение. Потеря информации. Это является основными ограничителями в командной работе, которые не всегда нужны. Не всегда сложная задача оправдана этими затратами, поэтому для большинства задач сложную командную работу можно разделить на два простых шага. Первый шаг — это когда из этих трех позиций, о которых мы говорили, сначала две позиции договариваются друг с другом, они понимают, что делать, они находят свое решение. При этом они, понимая, что же нужно третьему, вырабатывают и прорабатывают тезисы для третьей стороны. Они не просто так договорились друг с другом и пойдут кого-то уговаривать. Они думают именно из позиции третьего, как третий будет думать, и что будет с этим делать. Шаг номер два — это они уже идут вдвоем и вовлекают третьего, договариваются с ним на его конкретном языке. Как это выглядит в реальной жизни? Если речь идет о понятной нам всем ситуации, когда продуктолог разговаривает с технологом, когда мы о чём-то договариваемся, о том, как делать фичу, о том, как выполнять бэклог, о том, как реализовывать продукт, то встает вопрос о том, как это всё презентовать бизнесу, приходит к нему и потом встречать его непонимание, который говорит: «А где деньги? Мы зарабатываем заказчиков. Это всё здорово. Вы занимаетесь такими клевыми вещами. Где деньги?» Главный аргумент, который мы можем слышать от бизнеса. Здесь надо учитывать тот факт, что бизнес действительно про деньги, и он руководствуется двумя основными принципами, которые есть в деньгах. Первое. Деньги имеют так называемую временную стоимость. Из банковской среды мы все знаем, что деньги сегодня всегда дороже, чем деньги завтра. Отсюда возникает банковский процент. Второй принцип, которым руководствуется любой бизнес, это альтернативность вложений. Он не очень хочет разбираться, где лучше, где хорошо. Он смотрит, куда мне вложить эти ресурсы, на что мне сейчас их потратить для того, чтобы это принесло больше прибыли. Во всяком случае, с его точки зрения это правильная постановка, потому что если не будет этих ресурсов, если не будет возврата этих денег, то и наша с вами наша с вами деятельность как продуктологов, технологов рано или поздно закончится. Для того, чтобы разговаривать с бизнесом, нужно поработать эти два тезиса. Сколько мы можем сейчас вложить ресурсов и когда получим заработок? Почему нужно вложить именно сейчас? Почему именно сейчас, а не когда-нибудь потом? Идеи по поводу монетизации. Здесь речь идет не о том, чтобы вам всё полностью просчитать, потому что это будет сложно сделать без вовлечения бизнеса. Но достаточно продумать эти тезисы, достаточно про них поговорить друг с другом, проработать их, и тогда вам будет существенно легче разговаривать на языке бизнеса и в целом это тот самый необходимый фактор, особенно для продуктолога, для того, чтобы вырасти в позицию Chief в позицию Senior. Это будет сделать крайне сложно сделать без этой проработки. Другая ситуация, когда бизнес с продуктологом придумывают эту фичу, им нужно вовлечь технолога, потому что у технолога очень своеобразный способ размышления. Он не любит все эти вещи: разговоры про заказчика, всякую неопределенность, не понимает ее. В целом разработчики не сильно коммуникабельные, достаточно интровертные джентльмены, которые смотрят на тебя несколько свысока, считая, что они самые умные и знают про это. Для него главное — вы определитесь, чего хотите, насколько то, что будет сделано, будет полезно, востребовано. Он не очень любит гипотезы. Он очень хочет конкретное ТЗ, которое приведет к конкретному результату, что вся та работа, которую он сделает, обязательно будет использована. В этом смысле нужно понимать, что технолог и разработчик — это наш производственный цех. Как любой производственный цех, он всегда загружен. У него всегда много задач. У него всегда переполнен бэклог. Есть много команд, и среди вас, у которых в бэклоге могут висеть тысячи зада. Это всё большая работа для разработки. У него всегда нет ресурсов. У него всегда нет места для еще одной задачи, тем более, которую нужно было сделать вчера. Для него стоит всего две задачи — обеспечить решение задач сегодня и наращивать экспертизу для того, чтобы были задачи завтра. Это нужно использовать. Прежде, чем мы вовлекаем технологов, нужно проработать этот аргумент, понять, насколько, с одной стороны, можем использовать те ресурсы, которые уже есть сейчас. С другой стороны, каким образом наши продукты и фичи могут дать развитие команды, и что нужно сделать для того, чтобы решать задачи завтра, как завтра рассчитывать экспертизу. Третий очевидный вариант — это когда кто-то из них договорился, когда технолог договорился с бизнесом. Часто в IT-командах бывает так, что в бизнес приходят собственники — бывшие разработчики. Таких команд много. Бывшему разработчику, а сегодня бизнесу с технологом очень просто договориться. Они говорят на одном языке. У них иногда бывают свои задачи, когда они могут о чём-то подумать без продуктолога, без продукта, без вовлечения заказчика. Одна из базовых проблем такой разработки, особенно продуктовой, которая очень быстро бежит, сейчас есть команды, известные имена или рыночные продукты, которые фактически останавливались из-за того, что в свое время задача не была решена, а именно работа с техническим долгом и с рефакторингом. Рефакторинг и работа с техническим долгом вырубает команду разработки на достаточно долгое время, и наш бэклог в это время висит, с ним ничего не происходит. Наши метрики страдают. У нас всё двигается. Это бесит. Непонятно, что с этим делать. Главное, о чём здесь хотелось бы поговорить, как в этой ситуации самому не стать токсичным, тем самым лебедем, раком либо щукой, которая тащит в другую сторону и пытается манипулировать. Не надо. Здесь несколько рациональных вещей, которые нужно принимать для себя. Первое. Если не чинить фундамент, дом когда-нибудь рухнет. К сожалению, таких случаев много. Когда система надолго непредсказуемо останавливается, это большие деньги. Есть разовый бизнес, особенно в области туризма, перевозок. Там это всё становится очень критично. Второй момент, когда образуются так называемые «ножницы». «Ножницами» называют разрыв между технологическими новшествами, которые появляются на рынке, и их использование для бизнеса. Есть даже такое слово, «технологические ножницы». Сегодняшняя ситуация в продуктовых командах такова, что эти технологические тренды нужно всегда отслеживать, смотреть, что происходит, что такого необходимо втянуть. Это всегда влечет за собой потерю времени, определенные ресурсы, которые команда разработки вынуждена тратить на освоение новых технологических трендов, на понимание, как работают эти модели, на свои «песочницы», эксперименты. Без этого тоже никуда. С другой стороны, эти технологические тренды, которые будут вовремя внедрены в команду, помогут вам же продуктологу делать принципиально новый продукт и выходить на качественно другой уровень обслуживания нашего с вами клиента. Если всё совсем плохо, бизнес иногда так может рассуждать: «Я вам дам ресурсы, оставлю ответственность». Иногда складывается такая ситуация, что бизнес понимает, что что-то не так, но всё-таки он надеется, что продуктолог потом поднажмет, «котик еще выдавит из себя капельку», как в том анекдоте, и каким-то образом сможет пережить этот временный провал в ресурсах. Если совсем плохо, прийти к бизнесу, прийти к этой команде, говорить о том, что «Давайте пересмотрим метрики, потому что страдает мой бэклог, и не хотелось бы здесь оставаться у разбитого корыта». Это три варианта. Наша основная с вами задача — это понимать, как с ними работать, потому что CPO или продуктолог — то самое место, которое умеет собирать это дело, это внутренний предприниматель. Очень часто продуктолога называют внутренним предпринимателем, он в предпринимательской позиции. А его задача — не манипулировать, а собирать команду и действовать из интересов целого для того, чтобы всё это собралась. Последние выводы. Первое. Негативные эмоции, вплоть до токсичности, это нормально на определенном этапе команды. Если кто знает, у Такмана это называется шторминг. Проявление негативных эмоций и то, что мы часто называем токсичностью, бывает необходимой частью для того, чтобы происходило это бурление. Тем не менее, для того, чтобы быстрее прийти к решению, не надо брать позицию манипулятора и разговаривать с каждым по отдельности, потому что это всё приведет не к делу, а непонятно, куда. Не все наши задачи требуют вовлечения всех. Таких сложных задач не так много. Часто можно находить решение, разговаривать вдвоем, потом вдвоем разговаривать с третьим. Последний главный тезис. Позиция Chief (CPO), то, во что вырастает продуктолог, это «Тот, кто действует из интересов целого и выводит на эту позицию других». Всё. Спасибо.