Comments 68
Спасибо. Очень интересная статья для меня как для технаря (поставил бы плюс, да кармы не хватает).
Надеюсь, Ваша следующая статья будет про недостатки — кому, как ни Вам, они тоже должны быть видны (если они вообще существуют) =)
Надеюсь, Ваша следующая статья будет про недостатки — кому, как ни Вам, они тоже должны быть видны (если они вообще существуют) =)
Про недостатки много сказал TheR. В целом я с ним согласен, все эти моменты присутствуют. Мое мнение таково — как и в любой карьере все зависит от человека. Если ты рвешься вперед, готов брать на себя ответственность, развиваешься как профессионал — в любой области тебя ждет успех. А если сидеть на попе ровно, то кроме недостатков в твоей работе больше ничего и не будет.
Личностный рост и развитие коммуникативных навыков
Возможность «meet people»
На меня смотрят боссы
Командировки. Тысячи их
Далеко не все люди экстраверты. Для остальных это скорее минусы, чем плюсы.
Так что, выбор между технарём и менеджером — это психологический выбор, ИМХО.
Именно об этом я и говорю. Однозначных плюсов и минусов нет, но перейти от интраверта к экстраверту можно, я — живой пример. Это, скорее, вопрос мотивации…
ИнтрОверт. И вы им, скорее всего, не были. Боязнь людей совсем не признак интроверта
Как частный пример боязни, но не обязательно факта интроверта — компетенция «общение со статусными людьми».
Что бы там ни было, но я был достаточно типичным представителем программистского племени. С большинством стандартных фобий и проблем. Я не говорю, что это дорога для каждого (и уж тем более не агитирую за нее), это всего лишь один из возможных путей. Кстати про вариант «менеджер, превратившийся в программиста», я почти не слышал. Среди моих знакомых есть только один такой человек, и то, он сначала был программистом, потом побыл менеджером, а потом ему захотелось больше «работать руками» и он вернулся к истокам.
Я говорю только, что этот переход (технарь -> менеджер) не столь сложен и доступен практически каждому. Было бы желание.
Я говорю только, что этот переход (технарь -> менеджер) не столь сложен и доступен практически каждому. Было бы желание.
Любой переход не так сложен, как многие думают. Можно вообще проф. область сменить и, например, кафе открыть. Другое дело, что переход во что-то с префиксом хороший (в плане высококвалифицированный и успешный) — это, действительно, сложно и требует усилий в независимости от области.
А что за фобии и проблемы у программистского племени, можно поподробнее?
Вы знаете, этот вопрос, мягко говоря, неоднозначный.
Знаю довольно много примеров, когда замкнутые и нелюдимые кодеры, типичные хикки и интроверты, после получения первого нормального сотрудника в подчинение заметно раскрепощались. И к становлению PM-ами или тимлидами превращались во вполне весёлых-жизнерадостных дядек, получающих удовольствие от общения и новых знакомств.
Бытие определяет сознание, что ли?
Знаю довольно много примеров, когда замкнутые и нелюдимые кодеры, типичные хикки и интроверты, после получения первого нормального сотрудника в подчинение заметно раскрепощались. И к становлению PM-ами или тимлидами превращались во вполне весёлых-жизнерадостных дядек, получающих удовольствие от общения и новых знакомств.
Бытие определяет сознание, что ли?
Знаю довольно много примеров, когда замкнутые и нелюдимые кодеры, типичные хикки и интроверты, после получения первого нормального сотрудника в подчинение заметно раскрепощались.Это лишь говорит о том, что этот человек от природы был экстравертом, но в результате неудачного воспитания/травмирующего жизненного опыта и т.п. закрепостился, получил комплексы или страхи.
И ваш пример это отнюдь не «чудесное превращение интра в экстра», это просто пример излечения психики и обретение человеком самого себя.
Настоящего интроверта лишнее общение не «излечит» и всегда ему будет в тягость. Следует это помнить.
Я может быть молод и всё такое, но совсем не представляю, что может заставить меня даже в будущем превратиться из инженера в менеджера. С какой стороны не посмотри, это кажется дауншифтингом.
Неужели нет желания передвигаться по миру? Меня, так это очень привлекает! :) А инженером мне быть в свои 36 уже не очень хочется!
уже обсуждалось, для разработчика архитектором куда комфортнее и интереснее, а попутешествовать лучше по собственному желанию, чем 50% времени болтаться по черт знает где ради вовсе не себя, особенно семейным
кому то важен спокойный офис, чтобы лучше сосредоточиться, при таком развитии интернета, наверно, командировки остаются уделом крупных монополистов
кому то важен спокойный офис, чтобы лучше сосредоточиться, при таком развитии интернета, наверно, командировки остаются уделом крупных монополистов
Привлекает, но это не значит, что я готов пожертвовать своими интересами/хобби ради этого.
Думается, что люди из инженеров уходят в менеджеры, когда понимают, что программирование — это не их стезя. Вполне правильное и логичное решение. Но, честно признать, не представляю, как человек, которому нравится программировать, может уйти в менеджеры.
Думается, что люди из инженеров уходят в менеджеры, когда понимают, что программирование — это не их стезя. Вполне правильное и логичное решение. Но, честно признать, не представляю, как человек, которому нравится программировать, может уйти в менеджеры.
Может. Особенно, когда понимаешь, что совместными силами людей, с которыми ты работаешь (которыми управляешь), ты можешь, условно говоря, запрограммировать гораздо больше, чем одними только своими усилиями. Возможность задействовать больше ресурсов для достижения цели — одно из преимуществ работы в менеджменте.
Хотите передвигаться по миру сз счет работодателя? Посмотрите на инженеров-внедренцев. Особенно в области АСУ ТП. Я знаю компанию, в которой 180 дней в году командировок считается нормой :)
Командировок по миру? Или все таки по России?
Вот тут как раз все очень сильно зависит от индустрии в которой работаешь и конкретного работодателя. Я занимался в основном МИС (медицинские информационные системы) и хранилищами данных, поэтому география поездок была широчайшей. Ну и плюс, работа на западного интегратора — это и тренинги в головном офисе и международные проекты.
А в нефтяном поясе РФ я тоже побывал немало, когда попал в группу Oil & Gas внедренцев. Не понравилось, Анапа реально лучше )))
А в нефтяном поясе РФ я тоже побывал немало, когда попал в группу Oil & Gas внедренцев. Не понравилось, Анапа реально лучше )))
После превращения все выглядит с точностью наоборот. Правда в первое время объем изучаемой информации многократно возрастает, особенно если есть желание развиваться не только как управленец, но и как программист. Фактически менеджер должен разбираться как в работе своих подчиненных, так и в управлении ими, и даже в организации управления. Особенно последнее актуально на более высоких уровнях, т.к. возникает множество работы по организации и оформлению работ согласно нормам/правилам/инструкциям и прочим регламентам, причем отказаться от нее нельзя, иначе придут злые дяди/тети (хорошо если от начальства или по его поручению) и накажут. Но не смотря на все сложности и рутину такая работа весьма интересна и познавательна.
Но с моей точки зрения наиболее важным приобретением будут коммуникативные навыки. Особенно полезно общение с заказчиками. Умение свободно общаться с незнакомыми людьми в дальнейшем поможет быстро прижиться в любой команде, что позволит быстрее втянуться в работу. Конечно это ИМХО, но возникло оно еще во время работы кодером, когда приходилось по проектам общаться напрямую с заказчиками.
Но с моей точки зрения наиболее важным приобретением будут коммуникативные навыки. Особенно полезно общение с заказчиками. Умение свободно общаться с незнакомыми людьми в дальнейшем поможет быстро прижиться в любой команде, что позволит быстрее втянуться в работу. Конечно это ИМХО, но возникло оно еще во время работы кодером, когда приходилось по проектам общаться напрямую с заказчиками.
Это возможность «программировать» на более высоком уровне. Можно успевать делать больше за меньшее время (я в смысле, конечных инженерных задач).
1 причина быть разработчиком – мне это нравится.
через 20 лет сидения за клавиатурой несколько устаешь =)
Когда я был менеджером, я печатал больше чем сейчас (когда вернулся в разработку) — количество кода в день не сравнится с количеством писем в день, которые нужно было отписать каждому заказчику, продакту заказчика, дизайнеру заказчика, программисту заказчика, интермидиэт сейлу, сейлу а также своему непосредственному руководству и, конечно же, на нескольких проектах.
Когда плохие разработчики становятся хорошими менеджерами, можно только радоваться.
«Однако уже с уровня Product Manager (следующий шаг после проджекта)...» — это кто Вам такое сказал?
Мне кажется второй пункт вообще не вяжется с реальностью. Скорее все наоборот. Я, например, владею Java. И мне абсолютно все равно где работать джавистом. Хоть в банке, хоть в бухгалтерии, хоть в геотаргетинговом стартапе. А вот зачем нужен руководитель проектов, который не разбирается в предметной области, я не знаю.
Главная причина не быть управленцем — стрессов больше, чем в других сильно стрессовых профессиях. Еще управленцы зачастую не могут распоряжаться своим временем. Чаще всего можно прийти к выводу, что тот или иной управленец так вкалывает для того, чтобы красиво отдохнуть в старости.
Насчет стресса не уверен. Просто у технарей он более концентрированный вокруг дедлайнов, а у управленца более-менее размазан во времени. Средний уровень стресса на мой взгляд примерно одинаковый.
Не претендую на истину в последней инстанции, просто мои наблюдения.
Уровень стресса растет с уровнем ответственности, поэтому и программер, работающий на ответственной роли (архитектора, например) получает стресса не многим менее менеджера, который отвечает за проект в целом. Опять-таки, некоторые люди легко несут бремя ответственности, а некоторые открещиваются от нее всеми возможными способами, уровень стресса для них будет разным.
Уровень стресса растет с уровнем ответственности, поэтому и программер, работающий на ответственной роли (архитектора, например) получает стресса не многим менее менеджера, который отвечает за проект в целом. Опять-таки, некоторые люди легко несут бремя ответственности, а некоторые открещиваются от нее всеми возможными способами, уровень стресса для них будет разным.
Стресс бывает деструктивный (дестресс) и позитивный (эустресс). Некоторые люди работают значительно эффективнее под стрессом, чем без него.
Возможность влиять на продукт — это наверно самый важный плюс. Зачастую разработчику приходят уже готовые решения вида «сделать свистелку». И в такой момент практически невозможно объяснить, что никому свистелка не нужна, а критически важна другая фича. Несколько таких итераций и стоит искать новую работу.
Для меня это было основной причиной сменить профессию. Мне нравится работать руками, я до сих пор периодически прогаю для себя. Магия творения живого объекта (ПО) из ничего, одной силой мысли — это замечательно. Но будучи программистом а не менеджером в крупной компании от меня очень мало что зависело, мне это не нравилось.
Мне кажется, главная профессиональная деформация менеджеров — это полный отрыв от языковой действительности)
Возможность «meet people», вместо «Новые знакомства», например, очень бросается в глаза наравне с knowledge share и т.д.
Это не придирка, просто странно, почему так происходит. Вроде все на английском много говорят/читают, но выеживаются лишней ненужной английской терминологией только менеджеры.
Возможность «meet people», вместо «Новые знакомства», например, очень бросается в глаза наравне с knowledge share и т.д.
Это не придирка, просто странно, почему так происходит. Вроде все на английском много говорят/читают, но выеживаются лишней ненужной английской терминологией только менеджеры.
Я знаю, это раздражает. Прошу прощения за это, но у меня это действительно профессиональная деформация — ежедневное общение с англоговорящими людьми (естественно, ни бельмеса не понимающими по-русски) очень засоряет речь англицизмами. Зачастую, чтобы перевести на русский многие ежедневные американо-английские речевые обороты мне уже приходится очень сильно напрягать извилины. Слава богу, не все менеджеры так легко поддаются влиянию иноземной речи.
Я, конечно, все понимаю, но вот это: Возможность «meet people» можно было написать и по-русски!
вспомнилось
Что, опять? :)
Я писал ответ от менеджерского корпуса, так сказать
habrahabr.ru/post/165147/
вроде было норм :)
но давайте попробуем снова войти в эту реку
Я писал ответ от менеджерского корпуса, так сказать
habrahabr.ru/post/165147/
вроде было норм :)
но давайте попробуем снова войти в эту реку
Вот читаешь такие статьи и начинает казаться, что IT — это только программисты и их производные. И все проблемы IT — это на 99.99% проблемы программистов. Если же на кодерах не циклиться, актуальность некоторых пунктов снижается.
Добавил бы пункт, который начинается с первого же шага вверх.
Это возможность выбирать из потока подзадач более интересные и сплавлять другим более скучные.
Чем выше — тем в бОльших масштабах.
Это возможность выбирать из потока подзадач более интересные и сплавлять другим более скучные.
Чем выше — тем в бОльших масштабах.
Вы не в Parallels случайно работаете?
Свят-свят =) Нет, никогда там не работал, только с ними.
Ясно, а то у вас несколько очень знакомых моментов проскочило, сразу про паралелс подумал.
Btw, в некоторых компаниях, например, intel есть по сути две отдельные служебные лестницы — менеджерская и инженерская, можно с одной на другую перескакивать, при этом уровни зарплат там сравнимые (до некоторого предела, конечно, когда инженерская лестница кончается).
Btw, в некоторых компаниях, например, intel есть по сути две отдельные служебные лестницы — менеджерская и инженерская, можно с одной на другую перескакивать, при этом уровни зарплат там сравнимые (до некоторого предела, конечно, когда инженерская лестница кончается).
Не секрет в какой области работаете менеджером/управленцем? на стороне заказчика или исполнителя, и как долго?
Если ты занимаешься вебом, 90 шансов из 100, что на следующей работе/должности ты точно так же будешь делать сайты.
4 года работал веб-программистом, теперь работаю промышленным альпинистом :)
Для тех, кому важны плюшки и менеджеров и разработчиков, по-моему идеальная должность — руководитель группы разработки из 3-5 программистов. Ты еще продолжаешь писать код, график работы [почти] такой же свободный как и у линейных программистов, но при этом решаешь уже только самые сложные и интересные задачи, занимаешься архитектурой, принимаешь стратегические решения по дальнейшему развитию проекта с технической точки зрения. Например, повлиять на введение новой серьезной фичи в продукт ты еще не можешь (хотя зависит от конторы), зато можешь для ее реализации внедрить новый стек технологий.
Другой вариант получить многие из бонусов манагеров, это не идти в манагеры, а идти в компанию, где должным образом относятся к разработчикам. Например, к нам в JetBrains.
Когда я стал Project Manager'ом ситуация изменилась для меня не сильно — всегда есть Product Manager, отдел маркетинга, «акционеры продукта» и т.д. Однако уже с уровня Product Manager (следующий шаг после проджекта) у тебя есть реальная возможность формировать продукт так, как его видишь ты.
Это, конечно, вопрос терминологии и названий, но обычно под Project Manager'ом понимают руководителя заказных проектов. Product Manager — так называется эта роль для продуктов. Можете более подробно рассказать, как в вашей компании была устроена эта иерархия и кто за что отвечал?
И почему народ вечно делит программистов на менеджеров и собственно программистов? Нет в IT сферических менеджеров в вакууме, не-ту! Есть только программисты, настоящие и… не программисты вовсе. Навыки управления у программиста должны быть заложены в генах (ну в крайнем случае в каком-нибудь учебном заведении). Программисты, которых обычно называют менеджерами — они те же программисты, только сущностями у них являются не объекты всевозможных классов, а работники разных специализаций.
Программист умеет грамотно составлять эффективную схему взаимодействия отдельных компонентов программы между собой, применяя при этом абстракцию в тех местах, где требуется ветвление логики — этот паттерн легко накладывается на управление любым проектом. Собственно, часто упоминаемый оверхед, связанный с большим количеством менеджеров среднего звена (суть работы которых заключается только в передаче указаний с верхнего уровня на нижний), встречается часто и в программировании — чрезмерная абстракция — введение большого количества абстрактных классов, либо (в особо запущенных случаях) интерфейсов. А теперь представьте, что каждый абстрактный класс или интерфейс это менеджер.
Отсюда следует, что программист может легко справляться с управлением любого проекта, имея большой опыт в проектировании и использовании компонентов сложных программных комплексов. Если же программист не справляется с управлением, то либо он не программист (чаще всего именно так), либо ему просто не хочется тратить на это время.
ЗЫ: мое деление на своих и чужих немного отличается от общепринятого. Есть программисты и:
Выходит, что программист легко может стать менеджером в классическом понимании, а тестер может стать аналитиком — и то, и другое вполне закономерно и подчиняется логике. И чаще всего обратимо. Конфликты же (на уровне сознания и выше) возникают из-за ошибочного позиционирования.
Программист умеет грамотно составлять эффективную схему взаимодействия отдельных компонентов программы между собой, применяя при этом абстракцию в тех местах, где требуется ветвление логики — этот паттерн легко накладывается на управление любым проектом. Собственно, часто упоминаемый оверхед, связанный с большим количеством менеджеров среднего звена (суть работы которых заключается только в передаче указаний с верхнего уровня на нижний), встречается часто и в программировании — чрезмерная абстракция — введение большого количества абстрактных классов, либо (в особо запущенных случаях) интерфейсов. А теперь представьте, что каждый абстрактный класс или интерфейс это менеджер.
Отсюда следует, что программист может легко справляться с управлением любого проекта, имея большой опыт в проектировании и использовании компонентов сложных программных комплексов. Если же программист не справляется с управлением, то либо он не программист (чаще всего именно так), либо ему просто не хочется тратить на это время.
ЗЫ: мое деление на своих и чужих немного отличается от общепринятого. Есть программисты и:
- Менеджеры без навыков программирования (а значит без опыта управления сложными сущностями) — это на самом деле аналитики.
- Программисты без навыков управления — это тестеры (проектировать сложные системы без навыков управления невозможно).
Выходит, что программист легко может стать менеджером в классическом понимании, а тестер может стать аналитиком — и то, и другое вполне закономерно и подчиняется логике. И чаще всего обратимо. Конфликты же (на уровне сознания и выше) возникают из-за ошибочного позиционирования.
по-моему, программирование и прочее ТАУ, принципиально отличается от управления людьми, не смотря на то, что понятие «управления» используется и там и там. все дело в пресловутом человеческом факторе. в то время как программисты бездушных железяк споконо могут быть нердами, для управления людьми крайне важны личностные качества. сосбтвенно пост, отчасти, и про это.
Программист умеет грамотно составлять эффективную схему взаимодействия отдельных компонентов программы между собой, применяя при этом абстракцию в тех местах, где требуется ветвление логики — этот паттерн легко накладывается на управление любым проектом.
Это если программисты — роботы, а не люди.
Менеджер значительно более заметен большим боссам, успех проекта — его успех. А вот факап проекта в больших корпорациях, это как правило факап исполнителей
Насколько это распространенное явление? Кто может подтвердить, и еще к автору вопрос — с чем это связанно, то что вина лежит о провале на подчиненных Я имею ввиду причины этого, я например думал что как в спорте — за провал турнира несет ответственность главный тренер, как правило аргумент прост — он собирал этих исполнителей и он ими руководил, и как правило, за провалом — идет отставка. И не только в спорте, везде где есть высокая управленческая конкуренция — т.е. когда на твое место дышит в затылок другой.
Насколько это распространенное явление? Кто может подтвердить, и еще к автору вопрос — с чем это связанно, то что вина лежит о провале на подчиненных Я имею ввиду причины этого, я например думал что как в спорте — за провал турнира несет ответственность главный тренер, как правило аргумент прост — он собирал этих исполнителей и он ими руководил, и как правило, за провалом — идет отставка. И не только в спорте, везде где есть высокая управленческая конкуренция — т.е. когда на твое место дышит в затылок другой.
Руководству проще вникнуть в то, что неправильно сделал менеджер, чем в то, что неправильно сделал разработчик.
Поэтому не стоит думать, что за пендель разрабу, менеджеру ничего не будет.
Самый простой и грубый ответ на ваш вопрос «с чем это связанно» — козёл отпущения и сила тяготения. «Яблоки всегда сыпятся вниз».
Толковый руководитель, понимает, что виноват не менеджер и не разработчик, а он сам. Он не доглядел, не помог когда нужно было, не дал свободы, когда требовалось и т.п. Но таких сознательных людей немного, поэтому проще обвинить другого. Люди привыкли, что корни внизу, поэтому выкапывать корень проблемы сверху не всем приходит в голову.
Поэтому не стоит думать, что за пендель разрабу, менеджеру ничего не будет.
Самый простой и грубый ответ на ваш вопрос «с чем это связанно» — козёл отпущения и сила тяготения. «Яблоки всегда сыпятся вниз».
Толковый руководитель, понимает, что виноват не менеджер и не разработчик, а он сам. Он не доглядел, не помог когда нужно было, не дал свободы, когда требовалось и т.п. Но таких сознательных людей немного, поэтому проще обвинить другого. Люди привыкли, что корни внизу, поэтому выкапывать корень проблемы сверху не всем приходит в голову.
«Горизонтальное развитие карьеры»
Не согласен. Сейчас существует множество инструментов, позволяющих писать на одном языке, а приложения выпускать и под веб, и под мобилки, и даже клиентские. Т.е. даже без доп. изучения можно довольно сильно мотаться в областях.
«Работа для генералистов»
Спорно. Линый опыт говорит о том, что это не всегда так. Разрабатывая приложения для какой-либо области, разработчики точно также изучают эту область. Не так глубоко, но достаточно, чтобы понимать, что от них требуется и почему.
«На меня смотрят боссы»
«вы будете получать меньше плюшек/премий/повышений, чем менеджеры»
Тут скажу так: на мой взгляд, это проблема менеджера. Я всегда стараюсь, донести до руководства заслуги «технарей». Благодаря этому плюшек они получают больше (:
Последний пункт про связи.
Как минимум, у разработчика есть связь с вами. Поэтому ему не обязательно иметь такой же широкий спектр, как и ваш.
Не согласен. Сейчас существует множество инструментов, позволяющих писать на одном языке, а приложения выпускать и под веб, и под мобилки, и даже клиентские. Т.е. даже без доп. изучения можно довольно сильно мотаться в областях.
«Работа для генералистов»
Спорно. Линый опыт говорит о том, что это не всегда так. Разрабатывая приложения для какой-либо области, разработчики точно также изучают эту область. Не так глубоко, но достаточно, чтобы понимать, что от них требуется и почему.
«На меня смотрят боссы»
«вы будете получать меньше плюшек/премий/повышений, чем менеджеры»
Тут скажу так: на мой взгляд, это проблема менеджера. Я всегда стараюсь, донести до руководства заслуги «технарей». Благодаря этому плюшек они получают больше (:
Последний пункт про связи.
Как минимум, у разработчика есть связь с вами. Поэтому ему не обязательно иметь такой же широкий спектр, как и ваш.
Менеджер значительно более заметен большим боссам, успех проекта — его успех. А вот факап проекта в больших корпорациях, это как правило факап исполнителей. Насколько это распространенное явление? Кто может подтвердить?
На основе опыта не подтверждаю существование такого принципа. Факап проекта — это прежде всего факап менеджера.
Спасибо мотивирующая статья.
А еще архитектором быть неплохо… И решения по проекту технические принимаешь и график посвободнее.
Sign up to leave a comment.
11 причин быть управленцем