Комментарии 30
"Менеджер кидает разработчика в чат с клиентом, чтобы разработчик отвечал клиенту на технические вопросы" - по моему крайне негативному опыту, это самый верный способ довольно быстро потерять или клиента или разработчика, а то и обоих сразу...
Можно вспомнить Парацельса - "Всё есть яд, и ничто не лишено ядовитости; одна лишь доза делает яд". Иногда чат с заказчиком проворачивает непроворачиваемое, потому что у заказчика с программистом может оказаться общий язык (особенно, в районе высокотехнологичных API).
Избыток оного начинает отравлять всё. Так что в малой дозе это может быть полезно, превышение ПДК ведёт к LD50.
На практике это выглядит так: разработчика приглашают в чат/на митинг (публичный), просле чего разработчик чат/митинг покидает и больше никак не появляется в общении с клиентом.
В статье обе эти проблемы: и что говорит, и что таск под это не планируется. А еще (в случае, если после решения вопроса разработчик не покидает чат) есть проблема, что пошатнуть мотивацию исполнителя на проекте очень просто, если оставлять ему доступ к нефильтрованной информации от клиента.
Могу, конечно, ошибаться, но мне кажется общепринятым, что и в компетенцию, и в обязательные софт-скиллы, скажем, начиная от Senior Software Developer входит умение общаться с клиентом.
я не ставила минус, но эта фраза
У вас какие-то очень нежные разработчики, которым эмоции клиента работать не дают.
выглядит так, будто «потерпи некоторое дерьмо, а то че как неженка» для вас является нормой. А в реальности работать там, где приходится что-то терпеть и не налажены конструктивные отношения — стремно, и не нужно на такое соглашаться. И если не соглашаешься — ты обычный и адекватный, а не неженка.
К тому же вы сами пишете, что скилл коммуникации ОТ синьора.
А мидлам и джунам нафига без таких скиллов в чатах сидеть? И чем в этот момент занят менеджер, если команде приходится разруливать коммуникацию?
это самый верный способ довольно быстро потерять или клиента или разработчика
не прям САМЫЙ, но да, способ довольно эффективный (если цель — кого-то потерять)
при этом давайте будем реалистами, иногда нужно показать разработчика клиенту — когда клиент «шарит» и им проще напрямую договориться. Или наоборот, когда клиент не шарит и из-за этого робеет перед авторитетом разработчика.
Но эффективнее это делать на встречах, а не в общих чатах: в чатах решаются коммуникационные задачи, и лучше бы это делать ПМу
Менеджер без технического бэкграунда лезет в код: проверяет, критикует, мешает, навязывает свои решения. Уровень горения: 🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥
Менеджер без технического бэкграунда лезет в код
АААААААААА!!!!!!!!!!!
Есть ситуация гораздо хуже, с которой встречался лично:
Менеджер, который думает, что у него есть технический бэкграунд ...
(в итоге пришлось идти к гендиру и прямо ставить вопрос "или или", задвинули всё же менеджера)
Повезло. У меня вот на прошлом контракте гендир без технического бэкграунда, который думал, что он у него есть, лазил в код...
Тоже встречался с таким. Был гендир который решил, что он нашел генеальное решение как писаться html используя java. А давай-те мы сделает кучу классов - которые являются тегами в html - будем их вклюдывать друг вдруга, а потом вызовем toString и они сами весь html соберут. Чем его не устроили готовые решения на подобии Vaadin если уж сильно хотелось чтобы на java все было неизвестно. И это решение он внезапно распространил на все проекты - а давайте свой велосипед делать.
Ну попробовали полгода - а потом выкинули и начали все переписывать как у всех :)
ну это по классике Даннинга-Крюгера:
люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом не способны осознавать свои ошибки в силу низкого уровня своей квалификации
Гендиру нужно было решить какую-то проблему, вот и решал. Но было недостаточно знаний, чтобы понимать, как такие проблемы уже решались и какая вообще есть практика решения проблем: поэтому начал изобретать свой велосипед.
А теперь фокусы: есть некомпетентный человек, которому нужно решить проблему, но возможно он решает ее неоптимальным способом.
А есть компетентные люди — инженеры.
Задача компетентных людей: понятно и корректно объяснить, как лучше решать проблему. А не соглашаться на всё, что предложат люди которым нужно решать проблему, а потом переживать, что «ващет по-другому нужно было сделать, я это всегда знал, но молчал!»
Задача компетентных людей: понятно и корректно объяснить, как лучше решать проблему. А не соглашаться на всё ...
Иногда (а на деле часто) альтернативы нет - не дают. Человек же уверен и у него власть(и зарплата в 10 раз выше среднего) и "ответственность"! А чего добился в жизни "компетентный человек"?
Ну с одной стороны, да: кто несет ответственность (в том числе за финансовые потери), тот и принимает решение. А еще может оказаться так, что исполнитель не видит каких-то ограничений, потому что не смотрит на ситуацию «сверху». Часто управленцы принимают решение не по принципу «чтобы стало чотко и хорошо», а по принципу «как-нибудь решить проблему и не уронить все вокруг, что можно случайно уронить».
Но с другой стороны, если ты среди подчиненных считаешь себя самым умным — зачем тебе подчиненные :)
Это было лет 10 назад. Ему объясняли. Но это был человек своеобразный, который мог всех разрабов собрать и покрыть матом как прораб на стройке, без преувеличения. Чего только стоило интересное решение - "каждый разработчик в один из дней подписывал бумажку где обязался не допускать более одного бага в неделю, а если допустит - фиксит в личное время".
Собственно после одного из таких объяснений была группа разработчиков, которые написали письмо руководству с предложениями как улучшить процессы, вполне корректное - даже без ссылок на гендира вообще. Итог - всех кто подписался уволили. Увольнение кстати тоже отдельный цирк, просто письмо утром на почте - чтобы к моему возвращению в страну (он тогда был в отъезде) вас тут небыло.
Я не сильно конечно расcтороился и сейчас от этой компании мало что осталось ,а гендира все таки через пару лет попросили уйти.
А о каком менеджере идет речь? Ибо PM (менеджер по продукту), это одно. А engineering manager (руководитель команды разработки), это другое. Как по мне, смешивание этих двух ролей как раз таки много конфликтов и создает.
С тем же техническим бекграундом, в случае PM он не особо нужен (ну что то базовое), а руководитель отдела разработки должен быть экспертом. Ну и так далее по списку.
Имею ввиду менеджеров проектов / продукта — руководитель команды разработки может выполнять широкий спектр обязанностей. И понятно, что если «лезть в код и давать фидбэк» прямая обязанность, то руководитель разработчика должен это делать.
А когда в код лезет руководитель, но не разработчика а проекта (которому нужно чтобы проект был сделан, а не разработчик научен) то возникают проблемы.
смешивание этих двух ролей как раз таки много конфликтов и создае
верно, лучше не смешивать — на эти роли нужны люди с разным стеком компетенций
Менеджер проекта разработки без технического бэкграунда - это как слепой канатоходец
Знаю пару ПМов которые делают все что в статье сразу
«Свою работу делать не умеют, зато лезут в мою»: 7 вещей, которыми руководители проектов бесят разработчиков