Добрый день , Уважаемое сообщество !
В связи с подготовкой презентации собираю информацию о проблемах технарей в роли менеджеров. Очень хотелось бы услышать мнение как тех кто и технарей выбился в люди :-) Так и тех кто намучался с бывшими инженерами :-)
Для начала назову первую и главную на мой взгляд проблему :
- Технарь в роли менеджера находится в состоянии неосознанной некомпетентности - Он уверен что и так все что необходимо знает.
p.s. За ссылки на хорошие статьи посвященные той тематике буду благодарен :-)
April 29 2008, 13:29:16 UTC 4 years ago
April 29 2008, 14:04:55 UTC 4 years ago
4 years ago
4 years ago
April 29 2008, 13:45:26 UTC 4 years ago
Суперформулировка :)))
Начните с интервью с Грызловым
April 29 2008, 14:09:06 UTC 4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
April 29 2008, 14:34:58 UTC 4 years ago
April 29 2008, 19:07:02 UTC 4 years ago
April 29 2008, 14:38:47 UTC 4 years ago
слишком обще
Менеджер - никакое слово, это и менеджер по продажам, это и менеджер проектов, иногда руководителей среднего звена так называют. Соответственно, и проблемы разные. И некомпетентность - это не главная проблема. Чаще всего, это проблема делегирования (как уже отметили) и контроля (все сам), зачастую слабый уровень коммуникативных возможностей (поскольку технарь чаще всего интраверт), проблема общения с людьми (начальники, клиенты, подчиненные).April 29 2008, 18:45:38 UTC 4 years ago
Re: слишком обще
Согласен по всем пунктам :-)4 years ago
4 years ago
4 years ago
April 29 2008, 16:01:12 UTC 4 years ago
Задачи, которые надо решить техническому человеку, решившему стать управленцем
1-ая задача: сохранить мотивацию.
Технический специалист обычно видит ощутимый результат своего труда практически ежедневно. Управленец живет в виртуальной реальности и осязаемую обратную часть получается не часто. А если получает, то имеет возможность по разному её трактовать. Для организма это вредно. Можно заработать неврастению. Кроме того, при общении с нетехническими людьми часто остается впечатление что они идиоты. С этим не надо бороться. Надо просто принять. Понять что проблема имеет глобальный характер. Люди по природе своей субьективны. Они принимают решения исходя из необоснованных предпосылок и недостоверных фактов. Можно перечитать статью Дейкстры "о роли научности" 1974 года выпуска, в которой он сетует, что люди без технического образования пытаются рассуждать об ИТ в меру своих скромных возможностей. Можно почитать Друкера, который прямо рекомендует анализировать не факты, а мнения.
2-ая задача: стать понятным.
Это крайне важно. Объективных фактов больше не существует. Есть только мнение. Причем одно из них правильное, а другое - чужое. Вам придется учиться говорить на языке понятном каждому индивидуму
3-я задача: отбросить "правильные" стереотипы поведения.
Эффективность, качество, юзабилити, прибыль - всё это бред. В мире управления есть заинтересованные лица и преследуемые ими интересы. Все остальное - ярлыки. Слова не имеют смысла. Есть нескончаемая игра в которую заинтересованные лица играют друг с другом. У игры есть свои реквизиты, в которых надо разбираться и которыми надо владеть. Правила в игре, как-бы есть, но их можно менять в ходе игры.
Примерно так :)
April 29 2008, 18:47:33 UTC 4 years ago
April 29 2008, 16:09:49 UTC 4 years ago
http://www.bookline.ru/book2409500.htm
April 29 2008, 18:28:19 UTC 4 years ago
Но хотелось бы получить информацию из первых уст , так как литературы переварено уже слишком много и боюсь что то что является аргументом для меня просто не будет услышано :-)
4 years ago
4 years ago
4 years ago
April 29 2008, 17:00:13 UTC 4 years ago
"проблемы (даже незнаю как назвать как их назвать, пусть будет люди закончившие ВУЗ по специальности "менеджер") в роли руководителя технического проекта"
April 29 2008, 18:09:20 UTC 4 years ago
4 years ago
4 years ago
4 years ago
April 29 2008, 17:02:52 UTC 4 years ago
April 29 2008, 18:07:21 UTC 4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
April 29 2008, 17:13:05 UTC 4 years ago
совершенство
Нужно избавиться от стремления максимально доделать продукт и сделат ьего полностью совершенным,ведь то что делает программист и то что нужно заказчику немного разное, а подходы к понятию совершенство тем более..
April 29 2008, 18:05:07 UTC 4 years ago
Re: совершенство
Большое спасибо .По моему ваше предложение распадается на две части ( поправьте пожалуйста если я неправильно понял):
1. Отношение к качеству продукта.
Как правило повышают тех кто качественно делает свою работу как специалист - т.е. без ошибок, однако с точки зрения управления качество это всегда компромис между сроками , стоимостью и самим качеством.
2. Умение становится на точку зрения заказчика видеть вопросы шире своей специализации.
April 29 2008, 19:47:28 UTC 4 years ago
он видел со стороны, как работает повар и ел приготовленную еду, но это не значит, что он умеет готовить...
проблема любого человека одной специальности в роли специалиста другой специальности одна: он не умеет
А поддержка в данной ситуации точно такая же, как в случае с поваром. Даже среди опытных поваров не очень много хороших поваров, а кое-как приготовить сумеет любой. Кое-как управлять сможет почти любой, а хорошо управлять не умеет большинство менеджеров - это сглаживает неумение технаря.
April 30 2008, 20:23:06 UTC 4 years ago
Плотника в роли повара)))
Превосходная метафора :-)April 29 2008, 20:09:37 UTC 4 years ago
С другой стороны я долго работал вместе с технарями, которые выбрались в менеджеры и это ужасно. Причепм они этого впринципе не понимают. Ведь в технари идут люди которым интересно копаться с деталями, т.е. интроверты, а еще точнее и чаще всего максимы - рациональный-сенсорно-логический-интрове
Люди под таким руководителям чувствуют нереальную скуку, у команды не происходит развития и движения вперед, а самое главное он сам пребывает в состоянии напряга от возложенной на него ответственности, которую делегировать никому он не будет.
Т.е могу констатировать - ваше предположение неосознанной некомпетентности.
April 30 2008, 08:27:29 UTC 4 years ago
C моей точки зрения это не менеджер а администратор или мастер ...нет никакого смысла в руководстве людьми которые в чем то не могут дать тебе фору ..
4 years ago
4 years ago
April 30 2008, 07:44:05 UTC 4 years ago
И, как уже замечалось, почему-то считается, что человек, коорый знает процес изнутри способен на необходимый уровень абстракции, чтобы это все обобщить и этим управлять.
Кроме того, некоторые попробовав управлять - понимает, что это не его. Но вот тут уже проблема - уйти считается постыдным, как бы признав совю несосотоятельность и опять упирается в проблему того, что технические специалисты сейчас перестали быть в почёте. Круг замыкается. На выходе имеем средней паршивости управленца.
И где-то в сети (кажется, тут в рассылке было Happy-PM.com) недавно встречала, чье-то высказывание, что программист всегда читает и развивается, а вот менеджер считает, что и так все знает и крайне мало читает.
April 30 2008, 08:16:54 UTC 4 years ago
И по второму вопросу практически с Вами согласен.
По собственному опыту знаю что специалист ставший менеджером просто физически не в состоянии поддерживать свою техническую компетентность на должном уровне. И соотвественно это только вопрос времени когда он вновь становится неосознанно некомпетентным уже по своей специальности, и чем лучшим специалистом он был тем хуже становится ситуация в проекте ...
4 years ago
April 30 2008, 08:23:47 UTC 4 years ago
:)
April 30 2008, 08:37:33 UTC 4 years ago
April 30 2008, 19:53:15 UTC 4 years ago
May 3 2008, 21:55:10 UTC 4 years ago
Менеджеры, вышедшие из технарей, великолепно справлялись с проектами и достигали поставленных целей, развивали свою команду, но разительно отличались от "просто менеджеров" - занятых, в основном, политикой. Поэтому они как-то не вписывались в общую картину, и каждый раз приходилось думать - то ли с ними что-то не так, то ли привычный "менеджерский фон" вообще контрпродуктивен (а эта мысль столь революционна, что как-то трудно с этим согласиться).
Впрочем, в прошлом "технари", которым не успели объяснить, что они - оказывается - "все делают не правильно", на моих глазах строили с нуля крупные фирмы, зарабатывали миллионы и т.п.
May 4 2008, 19:19:59 UTC 4 years ago
Задача минимизации влияния медленного и склонного к ошибкам "человеческого звена" в менеджменте еще только начинает зарождаться, когда все более остро встает, например, проблемы организации цепочек поставок (SCM) путем непосредственного взаимодействия ERP систем разных предприятий. Однако эта проблеме еще очень далека от решения!"
May 5 2008, 13:06:23 UTC 4 years ago
Попробуйте сюда:
Для начала назову первую и главную на мой взгляд проблему :
- Технарь в роли менеджера находится в состоянии неосознанной некомпетентности - Он уверен что и так все что необходимо знает.
вместо "технарь в роли менеджера" подставить "менеджер без технических знаний" или "начинающий менеджер" или "практически любой менеджер". :)
Как уже сказали выше, "менеджер" - это очень туманно. Вы, видимо, имеете в виду конкретный класс менеджеров (напр. руководитель небольшого софтверного проекта) и, наверно, представляете себе набор компетенций, которыми должен обладать идеальный менеджер такого класса. Если у Вас нет такого списка, то начните с его составления. Если есть, то пройдите по этому списку и отметьте недостающие компетенции. Ваш вопрос ведь - это отличие профессиограммы технаря от профессиограммы менеджера. Кто такой технарь - тоже неясно. Это 20-летний мальчик-программист, рядовой член команды или ведущий инженер?
May 8 2008, 08:39:53 UTC 4 years ago
Anonymous
May 6 2008, 13:42:02 UTC 4 years ago
Олег
хм...как-то оскорбительно звучит...
я являюсь явным примером: технарь (технолог завода)--> менеджер проектов (инвестиций) :)
всегда был рад тому что прошел школу рабочего,инженера,технолга...и людьми управлять научили и проблемы с разных углов можем рассматривать...
"Технарь в роли менеджера находится в состоянии неосознанной некомпетентности" - это скорее всего зависит от личности но ни как не от специализации...
хотелось бы отметить плюсы:
- понимание технических вопросов по проекту;
- невозможность вешать мне лапшу на уши техническими специалистами завода;
- уважение со стороны заводчан к моей компетентности.
а теперь минусы:
- иногда слишком углубляюсь в детали...приходится брать тайм-аут для возврата к картине в целом;
- бывает слишком проникаешься проблемой заводчан...
May 7 2008, 15:21:16 UTC 4 years ago
Re: Олег
> как-то оскорбительно звучит...Прошу прощения, но ведь как то надо было спровоцировать людей на выражение своих мыслей :-)
Спасибо за то что поделились своими соображениями
p.s. А сколько людей находится в подчинении ?
Anonymous
4 years ago
4 years ago
Anonymous
4 years ago
4 years ago
Anonymous
4 years ago
4 years ago
Anonymous
4 years ago
May 7 2008, 14:04:48 UTC 4 years ago
Две стороны НИОКР.
Под технарями очень часть принято подразумевать тех, которые имеют какое-то отношение к НИОКР или могли бы иметь, по своему образованию. К сожалению довольно часто забывается разделение не естественное образование и техническое. Мысленно спроецируем всех технарей на НИОКР - если и не участвовали в них, то как могли бы участвовать.Теперь условно разделим всех "технарей" на тех, которые ближе к ОКР и тех, котрые ближе к НИР. И получим разное мышление, поведение и проблемы.
ОКР-овцы более многочисленны. Склонны проявлять механистическое и догматическое мышление. В вопросах управления социумом (микросоциумом) они либо терпят фиаско, либо занимают положение дикторов-технократов, либо иногда напрочь отбрасывают весь технический опыт и переучиваются на "стандартных" управленцев.
НИР-овцы встречаются реже. Эти более гибкие. Но их проблемы в том, что могут уйти в дебри и не удержаться в жестких временных рамках. Возможно плохое их "самочувствие" в рутинной работе, в налаженном процессе - лучше всего себя проявляют в нестандартных и тупиковых ситуациях, если при этом обладают еще и необходимыми морально-волевыми качествами.
В основе расслоения лежит разное понимание соотношения абстрактных моделей, "формул" с живой реальностью.
May 7 2008, 15:14:02 UTC 4 years ago
Re: Две стороны НИОКР.
Очень интересный поворот мысли , если честно под технарями понималась категория не имеющая отношения к НИОКР , нормальный НИОКР это еще та школа :-)Но описанные вами проблемы действительно можно спроецировать и на остальные виды "технарей" спасибо !
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...
И после такого небольшого раскладывания по полочкам вроде как становится ясно, что начинать нужно не с общей теории, а с нескольких кейсов, в которых разработчик ПО сменит свою позицию на одну из описанных выше в нескольких различающихся условиях. По каждому кейсу можно найти людей, прошедших через подобное, и их сложности как раз и будут ответом на поставленный вопрос :)
May 11 2008, 12:46:17 UTC 4 years ago
Re: менеджера ли мы здесь обсуждаем? :)
Мой случай:Целенаправленно (а не по воле судьбы или заказчика) и постепенно сменил деятельность разработчика баз данных + прикладного ООП-разработчика на деятельность руководителя проекта (в нескольких вариантах исполнения :) ). Время на смену - 5 лет. Среда - 3 разных по многим параметрам компании, в каждой из которых была возможность попробовать ту или иную практику управления.
Основные сложности:
1. Очень большой объем информации, который нужно освоить непосредственно перед и в самом начале перехода. Это и книги (которые еще нужно подобрать под текущую ситуацию), и статьи по методологиям управления в IT, и руководства по управленческому ПО.
У меня ушло действительно много времени (в основном личного) на самоподготовку.
2. Необходимость практически в один момент поменять взгляд и позицию по отношению к программному продукту, который разрабатываешь и/или внедряешь. Для успешного управления проектом позиции ПМ и разработчика должны различаться как минимум на фазе проектирования и планирования (а лучше, если всегда). При этом нужно не потерять трезвость взгляда, и не бросаться в крайности (и новому ПМ-у и разработчику из его команды).
В этом мне помог мой навык все раскладывать по полочкам. И я заставил себя изменить позицию, стараясь при этом принести как можно больше пользы в командную работу.
3. Необходимость отказаться от детального (микро-) контроля над тем, что и как сделано внутри продукта. Особенно это касается тех, кто достаточно долго работал "чистым" архитектором в крупных проектах.
Я это не сразу понял, но когда все же осознал, что постоянное погружение в детали - зло, начал себя сдерживать.
4. Переход от личного точечного взаимодействия в команде к организации группового взаимодействия. И вообще, по поводу работы с группой (и хорошо еще, если это уже команда, а не отдельные звезды) может возникнуть огромное количество сложностей, связанных с чертами характера и социальными навыками бывшего разработчика.
К счастью, у меня были сложности только системного характера, которые решились применением готовых методов.
5. Получение управленческих навыков. Не все понимают, что для выполнения работы хорошо нужно не только знать и понимать теорию, и не только перенять или доказать свое умение вполнять работу, но и выработать многократным повторением НАВЫК, который, как деталь хорошего немецкого авто срабатываем именно тогда и именно в той мере, как нужно для максимального движения вперед.
На это ушло больше всего времени, но сильно помогли тренинги с адаптированной игровой программой по развитию отдельных навыков.
6. Осознание ответственности руководителя (а с ней и возможностей, и власти). Здесь много можно писать, но я думаю, этот момент каждый человек сам решает для себя и своего коллектива. Отмечу только одно - пословица "Мы в ответе за тех, кого приручаем" хорошо отражает этот важный момент :)
Осознание пришло как-то само собой примерно через год после перехода. Если бы этого не случилось, вряд ли бы стал IT-менеджером.
4 years ago
4 years ago
4 years ago