Comments 32
Еще один важный момент, относящийся к этому уровню потребностей, это снова зарплата. Не размер зарплаты, как таковой, но наличие определённого порядка её изменения. В компании должен быть подход к определению требований к позициям разных уровней. Каждый разработчик должен иметь возможность обсудить ожидания к своей работе с компанией, понимать, как его и когда его усилия могут отразиться на его зарплате.
Вот прям один из самых ключевых моментов в программе мотивации. Наличие четкой, понятной дорожной карты в треугольнике «работник» — «зарплата» — «работодатель», один из ключевых факторов успеха в мотивации и получении результата.
Спасибо за статью, очень понравилась, жду продолжения.
Очень хорошо изложено. Полезно распечатать и повесить перед собой любому менеджеру софтверной команды. Момент про постепенное отрицательное влияние обсценной лексики в команде очень тонко подмечен.
Какой-то идеальный мир нарисован.
В реальной жизни никто не будет вникать в потребности разработчика, тем более по теории с избитой пирамидой Маслоу. Все намного проще. Цель бизнеса — прибыль, цель работника откусить из этой прибыли, дороже себя продав. Продавать себя не все умеют и хотят, что очевидно.
Одно другому не противоречит. Довольные продуктивные разработчики будут приносить бизнесу больше денег, чем недовольные и непродуктивные. И если менеджмент умеет добиваться первого, то это полностью соответствует целям бизнеса, который их нанимал.
У бизнеса нет цели повышать ЗП работнику, даже если он хорошо работает.
Цель у бизнеса обычно другая, это факт. Как правило, в цели бизнеса входит: 1) зарабатывание денег и 2) рост/развитие/стабильность/продолжительность.
Однако если не думать о мотивации и развитии людей, в компании останутся только люди, которым некуда больше идти. Неочевидно, что они сильно поспособствуют получению прибыли бизнесом и его стабильности.
Однако если не думать о мотивации и развитии людей, в компании останутся только люди, которым некуда больше идти. Неочевидно, что они сильно поспособствуют получению прибыли бизнесом и его стабильности.
Вы не правы.
Программисты обычно работают, потому что им нравиться программировать, точнее решать интеллектуальные задачи.
Как было отмечено в статье, если цели понятны, если не мешать работать и не контролировать программистов, то они обычно перерабатывают, а не наоборот.
Я это вижу на практике. Некоторых сотрудников нужно наоборот «тормозить» и заставлять их отдыхать. А то они уробатываются вплоть, до полной не работоспособности.
Деньги программисты рассматривают с точки зрения «справедливости».
Т.е. обычно программисты сильно де мотивируются, если считают, что оплата труда недостаточная. И очень слабо мотивируются «надбавками».
Программисты обычно работают, потому что им нравиться программировать, точнее решать интеллектуальные задачи.
Как было отмечено в статье, если цели понятны, если не мешать работать и не контролировать программистов, то они обычно перерабатывают, а не наоборот.
Я это вижу на практике. Некоторых сотрудников нужно наоборот «тормозить» и заставлять их отдыхать. А то они уробатываются вплоть, до полной не работоспособности.
Деньги программисты рассматривают с точки зрения «справедливости».
Т.е. обычно программисты сильно де мотивируются, если считают, что оплата труда недостаточная. И очень слабо мотивируются «надбавками».
Вы из какой-то параллельной реальности:) Среди программистов очень много нормальных людей и их деньги интересуют, потому что они должны понимать, что им надо развиватьсяи и развивать свою жизнь.
Среди программистов почти все нормальные люди.
И в основном они работают для самореализации.
Откровенных рвачей я лично не встречал.
Я же говорю немного о другом. Тезис «программисты работают только за деньги» не является верным.
И в основном они работают для самореализации.
Откровенных рвачей я лично не встречал.
Я же говорю немного о другом. Тезис «программисты работают только за деньги» не является верным.
Вы смените свою работу, если предложат на 1% больше?
Коллеги, приведу аналогию с кодом.
Если в данный конкретный момент Вы смотрите на кусок спагетти-кода без тестов и комментариев, без документации и с багами, это ведь не означает, что прям весь код в индустрии похож на него? В реальной жизни бывает и хороший код, и я его видел.
Я также видел, как в реальной жизни потребности программиста интересовали его компанию.
Я с Вами совершенно согласен, не все умеют и хотят себя продавать, тут спорить не о чем. Если цель человека — откусить из прибыли, это вполне себе определённая мотивация, хорошо вписывающаяся в избитую пирамиду Маслоу. При такой мотивации ему и не нужно, чтобы кто-либо вникал в его потребности. При нынешнем состоянии рынка (когда программисту достаточно поднять руку, и рекрутеры закружатся стайками, как говорится, «один-два крупных, три-четыре мелких»), не вижу, что может задержать программиста в компании, если его потребности не удовлетворены.
Игорь
Если в данный конкретный момент Вы смотрите на кусок спагетти-кода без тестов и комментариев, без документации и с багами, это ведь не означает, что прям весь код в индустрии похож на него? В реальной жизни бывает и хороший код, и я его видел.
Я также видел, как в реальной жизни потребности программиста интересовали его компанию.
Я с Вами совершенно согласен, не все умеют и хотят себя продавать, тут спорить не о чем. Если цель человека — откусить из прибыли, это вполне себе определённая мотивация, хорошо вписывающаяся в избитую пирамиду Маслоу. При такой мотивации ему и не нужно, чтобы кто-либо вникал в его потребности. При нынешнем состоянии рынка (когда программисту достаточно поднять руку, и рекрутеры закружатся стайками, как говорится, «один-два крупных, три-четыре мелких»), не вижу, что может задержать программиста в компании, если его потребности не удовлетворены.
Игорь
Неплохо. Одна важная тема не раскрыта — увольнения и их влияние на команду.
Во многих вещах мой подход идентичный. Но «красной нитью» для меня проходит не просто управление «приходом», а развитие мысли у команды, что они профессионалы со своей долей ответственности и возможностями в проекте. Чувство причастности к конечному продукту.
Конечным маркером я считаю возможность команды работать автономно продолжительный период времени. Т.е. набранный «запас прочности» от действий менеджера.
Во многих вещах мой подход идентичный. Но «красной нитью» для меня проходит не просто управление «приходом», а развитие мысли у команды, что они профессионалы со своей долей ответственности и возможностями в проекте. Чувство причастности к конечному продукту.
Конечным маркером я считаю возможность команды работать автономно продолжительный период времени. Т.е. набранный «запас прочности» от действий менеджера.
соглашусь, порою знание зарплат окружающих резко демотивирует
Rockstar разработчики обычно понимают, что их везде возьмут за высокую зарплату, поэтому зарплата не решающий фактор. Решающий фактор для них, пожалуй, интересные проекты и свобода. Если менеджеры будут пытаться «рулить» такими «рок-звездами» дедлайнами и другими ограничениями, или давать неинтересные проекты/задачи, то самые талантливые сбегут.
Да и сомневаюсь, что нужна вся команда таких вот талантов. Основной состав должен приходиться на «линейных» разработчиков, так сказать «средней руки». Они более исполнительные, поэтому их легче менеджить.
Да и сомневаюсь, что нужна вся команда таких вот талантов. Основной состав должен приходиться на «линейных» разработчиков, так сказать «средней руки». Они более исполнительные, поэтому их легче менеджить.
иногда в команде начинает использоваться обсценная лексика. Практика показывает, что на атмосферу это влияет отрицательно, общение постепенно становится грубым. Стоит избегать её использования самому и не поощрять её использования в команде.
Возражу против категоричности этой мысли.
Есть у меня интеллигентный знакомый математик, к.ф.-м.н., ну прямо воплощение идеала интеллигенции. Даже когда он употребляет ненормативную лексику, это приятно слушать. Он матом не ругается, просто называет вещи своими именами. Не всегда приличными, но всегда к месту.
Как в последнем сезоне ИП
Статья хорошая, автор явно все испытал на своей шкуре. Но не рассмотрен вопрос потолка зарплаты. Вот работаешь, копишь опыт, все хорошо. Но что делать если опыт разработчика 20+ лет? Явно денег больше он не получит, т.к. дойдет до потолка зарплаты. Т.е. надо уходить из разработчиков, вопрос: куда? Или в тим лидеры, или в менеджеры или в предприниматели. Может еще какие пути развития есть. Или просто перестать быть разработчиком.
Техлидеры, архитекторы. Ну и потолок зарплаты тоже надо суметь ещё достичь. В 25% самых оплачиваемых в регионе ещё можно попасть "за выслугу лет", а вот выше стараться надо
На роль карьерного консультанта я не претендую, но чисто субъективно, из своего опыта, я бы сказал, что потолок зарплаты в правильной компании соответствует только объёму пользы, которую приносит программист или менеджер (предпринимательство я бы не рассматривал в нашем контексте — это совсем из другой области).
Если растёт именно качественный опыт, а не просто количество лет, отсиженных на работе, обычно человек начинает работать над архитектурой систем, становится техническим (именно техническим) лидом, занимается какими-то сложными, сильно нагруженными, распределёнными штуками, техническими исследованиями, генерит спеки протоколов, разрабатывает API, пишет статьи, выступает на конференциях, и т.д. То есть, делает вещи, которые даже три-четыре-пять начинающих программистов, собранных вместе, сделать не смогут. Поэтому если жизнь компании зависит от софта, который она разрабатывает (а программисту, мне кажется, стоит работать именно в такой компании), в таких компаниях обычно нет предела роста для технического специалиста и после 20, и после 30 лет работы. Если есть желание продолжать быть разработчиком, я бы скорее поискал такую компанию, чем рассматривал вариант перехода в менеджеры или тимлиды. Это всё-таки работа другого рода. Это не теория, я видел много таких людей, программистов, начальник у которых, скажем, старший вице-президент, и которые получают зарплату на уровне директоров или вице-президентов, и которые репортят этому же вице-президенту. В западных компаниях есть такой термин «fellow», об этом можно почитать, например, здесь: www.quora.com/What-are-the-different-levels-of-software-engineers-at-Google
Если растёт именно качественный опыт, а не просто количество лет, отсиженных на работе, обычно человек начинает работать над архитектурой систем, становится техническим (именно техническим) лидом, занимается какими-то сложными, сильно нагруженными, распределёнными штуками, техническими исследованиями, генерит спеки протоколов, разрабатывает API, пишет статьи, выступает на конференциях, и т.д. То есть, делает вещи, которые даже три-четыре-пять начинающих программистов, собранных вместе, сделать не смогут. Поэтому если жизнь компании зависит от софта, который она разрабатывает (а программисту, мне кажется, стоит работать именно в такой компании), в таких компаниях обычно нет предела роста для технического специалиста и после 20, и после 30 лет работы. Если есть желание продолжать быть разработчиком, я бы скорее поискал такую компанию, чем рассматривал вариант перехода в менеджеры или тимлиды. Это всё-таки работа другого рода. Это не теория, я видел много таких людей, программистов, начальник у которых, скажем, старший вице-президент, и которые получают зарплату на уровне директоров или вице-президентов, и которые репортят этому же вице-президенту. В западных компаниях есть такой термин «fellow», об этом можно почитать, например, здесь: www.quora.com/What-are-the-different-levels-of-software-engineers-at-Google
Sign up to leave a comment.
Управление командой программистов: как и чем их правильно мотивировать? Часть первая