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

Делегирование

Объяснив подчиненным, какая задача перед ними стоит, заставьте их ее решить. Делегирование – это тоже искусство, а о том, почему оно является вашей главной обязанностью, я уже неоднократно говорил. Способность к делегированию – это одно из тех качеств, которое вы, лидер, должны постоянно совершенствовать. Косвенно этой темы я касался в главе 1. Сопоставив перечисленные в ней типы программистов с личностными качествами ваших сотрудников, вы сможете принять правильное решение относительно распределения задач между ними.

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

82

Среди изданий, перечисленных в библиографии, присутствует книга «Extreme Programming Explained» Кента Бека (Kent Beck).

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

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

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

Проверка

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

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

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

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

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

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

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

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

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

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

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

Участие

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

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