NLP-инженер Антон Балтачев написал на vc.ru колонку о способах эффективной коммуникации между разработчиком и менеджером.
Ниже приводим текст оригинальной публикации.
Эта статья построена на личном многолетнем опыте работы с различными специалистами: менеджерами по проекту, менеджерами по продукту, системными и бизнес-аналитиками и тестировщиками. Данный материал несет исключительно субъективный характер и не ставит своей целью кого-нибудь оскорбить или обидеть.
Видеть в разработчике лишь технического специалиста
Часто в процессе работы менеджеры перестают прислушиваться к разработчикам – ждут от них только новых фичей, дергают их словно игровой автомат, который выдает монетки. Забывают, что разработчики – не роботы, а такие же люди, как все. Им не менее важно получать похвалу, чувствовать уважение коллег и важность своего труда. Когда сотрудники их достижений не замечают, возникает взаимная антипатия, и вряд ли в такой атмосфере может получиться качественный продукт.
Что делать? Вот несколько советов, которые помогут сделать отношения с разработчиками более доверительными:
1. Будьте открыты к тому, что говорят разработчики. То, что вы придумываете различные идеи, не означает, что разработчики должны их бездумно воплощать. Они могут опровергнуть необходимость внедрения дополнительных функций – вам нужно внимательно выслушать аргументы коллег. Конечно, разработчики могут не понимать, как в целом развивается проект, тогда потратьте время и расскажите о продукте более подробно.
2. Если задачи не особо интересны и нет возможности поддерживать мотивацию стандартными материальными плюшками (ДМС/опционам/эклерами), то нужно донести до разработчиков насколько важно то, что они делают. Потратьте ресурсы на сбор фидбека от пользователей. Даже если отзывы не будут положительными, они покажут, что продуктом, действительно, кто-то пользуется. Помните, разработчики могут быстро заскучать, делая что-то в стол.
3. Упростить коммуникацию и заслужить уважение помогает понимание базовых принципов/технологий, которые используют разработчики. Не стесняйтесь проявлять интерес к техническим аспектам работы – многие разработчики с удовольствием расскажут о подходах, которые используют. Главное, желание хотя бы поверхностно разобраться в этих сложных терминах – потратить время на то, что не входит в вашу зону ответственности.
Отвлекать на бесконечные созвоны
Большинство разработчиков не видят смысла в частых созвонах или совещаниях. Как правило, добросовестные разработчики всегда заняты, а многочасовые обсуждения отнимают огромное количество времени и энергии, разрушают состояние потока (про него можете прочитать в книге Михая Чиксентмихайи).
Многие считают, что созвоны важны для понимания стратегии и синхронизации действий всей команды. Однако старайтесь всегда ответить себе на один вопрос: “Какие конкретно цели мы преследуем очередным созвоном?” Сделав это, проверяйте, не являются ли ваши ответы слишком абстрактными. Возможно, вам нужно заземлить их еще раз, пока не получите понятную четкую задачу (про заземление можете прочитать тут).
Если вы нашли цель созвона, то обязательно пропишите его план, буквально 3 предложения, чтобы не уйти в оффтоп. Но даже после этого не спешите кидать в чат ссылку на зум, еще раз спросите себя, является ли созвон самым оптимальным способом достижения поставленной цели или для решения задачи можно использовать другую стратегию (про все возможные стратегии можно узнать здесь).
Попробуйте посчитать, сколько денег компании вы потратите на час обсуждения проблемы, собрав на одной конференции сразу трех инженеров, вместо асинхронного написания конкретных вопросов текстом
Конечно, не бывает правил без исключения – созвоны часто помогают команде, когда нужно провести сложный мозговой штурм. Однако для решения оперативных вопросов довольно бесполезно собирать огромную толпу народа, половина из которых может просто молчать. Помните, если сотрудники не понимают какую-то задачу, скорее всего, проблема не в том, что не было созвона, а в том, что система управления построена неправильно.
Не доверять сотруднику
Одна из причин создания огромного количества созвонов – неявный контроль сотрудников. Не забывайте, ваши коллеги не дети и чрезмерный контроль может лишь навредить процессу. У любого разработчика есть четко прописанные задачи и сроки, они так же, как и вы, профессионалы своего дела. Просто доверьтесь им.
Если вам так важно держать руку на пульсе, то хотя бы не злоупотребляйте этим – ощущение того, что “гребешь на галере“ не поможет разработчику делать хороший продукт.
Ставить нереальные дедлайны
Больше всего разработчики ненавидят горящие дедлайны, особенно те, которые происходят не по их вине. Посмотрите, например, к чему привели непомерные амбиции руководства компании CD Projekt Red, которая недавно выпустила Cyberpunk 2077. Игру в течение семи лет разрабатывала команда, состоящая из тысячи профессионалов. Однако Cyberpunk 2077 оказалась абсолютно не приспособлена для игровых консолей – количество багов в ней зашкаливает. Скорее всего первая мысль будет: “У разработчиков просто кривые руки!” Однако на ПК все работает достаточно хорошо, просто у команды не хватило времени и сил, чтобы успеть все доделать к релизу на консоли.
Если сотрудники говорят, что для разработки данного функционала нужно как минимум два дня, не надо требовать от них сделать это за два часа. Тем самым вы показываете, что не доверяете коллеге.
И еще один важный момент – если дедлайн уже горит, паникой вы вряд ли сможете чего-то добиться. Лучше просто спросить, как можно помочь сделать задачу быстрее. Возможно, стоит просто отстать от разработчиков и не трогать их до дедлайна.
Не давать обратной связи
Для разработчиков важно регулярно делать ретроспективу процессов в команде. У всех людей свои индивидуальные фильтры восприятия реальности – для кого-то нормально работать в условиях постоянных дедлайнов, а кто-то за месяц выгорает от такого пламени.
Соберите всех, кто участвует в проекте, и спросите по очереди, что им нравится и что их не устраивает. Руководствуйтесь в процессе обсуждения двумя заповедями:
Не переходите на личности – высказывайте свои потребности без оценки действий другой стороны.
Не пытайтесь выдумать причину какой-то проблемы, а спросите о ее источнике самого человека.
Лучше всего разговаривать с разработчиками один на один, потому что не все могут публично критиковать своих коллег, боясь испортить с ними отношения. Если у вас огромная команда, фидбек также можно получить при помощи опросника. Однако часто люди ленятся заполнять подобные документы, не стесняйтесь напоминать разработчикам, насколько значима для вас их оценка.
Обсуждать только работу
Постарайтесь найти с разработчиками общие интересы, увлечения, хобби. Создавайте атмосферу доверия: лучше не устраивать стандартных тимбилдинговых активностей, а сходить вместе туда, где обычно собираются эти ребята – например, в их любимый бар. Неформальная обстановка идеально подойдет, чтобы что-то обсудить, открыто поговорить о болях и проблемах, с которыми вы сталкиваетесь.
Учтите, если человек не хочет, чтобы лезли в его личную жизнь, не осуждайте эту позицию никоем образом – оставьте ему право на личное пространство.
В заключение
Я перечислил в этой статье много всего, хотя мог лишь написать: “Относитесь к людям по-человечески, и все будет ок”. К сожалению, в реальности все складывается не так легко. Я хочу пожелать вам жить в гармонии со своими коллегами – это важно не только для создания успешного командного продукта, но и для сохранения ментального здоровья.
