Как пасти котов. Наставление для программистов, руководящих другими программистами

В большинстве проектов Алекс проявлял себя исключительно творческим человеком. Он ухитрился организовать полноценный графический интерфейс пользователя на черно-белом жидкокристаллическом экране, на котором можно было вывести всего четыре строки по 80 символов в каждой. В общем, остальные сотрудники группы остались под впечатлением. В свободное время он смастерил для разрабатываемых продуктов внутрисхемный эмулятор, с помощью которого значительно сократил продолжительность отладки. Тем не менее с английским у Алекса так и не сложилось, и хотя Фрэнк помог ему получить вид на жительство, нового сотрудника, по большому счету, так и не приняли в свой круг его коллеги.

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

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

Что стало с Алексом, неизвестно. Обе компании, в которых ему довелось работать, потерпели значительные убытки, так как созданные им программные продукты так и не продвинулись дальше первой версии. Парадоксально то, что Алекс в этом не виноват. Все началось с ошибки Фрэнка, который предпочел «гениальные» программные монументы возможности работы в команде и потребности в практичном и допускающем сопровождение коде. Нанимая к себе в группу Алекса, Фрэнк поступил необдуманно – в тот момент он делал то, что нужно было ему самому, и этот поступок не имел никакого отношения к перспективам деятельности его компании. Поддерживая изоляцию Алекса от других сотрудников, Фрэнк привел подведомственную ему группу к расколу – и все из-за того, что, по его мнению, выдающиеся способности могут компенсировать нечеткие проектные решения. Делайте выводы. Нанимать умных людей недостаточно – их нужно нанимать с умом!

Как увольнять сотрудников

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

Если вы подумываете о том, чтобы уволить какого-то сотрудника, спланируйте свои действия заранее. Зафиксируйте в письменном виде те неверные действия, которые предпринял сотрудник, и те трудности, причиной которых он стал. Предложите ему один, последний, шанс исправиться. Некоторые специалисты утверждают, что одного шанса мало, но, по моему опыту, даже две таких возможности – это непозволительная роскошь. От вас как от человека, курирующего исправительный период, потребуется слишком много сил; остальным же сотрудникам, если им придется с ним работать, придется очень трудно. Тем не менее просчитайте возможные последствия увольнения для компании в целом. Попросите своего начальника оценить принятое вами решение. Какие проблемы, связанные с неразглашением конфиденциальных сведений, могут появиться у компании в связи с увольнением? Быть может, программист, от которого вы намерены избавиться, обладает обширными знаниями и просто не успел их проявить. На эти и другие связанные с увольнением вопросы вам придется ответить.

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

Денежное поощрение и продвижение сотрудников по службе

Вопросов денежного вознаграждения я касался в главе 1. Скорее всего, именно в этой области управления вы столкнетесь с наибольшими трудностями. Некоторые предпочитают награждать новыми должностями, но никому пока что не удавалось избежать практики денежного поощрения. Какую тактику избрать вам? Одно из возможных решений нашло в 1960-х годах руководство Bell Labs – все исследователи в этой лаборатории получали должность «научно-технического сотрудника», и более высоких почестей, нежели вхождение в эту закрытую группу, в компании просто не существовало. Такая схема работает лишь в том случае, если штат вашей организации набран исключительно из высококвалифицированных сотрудников. В сегодняшних условиях обращение к ней зачастую не оправдано – с одной стороны, из-за того, что должности в компании устанавливаете не вы, с другой – из-за стремления отдельных специалистов к звучным званиям. Есть такая закономерность: чем моложе сотрудник, тем большее рвение он проявляет в погоне за высокой должностью. У людей постарше другие приоритеты – им нужна интересная работа и хорошие деньги. Если сотрудник хочет всего вместе значит – он либо действительно этого заслуживает, либо несколько неадекватно оценивает свои способности. Поскольку интересную работу получают большинство программистов, вам придется довольствоваться вариантами вознаграждения должностями и деньгами, основываясь при принятии решений на достоинствах и опыте конкретного человека.

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

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

«Возможно, они стоят значительно большего, чем получают в данный момент. Вероятно, они должны получать в пять или даже десять раз больше, чем среднестатистический разработчик… Чего на самом деле стоит человек, который «спас» проект? Для того чтобы ответить на этот вопрос, имеет смысл оценить последствия, которые могли бы наступить, если бы такой сотрудник перешел в другую компанию» [43] .

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

43

Pete McBreen, Software Craftsmanship (New York: Addison-Wesley, 2001), p. 61.

Как готовить преемника

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