Здравствуйте, Gaperton, Вы писали:

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

В сущности, это очевидно — исполнители должны этот "дух" как минимум понимать. Это означает, что они должны знать не только ЧТО надо делать, но и понимать, ЗАЧЕМ. А именно, исполнители нижнего уровня должны хорошо понимать логику принятия решений уровня выше.

Другими словами, программисты должны разбираться в продакт менеджменте и маркетинге. Не обязательно глубоко — им не обязательно уметь генерировать стратегии и знать нюансы ранка, но они ОБЯЗАНЫ ПОНИМАТЬ продуктовую стратегию, знать целевую аудиторию, ее потребности, и особенности позиционирования для того продукта, который разрабатывают.

То есть программисты ДЛОЖНЫ ПОНИМАТЬ маркетинговую стратегию, а менеджеры ДОЛЖНЫ ДОВЕСТИ эти вещи до программистов. И все будет зашибись.
Я долгое время пребывал в обеих ипостасях, я должен заметить, что этого категорически не достаточно. Менежемент очень туго воспринимает обратный поток информации, от исполнителей вверх, к управленцам.
Как человек, категорически не способный к механическому выполнению поставленных задач (из-за этого, кстати я расстался с карьерой кадрового офицера), я переодически сталкивался с подобными проблемами.
К примеру несколько лет назад, я участвовал в проекте разработки продукта из области BI в роли руководителя группы разработчиков и архитектора. Еще на стадии анализа мне стало понятно, что продукт позиционируется не правильно, упор делается не на те свойства, которые действительно могут быть востребованы. Но все попытки достучаться с до менеджеров отвечающих за выход продукта и продуктовых аналитиков ни к чему не привели. Все воспринималось как попытка влезть не в свою зону ответственности и даже как сабботаж. В результате продукт выл выпущен в срок и в соответствии с требованиями, но коммерческого успеха не имел. Во второй версии, насколько я знаю, они таки сделали изменения, которые я предлагал с самого начала, но я там уже не работал...
Этот пример характеризует общую проблему. Продуктовые менеджеры в большинстве своем не готовы воспринимать фидбек от разработчиков, направленный на улучшение маркетинговых свойств продукта. Разработчики часто сталкиваются с тем, что получают детальные требования, которые вызывают только улыбку. Но попытки объяснить, что все это можно сделать намного лучше, обычно наталкиваются на полное непонимание. Порой ни менеджер, ни заказчик ни пользователь не видит, что создаваемый продукт имеет скрытые потенциальные возможности (например, накопленные данные позволяют проводить корреляционный анализ, или облегчить ввод новой информации), но разработчику очень трудно продвинуть свои идеи "наверх". "Для этого у нас есть аналитики", "заказчику это не надо", "стратегия развития продукта это не предусматривает" — вот что слышит разработчик, и после этого стоит ли удивляться, что разработчики предпочитают "тупо кодировать по требованиям".
Требуя креатива в решении задач от подчиненных надо быть готовым делегировать им полномочия, и при этом не забывать что ответственность все равно остается на тебе. К этому большинство менеджеров категорически не готовы. И поэтому в управлении проектами царят действительно армейские методы, но описываются они не загадочным Auftragstaktik, а принципом, который у нас в армии назывался "принципом жолудя" — "Живешь среди дубов, и не знаешь какая свинья тебя съест"