Дмитрий ([info]cornerles) wrote in [info]ru_pm,

Каковы основные проблемы менеджеров с техническим опытом ?

Добрый день , Уважаемое сообщество !

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

Для начала назову первую и главную на мой взгляд проблему :

- Технарь в роли менеджера находится в состоянии неосознанной некомпетентности - Он уверен что и так все что необходимо знает.

p.s. За ссылки на хорошие статьи посвященные той тематике буду благодарен :-)

  • Post a new comment

    Error

    Your IP address will be recorded 

  • 157 comments

[info]greatshaitan

April 29 2008, 13:29:16 UTC 4 years ago

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

[info]alshur

April 29 2008, 14:04:55 UTC 4 years ago

согласен!

[info]cornerles

4 years ago

[info]arbinada

April 29 2008, 13:45:26 UTC 4 years ago

"кто из технарей выбился в люди"
Суперформулировка :)))
Начните с интервью с Грызловым

[info]dasannikov

April 29 2008, 14:09:06 UTC 4 years ago

Действительно, в противовес "Кто из гуманитариев способен хоть что то формализовать". :)

[info]cornerles

4 years ago

[info]dasannikov

4 years ago

[info]cornerles

4 years ago

[info]rolikoff

4 years ago

[info]cornerles

4 years ago

[info]arbinada

4 years ago

[info]johndegree

April 29 2008, 14:34:58 UTC 4 years ago

перечитать свой пост а потом повторять до просветления "Он уверен что и так все что необходимо знает." :-)

[info]cornerles

April 29 2008, 19:07:02 UTC 4 years ago

;-) Вы хотите об этом поговорить ? :-)

[info]serge_kond

April 29 2008, 14:38:47 UTC 4 years ago

слишком обще

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

[info]cornerles

April 29 2008, 18:45:38 UTC 4 years ago

Re: слишком обще

Согласен по всем пунктам :-)

[info]cornerles

4 years ago

[info]arbinada

4 years ago

[info]mshaman

April 29 2008, 16:01:12 UTC 4 years ago

Слово "проблемы" носит негативный оттенок, поэтому меняем его на слово "задачи". Тему сообщения формулируем следующим образом:
Задачи, которые надо решить техническому человеку, решившему стать управленцем

1-ая задача: сохранить мотивацию.
Технический специалист обычно видит ощутимый результат своего труда практически ежедневно. Управленец живет в виртуальной реальности и осязаемую обратную часть получается не часто. А если получает, то имеет возможность по разному её трактовать. Для организма это вредно. Можно заработать неврастению. Кроме того, при общении с нетехническими людьми часто остается впечатление что они идиоты. С этим не надо бороться. Надо просто принять. Понять что проблема имеет глобальный характер. Люди по природе своей субьективны. Они принимают решения исходя из необоснованных предпосылок и недостоверных фактов. Можно перечитать статью Дейкстры "о роли научности" 1974 года выпуска, в которой он сетует, что люди без технического образования пытаются рассуждать об ИТ в меру своих скромных возможностей. Можно почитать Друкера, который прямо рекомендует анализировать не факты, а мнения.

2-ая задача: стать понятным.
Это крайне важно. Объективных фактов больше не существует. Есть только мнение. Причем одно из них правильное, а другое - чужое. Вам придется учиться говорить на языке понятном каждому индивидуму

3-я задача: отбросить "правильные" стереотипы поведения.
Эффективность, качество, юзабилити, прибыль - всё это бред. В мире управления есть заинтересованные лица и преследуемые ими интересы. Все остальное - ярлыки. Слова не имеют смысла. Есть нескончаемая игра в которую заинтересованные лица играют друг с другом. У игры есть свои реквизиты, в которых надо разбираться и которыми надо владеть. Правила в игре, как-бы есть, но их можно менять в ходе игры.

Примерно так :)

[info]cornerles

April 29 2008, 18:47:33 UTC 4 years ago

Супер - Спасибо - очень интересно :-)

[info]darkboatman

April 29 2008, 16:09:49 UTC 4 years ago

Предлагаю бегло пролистать следующую книгу:
http://www.bookline.ru/book2409500.htm



[info]cornerles

April 29 2008, 18:28:19 UTC 4 years ago

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

[info]cornerles

4 years ago

[info]new_kiev

April 29 2008, 17:00:13 UTC 4 years ago

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

[info]cornerles

April 29 2008, 18:09:20 UTC 4 years ago

Тема действительно интересная. Давайте вывернем еще раз и получится преимущества которыми обладает технарь в роли руководителя ? :-) внимательно слушаю :-)

[info]new_kiev

4 years ago

[info]krf

4 years ago

[info]arbinada

4 years ago

[info]krf

April 29 2008, 17:02:52 UTC 4 years ago

Технари часто переоценивают кибернетику и системную теорию когда пытаются строить по ним свою управленческую практику

[info]cornerles

April 29 2008, 18:07:21 UTC 4 years ago

:-) Можно ли перефразировать это так, что технари недооценивают человеческий фактор , а это не только недостатки но и преимущества ?

[info]krf

4 years ago

[info]cornerles

4 years ago

[info]krf

4 years ago

[info]cornerles

4 years ago

[info]krf

4 years ago

[info]krf

4 years ago

[info]cornerles

4 years ago

[info]krf

4 years ago

[info]arbinada

4 years ago

[info]krf

4 years ago

[info]arbinada

4 years ago

[info]krf

4 years ago

[info]arbinada

4 years ago

[info]cornerles

4 years ago

[info]krf

4 years ago

[info]krf

4 years ago

[info]arbinada

4 years ago

[info]krf

4 years ago

[info]arbinada

4 years ago

[info]krf

4 years ago

[info]arbinada

4 years ago

[info]krf

4 years ago

[info]arbinada

4 years ago

[info]captador

4 years ago

[info]krf

4 years ago

[info]captador

4 years ago

[info]pater_leo

4 years ago

[info]pater_leo

4 years ago

[info]arbinada

4 years ago

[info]krf

4 years ago

[info]arbinada

4 years ago

[info]krf

4 years ago

[info]arbinada

4 years ago

[info]krf

4 years ago

[info]arbinada

4 years ago

[info]krf

4 years ago

[info]arbinada

4 years ago

[info]krf

4 years ago

[info]pater_leo

4 years ago

[info]krf

4 years ago

[info]pater_leo

4 years ago

[info]krf

4 years ago

[info]pater_leo

4 years ago

[info]krf

4 years ago

[info]pater_leo

4 years ago

[info]krf

4 years ago

[info]krf

4 years ago

[info]pater_leo

4 years ago

[info]krf

4 years ago

[info]pater_leo

4 years ago

[info]pater_leo

4 years ago

[info]krf

4 years ago

[info]pater_leo

4 years ago

[info]krf

4 years ago

[info]pater_leo

4 years ago

[info]krf

4 years ago

[info]pater_leo

4 years ago

[info]krf

4 years ago

[info]pater_leo

4 years ago

[info]krf

4 years ago

[info]pater_leo

4 years ago

[info]captador

4 years ago

[info]krf

4 years ago

[info]captador

4 years ago

[info]pater_leo

4 years ago

[info]crow_ru

4 years ago

[info]cornerles

4 years ago

[info]krf

4 years ago

[info]krf

4 years ago

[info]dmntr.blogspot.com

April 29 2008, 17:13:05 UTC 4 years ago

совершенство

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

[info]cornerles

April 29 2008, 18:05:07 UTC 4 years ago

Re: совершенство

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

[info]7803

April 29 2008, 19:47:28 UTC 4 years ago

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

проблема любого человека одной специальности в роли специалиста другой специальности одна: он не умеет

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

[info]cornerles

April 30 2008, 20:23:06 UTC 4 years ago

Плотника в роли повара)))

Превосходная метафора :-)

[info]bodhy

April 29 2008, 20:09:37 UTC 4 years ago

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

[info]cornerles

April 30 2008, 08:27:29 UTC 4 years ago

> В смысле проф. опыа менеджер обязан знать все технические тонкости.

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

[info]singalen

4 years ago

[info]captainl

4 years ago

[info]screenshoter

April 30 2008, 07:44:05 UTC 4 years ago

Скажу со стороны проектов тестирования. У нас проблема в том, что плохо развита техническая ветка, поэтому все дружно рулят в управления. Делается это без разбора того, есть ли у человека соотвествующие навыки. Как-то так исторически сложилось, что технические специалисты сейчас перестали быть в почёте,что весьма печально.
И, как уже замечалось, почему-то считается, что человек, коорый знает процес изнутри способен на необходимый уровень абстракции, чтобы это все обобщить и этим управлять.
Кроме того, некоторые попробовав управлять - понимает, что это не его. Но вот тут уже проблема - уйти считается постыдным, как бы признав совю несосотоятельность и опять упирается в проблему того, что технические специалисты сейчас перестали быть в почёте. Круг замыкается. На выходе имеем средней паршивости управленца.

И где-то в сети (кажется, тут в рассылке было Happy-PM.com) недавно встречала, чье-то высказывание, что программист всегда читает и развивается, а вот менеджер считает, что и так все знает и крайне мало читает.

[info]cornerles

April 30 2008, 08:16:54 UTC 4 years ago

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

[info]cornerles

April 30 2008, 08:37:33 UTC 4 years ago

Да расшифровка ПМ - "Прокладка между" весьма популярна в определенных кругах :-)

[info]rchernin

April 30 2008, 19:53:15 UTC 4 years ago

я тут писАл мысль про это: http://rchernin.livejournal.com/50346.html, прошу прощения за самоцитирование

[info]lucky__man

May 3 2008, 21:55:10 UTC 4 years ago

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

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

[info]captainl

May 5 2008, 13:06:23 UTC 4 years ago

Меня смущает такая постановка вопроса.
Попробуйте сюда:
Для начала назову первую и главную на мой взгляд проблему :
- Технарь в роли менеджера находится в состоянии неосознанной некомпетентности - Он уверен что и так все что необходимо знает.

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

[info]cornerles

May 8 2008, 08:39:53 UTC 4 years ago

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

Anonymous

May 6 2008, 13:42:02 UTC 4 years ago

Олег

хм...
как-то оскорбительно звучит...

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

"Технарь в роли менеджера находится в состоянии неосознанной некомпетентности" - это скорее всего зависит от личности но ни как не от специализации...

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

а теперь минусы:
- иногда слишком углубляюсь в детали...приходится брать тайм-аут для возврата к картине в целом;
- бывает слишком проникаешься проблемой заводчан...

[info]cornerles

May 7 2008, 15:21:16 UTC 4 years ago

Re: Олег

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

Спасибо за то что поделились своими соображениями

p.s. А сколько людей находится в подчинении ?

Anonymous

4 years ago

[info]cornerles

4 years ago

Anonymous

4 years ago

[info]cornerles

4 years ago

Anonymous

4 years ago

[info]cornerles

4 years ago

Anonymous

4 years ago

[info]az_from_belarus

May 7 2008, 14:04:48 UTC 4 years ago

Две стороны НИОКР.

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

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

ОКР-овцы более многочисленны. Склонны проявлять механистическое и догматическое мышление. В вопросах управления социумом (микросоциумом) они либо терпят фиаско, либо занимают положение дикторов-технократов, либо иногда напрочь отбрасывают весь технический опыт и переучиваются на "стандартных" управленцев.

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

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

[info]cornerles

May 7 2008, 15:14:02 UTC 4 years ago

Re: Две стороны НИОКР.

Очень интересный поворот мысли , если честно под технарями понималась категория не имеющая отношения к НИОКР , нормальный НИОКР это еще та школа :-)

Но описанные вами проблемы действительно можно спроецировать и на остальные виды "технарей" спасибо !

[info]artyrak

May 11 2008, 12:45:06 UTC 4 years ago

менеджера ли мы здесь обсуждаем? :)

Увлекательно окунулся в ветку о кибернетическом управлении, побродил по ссылкам, и хочу дополнить тем, что здесь еще не прозвучало.

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

Рассмотрим истоки понятий.
Управленец - человек, который "реализовывает свое право на власть позиции" (правит). Обычно он делает это через "систему" - систему правил, систему поощрений, систему бизнес процессов. Он управляет подчиненными, которые ОБЯЗАТЕЛЬНО ниже его по иерархии в компании. Типичные управленцы - служащие гос-сектора (у которых есть подчиненнные), старший офицерский состав. В коммерческой IT-компании управленцы - это начальники подразделений, или направлений деятельности. И чаще всего директора - управленцы.

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

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

Кстати, в английском существует точно такая же неразбериха. И ключевые посты названы не менеджерскими, а "officer", или "chief". Технический специалист с функциями руководителя - "leader" или "leading". Ну а PM - тот же. И в разных методологиях у него слегка разные функции, позиция и "подвиды" :) В Microsoft пришли к тому, что классический project management - это лишь одно из направлений деятельности Program Manager, который обеспечивает в основном "внутреннее" управление проектом. А "внешним" управлением (контрагентами) заведует Product Manager...

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

[info]artyrak

May 11 2008, 12:46:17 UTC 4 years ago

Re: менеджера ли мы здесь обсуждаем? :)

Мой случай:
Целенаправленно (а не по воле судьбы или заказчика) и постепенно сменил деятельность разработчика баз данных + прикладного ООП-разработчика на деятельность руководителя проекта (в нескольких вариантах исполнения :) ). Время на смену - 5 лет. Среда - 3 разных по многим параметрам компании, в каждой из которых была возможность попробовать ту или иную практику управления.
Основные сложности:
1. Очень большой объем информации, который нужно освоить непосредственно перед и в самом начале перехода. Это и книги (которые еще нужно подобрать под текущую ситуацию), и статьи по методологиям управления в IT, и руководства по управленческому ПО.
У меня ушло действительно много времени (в основном личного) на самоподготовку.
2. Необходимость практически в один момент поменять взгляд и позицию по отношению к программному продукту, который разрабатываешь и/или внедряешь. Для успешного управления проектом позиции ПМ и разработчика должны различаться как минимум на фазе проектирования и планирования (а лучше, если всегда). При этом нужно не потерять трезвость взгляда, и не бросаться в крайности (и новому ПМ-у и разработчику из его команды).
В этом мне помог мой навык все раскладывать по полочкам. И я заставил себя изменить позицию, стараясь при этом принести как можно больше пользы в командную работу.
3. Необходимость отказаться от детального (микро-) контроля над тем, что и как сделано внутри продукта. Особенно это касается тех, кто достаточно долго работал "чистым" архитектором в крупных проектах.
Я это не сразу понял, но когда все же осознал, что постоянное погружение в детали - зло, начал себя сдерживать.
4. Переход от личного точечного взаимодействия в команде к организации группового взаимодействия. И вообще, по поводу работы с группой (и хорошо еще, если это уже команда, а не отдельные звезды) может возникнуть огромное количество сложностей, связанных с чертами характера и социальными навыками бывшего разработчика.
К счастью, у меня были сложности только системного характера, которые решились применением готовых методов.
5. Получение управленческих навыков. Не все понимают, что для выполнения работы хорошо нужно не только знать и понимать теорию, и не только перенять или доказать свое умение вполнять работу, но и выработать многократным повторением НАВЫК, который, как деталь хорошего немецкого авто срабатываем именно тогда и именно в той мере, как нужно для максимального движения вперед.
На это ушло больше всего времени, но сильно помогли тренинги с адаптированной игровой программой по развитию отдельных навыков.
6. Осознание ответственности руководителя (а с ней и возможностей, и власти). Здесь много можно писать, но я думаю, этот момент каждый человек сам решает для себя и своего коллектива. Отмечу только одно - пословица "Мы в ответе за тех, кого приручаем" хорошо отражает этот важный момент :)
Осознание пришло как-то само собой примерно через год после перехода. Если бы этого не случилось, вряд ли бы стал IT-менеджером.

[info]cornerles

4 years ago

[info]artyrak

4 years ago

[info]cornerles

4 years ago

Create an Account
Forgot your login or password?
Facebook Twitter More login options
English • Español • Deutsch • Русский…