Какое -то извращение пошло...Начальник железных дорог не выпускает паровые котлы. Вопрос тогда должен стоять так: должен ли директор завода знать как выпускаются котлы или Должен ли начальник ж/д знать в каких вагонах он перевозит груз и людей? Ответ тогда очевиден: ДА. ОБЯЗАН!

Как выпускаются котлы - обязан знать главный инженер.
Директору эти знания полезны и желательны, но не обязательны:)

Как выпускаются котлы - обязан знать главный инженер.
Директору эти знания полезны и желательны, но не обязательны:)

По Вашему принциму, тогда на должность директора завода вполне подойдет директор ресторана, главное подобрать Главного инженера. Только на практике я такое не видела

По Вашему принциму, тогда на должность директора завода вполне подойдет директор ресторана, главное подобрать Главного инженера. Только на практике я такое не видела

Это уже другая сфера работ. Ресторан - не производственная отрасль.

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

Так что на знании предметной области свет клином не сошелся. Это важно, но вторично.

Управленцем в данной ситуации был Витте, а Александр 3 только заказчиком.

Александр 3 управлял государством, а дальше по нисходящей Витте управлял той зоной которую ему выделили.

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

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

Это уже другая сфера работ. Ресторан - не производственная отрасль.

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

Так что на знании предметной области свет клином не сошелся. Это важно, но вторично.

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

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

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

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

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

Дает неправильную задачу, запросите под ее выполнение информацию. Говорит нужно выполнить за 1 день, говорите конечно, но для этого нужно и далее по пунктам говорите, что вам конкретно нужно, чтобы выполнить за 1 день. Может быть жизнь окажется сказкой и он сразу предоставит все по вашему списку. А если не предоставит, то укажите точное время за сколько вы успеете выполнить каждый пункт списка. Вы же не отказываетесь выполнить работу за поставленный срок, просто еще нужно подготовиться к работе...

Господа, вернемся к определениям. Мы будем говорить о сотруднике у которого в трудовой "написано менеджер" или который "является менеджером"?
Давайте для начала определим эту разницу. Угу?
Чего настоящий то менеджер должен делать?


Кстати, можно еще взять модель PAIE Адизеса и рассмотреть ее.

Давайте спустимся с высот лидеров государств, директоров контор в 30 000 человек и прочих топов до уровня операционного менеджмента. Что там говорят великие? Что является первичной целью операционного менеджмента?

Давайте спустимся с высот лидеров государств, директоров контор в 30 000 человек и прочих топов до уровня операционного менеджмента. Что там говорят великие? Что является первичной целью операционного менеджмента?

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

Э. Голдратт:
"Улучшение потока [уменьшение Inventory] - это первичная задача операционного менеджмента".

Если некто не уменьшает Inventory, то он не выполняет основную задачу операционного менеджмента. Для уменьшения Inventory в проектах и процессах применяют различные методы. Определитесь с тем, рассматриваем мы проектного менеджера или процессного. И двинем дальше.

Э. Голдратт:
"Улучшение потока [уменьшение Inventory] - это первичная задача операционного менеджмента".

Если некто не уменьшает Inventory, то он не выполняет основную задачу операционного менеджмента. Для уменьшения Inventory в проектах и процессах применяют различные методы. Определитесь с тем, рассматриваем мы проектного менеджера или процессного. И двинем дальше.

Давайте определимся с понятием Inventory. Я бы предпочел говорить по-русски и использовать термины на русском.

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

Больная тема в нашем обществе.
Слушал пару лет назад интервью Рошаля, в котором он костил Голикову. По его словам министром здравоохранения должен быть в первую очередь врач, а во вторую менеджер. Т.е. более правильно, если врач переучится на менеджера, а не наоборот. Рошаль, кстати, упоминал и Глушко, и Королева, и всех министров здравоохранения (все, кроме Голиковой были ранее врачами).

На мой взгляд, управленец должен знать предметную область. Он ее, кстати, и будет изучать, хочет он этого или нет. Есть же устоявшееся мнение, что менеджер становится хорошим менеджером за 7 лет работы. Так что, Elf, надо просто подождать ))). А пока что "...и планы проектов буду заполнять я...".

Есть практика, когда управленец, не знающий предметку, работает в паре с techleader'ом (по сути, главным инженером), который отвечает только за технику. Управленец - за сроки, ресурсы и финансы.

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

Но бывают ситуации, обратные Вашей. Например, в моей конторе руководителем проекта, можно сказать всей разработки, назначили опытного программиста, по сути разработчика.
Он в IT понимает все на 100%, в предметной области заказчика тоже разбирается прилично. В итоге получился контроль и полное отсутствие делегирования задач.
Задачи валятся подробные, вплоть до "в такой-то таблице добавить такие-то записи". Так тоже работать не комфортно, хотя  "работодатель оплачивает ваше время", люди не хотят работать винтиками.

Сложно в такой ситуации что-либо советовать. Возможно, нужно "подождать 7 лет", хотя какой МП работает столько на одном месте, у них ведь основная мотивация - карьерный рост.
Скорее всего, нужно поднимать вопрос перед руководством о роли techleader'а в дополнении к МП. Elf, ведь вы по сути выполняете эту роль, т.е. работаете "за того парня".

PS. Если руководство ситуацию не будет решать, то возможно проще уйти. Читал у одного известного человека цитату (не помню у кого), которая мне понравилась «Если вы по-настоящему любите свою работу, будьте готовы в любой момент попросить расчет». Основная идея - уметь отстаивать свою позицию.