Фундаментальные принципы лидерства
Начну с вопроса, который, по-моему, ничем не хуже дилеммы курицы и яйца: кто появился раньше – лидер или его последователи? Не знаете? То-то – это вопрос с подвохом (это я так подготавливаю вас к более глубокому анализу фундаментальных принципов). Я думаю так: чтобы лидера можно было назвать лидером, ему нужны последователи; в то же время хороший лидер сам формирует для себя группу последователей. Процесс подготовки последователей прекрасно иллюстрируют пять основных принципов, которые, как мне кажется, определяют суть характера любого лидера. На рис. 8.1 эти принципы приводятся в двух вариантах группировки. Первый вариант иллюстрирует очередность применения принципов, второй – их цикличность.
Рис. 8.1. Основные принципы лидерства
Каждый из принципов важен как по своей сути, так и с точки зрения взаимодействия с остальными. Упомянутые принципы лидерства вы должны усвоить полностью – ведь они подобны фундаменту здания, который по определению должен быть его самым надежным элементом.
Понимание
Прежде чем приступать к обязанностям лидера, вы должны четко уяснить, в каком направлении поведете своих подчиненных. Для того чтобы забраться на вершину Эвереста, одной лишь карты недостаточно. Для этого нужно изучить действия тех, кому удалось это сделать до вас и кто после этого умудрился вернуться живым. Вы должны знать условия восхождения, связанные с ним риски, препятствия, встречающиеся на пути, правила применения соответствующего оборудования, цель путешествия. Правда, нередко энтузиасты совершают восхождение на гору только лишь «потому, что она есть». Полагаю, впрочем, что на самом деле цель заключается в другом – люди стремятся покорить то, что считают могущественнее себя; аналогичным образом для создания конкурентных преимуществ и завоевания доли рынка коммерческие предприятия производят товары и услуги. Быть может, такая аналогия слишком груба, но рынок, по моему мнению, представляет собой арену жесткой конкуренции и битв не на жизнь, а на смерть; и наша конечная цель как разработчиков программных средств заключается в том, чтобы выпустить продукт (или услугу), который может помочь нашей компании выиграть несколько таких битв. Битвы на рынке способны выигрывать только лидеры, понимающие характер, методы и цели военных действий в области программного обеспечения.
Битвы на рынке способны выигрывать только лидеры, понимающие характер, методы и цели военных действий в области программного обеспечения.
Вы должны полностью уяснить для себя цели компании – лишь в этом случае вы сможете донести их до своих подчиненных. Естественно, процесс изучения начинается с перспективного представления, хотя им одним задача не исчерпывается – специалистам в области разработки программных средств приходится копать довольно глубоко. Одно из обязательных качеств лидера – умение отличать лес от деревьев. Мы, программисты, нередко блуждаем среди деревьев, не понимая топологии леса. Лидер программистов не может себе позволить заблудиться – слишком серьезными могут быть последствия и для подчиненных, и для продукта.
Пока вы не обдумаете, не взвесите и не обоснуете каждое коммерческое требование, добравшись, наконец, до «эврики»[80], на комплексное понимание проблемы не рассчитывайте. Наивно надеяться на то, что сотрудники, прочитав спецификацию продукта, все сразу поймут и создадут реализацию именно такой, как требуется. Только выстроив для себя подробный план реализации от начала до конца, вы сможете руководить процессом и отслеживать его. Здесь опять же необходимы время и настойчивость. Первого никогда не бывает в достатке (за это я ручаюсь!), а второе условие напрямую зависит от того, насколько серьезно вы относитесь к своим лидерским обязанностям. Что касается времени, то у всех нас его поровну – просто некоторые им пользуются рациональнее, чем другие. Относительно того, как опасно пренебрегать личной ответственностью за деятельность подчиненных и судьбу продукта, лучшие рекомендации дает опыт.
Требования кто-то формулирует – значит, очевидно, они поддаются пониманию. Это своеобразная трактовка известного высказывания о том, что если есть воля, значит, есть и выход – правда, «волю» здесь следует понимать как исследование вопроса вплоть до его полного понимания. План анализа проблемы можно изложить следующим образом.
1. Прочтите требования дважды: один раз, чтобы понять широту замысла, второй – чтобы постичь его глубину.
2. Сопоставьте требования с известными методиками реализации и выявите те части функциональности, для реализации которых потребуются новые разработки.
3. Набросайте предварительный план макетирования проектов – он поможет выявить среди требуемых свойств неизвестные.
4. Составьте на основе документации с требованиями контрольный список, который, в свою очередь, послужит исходной точкой для формулирования задач. Так вы сможете привязать каждое требование к набору задач и тем самым гарантировать реализацию свойства.
Понимание рождает решения. Соответственно переходим к следующей роли лидера – передаче знаний коллегам.
Передача знаний
Слово «благовещение» я первый раз услышал в церкви еще ребенком. В религиозном контексте оно употребляется в совершенно четком смысле и обозначает распространение хорошей новости. Много позже я услышал этот термин в светской интерпретации от Microsoft – словосочетание «благовестник продукта»[81]показалось мне чрезвычайно точной характеристикой для восторженного молоденького преподавателя, к которому я ходил на курсы программирования. Способность передавать знания есть второй необходимый признак лидера. Иногда говорят: «тот, кто умеет, делает; тот, кто не умеет, преподает». Это изречение я считаю неверным и предлагаю встречную мысль: у того, кто не может адекватно изложить свои мысли, их слишком мало. Полагаю, что именно эта проблема обусловливает плохую передачу информации в бизнесе: недостаточное понимание проблемы порождает комплекс, в результате чего субъект, который, по смыслу, должен эту проблему доходчиво изложить, начинает надеяться на то, что окружающие смогут интуитивно разобраться в ней и уяснить свои задачи. Наитие выходит на первый план, если документацию с бизнес-требованиями по ночам не читать, а использовать по естественному назначению – в качестве подушки; впрочем, и наитие никогда не сможет заменить четкое изложение мысли.
Цель передачи знаний – обеспечить понимание персоналом предъявленных к продукту требований на том же уровне, на котором их понимает лидер. Итак, каким образом вам самому удалось понять проблему в комплексе? Восстановите последовательность действий, направленных на изучение требований, и перенесите ее на процесс обучения сотрудников. Тот, кто способен четко доносить свои знания до окружающих, сможет преуспеть в педагогике. Да, действительно, даже самый лучший учитель не может обойтись без заинтересованных учеников, но как лидер программистов вы располагаете в этом отношении существенным преимуществом – ваши «студенты» работают под вашим же началом, и никуда им от вас не деться. Может быть, они не всегда вас слушают, но ведь вы – шеф и поэтому располагаете методами принуждения к обучению. Поощрение, несомненно, выигрывает в сравнении с принуждением, но бывают ситуации, когда выбирать не приходится. Вернемся к основной мысли: если передача знаний равнозначна педагогической деятельности, то как лучше составить «план урока»? Элементы, приведенные в табл. 8.1, являются минимально необходимыми для адекватной передачи знаний.
Тот, кто способен четко доносить свои знания до окружающих, сможет преуспеть в педагогике.
Таблица 8.1. Необходимые элементы эффективной передачи знаний
Многие лидеры излишне увлекаются стилем – в основном по той простой причине, что у них не все в порядке с содержанием. Основное внимание нужно все-таки уделять содержанию, ну а тонкости изложения можно будет наработать с опытом. Перечисленные в табл. 8.1 элементы передачи знаний следует задействовать как при устном, так и при письменном общении.
Необходимо различать запланированный процесс передачи знаний и случайные разговоры на ту или иную тему. Поскольку вы – лидер, ваши замечания, пусть даже высказанные по случаю, зачастую воспринимаются сотрудниками как официальные распоряжения. Большую часть жизни мы доносим до окружающих информацию интуитивно, не пользуясь заготовками и отталкиваясь исключительно от текущего контекста. Различия между бессистемным и формальным мышлением следует обязательно иметь в виду; бывают ситуации, когда случайно высказанная мысль приводит к непредусмотренным разрушительным последствиям для бизнеса. Способность контролировать поле боя общения помогает выиграть битву понимания.
Способность контролировать поле боя общения помогает выиграть битву понимания.
Как лучше всего донести до программиста суть требований? Показать ему частично функционирующий макет. Даже одни пользовательские интерфейсы способны помочь программисту составить представление о задаче. Впрочем, не стоит сбрасывать со счетов архитектуру. Как я говорил в главе 6, прежде чем собирать урожай программных объектов, необходимо разбить сад, в котором вы намерены их выращивать.
Испытанный способ улучшить передачу знаний – обратиться к помощи UML, PowerPoint или Visio. Возможно, в вашей организации применяется оригинальный процесс документирования требований и составления проектных документов. Если это так, придерживайтесь его, а при необходимости адаптируйте к конкретному проекту. Впрочем, имейте в виду, что строить разработку программных средств исключительно на основе документов не стоит. Нередко такие важные элементы процесса передачи знаний, как макетирование и критический обзор предварительных аспектов реализации, просто-напросто игнорируются. Полагаю, что, став руководителем и лидером, вы начали испытывать ностальгию по кодированию. Если так, то, обратив внимание на два упомянутых элемента, вы сможете освежить навыки программирования и одновременно решить свою непосредственную задачу. Утверждения о «самодокументированности кода» слышны повсюду, но на самом деле они редко соответствуют действительности. Конструирование макетов как средств передачи знаний приносит пользу в двух отношениях: во-первых, удовлетворяет привычку к кодированию, во-вторых, помогает донести до окружающих ваше понимание решения поставленной задачи.
Делегирование
Объяснив подчиненным, какая задача перед ними стоит, заставьте их ее решить. Делегирование – это тоже искусство, а о том, почему оно является вашей главной обязанностью, я уже неоднократно говорил. Способность к делегированию – это одно из тех качеств, которое вы, лидер, должны постоянно совершенствовать. Косвенно этой темы я касался в главе 1. Сопоставив перечисленные в ней типы программистов с личностными качествами ваших сотрудников, вы сможете принять правильное решение относительно распределения задач между ними.
В идеале проект нужно разбить на рабочие единицы, которые впоследствии можно будет распределить между всеми разработчиками. Впрочем, на практике этот подход не всегда себя оправдывает. Может статься, что для решения отдельных задач по проекту или даже для комплексной его реализации лучше всего подходит ограниченная группа сотрудников. Иногда, в тех ситуациях, когда две головы лучше, чем одна, программистов имеет смысл разбивать по парам. Этот прием описан в методике разработки программных средств под названием экстремального программирования[82]. В рамках этой методики также культивируется другой тип делегирования – он предусматривает создание команды из двух программистов, в которой один пишет код, а другой ежедневно тестирует его и проводит критические обзоры. Если подобрать подходящих кандидатов (лучше всего – опытного программиста и новичка), эта схема делегирования оказывается очень эффективной – сам видел. Однако если подобрать партнеров неверно, присущая программистам независимость сведет эффективность этой замечательной идеи нулю. Помимо прочих навыков делегирования, вы должны понимать, какие из ваших сотрудников могут работать вместе, а какие – нет.
Не забывайте и о хрестоматийном правиле, согласно которому введение в проект новых сотрудников на завершающих стадиях разработки только оттягивает срок его сдачи. Делегировать можно задачи, но не темпы их решения. Если вы обнаруживаете, что разбить проект на отдельные задания трудно, значит, возможно, проблема кроется в проектном решении. Вероятно, плану конструирования недостает модульности. Иногда в самом начале работы над проектом кажется, что никаких проблем с делегированием не возникнет. Впоследствии, однако, выясняется, что одни группы уже решили поставленные перед ними задачи, а другие запаздывают. Подобные ситуации возникают из-за неверного представления о продолжительности выполнения тех или иных заданий. Эта проблема опять же связана с проектированием. Качественное проектное решение (при наличии достойной архитектуры) обеспечивает удобство делегирования по модулям.
Не забывайте и о хрестоматийном правиле, согласно которому введение в проект новых сотрудников на завершающих стадиях разработки только оттягивает срок его сдачи. Делегировать можно задачи, но не темпы их решения.
Нужно уметь корректировать план делегирования на ходу. К необходимости его корректировки нужно быть готовым с самого начала – она не должна стать для вас сюрпризом. В ходе выполнения проекта от начальных стадий к завершающим у лидера нередко появляется ощущение стрельбы по движущейся мишени – вот почему для него так важен опыт. Если бы лидеры разработки программных продуктов могли тренироваться в стрельбе по движущимся мишеням на стрельбище, было бы просто здорово. К сожалению, практиковаться нам приходится в реальных условиях – иначе вряд ли мы срывали бы сроки. Чем больше вы будете тренироваться, тем совершеннее станут ваши навыки. Делегирование – это лучший помощник в деле стрельбы по мишеням. Стоит вам попытаться сбить их все самостоятельно (то есть поддаться соблазну мелочной опеки), патроны кончатся раньше времени.
Проверка
В этом контексте на авансцену выходит знакомый принцип «ожидай, но проверяй». Естественная задача, возникающая после делегирования, заключается в контроле за ходом выполнения заданий. Это не мелочная опека – это именно проверка. Лучший способ приблизить перспективу завершения проекта в срок – проводить регулярные сборки компонентов вплоть до полной готовности кода. Такие действия, помимо прочего, помогают избежать попадания в проектный тупик. Слишком много времени теряется, если на подходе к завершению цикла разработки приходится начинать все сначала – по той лишь причине, что проектное решение себя не оправдало. Одним из элементов вашей повседневной деятельности должна стать ежедневная проверка результатов работы сотрудников; при приближении сроков сдачи такие проверки нужно проводить еще чаще.
Эффективный мониторинг подобен непрекращающемуся критическому обзору кода – он также предполагает контроль за соответствием проектному решению и стандартам кодирования. Чем дольше вы будете затягивать проведение обзора, тем больше задач вам придется решать, – а если откладывать процесс слишком долго, у вас просто не останется времени на то, чтобы разобраться в запутанном коде.
Перечислю некоторые методики проверки.
• Ежедневно наведывайтесь к своим подчиненным и интересуйтесь, как у них идут дела. Если личный контакт не представляется возможным, воспользуйтесь телефоном или, на крайний случай, электронной почтой.
• С регулярностью в несколько дней тестируйте готовые модули кода. Эта деятельность роднит вас с тестерами, но вы должны воспринимать ее как свою первоочередную обязанность.
• Регулярно пробуйте интегрировать компоненты в целостную систему и проверяйте архитектуру на стройность. Здесь придется «поиграть» с кодом. Так вы сможете выявлять ошибки, допущенные при конструировании, и держаться в курсе методов, которыми ваши программисты решают поставленные перед ними задачи.
• Проводя еженедельные совещания сотрудников (о них мы говорили в главе 5), не забывайте отслеживать состояние проекта и вырабатывать вместе с подчиненными новые идеи. Эта деятельность дополняет ежедневные визиты к сотрудникам и позволяет привлечь к решению проблем общего характера коллективный разум.
• Тех участников группы разработчиков, которым удалось быстро расправиться со своими задачами, следует привлекать к тестированию результатов труда остальных. Делать это нужно с осторожностью, допускать высказывания типа «тестирование – это не мое дело» нельзя. Программирование не ограничивается написанием кода, оно также предполагает обеспечение его реального функционирования.
• Требуйте от программистов документировать все новые модули кода и составляйте из этих отчетов сопроводительную документацию для отдела тестирования. Тем самым вы дадите возможность себе и своим подчиненным оценивать ход процесса и соответствие заданным требованиям.
Допускать высказывания типа «тестирование – это не мое дело» нельзя. Программирование не ограничивается написанием кода, оно также предполагает обеспечение его реального функционирования.
Вышеупомянутые методики (впрочем, их список можно расширять) помогают превратить процесс мониторинга в продуктивную и конструктивную деятельность, не ограничивающуюся оголтелой критикой. Если лидер не будет проверять своих подчиненных, кто-нибудь из них может выпасть из общего темпа разработки, вследствие чего продукт не будет сдан вовремя. Достичь сопоставимых успехов в разработке должны все участники группы – в противном случае толку от такой деятельности будет очень мало.
Участие
Несмотря на свое положение лидера, вам нередко придется участвовать в процессе кодирования. Если сочетать эту деятельность с делегированием и проверкой, ничего страшного не произойдет. Участие в «грязной работе» поможет вам утвердиться в роли лидера, хотя здесь нужно стараться воздерживаться от мелочной опеки. Разделяя обязанности по кодированию со своими подчиненными, вы не раз получите от них одобрение; впрочем, имейте в виду, что увлекаться кодированием для менеджера опасно. С учетом численности персонала отдела эта деятельность может стать необходимостью, однако за написание кода, с одной стороны, и организацию этого процесса, с другой, отвечают разные участки мозга. Переключаться с одного вида деятельности на другой довольно сложно. Для ведения административных дел далеко не всегда требуется такая же концентрация, как для программирования; таким образом, исполняя обязанности руководителя, можно позволить себе отвлечься на телефонный звонок или письмо, пришедшее по электронной почте. Что же касается кодирования, полагаю, мне не нужно вам объяснять, насколько губительными оказываются разного рода раздражители.
Если бы у нас вместо мозгов были микропроцессоры, в которых при «прерывании» предусматривается сохранение состояния системы, параллельное исполнение многочисленных заданий не составляло бы для нас такой проблемы. Мы можем сколь угодно хвастаться способностью делать несколько дел одновременно, однако, как правило, качество исполнения каждого из них оставляет желать лучшего. В нашей работе необходима концентрация – любой специалист в области разработки программных средств должен стремиться в каждый конкретный момент заниматься чем-то одним.
Как я уже говорил в разделе «Проверка», ваше участие в кодировании зачастую сводится к тестированию. Это жизненный пример участия лидера в процессе. Трудно найти компанию, в которой обязанности по интеграции и тестированию (до наступления этапа альфа-тестирования) мог бы взять на себя кто-то помимо лидера группы разработчиков. Готовьтесь к нетривиальным испытаниям ваших технических навыков и учитесь рационально использовать время. Справившись с этими трудностями, вы сможете укрепиться в положении лидера. Если вы будете активно участвовать в разработке, вам вряд ли хватит стандартных сорока часов в неделю. Правда, здесь вас подстерегают опасности – вспомните ощущения, которые, как я говорил в предыдущей главе, можно охарактеризовать одной фразой: «Мне уже все равно». Если человек доходит до такого состояния, то, наверное, менять что-либо уже поздно. Вы должны постоянно следить за уровнем своей загруженности – с тем, чтобы не выпасть из процесса в самый неподходящий момент. Как помните, разработка программных продуктов – это не спринт, а марафон; в этом контексте умение взять правильный темп есть необходимое условие стабильной работы всей команды. Чтобы выиграть марафон, нужно поддерживать взятый темп, прилагать усилия к тому, чтобы переставлять ноги, следить за рельефом и не забывать, как это здорово – пересечь финишную линию с достойным временем.
В школе и колледже я занимался бегом по пересеченной местности. Через несколько лет, за которые я успел жениться, отслужить в армии, завести детей и устремиться к достижению американской мечты, тренировки ушли на второй план. Много позже, пропустив несколько десятилетий, я начал тренироваться заново и попытался войти в форму. Конечно, сейчас я уже не могу пробежать пять миль за тридцать минут. Пару лет назад у меня это получалось за сорок минут, но, надо сказать, не так легко, как в молодости. Каждый раз, когда я пытаюсь побить собственный рекорд, мне приходится постоянно поддерживать концентрацию. Я обнаружил, что если во время пробежки вслух произносить «сконцентрируйся!», становится легче. Этот режим я стараюсь переносить в свою профессиональную деятельность. Участие – это способность пробежать всю дистанцию, ни разу не теряя внимания. Иногда, поскольку вы лидер, придется исполнять роль тренера, стоящего у трассы, но не стоит забывать – лучшие лидеры сами умеют бегать.
Иногда, поскольку вы лидер, придется исполнять роль тренера, стоящего у трассы, но не стоит забывать – лучшие лидеры сами умеют бегать.
В общем, участие предполагает переживание трудностей и побед вместе с подчиненными. Для этого нужно быть всегда готовым помочь окружающим, уметь прогнозировать возникновение проблем и решать их прежде, чем они окажут воздействие на сотрудников. Другой гранью участия является проявление здорового интереса к личной жизни подчиненных. Не нужно ни к кому навязываться в друзья – просто проявите понимаете того факта, что исполнением рабочих функций их жизнь не ограничивается.
Возвращусь ненадолго к примеру с моими юношескими беговыми упражнениями. Однажды, помнится, наш тренер сказал нам, потным и запыхавшимся, примерно следующее: «Придет время, ребята, и вы будете рассказывать своим детям, как быстро когда-то бегали!» Тогда я не понял, к чему это он сказал. Тридцать восемь лет спустя я уверен: он имел в виду, что участие в команде придает дополнительный смысл индивидуальным стараниям. Вы должны учитывать это обстоятельство в процессе взаимодействия со своими подчиненными – не пренебрегая тренерскими обязанностями, как можно активнее участвуйте в их деятельности.
Надстройка
Разобравшись с фундаментальными принципами, пора переходить к более очевидным вещам. Речь идет о некоторых наиболее значимых видах деятельности, которые естественным образом вытекают из вашего лидерского положения. Если вам они не покажутся столь очевидными, значит, необходимо проверить, насколько полно реализованы основные принципы лидерства. В процессе формирования команды лидер испытывает немало приятных минут – вы же не хотите их упустить, не правда ли? Ей-богу, головной боли в ходе руководства процессом разработки и так хватает. Так не будем пренебрегать возможностью разбавить ее более приятными ощущениями!
Наставничество
Обучая других обучать, мы приумножаем свои усилия и повышаем эффективность. Пусть это будет рабочим определением наставничества. Наставничество помогает решить множество различных задач, и чем больше внимания вы ему уделяете, тем серьезнее отдача. Вы уяснили смысл этого хитрого выражения: «обучать других обучать»? Наставничество – это больше, чем преподавание, поскольку оно предполагает передачу педагогических навыков. Как сказал мне мой отец, в колледже я должен прежде всего научиться находить источники нужной мне информации и правильно с ними обращаться. Он был прав. Наставничество подразумевает обучение самообразованию при одновременной передаче знаний.
Обучая других обучать, мы приумножаем свои усилия и повышаем эффективность.
В академической науке педагогике основную роль играют проблемы эвристики. Как наставник вы должны поощрять стремление своих сотрудников к получению дополнительных знаний и экспериментированию, совершенствуя тем самым способности своих подчиненных к самостоятельному решению задач. Последнее качество в контексте разработки программного обеспечения совершенно необходимо. Охотно верю, что, изучая в школе математику, вы ненавидели слово «задача», но ведь, по существу, вся наша жизнь – эта одна большая задача. Вы должны преобразовать требование в работающий программный продукт, а для этого необходимо установить соответствие между данными в области требований и машинной реализацией, воплотив в нее свой богатый опыт пользователя.
Цель наставничества – воспитать лидеров не хуже самого наставника, а может быть, даже лучше него. Чем больше ответственности за процесс разработки вы сможете привить своим подчиненным, тем серьезней будет та помощь, на которую вы сможете рассчитывать при приближении сроков сдачи. Если это возможно, выделите на наставническую деятельность один из дней рабочей недели. Придерживаться такого графика иногда будет сложно; однако ориентируясь на обучение сотрудников, вы помогаете не только им, но и себе. Подготовка к наставнической деятельности укрепляет ваши собственные знания, формирует более ясное представление о рабочих обязанностях, помогает уточнять задания, которые вы намереваетесь распределить между персоналом.
Характерным примером наставничества может стать построение в реальном времени макета, иллюстрирующего тот или иной метод конструирования программных средств. Быть может, имеет смысл на несколько часов присоединиться к сотруднику, которому попалось особо трудное задание. Это отнюдь не мелочная опека – скорее удачный пример сотрудничества. Наставничество – это сочетание участия и понимания (двух фундаментальных принципов лидерства), направленное на повышение квалификации сотрудников.
Наставник – это не обязательно «старый хрыч». Возраст в данном случае не имеет значения; куда важнее готовность делиться знаниями. Для того чтобы группа смогла добиться выдающихся успехов в разработке программных продуктов, ее сотрудники должны друг другу помогать. Инициатором таких отношений должны выступить вы, главный наставник; надо надеяться, на вашем примере этому научатся остальные.
В зависимости от ситуации вы должны демонстрировать владение двумя видами наставничества: целевым и комплексным. Целевое наставничество (targeted mentoring) предполагает оказание сотрудникам вполне конкретной помощи, например в написании процедуры вызова интерфейса прикладного программирования или подпрограммы сортировки – в зависимости от потребности. Такого рода наставничество востребовано всегда. Для комплексного наставничества (complete mentoring) нужно нечто большее. Оно требует установления с сотрудниками тесных отношений, построенных на искренности и взаимопонимании (в то же время необходимо отдавать себе отчет, что не со всеми сотрудниками это возможно). Выберите из числа подчиненных самых многообещающих – тех, кого вы хотели бы видеть своими последователями, – и уделите их воспитанию максимум внимания. Делясь своими знаниями, старайтесь укреплять отношения с избранниками. Взять хотя бы художника – он может научить студентов, как работать над эскизами, выстраивать тень и перспективу. Уроки художника посещают многие студенты, и, конечно, они перенимают у него часть знаний. Но лишь немногие, лучшие ученики сознательно подготавливаются художником для того, чтобы впоследствии занять его место. Я говорю о роли ученика, подмастерья, адепта. Если вы незаменимы, вас никогда не заменят. Учитывая планы карьерного роста, ничего хорошего в такой незаменимости нет.
Вознаграждение
Выдающиеся успехи нужно поощрять. Вы как лидер должны принимать решения о том, когда и в каком виде выдавать призы. Выбор широк: от повышения заработной платы до похода с отличившимся сотрудником в хороший ресторан или на какое-нибудь спортивное зрелище. Награда должна соответствовать достижениям и основываться исключительно на заслугах. За то чтобы сотрудники выкладывались на все сто, им платят: дополнительные поощрения должны распространяться лишь на тех, кто, превысив ожидания, прыгнул выше головы.
Принципы вознаграждения сотрудников обычно регулируются корпоративной политикой, что, однако, не исключает творческого подхода к этой задаче. Можно, например, провести в период бета-тестирования конкурс, в котором сотрудники будут соревноваться в количестве устраненных ошибок; победителю в таком соревновании, естественно, полагается денежный приз. Оценивать результаты вы должны исходя из характера ошибок и информации о лицах, их допустивших. Ниже я привожу пример схемы подобного рода оценки.
1. Количество исправленных ошибок.
2. Сложность каждой ошибки.
3. Время, потраченное на исправление каждой ошибки.
4. Успешность предложенного решения (зависит от результатов повторного тестирования).
5. Усилия по взаимодействию с другими сотрудниками, направленному на поиск решения (в случае, если такое взаимодействие необходимо).
6. Степень компетенции в области, к которой относится исправляемая ошибка.
7. Ваши собственные усилия по содействию сотрудникам, которые испытывают затруднения при исправлении ошибки.
8. Дополнительные усилия, выходящие за рамки рабочей необходимости.
9. Своевременность решения задач, не относящихся к текущему выпуску продукта.
10. Желание приобретать дополнительные сведения о продукте, преодолевая при этом трудности понимания и усваивая особо сложные моменты.
11. Настойчивость в решении задач, кажущихся невыполнимыми.
Естественно, отслеживать все эти моменты для каждой ошибки и каждого члена группы довольно сложно, однако рассматриваемый метод мониторинга – одного из фундаментальных принципов лидерства – конструктивен, а кроме того, придает деятельности по организации процесса развлекательный характер. Стоит также обратить внимание на то, как в вышеприведенном списке находит свое отражение концепция наставничества. Обычно, будучи лидером, вы стремитесь не допускать между разработчиками соперничества, способного усложнить достижение результата группой в целом. Именно поэтому при распределении вознаграждений так важно вести подсчет достигнутых сотрудниками успехов. Если бы я лучше разбирался в спорте, то, наверное, не удержался бы от какой-нибудь аналогии, например с количеством подстраховок (кажется, есть что-то такое в бейсболе или в баскетболе? или в обоих видах? не знаю).
Вне зависимости от того, какой метод поощрения сотрудников вы выберете, будьте справедливыми и не опаздывайте с вознаграждением. Когда какого-то богатого человека спросили о том, сколько денег ему нужно для счастья, он ответил: «Всегда немножко больше». Не забывайте, что вознаграждать нужно только тех, кто показал исключительные достижения, превысив все ожидания.
Не забывайте, что вознаграждать нужно только тех, кто показал исключительные достижения, превысив все ожидания.
Исправления
Необходимым условием профессионального роста любого программиста должна быть перепроверка результатов его деятельности. Исправляя ошибки, вы не должны действовать как университетский профессор и ставить жирный крест поверх неправильно решенной задачи. Настоящий лидер программистов старается сделать так, чтобы его подчиненные сами находили свои ошибки и учились на них. Конечно, при этом он должен советовать наиболее разумные способы решения проблем. Это очень тонкая задача, к решению которой лидер должен подходить со всей осторожностью, не впадая при этом в занудство. Недопустимо закрывать глаза на неаккуратный код и нерациональные действия сотрудников.
В главе 6, посвященной техническому лидерству, мы обсуждали метод критического обзора кода, а также последствия пренебрежения этой крайне важной обязанностью лидера. Вообще говоря, ваши корректирующие усилия должны быть в основном направлены на обеспечение максимальной отдачи всех сотрудников. Если кто-то работает одной левой, попытайтесь понять, почему. Не думаю, что ваш отдел так богат, что в нем можно держать сотрудника, который ограничивается исполнением своих минимальных обязанностей. Как я говорил в главе 3, иногда проблемы с сотрудниками решаются только путем увольнения. Если же проблема решаема, то доводить ее до необходимости увольнения неразумно. Значительно лучше попытаться регулярно оказывать сотруднику помощь, которая может привести к его реабилитации.
Пытаясь помочь программисту исправить ошибки или обрести мотивацию к активной деятельности, не забывайте, что процесс этот двунаправленный. Если вы не проверяете собственные ошибки, вряд ли к вашей правке будут относиться серьезно. Быть может, в человеческих отношениях действительно слишком много лицемерия, но лидеру программистов это качество противопоказано. В главе 2, говоря о борьбе с собственными слабостями, я упоминал о том, какое сильное влияние на сотрудников способен оказывать ваш стиль кодирования, – вопрос в том, какой характер носит это влияние: положительный или отрицательный? Ваши подчиненные прекрасно видят, насколько увлеченно вы относитесь к своим обязанностям, – укоряя кого-нибудь за недостаточное усердие, имейте это в виду.
Быть может, в человеческих отношениях действительно слишком много лицемерия, но лидеру программистов это качество противопоказано.
Предвидение
Способность предугадывать будущее развитие событий привлекает к вам последователей. Некоторые даже считают, что это – основное качество лидера. И действительно, оно играет очень важную роль – даже если ваших способностей провидца не хватает для создания очередной убойной программы. И самые скромные прогнозы чрезвычайно вдохновляют сотрудников. Представление о том, как сократить усилия по сопровождению в очередной версии флагмана вашей компании, может сыграть для нее не меньшую роль, чем изобретение Интернета.
Можно ли сформулировать метод предвидения? Быть может, настоящий провидец действительно общается с музами и сообщает людям услышанное? Наверное, при создании образцов высокой литературы и музыки без муз не обошлось, но вообще во всех творческих начинаниях очень важно мыслить нестандартно. Когда во время Второй мировой войны Алан Тьюринг (Alan Turing), работая на британскую разведку, расшифровывал немецкие сообщения, он попутно сформулировал новый способ осмысления вычислительных методов. В краткой биографии Тьюринга имеется следующий фрагмент:
«Тьюринг изначально представлял себе, что его машина должна будет выполнять те же функции, что и человеческий мозг. [Тьюринг] предлож<