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

Согласен.
Менеджер  может успешно управлять проектом, не зная самого ПО.
Гораздо хуже обратное.
Когда "менеджер" знает только ПО, и думает что этого достаточно чтобы управлять проектом.

Я так поняла что можно управлять кому угодно и чем угодно. А вот, например, программировать кому угодно не получиться. Вся страна управляется "кухарками" и имеем, что имеем. Просто результат программиста виден сразу, а менеджера можно и не увидеть никогда.
Да нельзя управлять, не зная предметной области. Это плохой управленец и его управленцем язык не поворачивается назвать. Если ты хочешь управлять кем то хорошо, то сначала научись управлять собой и вникни в отрасль, которой управляешь!

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

Где же тогда взять критерии, по которым можно определить на сколько именно надо углубляться менеджеру в предметную область?

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

А с каких пор качество управленца определяется знанием предметной области?
Ему что, надо знать как система работает с БД чтобы составить бюджет?
Ему надо знать особенности архитектуры чтобы опросить разработчиков на предмет трудозатрат и составить план-смету с продажником?
Ему надо владеть используемой в компании IDE чтобы планировать загрузку сотрудников на год с учетом проектов, больничных и отпусков?
Ему нужно уметь писать на Java чтобы поддерживать мотивацию команды и разруливать конфликты?

Знание предметной области это несомненно плюс и важно, но оно  вторично по отношению к управлению.

Да...да...и да. А закладывать бюджет в 2 дня  на перенос огромного функционала (из сотни таблиц) из одного вида системы в совсем в другой, оправдываясь тем, что только скопировать надо таблицы mssql в oracle, это правильно? И никак не понимая, почему нужен год, когда он сам может их ехселя в ворд перенести одним нажатим клавиши. И главное обнадеживать Заказчика. И потом может это и неправильно, я лично не могу себя заставить уважать манагера, который не разговаривает со мной на одном языке и стимула для выполнения его хрустальных планов не испытываю.

Ну тут же проблема не в предметной области, а в менеджменте.

Он НЕ СПРОСИЛ про трудоёмоксть и сроки. Это его ответственность и его жопа, пусть он и страдает — выговором, лишением премии, увольнением. Вы-то тут при чём? Это его проблема.

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

Значит он просто хреновый менеджер. Предметная область тут совсем не при чем.

Ну тут же проблема не в предметной области, а в менеджменте.

Он НЕ СПРОСИЛ про трудоёмоксть и сроки. Это его ответственность и его жопа, пусть он и страдает — выговором, лишением премии, увольнением. Вы-то тут при чём? Это его проблема.

Проблема моя. Когда менеджер заявляет, что 5 мин, а аналитик говорит год. Как-то Заказчик начинает косо смотреть на аналитика и считать его саботажником. Но в принципе, вы наверно правы, если бы был нормальный бизнес, а не по знакомству, то за такие решения отвечал бы менеджер, а не аналитик.

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

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

Не сталкивалась с такими, поэтому просто не знаю.

Мне кажется, понимание предметной области упрощает задачу, но понять предметную область можно в среднем за полгода непрерывной работы в ней.

Можно вспомнить советских конструкторов - Глушко, Королева и многих других. Все они выросли из "разработческой" среды и потом ушли в управленцы.  Видимо, в большинстве случаев они становились вполне удачными менеджерами. А можно вспомнить Чубайса - он является хорошим примером менеджера без понимания области в которой он ведет деятельность. Приватизация, энергетика, нанотехнологии - первая точно неудача, вторая - насколько я понимаю тоже к этому идет. Посмотрим что получится в третьей области!

Управленец не обязательно должен знать ПО, но он должен хорошо разбираться в процессе "Как именно достигать результата в айти проектах". Его функции грамотно поставить задачу, определить срок ее исполнения и проконтролировать результат.
Конечно, если управленец знает ПО, то ему легче выполнять свою работу.
Если не знает, то это его проблема, пусть находит людей. которые обладают нужными знаниями и на которых он может положиться, при решении вопросов в которых он "0". В любом случае за результат отвечает управленец. Если аналитик "накосячил", то виноват управленец. Варианты его ошибки: выбрал не того человека; поставил не правильную задачу; не правильно оценил сроки и пр.

Александр 3 не разбирался в деталях экономических теорий, был далек от проблем транспортных перевозок, но он разбирался в людях. В случайной встрече с Витте он разглядел его потенциал и предложил работу. А через некоторое время в России была проведена экономическая реформа и другие успешные проекты. По сути Александр 3 это аналогия управленца успешно управляющего проектом, без знания ПО.

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

Можно вспомнить советских конструкторов - Глушко, Королева и многих других. Все они выросли из "разработческой" среды и потом ушли в управленцы.  Видимо, в большинстве случаев они становились вполне удачными менеджерами.

И Королев и Глушко не были менеджерами в том смысле, как мы понимаем это слово сейчас. Они были скорее "тим лидами", в то время как реальное управление осуществляло непосредственно советское руководство.

А можно вспомнить Чубайса - он является хорошим примером менеджера без понимания области в которой он ведет деятельность. Приватизация, энергетика, нанотехнологии - первая точно неудача, вторая - насколько я понимаю тоже к этому идет. Посмотрим что получится в третьей области!

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

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

Александр III, например, грамотно ставил задачи, и он же, как заказчик знал что должна решить задача, и оценить результат.
А Витте соответственно отвечал за поиск и реализацию решения. Если говорить о тех же железных дорогах, то наверняка задачей было бесперебойное ж/д снабжение всей страны в соответствии с графиками движения. А национализация ж/д была способом решить эту задачу.
Но был ли Витте железнодорожником? Знал ли он как делать паровозные котлы? Вряд ли. Но при этом прекрасно справился.

В итоге наше обсуждение можно выродить к вопросу: Обязан ли начальник РЖД знать как делают паровозные котлы?
Имхо в такой  постановке, ответ очевиднее чем изначально:)