Совет о том, чем мотивировать IT-специалистов

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

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

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

А если не закроет? Как-то ведь надо оценивать эффективность и работоспособность программиста.

Хорошо, закрыл он задачу не вчера, а сегодня - молодец! А Вася из соседнего отдела не успел что-то сделать.

Творчество-творчеством, но рабочий порядок должен быть.

Самый хороший мотиватор - это оказаться на улице безработным и бездомным