Управление командой программистов: как и чем их правильно мотивировать? Часть первая

    Эпиграф:
    Муж, глядя на чумазых детей, говорит жене: ну, что, этих отмоем или новых нарожаем?


    Под катом рассуждения нашего тимлида, а также директора по развитию продукта RAS — Игоря Марната об особенностях мотивации программистов.

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

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

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

    image

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

    Итак, теперь пройдёмся по пирамиде Маслоу и рассмотрим её уровни в применении к управлению командой программистов.

    I: Физиологические, биологические потребности:

    Говоря о мотивации, многие, в первую очередь, часто думают о зарплате. Под зарплатой в этом случае я понимаю постоянную часть пакета компенсации, которая никак не зависит от результатов. Это не относится к бонусам, премиям и акциям компании. Именно зарплату я бы отнёс к уровню «физиологических потребностей» в нашем случае. Бонусы, премии по результатам работы, опционы и акции компании – все это я бы отнёс уже к другим уровням.

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

    В то же время отсутствие справедливой в их понимании зарплаты программистов демотивирует, и демотивирует сильно. Наличие справедливой зарплаты — это норма. Зарплата сильно выше нормы (рынка) – тоже, как ни странно, фактор скорее демотивирующий. Один коллега мне как-то рассказывал о команде программистов в одной из больших анимационных американских компаний, которая, в силу ряда обстоятельств, получала зарплаты на уровне в два-три раза больше рынка. Как он рассказывал, более заевшихся, ленивых и демотивированных программистов он в своей жизни не видел. Факт повышения зарплаты может мотивировать краткосрочно, но через несколько месяцев новая зарплата становится нормой и перестаёт мотивировать. В целом, я бы сказал, для программистов в начале карьеры фактор зарплаты важнее, по мере их профессионального роста и развития — его важность снижается, и другие факторы начинают превалировать.

    Второй важный момент — наличие справедливого баланса в уровне зарплат в команде. Если команда ощущает, что вклад одного из участников заметно ниже, но уровень компенсации при этом не отличается, это будет демотивировать всю команду. Иногда менеджеры испытывают искушение заливать пожар деньгами — удерживать выгоревшего или демотивированного человека, повышая ему зарплату выше нормы. Это обычно только создаёт проблемы в долгосрочной перспективе — мотивация самого человека особенно не вырастет, или подрастёт на пару месяцев, а вот мотивация остальной команды упадёт. В таких ситуациях стоит искать другие подходы, если, конечно, это не уникальный специалист, которого нужно удержать любой ценой даже на короткое время.

    II. Потребность в безопасности, комфорт, постоянство условий жизни:

    70 лет назад наличие печки в автомобиле могло быть мотивирующим фактором при выборе машины, тогда это было выше нормы, было признаком luxury. Сейчас даже отсутствие кондиционера — это нонсенс, и его наличие мотивирующим фактором при выборе автомобиля, разумеется, не будет. Так еще 10-15 лет назад удобный офис, хорошее железо, вкусный кофе, фитнес, гибкий график, и т.д. могли быть хорошими мотивирующими факторами, сейчас же это скорее норма для работы хорошего программиста. В то же время их отсутствие, опять же, будет демотивировать.

    Важный демотивирующий фактор — отсутствие возможности сконцентрироваться, шумное рабочее окружение. Работа программиста требует тишины и сосредоточенности. Если офисное пространство не даёт возможности предоставить разработчикам уединённое рабочее место, необходимо хотя бы обеспечить комфортную совместную работу коллег, которые не мешают друг другу. Энергичных и громогласных товарищей лучше объединить друг с другом, дав возможность сосредоточиться тем, кому это необходимо.

    Стоимость времени программиста сейчас заметно выше, чем стоимость железа, на котором он работает. Два-три монитора, мощные компьютеры, удобное рабочее место для каждого разработчика — должны быть нормой в любой компании. Эта тема хорошо раскрыта в одной из статей Джоэла Спольски “The Joel Test: 12 steps to better code”.

    Физическая составляющая комфорта — самая базовая и простая, поговорим теперь об остальных.

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

    Важный момент — наличие определенного окна времени, когда вся команда работает вместе локально, чтобы люди могли общаться и решать вопросы в личном общении. Программист, в сущности, с работы не уходит и после работы. Обычно рабочие моменты прокручиваются в его уме вне зависимости от присутствия в офисе, и хорошие решения часто приходят вне его. С учётом потребности быть хорошим (на которой мы остановимся чуть ниже), мелочный контроль вреден. Мало того, что он демотивирует, он еще и снижает производительность. Как показывает практика, в отсутствии контроля замотивированная команда скорее работает дольше, чем нужно. При наличии контроля разработчики могут сидеть за клавиатурой с девяти до шести, но результат, думаю, будет хуже. Как говорится, привести коня на водопой может и один человек, но даже сотня не заставит его пить, если он не хочет.

    В описании этого уровня потребностей упоминается также свобода от тревоги и страха, отсутствие хаоса, потребность в структуре и порядке. Это тоже крайне важные моменты, которые сильно влияют на атмосферу в команде.

    Во-первых, отсутствие хаоса, структура и порядок — команда должна понимать, кто за что отвечает, как распределены роли, что предстоит делать, кому, когда, какие требования лежат в основе продукта, каковы ожидания начальства и заказчика… Большая часть из этого должна быть формально описана, всё должно периодически обсуждаться. Без обсуждения и периодического использования описания не работают. Хорошей практикой является их периодическое обсуждение и обновление по результатам postmortem анализа после релиза.

    Во-вторых, спокойная и дружеская атмосфера. Все мы проводим на работе большую часть времени, и хотим делать это без стресса, конфликтов, страха. Команда разработки и так обычно работает под давлением расписания и заказчиков. Добавочный стресс со стороны коллег и начальства никому не нужен. Атмосфера в команде, вообще сам факт того, что группа разработчиков может называться и быть «командой» — прямая и важная ответственность менеджера, одна из самых главных среднесрочных и долгосрочных задач. Поэтому менеджеру важно работать, в частности, с конфликтами в команде, не пускать их развитие на самотёк. Управление конфликтами — отдельная тема, заслуживающая отдельного изучения.

    Есть два основных способа влияния на эмоциональное состояние команды, на поведение коллег (если кто-то дополнит в комментариях — будет прекрасно). Первый — собственное поведение. Личный пример — суперважно для менеджера и команды. Как говорится, каков поп, таков и приход. Ведите себя так, как вы ожидаете, чтобы ваши коллеги вели себя. Второй — поощрение правильного поведения, и, так сказать, де-поощрение неправильного. Общайтесь с людьми, давайте им фидбек, есть много способов это делать. Вообще, фидбек — это тема для отдельного разговора, это большая и важная часть работы с мотивацией.

    Ещё замечание об атмосфере, которое может показаться необычным, но на практике оно важно. Чаще всего, в команде разработчиков девушек меньше, чем мужчин. Зачастую коллективы полностью мужские. В таких условиях, еще и под нагрузкой, иногда в команде начинает использоваться обсценная лексика. Практика показывает, что на атмосферу это влияет отрицательно, общение постепенно становится грубым. Стоит избегать её использования самому и не поощрять её использования в команде.

    Команды разработки часто называют R&D (research and development), при этом research составляет значимую часть работы. Это та часть, которую обычно трудно запрограммировать и запланировать, иначе это не был бы research. Важно, чтобы команда имела право на ошибку, на инициативу, на опробование разных вариантов, которые могут закончиться удачей, а могут и не закончиться. Ошибки — нормальная часть работы, их нельзя избежать, но можно изучать, анализировать, извлекать из них уроки на будущее и двигаться дальше. Принцип 5 why’s, зародившийся в Toyota, хорошо помогает добраться до исходной причины проблемы. Наказывать за ошибки – это отличный способ создать атмосферу страха и неуверенности. Единственное исключение — когда по результатам разбора оказывается, что ошибка вызвана непрофессиональным отношением к работе, в таком случае, возможно, нужно будет принимать кадровые решения.

    На атмосферу в команде очень влияют ваши ожидания, эмоциональное состояние до начала разговора. Перед началом сложного обсуждения, какого-то разбора полётов или просто эмоционального разговора важен ваш настрой, отношение к человеку, с которым вы собираетесь говорить. Я всегда по умолчанию считаю и действую исходя из того, что человек искренне старался сделать как лучше. Если с вашей позиции видится, что это не так — нужно спокойно и детально выяснить контекст и понять, что он сделал правильно, почему он считал, что это правильно, и где наши ожидания расходятся. Обычно оказывается, что они и не особо расходятся, просто его видение контекста более полное или свежее, и вы чего-то не знали. Или, наоборот, он чего-то не знал. Особенно это важно в распределённой команде, когда люди реже общаются лично, используют почту и мессенджеры. Еще более это критично в команде, состоящей из программистов из разных стран и распределённых между разными временными зонами. Здесь большую роль начинают играть культурные различия.

    В сложной ситуации наехать с ходу просто, очень просто, но вот отъехать назад потом тяжело, и осадок остаётся надолго. Приведу простой пример из недавнего опыта. Одному из менеджеров команды срочно нужны были комментарии по поводу какой-то проблемы у заказчика от менеджера из смежной команды из другой страны. Он пинганул коллегу в мессенджере, подождал минут 15, пинганул еще раз, потом минут через 15 пошёл в большой чат, в котором были и остальные менеджеры, и слегка наехал на коллегу, с формулировкой вроде: “раз уж ты мне не соблаговолишь отвечать, может, и вопрос не такой уж срочный?”. В итоге оказалось, что наш корпоративный мессенджер слегка затупил, и коллега вопроса вообще не видел. Пришлось извиняться. В общем, лучше исходить из хорошего. Ошибиться в плохую сторону и наехать позже всегда получится, проблем с этим нет (хотя делать этого не стоит). Вообще, за более чем 20 лет работы в нашей индустрии я встречал реально злонамеренного коллегу всего один (!) раз. К счастью, мы довольно быстро расстались. Исходить из того, что коллеги хотят как лучше, в меру своего видения контекста, оказывается правильным в подавляющем большинстве случаев.

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

    Кстати, заговорил о команде поддержки и вспомнился канонический для меня пример. Как-то у одного из заказчиков в Америке возникла проблема с продуктом, один из инженеров команды поддержки, которые работали у него на внедрении (командированные из России), остался после работы, чтобы помочь, но проблема всё не решалась и не решалась. В общем, он задержался и сидел там практически до утра. В это время менеджеры заказчика эскалировали проблему, обозначили её критичность для них и вечером ушли с работы. Процесс эскалации набирал обороты уже в другой временной зоне, менеджеры поддержки в России начали пытаться помочь, в силу определённых сложностей в коммуникации с офисом заказчика (VPN, проблемы со связью, сложности со звонками между странами, …) они не знали, что парень уже сидит в офисе и решает вопрос, и пытались его разыскать. Нашли только под утро (американское), когда вопрос был им уже практически решён, и продукт заработал. С места в карьер стали наезжать, что какого чёрта, у заказчика такая эскалация, ничего не работает, где тебя носит, мы не можем тебя найти, и т.д. Надо ли говорить, что в результате подобного поведения парень был сильно демотивирован. Организация работы распределённой команды — отдельная большая тема, но важно помнить о двух вещах. Во-первых, коммуникации, атмосфера — это очень важно, от этого зависит успех работы. Во-вторых, это не работает само по себе, этим надо заниматься отдельно и углублённо.

    Еще один важный момент, относящийся к этому уровню потребностей, это снова зарплата. Не размер зарплаты, как таковой, но наличие определённого порядка её изменения. В компании должен быть подход к определению требований к позициям разных уровней. Каждый разработчик должен иметь возможность обсудить ожидания к своей работе с компанией, понимать, как его и когда его усилия могут отразиться на его зарплате. Периодические встречи с менеджером, полугодовые или годовые аттестации служат этой цели. Это, опять же, один из тех моментов, наличие которых не мотивирует в явном виде, но их отсутствие демотивирует сильно.

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

    Еще важный момент, который стоит отнести к потребности наличия порядка и отсутствия хаоса — возможность концентрации на задаче, отсутствие частых переключений контекста. Работа программиста требует времени и сосредоточенности. Программисты очень не любят срочно бросать одну задачу и переключаться на другую. Необходимой частью работы программиста обычно бывает не только непосредственно разработка кода, но и баг фиксинг, и помощь с обработкой обращений от заказчиков. Стоит планировать такие вещи заранее, таким образом, чтобы дать возможность программисту спокойно и полностью завершить работу над одной задачей перед переключением на другую. Лучший вариант — дать возможность планировать свою работу самостоятельно, обозначив приоритеты и предстоящие задачи заранее, выделив длинное, продолжительное время для работы над одним типом задач. Эта тема хорошо описана в книге “Google — Site Reliability Engineering”, в которой хорошо описаны подходы к планированию работы команд, обеспечивающих эксплуатацию и развитие больших, высоконагруженных отказоустойчивых систем, а также инженеров, которые по роду деятельности совмещают разработку программного обеспечения и его поддержку.

    Продолжение следует...
    Parallels
    218,74
    Мировой лидер на рынке межплатформенных решений
    Поделиться публикацией

    Комментарии 32

      +3
      Еще один важный момент, относящийся к этому уровню потребностей, это снова зарплата. Не размер зарплаты, как таковой, но наличие определённого порядка её изменения. В компании должен быть подход к определению требований к позициям разных уровней. Каждый разработчик должен иметь возможность обсудить ожидания к своей работе с компанией, понимать, как его и когда его усилия могут отразиться на его зарплате.

      Вот прям один из самых ключевых моментов в программе мотивации. Наличие четкой, понятной дорожной карты в треугольнике «работник» — «зарплата» — «работодатель», один из ключевых факторов успеха в мотивации и получении результата.
        0
        Верно, когда после двух лет работы тебе скажут «какое еще повышение?», тогда первая мысль это свалить в другое место.
        +2
        Спасибо за статью, очень понравилась, жду продолжения.
          +1
          Очень хорошо изложено. Полезно распечатать и повесить перед собой любому менеджеру софтверной команды. Момент про постепенное отрицательное влияние обсценной лексики в команде очень тонко подмечен.
            +3
            Какой-то идеальный мир нарисован.
              +1
              В реальной жизни никто не будет вникать в потребности разработчика, тем более по теории с избитой пирамидой Маслоу. Все намного проще. Цель бизнеса — прибыль, цель работника откусить из этой прибыли, дороже себя продав. Продавать себя не все умеют и хотят, что очевидно.
                +1
                Одно другому не противоречит. Довольные продуктивные разработчики будут приносить бизнесу больше денег, чем недовольные и непродуктивные. И если менеджмент умеет добиваться первого, то это полностью соответствует целям бизнеса, который их нанимал.
                  0
                  У бизнеса нет цели повышать ЗП работнику, даже если он хорошо работает.
                    0
                    Цель у бизнеса обычно другая, это факт. Как правило, в цели бизнеса входит: 1) зарабатывание денег и 2) рост/развитие/стабильность/продолжительность.
                    Однако если не думать о мотивации и развитии людей, в компании останутся только люди, которым некуда больше идти. Неочевидно, что они сильно поспособствуют получению прибыли бизнесом и его стабильности.
                      0

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

                  +2
                  Вы не правы.
                  Программисты обычно работают, потому что им нравиться программировать, точнее решать интеллектуальные задачи.
                  Как было отмечено в статье, если цели понятны, если не мешать работать и не контролировать программистов, то они обычно перерабатывают, а не наоборот.
                  Я это вижу на практике. Некоторых сотрудников нужно наоборот «тормозить» и заставлять их отдыхать. А то они уробатываются вплоть, до полной не работоспособности.
                  Деньги программисты рассматривают с точки зрения «справедливости».
                  Т.е. обычно программисты сильно де мотивируются, если считают, что оплата труда недостаточная. И очень слабо мотивируются «надбавками».
                    0
                    Вы из какой-то параллельной реальности:) Среди программистов очень много нормальных людей и их деньги интересуют, потому что они должны понимать, что им надо развиватьсяи и развивать свою жизнь.
                      +1
                      Среди программистов почти все нормальные люди.
                      И в основном они работают для самореализации.
                      Откровенных рвачей я лично не встречал.
                      Я же говорю немного о другом. Тезис «программисты работают только за деньги» не является верным.

                        0

                        Вы смените свою работу, если предложат на 1% больше?

                          0
                          Нет.
                            0

                            Так больше же возможностей развиватьсяи и развивать свою жизнь?

                              0
                              Во первых, сумма, не такая большая, чтобы думать о смене работы.
                              Во вторых не всякая работа оценивается только ЗП.
                              В третьих, проще управлять своими желаниями, чем желаниями других. :-)
                                0

                                Про что и речь:


                                И очень слабо мотивируются «надбавками».
                                  0
                                  Да. Про это я и говорю.
                      0
                      Коллеги, приведу аналогию с кодом.
                      Если в данный конкретный момент Вы смотрите на кусок спагетти-кода без тестов и комментариев, без документации и с багами, это ведь не означает, что прям весь код в индустрии похож на него? В реальной жизни бывает и хороший код, и я его видел.
                      Я также видел, как в реальной жизни потребности программиста интересовали его компанию.
                      Я с Вами совершенно согласен, не все умеют и хотят себя продавать, тут спорить не о чем. Если цель человека — откусить из прибыли, это вполне себе определённая мотивация, хорошо вписывающаяся в избитую пирамиду Маслоу. При такой мотивации ему и не нужно, чтобы кто-либо вникал в его потребности. При нынешнем состоянии рынка (когда программисту достаточно поднять руку, и рекрутеры закружатся стайками, как говорится, «один-два крупных, три-четыре мелких»), не вижу, что может задержать программиста в компании, если его потребности не удовлетворены.
                      Игорь
                        +1

                        Не согласен, выше определенного уровня комфортное место и интересный сложный проект важнее, чем +25% к зарплате в другом месте, где рутина и шумный опенспейс.

                        0
                        Неплохо. Одна важная тема не раскрыта — увольнения и их влияние на команду.

                        Во многих вещах мой подход идентичный. Но «красной нитью» для меня проходит не просто управление «приходом», а развитие мысли у команды, что они профессионалы со своей долей ответственности и возможностями в проекте. Чувство причастности к конечному продукту.

                        Конечным маркером я считаю возможность команды работать автономно продолжительный период времени. Т.е. набранный «запас прочности» от действий менеджера.
                          0
                          Добрый день,
                          спасибо за комментарий.
                          Да, чувство причастности и возможность работать автономно — это очень важно, об этом планирую подробно рассказать во второй части статьи, она еще пока не окончена :)
                          Игорь
                          –1
                          соглашусь, порою знание зарплат окружающих резко демотивирует
                            0
                            Rockstar разработчики обычно понимают, что их везде возьмут за высокую зарплату, поэтому зарплата не решающий фактор. Решающий фактор для них, пожалуй, интересные проекты и свобода. Если менеджеры будут пытаться «рулить» такими «рок-звездами» дедлайнами и другими ограничениями, или давать неинтересные проекты/задачи, то самые талантливые сбегут.
                            Да и сомневаюсь, что нужна вся команда таких вот талантов. Основной состав должен приходиться на «линейных» разработчиков, так сказать «средней руки». Они более исполнительные, поэтому их легче менеджить.
                              –2
                              иногда в команде начинает использоваться обсценная лексика. Практика показывает, что на атмосферу это влияет отрицательно, общение постепенно становится грубым. Стоит избегать её использования самому и не поощрять её использования в команде.

                              Возражу против категоричности этой мысли.
                              Есть у меня интеллигентный знакомый математик, к.ф.-м.н., ну прямо воплощение идеала интеллигенции. Даже когда он употребляет ненормативную лексику, это приятно слушать. Он матом не ругается, просто называет вещи своими именами. Не всегда приличными, но всегда к месту.
                                0
                                Как в последнем сезоне ИП
                                image
                                  0
                                  Статья хорошая, автор явно все испытал на своей шкуре. Но не рассмотрен вопрос потолка зарплаты. Вот работаешь, копишь опыт, все хорошо. Но что делать если опыт разработчика 20+ лет? Явно денег больше он не получит, т.к. дойдет до потолка зарплаты. Т.е. надо уходить из разработчиков, вопрос: куда? Или в тим лидеры, или в менеджеры или в предприниматели. Может еще какие пути развития есть. Или просто перестать быть разработчиком.
                                    0

                                    Техлидеры, архитекторы. Ну и потолок зарплаты тоже надо суметь ещё достичь. В 25% самых оплачиваемых в регионе ещё можно попасть "за выслугу лет", а вот выше стараться надо

                                      0
                                      Ну вот я смог :0) Когда осознал очень удивился. Архитектором думал работать, но не прикалывает с людьми нелогичного склада ума иметь дело. Бизнесмены это еще те заказчики. Сейчас фактически техлидер, но чувствую, тупик это. Да можно скилы еще растить, но все равно тупик.
                                      0
                                      На роль карьерного консультанта я не претендую, но чисто субъективно, из своего опыта, я бы сказал, что потолок зарплаты в правильной компании соответствует только объёму пользы, которую приносит программист или менеджер (предпринимательство я бы не рассматривал в нашем контексте — это совсем из другой области).

                                      Если растёт именно качественный опыт, а не просто количество лет, отсиженных на работе, обычно человек начинает работать над архитектурой систем, становится техническим (именно техническим) лидом, занимается какими-то сложными, сильно нагруженными, распределёнными штуками, техническими исследованиями, генерит спеки протоколов, разрабатывает API, пишет статьи, выступает на конференциях, и т.д. То есть, делает вещи, которые даже три-четыре-пять начинающих программистов, собранных вместе, сделать не смогут. Поэтому если жизнь компании зависит от софта, который она разрабатывает (а программисту, мне кажется, стоит работать именно в такой компании), в таких компаниях обычно нет предела роста для технического специалиста и после 20, и после 30 лет работы. Если есть желание продолжать быть разработчиком, я бы скорее поискал такую компанию, чем рассматривал вариант перехода в менеджеры или тимлиды. Это всё-таки работа другого рода. Это не теория, я видел много таких людей, программистов, начальник у которых, скажем, старший вице-президент, и которые получают зарплату на уровне директоров или вице-президентов, и которые репортят этому же вице-президенту. В западных компаниях есть такой термин «fellow», об этом можно почитать, например, здесь: www.quora.com/What-are-the-different-levels-of-software-engineers-at-Google
                                        0
                                        Да, я ищу такую компанию. Однако чаще всего это связано с переездом в другую страну, т.е. надо бросать дом и куда-то ехать. А дистанционно возможностей намного меньше.

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

                                    Самое читаемое