Задать вопрос

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

За что вы уважаете менеджеров?
  • Вопрос задан
  • 3539 просмотров
Подписаться 11 Оценить Комментировать
Пригласить эксперта
Ответы на вопрос 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 Модель может уважать Контроллер.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Похожие вопросы