Оправданно ли поведение менеджера проекта в описанной ситуации?
=================================================================

 Добрый вечер, я работаю тестером в небольшой компании. Однажды я наткнулся на такой текст:  

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

  
  

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

Мне кажется, что попадавшиеся на пути менеджеры проектов лезут во все дела, даже куда им и не надобно соваться. Я решил порассуждать, а собственно почему? И сделал вывод: потому что у обычных работников есть четко измеримый результат работы: написанные строки кода для исправления баги, оформленные отчеты по тестированию. А у менеджера: поговорил с заказчиком... принял важный звонок... посидел на собрании... так абстрактно, неосязаемо  

Приведу примеры:  

- Первый менеджер любил повозиться с фронтендом и продвигал свои решения на js вместо решений коллег  

- Второй менеджер периодически (и безуспешно) возился с настройкой php-fpm и nginx для нужд проекта, имел доход с pet-project'а на ruby и сорил фразами "как сложно с *этими* людьми, в отличие от программ. С ними все просто: true or false, а с этими..."  

- Третий менеджер был бывшим тех. писателем. Он ревьюил документацию, подсказывал junior'ам как работать с БД, а также совмещал должность тестлида  

- Сейчас я в другой конторе, новый менеджер... лезет **буквально** во все, как Юлий Цезарь. Он "подсказывает" как тестировать, но со стороны идеи выглядят нелепо. Поменьше проверять валидацию вводимых значений, не уходить дальше основных сценариев (хорошо, это еще можно понять), оперировать только объективными критериями качества (извините, конечно, но если общеуважаемые эксперты тестирования вроде Баха, Болтона, Вайнберга заявляют о субъективности понятия качества для каждого отдельного лица, а тут...), автоматизировать проект как можно больше, чтобы тестировщики не обращали внимания на него в будущем (уже остапа понесло; а автотесты поддерживать кому? а то, что не покрыто ими?). Он может забрать повешенный на меня запрос, "проверить" (за пару минут), а потом от заказчика приходят жалобы. Половина того, что тестеры хотят завести - по его мнению, "не баг, а фича". Режет сроки для test lead на минимальные. Отпускает циничные шуточки по поводу заводимых багов, которые я бы счел приемлимыми максимум для анонимных комментариев на одном ресурсе с доменом .it Касательно разработки у него есть свои четкие представления, какие технологии true, а что не true. Оценка сроков, реалистичность внедрения, человеко-часы - не дело ли teamlead? Как оказалось, нет. Отдел UX-дизайна перегружен его видениями правильного дизайна, согласно статьям с Хабра. При этом в разработке наняты только backend, нет выделенных для frontend программистов. Люди, способные оптимизировать запросы к БД, разбирающиеся в тонкостях orm и настройки nginx, должны как малые дети копаться в js-лапше, на каждую правку делая по 2-3 других бага, за что тестерам прилетает по шапке потом.   

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

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

 Я так понимаю вопрос больше риторический чем требующий практического решения или кодревью ) Так сказать крик души, покинувшей комфортное тело ) Плавали, знаем.  

Если нужен ответ - ПМ в большинстве своем мудаковат, дурен и имеет завышенное ЧСВ, страдает синдромом Даннинга-Крюгера(оно эффект на самом деле, но эти люди им **страдают** однозначно). Обусловлено тем что такой профессии как таковой нет, эти люди занимаются трансляцией из "Сделайте шоб красиво" в "Надо на бутстрапе во флэт дизайне все сверстать, будем делать спа". То есть либо малокомпетентные разрабы, осознашие тщетность потуг в области разработки, либо наоборот, менеджеры среднего звена из МВидео, осознавшие крутость современных технологий, но на разработчика, опять же, не тянущие. Некоторая часть выбрала это направление осознанно и ответственно, их мало, но они есть, они тянут проект, хорошо разбираются в людях и планировании, кароче этакие ангелы ~~Чарли~~ хранители фирмы. Вид редкий, исчезающий, занесен в Красную книгу. 

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

 Я для себя давно вывел: хороший начальник всегда сможет быть хорошим подчиненным, хороший подчиненный не всегда сможет быть хорошим начальником.  
  

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

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

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

В общем мой совет: не парьтесь тем, что делает менеджер, парьтесь задачами за которые Вы отвечаете. 

>  что PM нужен для переговоров с заказчиками и для трансляции мыслей высшего руководства нам в виде, доступном для понимания простых смертных.

 сейчас вот обидно было(  
  

В целом - все 4-е ПМа с боязнью делегирования, и когда ПМ садится делать что-то вместо разрабов это прискорбно.  
  

Выражения от ПМа типа "Не баг а фича" и урезание сроков \ урезание какого-то вида тестирования = в 90% чуваку просто дали проект с горящими сроками и он ищет способы чтобы в эти сроки уложиться. По этому я бы его назвал только "полуМудаком" 

 Все это делается, по моему, от безделья и кучи свободного времени у ПМ.  

У ПМ должна быть основные задачи:  

1. организовать процесс разработки;  

2. контроль за временем разработки версий ПО;  

3. СДАЧА РАЗРАБОТАННОЙ ПРОГРАММЫ ЗАКАЗЧИКУ: оформление (или организация этого), ПОЛУЧЕНИЕ, ПОДПИСАНИЕ ВСЕХ НЕОБХОДИМЫХ ДОКУМЕНТОВ ТОЧНО В СРОК.  

4. РЕШЕНИЕ ВСЕВОЗМОЖНЫХ ПРОБЛЕМ И ПОТЕНЦИАЛЬНЫХ ПРОБЛЕМ ПРИ СДАЧЕ ПО ЗАКАЗЧИКУ С ЦЕЛЬЮ СМ. П.3.  
  

Вот как раз с п.3-4 часто у ПМ и проблемы, нужно им этим заниматься. Вроде как есть даже в инете должностные инструкции с описанием чем ПМ должен заниматься.  
  

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

Как решить подобную проблему, как бы "подсказать" ПМ об этом, чтобы потом не аукнулось на данный момент не представляю) 

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

  

Вполне может совмещать с тим-лидом. 

 Эх, как я вам завидую )