За что разработчик может уважать менеджера?

За что вы уважаете менеджеров?
  • Вопрос задан
  • 3536 просмотров
Пригласить эксперта
Ответы на вопрос 9
80x86
@80x86
За то, что это — образ жизни.

Я попробую изложить тут свой опыт. Думаю, получится ОЧЕНЬ субъективно. Увы.

Последние три года мне приходится быть этаким Jack Of All Trades (к счастью, без продолжения “master of none“). Я начальник отдела автоматизации учебного процесса довольно большого, но весьма вялого до этой самой автоматизации ВУЗа. Жизнь сложилась так, что кроме этого я занимаюсь веб-разработкой (скорее фрилансом) и координацией нескольких полузакрытых проектов, выросших из аутсорса.

Соответственно, приходится заниматься административной работой, организационно-координационной и непосредственно разработческой. И рисовать, верстать, копирайтить, тестировать, составлять матмодели, заниматься статистической обработкой и немного паять.

Это, так сказать, для более глубокого понимания того, почему будет много субъективизма с претензией на объективность.

До этого, примерно лет пять назад, когда я был чистым разработчиком, на работу менеджеров проекта/команды (да чего уж кривить душой — и на работу любого административного работника) смотрел с презрением, граничащим с этаким public riot. Скорее всего, мне просто не попадалось действительно хороших ПМов, которые бы умели поставить рабочий процесс так, чтобы разработчик понял, что о нём заботятся.

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

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

— Надо срочно сдать! Хватит тянуть резину, что у тебя там, почему нельзя сделать быстрее?

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

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

Потом было много разных событий, которые во мне окончательно убили веру в то, что менеджер — это друг, товарищ и практически брат. Эти люди не видели проблем коллектива, не хотели для достижения результата жертвовать своими ресурсами или вообще абстрагировались от проблем за мифическими скрамами, процессами, UML и прочей серебряной атрибутикой современного IT.

А потом я стал начальником.

Начальником болота, где не слышали про VCS, например. Вообще. И про проектирование.

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

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

С тех пор многое поменялось в голове: я научился жертвовать перфекционизмом в пользу выполнения поставленной задачи; научился делегировать работу; научился избавлять разработчиков от головной боли и смятений в выборе способа решения задач, выполняя роль своеобразной бритвы Оккама; научился… да научился много чему.

Теперь я понимаю, что основная работа менеджера — это, в первую очередь, аргументированное и действенное избавление разработчика (исполнителя, подрядчика и т.д.) от психологической «головной боли», которая вызывается тем, что тот выполняет несвойственную ему работу. Собственно, за это разработчик и может уважать менеджера, как человека, профессионально выполняющего свою работу.

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

Слава святому фон Нейману, такие люди, оказывается, есть и их достаточно много. В сравнении себя со многими из них я понимаю, что мне есть, куда стремиться. И это потихоньку топит лёд моего внутреннего разработчика, который потихоньку учится уважать менеджеров.
Ответ написан
Комментировать
Stdit
@Stdit
За то, что он снимает с меня обременительную задачу общения с заказчиком напрямую.
За то, что он понимает и грамотно описывает желания заказчика, после имплементации которых последний получает именно то, что хотел.
За то, что он правильно расставляет этапы и знает цену хотелкам-переделкам, особенно после утверждения заказа.
За то, что создаёт комфортные и приятные условия работы (мебель, воздух, чистота, шумоизоляция и т.д.).
Вообще, за то, что он понимает, зачем он нужен и как его работа повышает стоимость часа. И делает это, а не чатится в социальных сетях.
Ответ написан
@sergei-grigorev
за то, что они закрывают глаза, когда я вместо того, чтобы заниматься непосредственно «реализацией новой фичи продукта», занимаюсь рефакторингом, оптимизацией ядра, или автоматизации процесса сборки, деплоя. Я не говорю, что это происходит постоянно, просто иногда это действительно нужно, и менеджер может позволить затратить пару дней на это, не донимая вопросами «К какому сроку будет готова новая фича?».
Ответ написан
Комментировать
Cofemiss
@Cofemiss Автор вопроса
ок, это действительно важно.
тут попалась статейка намедни — java.dzone.com/articles/fix-code-immediately

однако лояльность у менеджера, по рабочим вопросам, — отдельная тема.
Ответ написан
Комментировать
@edogs
Менеджер позволяет оставаться узким специалистом.
Не распыляясь на «рекламу себя, поиск верстальщика, общение с клиентом» и прочее, что не имеет прямого отношения к основной профессии.
Ответ написан
Комментировать
Akson87
@Akson87
За наличие собственного серьезного программерского опыта и понимания того, что же разработчики делают.
За понимание того, какие сроки реальны, а какие нет.
Ну и за то, что человек нормальный и адекватный.
Ответ написан
Комментировать
@g00d
пока не встретил такого человека :( все ПМы что я встречал были не достаточно компетентны. А вообще уважение появляется когда человек действительно что то знает и умеет, и это больше и лучше чем ты
Ответ написан
Комментировать
xldsakamrhahn
@xldsakamrhahn
Уважаю, если менеджер понимает зачем он нужен, то есть понимает, что не поганять пришел кнутом, а создавать условия комфортной работы и налаживать отношения в коллективе и между ним.
Ответ написан
Комментировать
ANUFRiY
@ANUFRiY
За то же, за чтов MVC Модель может уважать Контроллер.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
Искра Екатеринбург
от 80 000 до 100 000 ₽
Art gorka Санкт-Петербург
от 60 000 ₽
от 40 000 до 60 000 ₽
19 апр. 2024, в 22:48
100 руб./за проект
19 апр. 2024, в 20:43
20000 руб./за проект