Презентация
серверов от Acer
До начала осталось:
Смотреть
Карьера
Антон Балтачев

Мэтч между разработчиком и менеджером. 9 способов не бесить друг друга

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

Видеть в разработчике лишь технического специалиста

Часто в процессе работы менеджеры перестают прислушиваться к разработчикам – ждут от них только новых фичей, дергают их словно игровой автомат, который выдает монетки. Забывают, что разработчики – не роботы, а такие же люди, как все. Им не менее важно получать похвалу, чувствовать уважение коллег и важность своего труда. Когда сотрудники их достижений не замечают, возникает взаимная антипатия, и вряд ли в такой атмосфере может получиться качественный продукт.

Что делать?

Вот несколько советов, которые помогут сделать отношения с разработчиками более доверительными:

  1. Будьте открыты к тому, что говорят разработчики. То, что вы придумываете различные идеи, не означает, что разработчики должны их бездумно воплощать. Они могут опровергнуть необходимость внедрения дополнительных функций – вам нужно внимательно выслушать аргументы коллег. Конечно, разработчики могут не понимать, как в целом развивается проект, тогда потратьте время и расскажите о продукте более подробно.
  2. Если задачи не особо интересны и нет возможности поддерживать мотивацию стандартными материальными плюшками (ДМС/опционам/эклерами), то нужно донести до разработчиков насколько важно то, что они делают.
    Потратьте ресурсы на сбор фидбека от пользователей. Даже если отзывы не будут положительными, они покажут, что продуктом, действительно, кто-то пользуется. Помните, разработчики могут быстро заскучать, делая что-то в стол.
  3. Упростить коммуникацию и заслужить уважение помогает понимание базовых принципов/технологий, которые используют разработчики.
    Не стесняйтесь проявлять интерес к техническим аспектам работы – многие разработчики с удовольствием расскажут о подходах, которые используют. Главное, желание хотя бы поверхностно разобраться в этих сложных терминах – потратить время на то, что не входит в вашу зону ответственности.

Отвлекать на бесконечные созвоны

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

Многие считают, что созвоны важны для понимания стратегии и синхронизации действий всей команды. Однако старайтесь всегда ответить себе на один вопрос: “Какие конкретно цели мы преследуем очередным созвоном?” Сделав это, проверяйте, не являются ли ваши ответы слишком абстрактными. Возможно, вам нужно заземлить их еще раз, пока не получите понятную четкую задачу (про заземление можете прочитать тут).

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

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

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

Не доверять сотруднику

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

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

Ставить нереальные дедлайны

Больше всего разработчики ненавидят горящие дедлайны, особенно те, которые происходят не по их вине. Посмотрите, например, к чему привели непомерные амбиции руководства компании CD Projekt Red, которая недавно выпустила Cyberpunk 2077. Игру в течение семи лет разрабатывала команда, состоящая из тысячи профессионалов. Однако Cyberpunk 2077 оказалась абсолютно не приспособлена для игровых консолей – количество багов в ней зашкаливает. Скорее всего первая мысль будет: “У разработчиков просто кривые руки!” Однако на ПК все работает достаточно хорошо, просто у команды не хватило времени и сил, чтобы успеть все доделать к релизу на консоли.

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

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

Не давать обратной связи

Для разработчиков важно регулярно делать ретроспективу процессов в команде. У всех людей свои индивидуальные фильтры восприятия реальности – для кого-то нормально работать в условиях постоянных дедлайнов, а кто-то за месяц выгорает от такого пламени.

Соберите всех, кто участвует в проекте, и спросите по очереди, что им нравится и что их не устраивает. Руководствуйтесь в процессе обсуждения двумя заповедями:

  • Не переходите на личности – высказывайте свои потребности без оценки действий другой стороны.
  • Не пытайтесь выдумать причину какой-то проблемы, а спросите о ее источнике самого человека.

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

Обсуждать только работу

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

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

В заключение

Я перечислил в этой статье много всего, хотя мог лишь написать: “Относитесь к людям по-человечески, и все будет ок”. К сожалению, в реальности все складывается не так легко. Я хочу пожелать вам жить в гармонии со своими коллегами – это важно не только для создания успешного командного продукта, но и для сохранения ментального здоровья.

Выражаю благодарность за советы и идеи для данной статьи ведущему разработчику Ивану Меньших и всей R&D-команде в Embedika.

{ "author_name": "Антон Балтачев", "author_type": "self", "tags": [], "comments": 13, "likes": 21, "favorites": 43, "is_advertisement": false, "subsite_label": "hr", "id": 214977, "is_wide": false, "is_ugc": true, "date": "Mon, 01 Mar 2021 14:06:41 +0300", "is_special": false }
0
13 комментариев
Популярные
По порядку
Написать комментарий...
2

Окей, жди статью «как общаться с менеджерами» в ответ!)

Ответить
0

Вы напишите?

Ответить
0

Может получиться интересный сиквел, попробую.

Ответить
0

Надеюсь, когда-нибудь сделаем кроссовер покруче, чем война бесконечности!

Ответить
1

Все по делу, наверное, но так не бывает и, вероятно, не будет:)
И не потому что одна сторона "как дети", а потому что одной стороне по-взрослому фиолетово.

Ответить
0

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

Ответить
1

Ну да, не считаю. Для разработчика вникнуть, разобраться в вопросе это задача-минимум, иначе он не достигнет цели. Для заказчика задачей-максимум является "озадачить разработчика". В итоге разработчик начинает вытягивать информацию по крупицам, что раздражает заказчика, потому что вдруг на поверхность всплывают неудобные вопросы, ответов на которые нет.
К тому же представитель заказчика часто транслирует вовсе не свою потребность, а руководителя, например, про себя думая "блин, ну почему я?!"
Всё усугубляется неспособностью формулировать мысли, понимать сложносочиненные предложения и неумением в логику, которая для разработчика чего бы то ни было является святым граалем.
//че сказал...
В итоге имеем целую новую профессию аналитик/консультант, который выступает "переводчиком" с языка обывателя на язык ТЗ. Но новая проблема - это доп звено, это испорченный телефон, у него свои критерии эффективности работы, и консультирует он 100500 идиотов, и надо уже хоть какое-то ТЗ написать и как вы мне все надоели...

Ну, в общем, это исключительно собственные наблюдения и мнение. Довольно часто приходится видеть, как люди обсуждают вообще разные вещи, но постоянно говорят друг-другу "да, да!.."
А потом рождается "что мертво, умереть не может". И заказчик думает "вот они козлы", а разработчик думает, "во дурак"...

Короче, понятно, КАК должен выглядеть диалог. Непонятно, как этого добиться :)

Ответить
0

У меня очень отзываются ваши слова про то, что зачастую у всех разное понимание, желания, способности и сложно понять каким образом все это соединить. Эта статья, я надеюсь, один из маленьких шагов в сторону взаимопонимания и избавления от «глухого телефона». Мне ценно, что вы поделились своими болями)

Ответить
0

А ведь я выступаю со стороны заказчика в 9/10 случаев 🤣

Ответить
1

Очень продуманная статейка. Есть смысл.

Ответить
–4

Такие советы нужно смело выбрасывать на помойку.
Они годятся только для приспособленцев, которых нормальный руководитель должен уметь видеть и избавляться от таких менеджеров.

Ответить
1

Можете пояснить, что мы имеете в виду под "приспособленец" и почему они должны быть уволены?

Ответить
0

Отличная статья, причём не только для отношений менеджер-разработчик, а в целом заказчик-исполнитель.
Спасибо !

Ответить

Комментарии

null