Некоторые компании выстраивают четкую иерархию технических сотрудников, поднимаясь по которой любой квалифицированный специалист может получать зарплату, сопоставимую с окладами высшего руководящего звена. Если вы работаете в такой организации – что ж, здорово! Эта политика исключает стремление технических специалистов получить руководящие должности лишь для того, чтобы заработать больше денег. В таком случае не удивляйтесь, что некоторые специалисты будут получать больше, чем вы. В организациях, где такая система практикуется, высокие зарплаты выдаются в основном тем сотрудникам, которые помогли компании удержаться на плаву в трудные дни. Действительно ли подобных передовиков, работающих в вашей компании, стоит оценивать финансово выше, чем вас? Вполне может быть, что стоит, и вы должны ценить таких людей, радоваться, что они есть в вашем распоряжении. В своей книге, восхваляющей искусство кодирования, Пит Макбрин (Pete McBreen) поднимает вопрос о реальной финансовой оценке ведущих разработчиков:
«Возможно, они стоят значительно большего, чем получают в данный момент. Вероятно, они должны получать в пять или даже десять раз больше, чем среднестатистический разработчик… Чего на самом деле стоит человек, который «спас» проект? Для того чтобы ответить на этот вопрос, имеет смысл оценить последствия, которые могли бы наступить, если бы такой сотрудник перешел в другую компанию»[43].
Оценивайте своих сотрудников по достоинству. Платите им столько, сколько они заслуживают. Не нужно чрезмерно экономить, иначе вы можете их потерять. Скорее всего, вы слышали о классическом треугольнике «дешево – быстро – качественно» применительно к процессу разработки программных средств. Так вот, из этих трех качеств сочетаться могут только любые два. Если вы придерживаетесь практики привлечения низкооплачиваемых сотрудников, то результат получите соответствующий – дешевое (во всех смыслах) программное обеспечение. Если хотите получить качественный конечный продукт, имейте в виду, что за качество нужно платить.
Как готовить преемника
Что?! Я только что получил эту работу и воспитывать себе смену не собираюсь! Этот ход мысли не отличается проницательностью. Никогда не забывайте о «факторе падающего кирпича». А вдруг вас приберет Бог или случится какое-то несчастье? Кто вас заменит (или сменит)? Как отдел продолжит работу? В некоторых ситуациях кому-то все равно придется исполнять ваши обязанности – для этого не обязательно попадать в беду. Выстраивая свой стратегический план, вы должны постоянно учитывать такие возможности и искать людей, способных время от времени подменять вас. Это помогает, с одной стороны, выявить сотрудников, заслуживающих более широкого круга обязанностей, с другой – определить набор высокоуровневых организационных задач, которые можно с уверенностью делегировать другим.
С поиском преемника тесно связана проблема углубления познаний сотрудников и формирования своеобразной «скамейки запасных». Если каждый из ваших программистов специализируется на определенном проекте, в случае его отсутствия на рабочем месте вас ожидают серьезные неприятности.
В подготовке спортсменов широко применяется методика обучения смежным видам; так почему бы не опробовать ее на программистах? Согласно распространенному мнению, зрелость в профессии программиста наступает тогда, когда он овладевает вторым языком. Таким образом, нужно стремиться к повышению компетенции персонала, с тем чтобы, переходя от одного проекта к другому, специалисты не теряли темп работы и концентрацию. С вашей стороны для достижения этой цели потребуется серьезное планирование, но, по большому счету, проблема эта не нова – думать о том, как распределить задачи между программистами, руководитель должен постоянно. Некоторые легко переходят от задачи к задаче, у других такой мобильности не получается. Изучайте сильные и слабые стороны своих подчиненных и пользуйтесь этими знаниями в интересах общего дела.
Ну хватит уже!