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

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

Проверка

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

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

Перечислю некоторые методики проверки.

• Ежедневно наведывайтесь к своим подчиненным и интересуйтесь, как у них идут дела. Если личный контакт не представляется возможным, воспользуйтесь телефоном или, на крайний случай, электронной почтой.

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

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

• Проводя еженедельные совещания сотрудников (о них мы говорили в главе 5), не забывайте отслеживать состояние проекта и вырабатывать вместе с подчиненными новые идеи. Эта деятельность дополняет ежедневные визиты к сотрудникам и позволяет привлечь к решению проблем общего характера коллективный разум.

• Тех участников группы разработчиков, которым удалось быстро расправиться со своими задачами, следует привлекать к тестированию результатов труда остальных. Делать это нужно с осторожностью, допускать высказывания типа «тестирование – это не мое дело» нельзя. Программирование не ограничивается написанием кода, оно также предполагает обеспечение его реального функционирования.

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

Допускать высказывания типа «тестирование – это не мое дело» нельзя. Программирование не ограничивается написанием кода, оно также предполагает обеспечение его реального функционирования.

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

Участие

Несмотря на свое положение лидера, вам нередко придется участвовать в процессе кодирования. Если сочетать эту деятельность с делегированием и проверкой, ничего страшного не произойдет. Участие в «грязной работе» поможет вам утвердиться в роли лидера, хотя здесь нужно стараться воздерживаться от мелочной опеки. Разделяя обязанности по кодированию со своими подчиненными, вы не раз получите от них одобрение; впрочем, имейте в виду, что увлекаться кодированием для менеджера опасно. С учетом численности персонала отдела эта деятельность может стать необходимостью, однако за написание кода, с одной стороны, и организацию этого процесса, с другой, отвечают разные участки мозга. Переключаться с одного вида деятельности на другой довольно сложно. Для ведения административных дел далеко не всегда требуется такая же концентрация, как для программирования; таким образом, исполняя обязанности руководителя, можно позволить себе отвлечься на телефонный звонок или письмо, пришедшее по электронной почте. Что же касается кодирования, полагаю, мне не нужно вам объяснять, насколько губительными оказываются разного рода раздражители.

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

Как я уже говорил в разделе «Проверка», ваше участие в кодировании зачастую сводится к тестированию. Это жизненный пример участия лидера в процессе. Трудно найти компанию, в которой обязанности по интеграции и тестированию (до наступления этапа альфа-тестирования) мог бы взять на себя кто-то помимо лидера группы разработчиков. Готовьтесь к нетривиальным испытаниям ваших технических навыков и учитесь рационально использовать время. Справившись с этими трудностями, вы сможете укрепиться в положении лидера. Если вы будете активно участвовать в разработке, вам вряд ли хватит стандартных сорока часов в неделю. Правда, здесь вас подстерегают опасности – вспомните ощущения, которые, как я говорил в предыдущей главе, можно охарактеризовать одной фразой: «Мне уже все равно». Если человек доходит до такого состояния, то, наверное, менять что-либо уже поздно. Вы должны постоянно следить за уровнем своей загруженности – с тем, чтобы не выпасть из процесса в самый неподходящий момент. Как помните, разработка программных продуктов – это не спринт, а марафон; в этом контексте умение взять правильный темп есть необходимое условие стабильной работы всей команды. Чтобы выиграть марафон, нужно поддерживать взятый темп, прилагать усилия к тому, чтобы переставлять ноги, следить за рельефом и не забывать, как это здорово – пересечь финишную линию с достойным временем.

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