[winipuh 0]

На мой взгляд вы путаете два понятия - руководитель и менеджер. Почему вы считаете менеджера руководителем?

Во-первых, потому что слово "management" означает управление, руководство и т.д.

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

Речь шла конкретно о менеджере по продукту (product manager) - http://ru.wikipedia.org/wiki/Product_manager Прочитайте его список обязанностей и Вы увидите, что фактически именно он ставит задачи отделу разработки (R&D)

 

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

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

 

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

Это менеджер по продукту.

 

ок :)

 

Теперь смотрите - у нас уже есть три человека:

1. Руководитель группы разработчиков, который (по моему опыту) помимо того что "обдумывает системные вопросы, направляет их мысли и труды подчиненных в нужную сторону" и т.д., также еще сам принимает участие в разработке. Не является инициатором разработки.
2. Главный конструктор (либо начальник большого отдела разработчиков). Обдумывает системные вопросы совместно (как правило) с руководителями групп разработчиков, раздает им укрупненные задачи для дальнейшей проработки. Хотя ГКР нужен только в очень-очень крупных проектах, но в гос.предприятиях он почему-то есть всегда (видимо, ГОСТ обязывает), правда порою исполняет номинальные функции. В коммерческих фирмах такая должность часто просто отсутствует за ненадобностью (я имею ввиду в условиях нашей суровой действительности частным фирмам очень редко перепадают крупные заказы). Да, чуть не забыл! ГКР тоже не является инициатором разработки (там где есть ГКР - инициатива приходит сверху). Кстати - вот его должностные обязанности
3. Менеджер по продукту - в его задачу помимо прочего входит найти идею, оценить ее коммерческую ценность, сформулировать общие требования и спустить их в R&D (как вариант - аутсорс или оем) на обсуждение (можно ли сделать, сколько стоит во времени/деньгам и т.д.). Если окей - спустить ТЗ. Естественно согласовать в разработчиками. Является инициатором разработки.

 

А теперь - о каком человеке идет речь в этом топике? Я прочитал все посты, но так и не понял... :laughing:

[Methane 0]

Уважаемый Methane, интересная у Вас позиция:

1. Из инженера руководитель получается крайне редко.

2. Из не-инженера никогда.

По этой логике рынок труда должен сейчас испытывать просто неимоверную нехватку руководителей в области электроники. Сайты должны быть увешаны гроздьями объявлений "ищется руководитель за миллион баксов и полцарства в придачу". ВУЗ-ы должны массово начать открывать специальности "руководство разработкой embedded-устройств" с конкурсом как в театральные училища. Только что-то не видно всех этих чудес...

Еще раз. Нельзя научить руководить в электронике.

 

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

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

 

Считаю, что сама по себе работа руководителя является такой же технической, как и работа инженера. Строго говоря, если переводить на деньги, хороший спец по RF, например, может обходиться компании дороже, чем руководитель низшего звена. Это нормально, раз уж так сложился рынок, главное - это результат работы. Согласитесь, не правда ли?

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

 

Сам по себе поиск специалиста является задачей отдела кадров,

Еще одна шутка? Отдел кадров в лучшем случае может по keyword-ам резюме проверить.

 

fraction однозначно прав в том, что физически здоровому и морально крепкому человеку проще подчинить других, чисто на эмоциях. Есть такое понятие, "реактивный менеджмент", недавно столкнулся на практике :)

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

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

[krdmitry 0]

Во-первых, потому что слово "management" означает управление, руководство и т.д.

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

Речь шла конкретно о менеджере по продукту (product manager) - http://ru.wikipedia.org/wiki/Product_manager Прочитайте его список обязанностей и Вы увидите, что фактически именно он ставит задачи отделу разработки (R&D)

 

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

 

Это менеджер по продукту.

 

ок :)

 

Теперь смотрите - у нас уже есть три человека:

1. Руководитель группы разработчиков, который (по моему опыту) помимо того что "обдумывает системные вопросы, направляет их мысли и труды подчиненных в нужную сторону" и т.д., также еще сам принимает участие в разработке. Не является инициатором разработки.
2. Главный конструктор (либо начальник большого отдела разработчиков). Обдумывает системные вопросы совместно (как правило) с руководителями групп разработчиков, раздает им укрупненные задачи для дальнейшей проработки. Хотя ГКР нужен только в очень-очень крупных проектах, но в гос.предприятиях он почему-то есть всегда (видимо, ГОСТ обязывает), правда порою исполняет номинальные функции. В коммерческих фирмах такая должность часто просто отсутствует за ненадобностью (я имею ввиду в условиях нашей суровой действительности частным фирмам очень редко перепадают крупные заказы). Да, чуть не забыл! ГКР тоже не является инициатором разработки (там где есть ГКР - инициатива приходит сверху). Кстати - вот его должностные обязанности
3. Менеджер по продукту - в его задачу помимо прочего входит найти идею, оценить ее коммерческую ценность, сформулировать общие требования и спустить их в R&D (как вариант - аутсорс или оем) на обсуждение (можно ли сделать, сколько стоит во времени/деньгам и т.д.). Если окей - спустить ТЗ. Естественно согласовать в разработчиками. Является инициатором разработки.

 

А теперь - о каком человеке идет речь в этом топике? Я прочитал все посты, но так и не понял... :laughing:

 

Искренне полагал, что речь о product-managment'е. Перечитав первые сообщения ТС, понял, что ничего не понял :)

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

 

 

Еще раз. Нельзя научить руководить в электронике.

 

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

 

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

 

Правильно! "Настраивающий отношения" должен разбираться во всем этом.

 

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

 

Какой Вы оптимист... Спецы по RF порой очень нужны, только найти их непросто, поперевелись все...

 

Еще одна шутка? Отдел кадров в лучшем случае может по keyword-ам резюме проверить.

 

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

 

Methane, не все так плохо, на самом деле все еще хуже! :cranky:

На хамство можно ответить в 2 раза бОльшим хамством, на контроль по кол-ву строк кода - "индусским" кодом.

[AlexandrY 2]

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

 

Хм, я вот припоминаю когда сразу три коллектива было брошено на одну разработку. И ими никто не руководил, а работа кипела.

А еще сильнее начинала кипеть когда их посадили в одно помещение.

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

 

 

[winipuh 0]

Искренне полагал, что речь о product-managment'е. Перечитав первые сообщения ТС, понял, что ничего не понял :)

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

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

Вот нашел интересную статейку.

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

Ну или я его не так понял

Плохо ли это или хорошо - я не знаю.

Возможно ли это или нет - полагаю вполне возможно.

 

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

А инженерное образование - так оно везде ценится...

 

Вот :)

[Methane 0]

Искренне полагал, что речь о product-managment'е. Перечитав первые сообщения ТС, понял, что ничего не понял :)

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

 

 

 

 

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

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

 

Правильно! "Настраивающий отношения" должен разбираться во всем этом.

А тут обсуждается, как научиться руководить не зная всего этого.

 

Какой Вы оптимист... Спецы по RF порой очень нужны, только найти их непросто, поперевелись все...

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

 

Methane, не все так плохо, на самом деле все еще хуже! :cranky:

На хамство можно ответить в 2 раза бОльшим хамством, на контроль по кол-ву строк кода - "индусским" кодом.

Все совершенно точно. Но! В таких условиях победит хам и специалист по "индусскому" коду.

 

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

Вот это и правильно. В электричестве если деньги и могут появится, то только тогда когда уже помирать пора. У нас в стране так точно.

[krdmitry 0]

Хм, я вот припоминаю когда сразу три коллектива было брошено на одну разработку. И ими никто не руководил, а работа кипела.

А еще сильнее начинала кипеть когда их посадили в одно помещение.

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

 

Alexander, какая мотивация была у команды? На чистом энтузиазме далеко не уедешь :)

[krdmitry 0]

Господа хард-менеджеры, все-таки, где посоветуете учиться? Нужен Ваш совет.

[fractcon 0]

.

Изменено 20 июня, 2013 пользователем fractcon

[Maverick_ 15]

Господа - интересно читать Ваши сообщения

[ZASADA 0]

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

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

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

[ZASADA 0]

и самое главное-умение (а не желание) управлять людьми B)

[Methane 0]

и самое главное-умение (а не желание) управлять людьми B)

А что тут сложного?

http://www.youtube.com/watch?v=VGVQn70rXvk

Правда потом получается так.

http://www.youtube.com/watch?v=z_EEv_CmOyA

Но найти виновного кто не докрутил гайку, использовал китайский резистор без военной приёмки, пользовался не сертифицированным компилятором или компьютером созданным вероятным противником, совершенно не проблема.

 

[Гость TSerg]

К вопросу о главном конструкторе или руководителе проекта.

 

Расскажу историю одного человека времен Союза:

 

1. Радиолюбитель он с малых лет ( приемники, передатчики, бытовая автоматика )

2. Поступил в ВУЗ на специальность "Системы автоматического управления".

3. В процессе учебы занимался в студенческом научном обществе и на старших курсах уже помогал аспирантам делать расчеты САУ.

4. При распределении по окончании ВУЗ-а удалось договориться и получить место в фирме куда мечтал попасть - разработка систем автоматического управления и навигации для ВМФ.

5. Три года, будучи молодым специалистом, его носом водили по столу, вдалбливая азы работы в большом коллективе.

В это время он занимался разработкой интерфейсных блоков на логике и участвовал тестировании бортовых программно-аппаратных комплексов, включая алгоритмическую составляющую.

 

6. Поскольку продолжал проявлять научные дарования, после отработки обязательных 3-лет был переведен в мл.научные сотрудники и придана группа из трех молодых специалистов.

 

Примечание 1: Организационно-административное деление НПО: отдел, сектор. В отделах обычно по 200-300 чел, сектор до 50 чел.

Группа - неформальное подразделение внутри сектора для выявления будущих руководителей секторов и отделов.

 

Примечание 2: Кроме административного деления НПО существовала система руководства проектом.

На каждый проект (ОКР) назначались: главный конструктор, его замы (электроника, софт, конструкция, технология) + руководитель заказа (этакий контролер/завхоз/снабженец)

На каждый НИР назначались научный руководитель и его замы + рук.зак.

 

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

 

7. В течении 3 лет выполнял обязанности зам.научного и зам.главного по электронике, дорос до научного сотрудника, руководя группой уже до 10 чел.

Сфера интересов: hard&soft, поскольку к этому времени ( 1978..1980 гг ) уже появились отечественные микропроцессоры.

8. В 28 лет группа переродилась в сектор, который постепенно вырос до 50 чел и состоял из 3-х групп по ~15 чел, которые возглавили его бывшие молодые специалисты, моложе его на 3-4 года.

Продолжал пребывать в статусе зам-а по проектам. Обычным делом являлось одновременное участие в 1-2 НИР-ах и 2-3 ОКР.

 

Длительность НИР составляла от полугода и до года, ОКР - от 3 лет и до..

 

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

 

P.S.

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

 

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

документацией класса тех.описание комплекса, участием в испытаниях на объектах.

 

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

[topor_topor 0]

Что можете посоветовать? с чего начать? что почитать?

В интернете нашел информацию про MS Project, ISO 9001, Scrum, Agile.

какие методологии существуют хард-менеджеров?

 

Приму любую критику!

 

А если обсуждать тему с другой стороны....

 

1) А зачем человеку верующему в свои способности руководителя к кому-то наниматься на роботу "менеджером"?

У нас капитализм - зарегистрировал ЧП Менеджер - и вперёд к милиардам.

2) Что-то мешает? Нет опыта? Что-то есчё не прочитал?

Тогда может рано и думать? Или нет мнимых способностей?

 

3) В электронике боюсь, тупой проверкой в конце дня сколько подчинённый кв.м плитки выложил и зарплату соответственно отсчитать, не обойтись...

4) С чего начать?

Менеджментом ремонта своей квартиры например: тут и изыскание бюджета, и собеседование исполнителей и логистика... И попробуйте то-же качество за минимальные деньги и приемлемое время... а не тупо нанять под ключ самую крутую контору... PMBOOK Вам в помощь :) Не стесняйте - применяйте тайные знания ;)

Получили удовольствие?

Тогда дальше: анализ рынка харда, нахождение USP (unique selling point если не ошибаюсь), ну а дальше Вы уже умеете: найти бюджет, собеседование и PMBOOK Вам в помощь...

Вышло? Да Вы безценный CEO!

 

 

P.S.

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

Удачи