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

Как объединить усилия тех, кто гуляет сам по себе

Речь не о кошках, а о программистах. О том, что они блуждают в потемках, можно судить по характеру их кода, – он начинает походить на огромный памятник их гениальности. Практика регулярного критического обзора кода помогает сносить подобные монументы еще до того, как самовлюбленные хозяева их окончательно возведут. Более подробно мы побеседуем об этом явлении в главе 6, полностью посвященной техническому руководству. Пока что запомните один замечательный принцип: творчество бесценно, а вот практичный и удобный в сопровождении код можно не только оценить, но и продать. В ваши обязанности как руководителя входит координация деятельности программистов, направленная на достижение максимальной функциональности за счет минимального объема кода. Усложнение – это то, с чем вам предстоит вести постоянную борьбу. К понятности кода придется идти мелкими шажками – благо, скорее всего, вам предстоит бороться со смертными грехами программистов, такими как[39]39
  Это лишь немногие грехи. Существует множество альтернативных перечней. Добротный пример см. в издании William H. Brown et al, AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (New York: John Wiley & Sons, 1998).


[Закрыть]:

• недостаточное функциональное разделение при создании объектов и стыковке логических уровней;

• непродуманные интерфейсы объектов;

• чрезмерная взаимозависимость объектов;

• пристрастие к усложнению внутреннего устройства объектов.

В попытках исцелить молодых и неопытных программистов проявляйте такт. Упираются рогом? Ради бога – пусть некоторое время поучатся на собственных ошибках; при этом не забывайте регулярно показывать им правильное направление. Естественно, прежде чем допустить их код до компиляции, предложите свои коррективы. Мы, программисты (впрочем, как и все человеческие существа), имеем обыкновение совершать ошибки, лицезреть их последствия и только после этого искать лучшие пути достижения тех же целей – так мы учимся. При том условии, что допущенные ошибки будут исправлены до альфа-тестирования, в них нет ничего страшного.

В отличие от плодов творчества, которое бесценно, практичный и удобный в сопровождении код можно не только оценить, но и продать.

Опасность!

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

Если хотите снизить риск, связанный с попытками управлять кодом, который вы не понимаете, заведите себе помощника, разбирающегося в неподвластных вам языках. Проведение критических обзоров кода предполагает элементарное умение его, скажем так, читать. В своем классическом труде о том роде человеческой деятельности, который мы называем кодированием, Джеральд Вейнберг (Gerald Weinberg) пишет:

«Несколько лет назад, когда язык COBOL еще называли будущим программирования, очень активно обсуждался вопрос о том, умеют ли руководители читать программы. По прошествии времени кажется совершенно очевидным, что все эти разговоры были нацелены лишь на выбивание средств из руководителей, стремившихся свести свою зависимость от программистов к минимуму. На самом деле никто не верил, что руководители умеют читать программы. И с какой стати они должны это делать? Ведь даже программисты не читают программы!»[40]40
  Gerald M. Weinberg, The Psychology of Computer Programming: Silver Anniversary Edition (New York: Dorset House Publishing, 1998), p.5.


[Закрыть].

Естественно, дальше по тексту автор утверждает, что руководитель обязан уметь читать программы, и даже если не умеет, должен обязательно привлечь кого-то, кто с этой задачей справляется. В цитате упомянута зависимость от программистов – это та самая вещь, от которой вы всеми силами будете стараться избавиться. Найдите среди своих сотрудников кого-то, кто смог бы помочь вам свести к минимуму ущерб от недостатка знаний в тех или иных областях. Время от времени вам придется сталкиваться с устаревшими технологиями, поскольку для решения отдельных проблем они вполне адекватны. У руководителя есть еще одна цель: состоит она в том, чтобы разрушать новые (и даже старые) границы, открывая при этом новые пути в программировании, – те, по которым ранее никто не додумался пройти. Имейте в виду, что невежество очень опасно. Самое страшное – это когда человек упорствует в своем невежестве, выдавая его за принцип; такое поведение иначе как глупостью не назовешь.

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

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

Как сформировать команду и как ее поддерживать

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

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

• Заставьте кандидата выполнить тестовое задание. Поставьте перед потенциальным сотрудником задачу, которую он должен будет либо решить сразу, либо взять на дом и решить к установленному сроку.

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

• Если вам удастся убедить кандидата в том, что ему следует пройти сетевой тест оценки личности, зная, что возможности такого рода проверки весьма ограничены, значит – действуйте.[41]41
  Достойные тесты оценки личности есть на сайте http://www.advisorteam.com.


[Закрыть]

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

• Не ограничивайтесь одним интервью. Если возможно, попросите одного из ваших лучших и доверенных подчиненных провести с кандидатом еще одну беседу. В то же время не позволяйте потенциальному сотруднику общаться со всем персоналом – таким способом вы не добьетесь взвешенного решения.

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

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

Обычно консультанты не заинтересованы в том, чтобы передавать клиентам свои знания, – ведь это гарантия их дальнейшего пребывания на своей позиции. В таких случаях сотрудникам приходится проводить дизассемблирование кода, созданного консультантом, – это единственный способ разобраться в предложенном им решении. Подобная практика довольно распространена – в конце концов, многие из нас учатся на примере мастеров программирования, результаты работы которых можно встретить в книгах, существующих проектах, Интернете. Учиться нужно при любой возможности и на любом примере. Старайтесь только не пасть жертвой консультанта, оставившего вас, выражаясь словами Черчилля, лицом к лицу с загадкой, которая завернута в головоломку, а головоломка – в ребус.[42]42
  Это знаменитая фраза Черчилля – так он охарактеризовал Советский Союз перед началом Второй мировой войны. Если будущее вашего продукта зависит от результатов работы скрытного консультанта, будьте готовы к тому, что на его сопровождение уйдет много усилий.


[Закрыть]

Кошачьи разборки – блюз одинокого ферзя

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

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

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

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

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

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

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

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

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

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

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

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


[Закрыть].

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