Если кто-то именует функцию (реальный случай) типа

IXMLDomDocumentLoadXMLAsynchronously(…, …)

то абсолютно неважно, кто ты – менеджер или кодер.

Если кодер – будь добр, прими к сведению руководство по стилю
кодирования.

Если такие имена навязывает менеджер – все зависит от него.
Скорее всего придется сказать “ээээ… йес, афеметив!”
Ну или поискать другого.

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

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

Мой опыт мне показал, что от каждого человека можно получить положительный результат, найти к нему подход. Признаюсь, что я тоже вначале своей карьеры менеджера пытался “рулить” на низком уровне, диктуя, как именно нужно делать, но быстро отказался от этой идеи. Вместо этого я предпочитаю теперь “прессовать” своего лида, получая от него нужный мне результат, настойчиво подсказывая, что он также не должен все делать и переделывать за разработчиков, а в свою очередь должен ими командовать. Ну а если результат меня не устраивает, то не жалею сил и терпения, чтобы объяснить почему он меня не устраивает и потом дать указание переделать. В результате вырастают нормальные, опытные ребята, на которых можно положить и поручать ответственные задачи. Они четко представляют вертикаль организации, знают свои права и обязанности, знают как нужно решать проблемы и достигать нужного результата. Как менеджеру мне остается только отдать указание и проконтролировать его выполнение Вуаля!

Если реч идет о технических мелочах и попытках бывалого программиста, а ныне руководителя, котролироват даже “выбор имен классов”, то почему бы не исползовать подход, когда ПМом является не “техничекии” человек, а руководител, которыи способен оценивать работу и продукт с точки зрения заказчика и потребителя продукта, которыи может организовать и котролировать ПРОЦЕСС разработки?

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

Manager.net.ua – независимый украинский информационный ресурс для руководителей проектов в сфере разработки программного обеспечения.