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