Как найти и удержать программиста 17/10/07

Читая Юрия Скалецкого узнал об интересной ветке на RSDN «Как найти и удержать программиста». Мнения и советы противоречивые, но думаю, соприкосновение различных точек мнения заслуживает вашего внимания. Основной посыл поста такой:

«Столкнулся с ситуацией — приходит человек на работу, работает какое-то время, потом уходит, мотивируя тем, что работа ведется не по классическим технологиям, техзадания неконкретные, код не по Макконелу, архитектура не по паттернам проектирования и вообще, мол, хочу в крупную компанию.

Да, действительно, мы не используем в работе никакой из современный методологий разработки ПО; да, формализация задач слабая; да, работа не вполне регламентирована и упорядочена. Но надо же четко понимать, что москва не сразу строилась и все такое. Любая компания начинала с комнатки в нии и два разработчика за пыльным столом.

Зато у нас высокая степень самостоятельной организации труда и широкий простор для творчества. В том плане, что никто не заставляет тебя писать код по предварительно нарисованным UML-диаграммам, приветствуется самообразование, никто не бегает и не орет, что сорки летят (под задачу выделяются сроки заведомо большие, чтобы человек имел возможность попробовать разные варианты решения задачи) ит.д. ит.п.

А люди бегут.

Что делать, господа? Как найти и удержать разработчика, чтобы он приходил на работу не отработать номер и получить зарплату, а как-то был заинтересован в результатах труда, в развитии не только себя любимого (ну все, господа, я всему у вас научился, бывайте), но и компании, в которой он работает?»

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

Конкретно про программистов я могу сказать следующее:

Часто в компаниях берут человека на должность "программиста/разработчика", а требуют, чтобы он выполнял проект от начала до конца во всех ролях. Формулировал ТЗ, ТП, определял функциональные требования (как аналитик), ставил себе задачи и контролировал их (как менеджер); проектировал архитектура системы (как архитектор); документировал задание, и архитектуру; реализовывал и программировал (как обычный кодер на должность, которого его и наняли); затем этот человек должен составить планы тестов и описать их (как руководитель группы тестирования), затем (как рядовой тестер) должен протестировать и задокументировать и так далее. Плюс он часто должен быть сисадмином и службой поддержки пользователей.

В итоге от человека хотят, чтобы он совмещал в себе весь этот ворох должностей, был компетентен в каждой и ПРИ ЭТОМ получал зарплату обычно кодера! А на собеседовании ему, скорее всего, давались именно кодеровские задачки? А уж про то, что он должен отдать всю свою душу своей компании я вообще молчу! С другой стороны он же хочет карьерного роста? А вдруг не хочет? Вдруг у него есть дела поважнее, чем до ночи оставаться на работе.

А вообще все эти вопросы решены Томом Демарко еще 20 лет назад в книге «Человеческий фактор: успешные проекты и команды» благо она переведена и переиздана.

Жизнь | Оставить комментарий