Comments 51
А какая была мотивация менять профессию?
Искренне не понимаю зачем, будучи программистом, переходить на административную работу.
Сам тружусь много лет продактом и проджектом, и с легкой завистью смотрю на ребят, которым удалось переквалифицироваться из менеджеров в программцы. И работа творческая, и постоянно новое учат — а это само по себе очень полезно, улучшает кровообращение головного мозга и снижает риск получить склероз в старости.
Возвращайся, пока не поздно! :)
Сам тружусь много лет продактом и проджектом, и с легкой завистью смотрю на ребят, которым удалось переквалифицироваться из менеджеров в программцы. И работа творческая, и постоянно новое учат — а это само по себе очень полезно, улучшает кровообращение головного мозга и снижает риск получить склероз в старости.
Возвращайся, пока не поздно! :)
Ну менеджер среднего звена это совсем другие деньги, не уверен, что uster захочет назад.
Действительно хороший разработчик зарабатывает на уровне менеджера среднего звена, а иногда и больше.
Когда я переходил на позицию менеджера для себя оперировал следующими аспектами:
— На позиции производственной единицы (разработчик, дизайнер etc) человек занимается низкоуровневым творчеством, выполняя поставленные задачи, чаще всего имея меньше степеней свободы, так как действуешь в рамках чужой постановки.
— На позиции менеджера (PM, CTO etc) ты имеешь больше степеней свободы, действуешь в рамках более выскоуровневой постановки, можешь влиять сразу на весь проект или на несколько, по сути простор для творчества не меньше, а часто больше, так как ты являешься первоочередным постановщиком задач и можешь моделировать\проектировать в своем видении, ограничиваясь лишь рамками проекта и здравого смысла.
Попробовав себя в обеих ролях выбрал второе, но тут уж вопрос предрасположенности и личного настроя.
Когда я переходил на позицию менеджера для себя оперировал следующими аспектами:
— На позиции производственной единицы (разработчик, дизайнер etc) человек занимается низкоуровневым творчеством, выполняя поставленные задачи, чаще всего имея меньше степеней свободы, так как действуешь в рамках чужой постановки.
— На позиции менеджера (PM, CTO etc) ты имеешь больше степеней свободы, действуешь в рамках более выскоуровневой постановки, можешь влиять сразу на весь проект или на несколько, по сути простор для творчества не меньше, а часто больше, так как ты являешься первоочередным постановщиком задач и можешь моделировать\проектировать в своем видении, ограничиваясь лишь рамками проекта и здравого смысла.
Попробовав себя в обеих ролях выбрал второе, но тут уж вопрос предрасположенности и личного настроя.
Если сравнивать действительно хорошего разработчика и действительно хорошего менеджера среднего звена, то разработчик будет даже не близко. Плюс самая большая разница в том, что труд разработчика не масштабируется так хорошо, как труд управленца.
Результаты труда программиста масштабируются на порядки лучше. Так что это не аргумент.
Как раз по деньгам разницы особой нет
Менеджеры среднего звена это менеджеры у которых в подчинении менеджеры. Если лидов считать менеджерами, то проджект менеджер среднее звено, если не считать то проджект менеджер это менеджер нижнего звена.
Сеньоры тоже могут выполнять часть менеджерских функций.
Проджект менеджер тоже может писать код или креативить.
Чаще всего проджект менеджер это нижнее звено, потому что на нем висят проблемы не только лидов, но и все остальное, от закупки печений до разрешения внутрених конфликтов между рядовыми сотрудниками.
Если компания большая и проект большой, то для закупки печенек существует специальная отдельная девушка а для разруливания внутринних конфликтов другая специально обученая девушка. А проджект менеджер решает все вопросы собрав лидов в специальной комнате. Вот этот вариант и есть среднее звено.
Но в любом случае можно называть себя кем угодно, у нас, например, реализаторов называют лидами, чтобы они были довольные и писали код с удвоеной силой и за небольшие деньги.
Чаще всего проджект менеджер это нижнее звено, потому что на нем висят проблемы не только лидов, но и все остальное, от закупки печений до разрешения внутрених конфликтов между рядовыми сотрудниками.
Если компания большая и проект большой, то для закупки печенек существует специальная отдельная девушка а для разруливания внутринних конфликтов другая специально обученая девушка. А проджект менеджер решает все вопросы собрав лидов в специальной комнате. Вот этот вариант и есть среднее звено.
Но в любом случае можно называть себя кем угодно, у нас, например, реализаторов называют лидами, чтобы они были довольные и писали код с удвоеной силой и за небольшие деньги.
Я про то, что у сеньора могут быть подчиненные миддлы и/или джуниоры (как вариант у ведущего инженера-программиста — инженеры-программисты, программисты и техники-программисты). Вроде это обычная практика, что должность сеньора/ведущего это не просто «чтобы они были довольны» и не просто другой уровень технических задач, но и другой уровень задач административных, работа с людьми не только как исполнитель низшего звена, но и как начальник, менеджер, администратор звена среднего, с ответственностью перед вышестоящим начальством за работу подчиненных.
Лидов можно считать менеджерами с очень большой натяжкой.
Они хоть и выполняют часть менеджерских задач, но очень-очень далеки от полноценного менеджмента.
Они хоть и выполняют часть менеджерских задач, но очень-очень далеки от полноценного менеджмента.
Я имею работу именно чистого менеджера, тимлидер это все таки промежуточное звено и он держит в уме только свою команду и клиента. У менеджера гораздо больше возможностей и обязанностей и главное — совершенно другие оценки эффективности работы
Программист (особенно тот, кто хорошо разбирается в ООП) относительно легко может стать менеджером по той простой причине, что работа программиста требует развитых навыков менеджмента — менеджмента сущностей программы. Чем опытнее программист, тем лучший из него может получится менеджер.
Не все программисты готовы променять управление сущностями программы на управление людьми. Аналогию между этими двумя типами менеджмента проследить довольно легко, но в последнем случае приходится работать так сказать с «чужим кодом» — людей «зарефакторить» не получится —тем, кто не переваривает не оптимально написанный код перфекционистам будет очень нелегко.
Не все программисты готовы променять управление сущностями программы на управление людьми. Аналогию между этими двумя типами менеджмента проследить довольно легко, но в последнем случае приходится работать так сказать с «чужим кодом» — людей «зарефакторить» не получится —
Чего только не прочитаешь в статьях про менеджмент и менеджеров и комментариях к ним.
Большинство из них пестрит заблуждениями на тему того, что есть менеджмент, что есть проект и кто такой менеджер проектов.
Сам являюсь менеджером среднего звена, сам когда-то был разработчиком, затем синьором, затем лидом.
Перешёл в менеджмент целиком по собственной инициативе. Однако периодически имею возможность заниматься разработкой на работе.
Я не согласен с тем, что работа менеджера проектов не креативна.
Она в чём-то похожа на программирование, только для создания результата используются не классы, функции, операторы и прочие сущности, а ресурсы, люди, взаимоотношения и т.д. и т.п.
Кроме того, будучи разработчиком никогда не мог дома отключаться от работы полностью. И поэтому если и занимался разработкой дома, то всё это было связано с работой.
Сейчас я могу отключаться от работы полностью. Возможно, это не так, но я это связываю именно со своей позицией. И теперь дома я могу заниматься разработкой для себя. Какие-то свои проекты, идеи и т.п.
И, наконец, по поводу доходов. Чаще всего ЗП разработчика выше, чем ЗП менеджера среднего звена.
Большинство из них пестрит заблуждениями на тему того, что есть менеджмент, что есть проект и кто такой менеджер проектов.
Сам являюсь менеджером среднего звена, сам когда-то был разработчиком, затем синьором, затем лидом.
Перешёл в менеджмент целиком по собственной инициативе. Однако периодически имею возможность заниматься разработкой на работе.
Я не согласен с тем, что работа менеджера проектов не креативна.
Она в чём-то похожа на программирование, только для создания результата используются не классы, функции, операторы и прочие сущности, а ресурсы, люди, взаимоотношения и т.д. и т.п.
Кроме того, будучи разработчиком никогда не мог дома отключаться от работы полностью. И поэтому если и занимался разработкой дома, то всё это было связано с работой.
Сейчас я могу отключаться от работы полностью. Возможно, это не так, но я это связываю именно со своей позицией. И теперь дома я могу заниматься разработкой для себя. Какие-то свои проекты, идеи и т.п.
И, наконец, по поводу доходов. Чаще всего ЗП разработчика выше, чем ЗП менеджера среднего звена.
— Кроме того, будучи разработчиком никогда не мог дома отключаться от работы полностью.
Здесь безусловно соглашусь. У меня изза этого возникла проблема, не мог полностью абстрагироваться от работы (работаю дома, рабочее место всегда на виду). Сняв с себя полностью кодинг по работе — научился расслабляться и «ничегонеделать» в нерабочие часы, по крайней мере по работе.
Здесь безусловно соглашусь. У меня изза этого возникла проблема, не мог полностью абстрагироваться от работы (работаю дома, рабочее место всегда на виду). Сняв с себя полностью кодинг по работе — научился расслабляться и «ничегонеделать» в нерабочие часы, по крайней мере по работе.
UFO just landed and posted this here
> Чаще всего ЗП разработчика выше, чем ЗП менеджера среднего звена.
Менеджер среднего звена (=руководит другими менеджерами) по самому минимальному сценарию организует работу 15-20 человек, реально до сотни.
Его зарплата никаким образом не может быть меньше зарплаты типичного сотрудника, находящегося ниже по иерархии.
То, что обозначено в этой статье («руководитель небольшого отдела») — это тимлид, младший менеджер. Но никак не среднего звена.
Менеджер среднего звена (=руководит другими менеджерами) по самому минимальному сценарию организует работу 15-20 человек, реально до сотни.
Его зарплата никаким образом не может быть меньше зарплаты типичного сотрудника, находящегося ниже по иерархии.
То, что обозначено в этой статье («руководитель небольшого отдела») — это тимлид, младший менеджер. Но никак не среднего звена.
UFO just landed and posted this here
Это эгоистично было, полностью согласен. Сейчас слава богу не занимаюсь такими вещами. Зато нашел другую отдушину — начал немного работать сопровожденцем, находить проблемы пользователей и решать их. Это позволяет и оставаться в курсе продукта и не мешает нормальным программистам делать свою работу.
А дальше решать задачу, не отвлекаясь на эмоции.
Как бы их вообще отключать (на время) научиться, было бы здорово.
(Я тоже менеджер из программистов. Но всё ещё программирую дома ночью под одеялом =) ).
Спасибо за статью. Сам в свое время проходил через это, но в итоге решил вернуться в разработку. По мимо всего вышеперечисленного, для меня стало проблемой, что для менеджера, по мимо самих результатов, еще важно, как ты эти результаты преподнесешь. Т.е. просто отработал план на все 100%, в глазах руководства может быть менее ценно, чем отработать план на 70% + три часа рассказывать, какие все молодцы и как все здорово.
Можно немного расшифровать эту фразу:
Запивать стресс алкоголем, не спать и сильно переживать — это безусловно здорово и молодежно, но какая конкретно ответственность лежит на менеджере? И что он может сделать, если он не пишет и не ревьювит код? Придет к начальству после наступления дедлайна, потупив глаза в пол, со словами: «Мы недостаточно сильно старались, но в следующий раз будем стараться сильнее?»
P. S. не троллинг, просто в самом деле интересно
Менеджер — это ответственность за проект, за команду
Запивать стресс алкоголем, не спать и сильно переживать — это безусловно здорово и молодежно, но какая конкретно ответственность лежит на менеджере? И что он может сделать, если он не пишет и не ревьювит код? Придет к начальству после наступления дедлайна, потупив глаза в пол, со словами: «Мы недостаточно сильно старались, но в следующий раз будем стараться сильнее?»
P. S. не троллинг, просто в самом деле интересно
Менеджер — это ответственность за проект, т.е. ответственность за то, что эта активность будет выполнена в соответствии с ожиданиями всех заинтересованных сторон, а сроки и бюджет будут соблюдены.
Проект — это не только писать и ревьюить код. Тем более, что проекты по своему роду бывают очень разные, в том числе не связанные с разработкой или связанные не только с разработкой.
Контролировать выполнение задач, качество выполнения задач, сроки, бюджет, согласовывать изменения в проекте, следить за рисками и реагировать на них и многое-многое другое.
Те слова, которые вы процитировали, — это пример плохого менеджмента. Хороший менеджер определит это самое «мы недостаточно сильно старались» своевременно и примет меры.
Я понимаю, что это как игра в шахматы, но попробуйте побыть для себя одновременно и заказчиком, и исполнителем. Представьте, что на кону очень-очень большие деньги и положение на рынке. Если вы сделаете упор только на код, вы быстро поймёте, что гарантировать качество, сроки и бюджет без кучи посторонней для программиста деятельности очень трудно. Вот эта «куча посторонней для программиста деятельности», сильно утрируя, и есть деятельность менеджера проекта.
Проект — это не только писать и ревьюить код. Тем более, что проекты по своему роду бывают очень разные, в том числе не связанные с разработкой или связанные не только с разработкой.
Контролировать выполнение задач, качество выполнения задач, сроки, бюджет, согласовывать изменения в проекте, следить за рисками и реагировать на них и многое-многое другое.
Те слова, которые вы процитировали, — это пример плохого менеджмента. Хороший менеджер определит это самое «мы недостаточно сильно старались» своевременно и примет меры.
Я понимаю, что это как игра в шахматы, но попробуйте побыть для себя одновременно и заказчиком, и исполнителем. Представьте, что на кону очень-очень большие деньги и положение на рынке. Если вы сделаете упор только на код, вы быстро поймёте, что гарантировать качество, сроки и бюджет без кучи посторонней для программиста деятельности очень трудно. Вот эта «куча посторонней для программиста деятельности», сильно утрируя, и есть деятельность менеджера проекта.
но какая конкретно ответственность лежит на менеджере?
Увольнение за профнепригодность, но плюс кучу минусов в карму как и от исполнителей, так и от заказчиков.
Согласен с VolCh, это такая же работа, просто не имеющая такой явной оценки результата как программирование. Можно конечно уйти в абсолютизм — завалил проект, значит твой косяк. Но наверху обычно тоже не дураки сидят и видят окружение. Плюс это один из аспектов работы — уметь себя разрекламировать (без фанатизма).
просто не имеющая такой явной оценки результата как программированиеЕсли нет критериев оценки менеджера, значит его руководство недорабатывает. Как правило — это достижение заданных целей. Это могут быть не только релизы и законченные проекты, а например построение команды, инфраструктуры, разработка и введение каких-то регламентов и стандартов и т.п.
Тогда немного перефразирую — у программиста гораздо легче понять добился результата или нет и это даже в разных конторах более или менее похоже. У менеджера — такой разброс гораздо шире, что по одной системе молодец, по другой — просто недоразумение занимающее стул.
у программиста гораздо легче понять добился результата или нетРасскажите пожалуйста, подробнее, как вы это определяете. Из моей практики это очень непростая задача.
Приемочные тесты (необязательно автоматизированные).
1. тесты прошли успешно. Правда со 110 раза и с отставанием на полгода. Добился результата?
2. Тесты прошли успешно, раньше срока. Правда выяснилось, что программа работает только на машине разработчика и тестовом сервере. А у клиента не работает. Добился результата?
3. Тесты прошли успешно, все работает, клиент счастлив. Через месяц клиент просит допилить фичу, команда программистов смотрит код и выясняет, что хоть фича и мелкая но код настолько негибкий, что придется переписать половину.
И т.п. кейсы. не все так просто.
2. Тесты прошли успешно, раньше срока. Правда выяснилось, что программа работает только на машине разработчика и тестовом сервере. А у клиента не работает. Добился результата?
3. Тесты прошли успешно, все работает, клиент счастлив. Через месяц клиент просит допилить фичу, команда программистов смотрит код и выясняет, что хоть фича и мелкая но код настолько негибкий, что придется переписать половину.
И т.п. кейсы. не все так просто.
Если в задании на разработку был указан срок, окружение в котором должно всё работать и требования к архитектуре/коду, то всё это довольно просто верифицируется в булевых значениях (разве что субъективно может быть мнение гибко/не гибко, но какие-то формальные условия все равно можно предусмотреть).
В статье про менеджера «среднего звена» пишут. Это ближе, что по-английски Resource manager, а по-русски — начальник отдела. Т.е. руководитель 15-50 человек обычно. Одна из форм ответственности — финансовая за отдел. Т.е., скажем, приходы по проектам, где заняты подчиненные проектные менеджеры и программисты, должны покрыть расходы на зп, аренду и т.п. Плюс норма прибыли. Ответственность — не покрыли — ищи деньги.
Всего 4 проблемы? Пффф…
По критерию «Что для меня было самое сложное и где надо было себя перебороть». Были трудности связанные с недостатком знаний и умений, но их пришлось преодолевать и это верно. А эти 4 проблемы прямо были как кость в горле.
Для меня самой большой проблемой было делегирование ответственности. Т.е. полномочия я вполне успешно делегировал, а ответственность принимал всю на себя. Когда случился большой фейл (что бывает у всех) и система отреагировала репрессиями на всех уровнях, команда была сильно обижена, т.к. раньше руководителю удавалось оградить команду от суровой корпоративной действительности.
Удалил
Sign up to leave a comment.
Проблемы перехода в менеджеры среднего звена