Дж.Ханк Рейнвотер - Как пасти котов. Наставление для программистов, руководящих другими программистами

Продвигая сотрудников ввысь по должностной лестнице, делайте это с осторожностью. Обязательно оценивайте, по силам ли им новые обязанности. Многие программисты, да и технари в целом, готовы всю жизнь довольствоваться интересной и творческой работой, даже не задумываясь о том, чтобы принять на себя руководящие функции. Учитесь определять максимальный доступный сотруднику уровень обязанностей. Возможно, программист, за которым вы наблюдаете, сможет в будущем достичь большего, но обычно для этого человек должен в течение определенного времени привыкать к выполняемому им уровню обязанностей. Как только вы поймете, что со своими нынешними функциями он справляется вполне успешно, можете поднять его еще на ступеньку вверх. Процесс продвижения сотрудников, как правило, носит итерационный характер – подобно определению коммерческих требований и макетированию. Прежде чем нагружать сотрудника более серьезными функциями, необходимо убедиться в том, что он справляется с текущими. Некоторые считают, что чем больше обязанностей выполняешь, тем больше денег получаешь. В некотором отношении это так. В то же время следует помнить, что жалование нужно увеличивать в ответ на повышение продуктивности и эффективности выполняемой работы, а не просто за расширение рамок проекта и распределение обязанностей между подчиненными.

Некоторые компании выстраивают четкую иерархию технических сотрудников, поднимаясь по которой любой квалифицированный специалист может получать зарплату, сопоставимую с окладами высшего руководящего звена. Если вы работаете в такой организации – что ж, здорово! Эта политика исключает стремление технических специалистов получить руководящие должности лишь для того, чтобы заработать больше денег. В таком случае не удивляйтесь, что некоторые специалисты будут получать больше, чем вы. В организациях, где такая система практикуется, высокие зарплаты выдаются в основном тем сотрудникам, которые помогли компании удержаться на плаву в трудные дни. Действительно ли подобных передовиков, работающих в вашей компании, стоит оценивать финансово выше, чем вас? Вполне может быть, что стоит, и вы должны ценить таких людей, радоваться, что они есть в вашем распоряжении. В своей книге, восхваляющей искусство кодирования, Пит Макбрин (Pete McBreen) поднимает вопрос о реальной финансовой оценке ведущих разработчиков:

«Возможно, они стоят значительно большего, чем получают в данный момент. Вероятно, они должны получать в пять или даже десять раз больше, чем среднестатистический разработчик… Чего на самом деле стоит человек, который «спас» проект? Для того чтобы ответить на этот вопрос, имеет смысл оценить последствия, которые могли бы наступить, если бы такой сотрудник перешел в другую компанию» [43] Pete McBreen, Software Craftsmanship (New York: Addison-Wesley, 2001), p. 61. .

Оценивайте своих сотрудников по достоинству. Платите им столько, сколько они заслуживают. Не нужно чрезмерно экономить, иначе вы можете их потерять. Скорее всего, вы слышали о классическом треугольнике «дешево – быстро – качественно» применительно к процессу разработки программных средств. Так вот, из этих трех качеств сочетаться могут только любые два. Если вы придерживаетесь практики привлечения низкооплачиваемых сотрудников, то результат получите соответствующий – дешевое (во всех смыслах) программное обеспечение. Если хотите получить качественный конечный продукт, имейте в виду, что за качество нужно платить.

Что?! Я только что получил эту работу и воспитывать себе смену не собираюсь! Этот ход мысли не отличается проницательностью. Никогда не забывайте о «факторе падающего кирпича». А вдруг вас приберет Бог или случится какое-то несчастье? Кто вас заменит (или сменит)? Как отдел продолжит работу? В некоторых ситуациях кому-то все равно придется исполнять ваши обязанности – для этого не обязательно попадать в беду. Выстраивая свой стратегический план, вы должны постоянно учитывать такие возможности и искать людей, способных время от времени подменять вас. Это помогает, с одной стороны, выявить сотрудников, заслуживающих более широкого круга обязанностей, с другой – определить набор высокоуровневых организационных задач, которые можно с уверенностью делегировать другим.

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