Как подружить менеджера и разработчика

Старая японская поговорка гласит: «Из-за незабитого гвоздя потеряли подкову, из-за потерянной подковы лишились коня, из-за лишенного коня не доставили донесение, из-за не доставленного донесения проиграли войну». Как это относится к IT и веб-разработке? Давайте разбираться.

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

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

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

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

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

- Друг, нам нужна таблица с котятами!
- Ок. А сколько котят нужно?
- Ну, 5 - 10. А может и 1000.
- Хм, 1000 котят. Надо сделать пагинацию, ленивую подгрузку, проверить на разных устройствах и скоростях. Нужен месяц.

При чем здесь детерминированность и вероятность? Притом, что стороны диалог то вели, но не поняли друг друга. Во-первых, огромная пропасть в исходных данных. Так пара десятков или тысяч котят? Поскольку менеджер живет в вероятностном мире, он допускает, что клиент захочет добавить больше 1000 котят, либо сделает это постепенно со временем. А что же услышал программист? Лимит котят равен 1000. Но ведь когда он будет писать код, программист не сможет поддерживать определённый кейс только чуть-чуть. Он будет поддерживать этот кейс либо полностью, либо никак. Значит, разработчик будет проектировать приложение сразу под 1000 котят, отсюда и сроки.

При этом, стоит немного поменять диалог, и эта проблема исчезнет сама собой:

- Нужны котята в таблице!
- Окей, сколько их?
- От 5 до 10. А если их будет 1000, то насколько дольше делать?
- Ну для 5-10 я сделаю за день, а 1000 - за месяц.
- Много котов пока не нужно, давай для 5-10, а дальше посмотрим.

Есть одна волшебная фраза, которую должен озвучить программист: “А это реально нужно? Без этой маленькой фичи разработка будет быстрой, а с ней - минимум в N раз дольше”. Она очень часто может сэкономить и время и деньги, но чаще всего не звучит.

Получается, что программисты плохие? Нет.

Как уже было написано выше, стороны должны поровну делить дискомфорт. Хороший менеджер должен сам узнать, из чего состоит эстимейт (это оценка времени или усилий, необходимых для выполнения задачи), что доставляет больше всего дискомфорта, и в каждой конкретной ситуации давать именно те исходные данные, которые оптимальны для задачи. А программист должен ему в этом помогать, подсказывая, что можно выбросить, экономя ресурсы, а где дешево и сердито сделать с запасом. В приведенном примере прослеживается очевидная вещь: в большинстве проблем виновата коммуникация.

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

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

Разработчик понимает, на каком этапе его фича или весь проект, только когда смотрит в код. А как же узнать об этом менеджеру, учитывая, что он так не может? Самый простой и логичный ответ - спросить у разработчика. При этом, менеджер отвечает за проект перед пользователем, клиентом, начальством, а иногда даже и Родиной. И очень сложно за что-то отвечать, не понимая, что вообще сейчас происходит. Отсюда эти вечные вопросы:

- “На каком этапе?”
- “Когда сделаешь?”
- “В чем затык?”
- “Сделаешь до N числа?”
- “Ну шо там??????”

Обычно эти вопросы задаются не с целью давления, как кажется разработчикам, просто менеджеры искренне не знают. Их действительно можно и нужно понять разработчикам, ведь по сути менеджеру нужно рассказать клиенту, что сейчас делается, показать, что было обещано сделать и уже сделано, либо объяснить, почему не успели. Но, по личному опыту и опыту коллег, который будет приведен позже, иногда для разработчика это выглядит как прессинг и проверка на устойчивость/компетентность/адекватность (нужное подчеркнуть).

Как тогда защитить себя от стресса разработчику? Самое первое - перестать воспринимать такие вопросы как личные оскорбления и сомнения в своих навыках и просто отвечать, как есть. Положил продакшн, потоп, пожар, кошка рожает, банально нет сил делать или же всё-таки сделал по срокам как обещал - об этом всём нужно говорить как есть. А лучше вообще не дожидаться, когда менеджер забьёт тревогу, и написать первым, чтобы можно было вовремя решить вопрос.

Есть ещё одна особенность взаимодействия разработчика и менеджера. Это жизнь в разном времени: Менеджер в будущем, а разработчик - в настоящем. Обычно в эту цепочку можно добавить ещё и тестировщика, который живет в прошлом.

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

- тестировщики дергают разработчиков в прошлое (“Глянь пж ты там на прошлой неделе делал задачу, я нашел баг…”)
- программисты тянут менеджера в настоящее (“Я тут читаю тз от клиента, и по-моему тут какая-то дичь. А зачем ….”)
- а менеджеры тянут программистов в будущее (“Посмотри пж эту штуку и примерно оцени”)

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

Представьте, вы пытаетесь уснуть, и в тот момент, когда уже почти уснули, кто-то постоянно вас дергает и спрашивает: “Ты спишь?”. И так по несколько раз за день, причем каждую ночь. Разработчикам об этом известно не понаслышке, они то же самое чувствуют, когда только войдут в состояние потока, а их выдергивают фразой: “Ты занят?”. Для качественной и продуктивной работы главный враг разработчика - внешний раздражитель. Обычно, состояние потока длится как минимум около 2-3 часов. Начинается с разбора, что уже было сделано, вспоминания проекта, настройки на работу. В самом разгаре продуктивность, концентрация и мотивация находятся на своём пике, что позволяет успешно щелкать задачи как семечки. Заканчивается оно завершением собственного плана, удовлетворенностью от себя и работы, хорошим настроением и приближением проекта к деплою. Что будет, если в этот момент потревожить программиста? Потеря потока и времени, а в дальнейшем входить в поток заново. Отсюда и раздражение программиста, и недовольство менеджера перфомансом последнего.

Всё это звучит красиво, однако, есть небольшая проблема. А как тогда коммуницировать, если всегда есть шанс сбить программиста с потока? 21 век - век социальных сетей. Договоритесь с командой об удобном всем канале связи и пишите туда. Как только адресат освободится немного - глянет.

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

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

А зачем же тогда менеджеру “дружить” с программистами?

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

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

На случай, если кто то не хочет читать полностью, ниже приведена более компактная форма со счетчиком микротем. Для менеджеров существует такая же выноска.

Мне главное, чтобы менеджер был адекватным, всегда был на стороне разработчика, а не клиента. И еще, чтобы не спамил в ЛС, так как это отвлекает от работы.
Хотелка для менеджеров: попытаться хоть немного разобраться в технологиях проекта, чтобы не требовать невозможного. Если есть какие-то ограничения платформы - чаще всего МП всё равно, требуют что-нибудь придумать, но все равно сделать, когда платформа этого не позволяет.
Недавняя проблема: изначально не обговорили с клиентом, как пользоваться АПИ, в итоге задача растянулась на неделю. Про подготовку данных для БД от клиента тоже не обговорили, пришлось вручную заполнять много контента.
Даже не знаю, что предложить, т.к мне пока с менеджерами везёт. Кое-кто только иногда может отвлекать со своими просьбами описать, что было сделано по одному проекту, но я понимаю, что от него это заказчики требуют, поэтому зла не держу.
Для меня, как для новичка, важно начинать проект с ТЗ, в котором описано, что конкретно хочет клиент. Не структура проекта, где додумай сам, а полностью описанные схемы работы АПИ (к примеру, какие-то функции математические, описанные этапы, приблизительные пункты сбора статистики, которые планируется выгрузить в дальнейшем). В общем, конкретика по ТЗ. Все обговорить, понятное дело, невозможно, но минимизировать ситуации "подразумевалось" и "это и так было понятно". Работа с БД и т.п. : если нужно как-то заполнять ее (большое количество данных), то нужен отдельный файл .csv к примеру, чтобы не заполнять вручную и тратить на это большое время. При получении каких-то сторонних АПИ - документация к ним, либо созвон с тем, кто ее выдал. Задачи на битриксе с разделением на горящие и не горящие задачи при старте проекта, к примеру нужен функционал, а не статистика и обсуждать тайминги, чтобы не работать ночами перед запуском проекта. Обговаривать, где будет размещен проект (вначале проекта). Общение нужно не только менеджеру с разрабами, а также фронту с бэком (особенно для начинающих разработчиков). Запись созвонов с МП, клиентом или еще кем-то, для пользования в дальнейшем.
Могу сказать только то, что нравится: Например, круто, когда разъясняются ясно и четко по указаниям и чем больше структурирована информация, тем лучше. Еще могу сказать, что удобно, когда за тебя что-то узнают, уточняют и все такое, и тебе не нужно искать, у кого взять эту информацию, переспрашивать у других, и можно сосредоточиться на самой информации.
Наверно самая большая проблема менеджеров в том, что они тупят. При чем ладно, когда они тупят с заказчиками и что-то не так ему рассказывают. Беда, когда они просьбы заказчиков передают не напрямую, а сами пытаются придумать, что надо сделать и это передают, хотя не имеют знаний, чтобы что-то придумать. Получается, что аналитик или разработчик должен придумать, как это сделать, а не менеджер. Часто даже заказчик придумывает, как сделать, хотя это ничего не решает, а менеджер не понимает, что у задачи есть какой-то подтекст и передает как есть, это по сути приводит к той же проблеме.

Пример: Мы делали приложение, а-ля тиндер для спортсменов. Кое-кто как-то написал, что заказчик хочет купить сервис для анализа изображений и банить контент. Кое-кто говорит, ну, разработчик, поресерч, что есть. Мы разные сервисы искали. Оказалось, что при публикации приложения в AppStore есть требование о блокировке нежелательного контента в течение 24-х часов. И мы просто добавили кнопку - блок и репорт.

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

"Если требование заказчика звучит необычно и не связано со вкусом, то стоит спросить: Зачем это нужно?".
"Если требование звучит витиевато, стоит обсудить решение с разрабом. Или разработчику достаточно знаний самому придумать решение?"

8. Что делать менеджеру, чтобы мне не мешать:

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

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

Скорее мне не хватает отзывчивости. Не люблю трекать время по задачам.

10. Было бы круто побольше участвовать в обговаривании сроков с менеджером, Бывает, что прилетают задачи с дедлайном, которые закрыть в срок можно лишь принеся что-то или кого-то в жертвы… Еще было бы замечательно получать более развернутое ТЗ и так же все необходимые данные, файлы, тексты по задаче сразу, а не, например, рыскать по фигме, в поисках нужной картинки или правильного тайтла нового блока. Когда все сделано идеально, работа становится более эффективней.

Положительные черты:

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

Отрицательные черты:

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

Рекомендации:

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

Микротемы:

Адекватность и поддержка: 4
Информация и документация: 2
Отзывчивость: 1
Проработка ТЗ: 2
Открытость для обсуждения: 2
Спам и отвлечение: 2
Техническое понимание: 3
Недопонимания и спешка: 1

Часто не делаются задачки, потому что разработчикам лень разбираться или неохота думать, как еще можно сделать. Говорят менеджеру нельзя. А в итоге можно!
Исходя из моего опыта могу выделить несколько пожеланий, что, на мой взгляд, улучшит взаимодействие менеджера и программиста (буду писать именно со стороны менеджера).
Во-первых, хочется сказать, что разработчики часто воспринимают задачу так, как будто ее поставил именно менеджер и ее выполнение нужно именно менеджеру. Но мы не придумываем задачи просто так, потому что нам скучно, все, что мы передаем в работу - это непосредственно идет от клиента, конечно, наша работа проконтролировать, как будет выполнена задача, поэтому мы стараемся тщательно следить за ее выполнением, а не просто накидываем правки, потому что скучно. Нам нужно будет отчитаться по результату клиенту и отвечать перед ним, если что-то не так. Но когда менеджер часто пишет, дергает и спрашивает про выполнение задачи - это опять же вопросы идут от клиента, а не от нас. Мне тоже бывает неловко часто написывать, но когда клиент постоянно интересуется - выхода нет).

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

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

Еще я не разбираюсь во многих технических моментах, поэтому часто прошу что-то пояснить, чтобы разобраться, думаю, это полезно будет в будущем, так как при следующей подобной задаче я, возможно, уже буду больше понимать. Но не всегда все понятно с первого раза, несмотря на то, что что-то может казаться для разработчиков мелочью или пустяком, поэтому хочется чуточку терпения (мне и так стыдно, когда я начинаю доставать вопросами). Все персонажи вымышлены, а совпадения случайны!
Во-первых, разработчик должен понимать, что всякие интересные механики придумывает клиент, а МП уже пытается эти механики отбить. Если уже пришли с интересной механикой, значит так надо.

Во-вторых, МП не всегда может всякую техническую штуку понять, и поэтому надо ему объяснять всё подробно, чтобы он понимал (с обоих сторон должно быть ощущение, что ты общаешься с не особо одарённым, потому что люди часто ошибочно думают, что собеседник их понимает).

В-третьих, нужно понимание, что МП находится между двух огней, и он не против тебя, а за тебя. У каждого здесь, конечно, свой подход, но я никогда разрабов не дергаю зря, потому что это незачем. Это же мои ребята! Я лучше для них что-то сделаю, как-то подвину сроки, а если не получается, нужно как-то сплочаться и быть заодно.
Больно, когда разрабы выражаются очень техническим языком, приходится переспрашивать и уточнять. Их это может злить, отвлекать. Чтобы их не отвлекать и по 100 раз не переспрашивать, было бы отлично, чтобы они излагали свои мысли более простым языком.
Если разработчик видит, что МП не понимает и требует какую-то невозможную фигню, не нужно на него наезжать. Может стоит предложить созвон и спокойно объяснить, почему так нельзя. Т.к. часто это желание клиента. Если это новые друг для друга люди, то нужно для начала познакомиться и разработчик должен заранее понять погруженность МП в тему, чтобы понимать, на каком языке общаться.
Не нужно бояться друг друга, и например, если не можешь внести какие-то правки сейчас, не игнорить МП, а написать ему, что задачу увидел и все норм, но сделаешь через час. Т.к. МП могут доставать клиенты и ему нужно ответить что-то, а это проще сделать, когда он знает, что происходит. МП также нужно обозначить четкие рамки, когда он может писать или звонить. Вне рабочего времени, только если случился апокалипсис. Иногда может писать вне рабочее время, то нужно сразу делать пометку, что это сообщение, чтобы не забыть и не нужно делать сейчас.

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

Если есть какие-то затыки и сложности, то нужно не замыкаться на самом себе, а идти и спрашивать других, узнавать, что где и как можно сделать, какие где варианты. Но понятное дело, что если самому какой-то базы не хватает, чтобы вникнуть в суть, нужно подтягивать её. И её ОДНОЗНАЧНО надо подтягивать, потому что когда-нибудь такая же ситуация ещё раз встретится, и не нужно искать отговорки "блин, сейчас загруз большой, не могу посмотреть". В изучении материала уж точно надо самим разбираться, другие максимум могут материал сам скинуть. Но это отступление.

Если есть проблемы любого рода, о них надо сразу говорить, их надо обсуждать, если есть какие-то затыки. Также важно (так кажется, что это не все понимают), менеджер и прогер — это одна команда, и надо работать сообща. Если у тебя что-то произошло, из-за чего ты не успеваешь что-то доделать, то не нужно оттягивать до последнего и потом говорить, что блин, не успел из-за того, что на той неделе у меня кошка рожала. Если она рожает, то об этом надо говорить сразу же, потому что менеджеру перед клиентом надо как-то отчитываться, и там либо согласуем ЗАРАНЕЕ перенос сроков, либо придумаем, как так извернуться, чтобы видели работу с нашей стороны (если понимаем, что в дедлайн укладываемся, но работа ведётся не первый день и каждый из них нужно о чём-то отчитываться). А то в таких ситуациях менеджер остаётся крайним, клиент будет крайне недовольным и злым. А злой клиент навряд ли будет в будущем допускать какие-то поблажки в плане правок, а то может и с оплатой что-то сделать не то.

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

Ну есть ещё придирка, к которой нормальный прогер скорее всего не будет прислушиваться, потому что нафиг тратить дополнительное время, но хотелось бы, чтобы если в условии задачи был какой-то косяк, то не полениться уточнить сразу, что не так (не все это делают). Или просто попробовать самим подумать, может какие-то варианты ещё попробовать. Вот скинул клиент почту, сказал, что из системы её надо удалить, но написал её с большой буквы (автонабор так сработал). В системе всё хранится с маленькой, и понятное дело, что поисковик ничего не найдет. Так можно же попробовать эту большую букву почты поправить на маленькую и посмотреть, может так сработает. И если так, то можно будет потом постановщика задачи ткнуть носом в ошибку в условии, но задачу сделать. Можно же иногда самую малость подключать творческий подход к решению проблем, не всё всегда сваливать на других. Мы же в команде как никак работаем, и постоянное перебрасывания мячика к нормальному результату навряд ли приведёт.

7. Много тезисов, с чем сталкивались во время работы.

Для некоторых разработчиков правки - личное оскорбление.
Менеджер может вкинуть задачу с дедлайном реальным и ликвидироваться вплоть до этой даты. Не поинтересоваться, как дела, как процесс. А только в назначенный день вернуться за результатом.
Менеджеры могут делать доки для разрабов (те же баг-листы) ожидая, что разработчик там дальше работает сам, а менеджер больше этот докс не открывает. Зачем делал - непонятно.
Менеджеры наваливают кучу правок задач, часть в Б24, часть потом в телеге. И, естественно, разработчик может что-то упустить, но виноват все равно будет он в мире менеджера.
Менеджер может почувствовать ложное чувство власти. Да, он руководитель, но не бог. Не стоит орать на разраба в силе “ты должен это сделать и меня больше ничего не волнует!!!”.
Просишь помощи - тебе помогли - поблагодари!
Переход на личности и оскорбления (вообще дно).
Субъективная критика работы. Работает в две стороны. Ты вот в задаче мог покрасивее слово написать (что сути не поменяет).
Разработчики боятся давать оценку и открещиваются от нее.
На вопрос все понятно? Отвечают да. А в итоге не понятно, задача сделана не так, а дальше смотри 1 и 3 пункт.
Разработчики не всегда готовы идти на созвон, как будто там на них будут орать либо в чем-то обвинять.
Менеджеры могут тупо кидать скрины переписок с клиентом, либо пересылать сообщения, не удосуживаясь написать самому.
Менеджеры могут закинуть разработчика в чатик, а потом только его тегать и все. Итог: недовольный разраб и менеджер-чайка.
Поливание грязью клиента.
Не всегда есть должная предусмотрительность.
Стремление завалить тяжелыми и непонятными терминами в надежде, что менеджер отстанет.
Стиль общения от свысока “да кто ты, тебе не понять” до “ты мне зп не платишь”. Но думаю тут зависит от качеств и воспитания человека.
Сказать, что нельзя, когда можно.
Истерики из-за доработок, или когда при тестировании не работает.

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

Положительные черты:

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

Отрицательные черты:

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

Рекомендации:

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

Микротемы:

Негативные эмоции: 8
Некорректное общение: 3
Отсутствие предусмотрительности: 2
Трудности в общении: 4
Недостаток терпения: 2
Боязнь оценки и ответственности: 1

Список вдохновений:

Как подружить менеджера и разработчика

Понимание ролей

Зачем же всё-таки разработчику “дружить” с менеджером?

Бонусный материал

Фидбек от разработчиков:

Аналитика

Фидбэк от менеджеров:

Аналитика