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

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

Координация информационных потоков – это тот род деятельности руководителя, который требует отдельного рассмотрения. Как вы, я надеюсь, помните, согласно методике объектно-ориентированного (ОО) анализа и проектирования, для формулирования проектного решения и разрешения проблем, связанных с конструированием программного продукта, вы должны иметь в виду три перспективы. Если хотите освежить память, взгляните на табл. 3.1.

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

Предлагаемый мною административный фильтр в первую очередь призван помочь вам сориентироваться в информационной мгле[31], которая нас ежедневно окружает. Мгла эта состоит из электронных сообщений, телефонных звонков, технических условий, маркетинговых сведений, планов Microsoft на следующий год, вашей вечной головной боли в лице разгильдяя-программиста Джорджа и т. д. Другими словами, пытаясь вести свою стаю, вы ежедневно, если не ежечасно, попадаете в ситуацию информационной перегрузки. Все поступающие сведения на первый взгляд кажутся важными, однако без фильтра не обойтись. Смысл этого фильтра можно выразить одним словом (кстати, это еще один удачный термин из области объектно-ориентированного программирования):

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

Намотайте себе на ус: если уж у вас есть задача организовать производство программного продукта, остальные сведения, отвлекающие от этой задачи, независимо от того, насколько важными они кажутся, нужно отложить[32].

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

Вот некоторые ситуации-раздражители, часто встречающиеся в повседневной деятельности руководителя.

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

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

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

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

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

Фокусироваться – значит расставлять приоритеты среди тех сведений, которые претендуют на значимость наравне со сведениями, действительно значимыми для завершения текущих проектов.

Предположим, например, такую ситуацию: в ходе написания кода вы замечаете в одном из объектов, который предполагаете расширить (или добавить интерфейс), некую аномалию. Искушение приняться за исправление такого объекта – по большому счету, попавшегося вам на глаза случайно – велико. Что сделает хороший программист? Он примет аномалию во внимание, но продолжит заниматься текущей процедурой. Вспомните, как просто потерять концентрацию при кодировании, отвечая на телефонный звонок. На то, чтобы в подобных ситуациях вернуться в колею (и восстановить в сознании логику кода), уходит битый час. В организационном управлении действует тот же принцип: либо вы решаете первоочередные задачи, либо теряете последние шансы укладываться в график. Ко времени, выделяемому на решение административных задач, нужно относиться так же трепетно, как и ко времени, выделяемому на кодирование.

Ко времени, выделяемому на решение административных задач, нужно относиться так же трепетно, как и ко времени, выделяемому на кодирование.

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

Еще один дьявольский инструмент уточнения – служба мгновенных сообщений. Пользоваться ею нужно с умом. Не тратьте на нее свое время впустую и не позволяйте ее значку на рабочем столе постоянно отвлекать вас от дела. Не пытайтесь с ее помощью проверять, находятся сотрудники на рабочих местах или нет, – никто не любит, когда за ним открыто наблюдают. В деле слежки нужно проявлять изобретательность – об этом, кстати, я говорил в главе 2 в подразделе «Бессмысленно ожидать чего-либо при отсутствии контроля» раздела «Естественный отбор и время».

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

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

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

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

Скорее всего, вам не удастся сильно продвинуться в вопросах физического размещения программистов, но все-таки при любой возможности требуйте, чтобы каждый сотрудник вместо отгороженной кабины имел отдельное помещение. Если руководство вашей компании больше думает не о продуктивности, а об арендной плате, у вас мало шансов – и, тем не менее, гните свою линию. Один из наиболее заметных раздражителей в деятельности программистов создают инженеры-технологи компаний с их квадратно-гнездовым мышлением. Фильм «Office Space», в котором, так сказать, «в естественном виде» изображены программисты в своих кубышках, должен стать обязательным для просмотра вредителями, планирующими офисное пространство. Факторы, влияющие на «отупение» сотрудников, на примере 32 346 компаний изучили Том Димарко (Tom DeMarco) и Тимоти Листер (Timothy Lister). На составленной ими диаграмме видна четкая обратная зависимость между степенью отупения сотрудников и объемом выделяемого каждому из них офисного пространства[34]. О чем это говорит? О том, что шум, отвлекающие факторы и все прочие побочные эффекты политики снижения затрат серьезно снижают продуктивность работы.

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

Я имею в виду классическое понятие разрастания проекта. Если аналитик бизнес-требований утверждает, что занимается уточнением рамок, знайте: он их раздвигает. Не важно, как этот процесс называть. Факт тот, что специфицировать и сконструировать программу, избежав разрастания требований, не удавалось еще никому. Объясняется это натурой человека – невозможно с первой попытки сформулировать все функции, которые предполагаемой программе предстоит выполнять.

Рассмотрим типичный процесс производства программного продукта. Вне зависимости от того, что вы предпочитаете – стремительный напор или постепенные итерации, – процесс этот всегда состоит из нескольких фиксированных этапов.

1. Замысел. У кого-то появляется блестящая идея.

2. Специфицирование. Куча людей пытаются описать эту идею.

3. Проектирование. Высокоинтеллектуальные товарищи решают, как сконструировать предполагаемый программный продукт.

4. Конструирование. Бессонными ночами и нескончаемыми днями программисты программируют.

5. Тестирование. Обнаруживается, что конечная реализация блестящей идеи не так хороша, как хотелось бы, или, еще хуже, что идея-то отнюдь не блестящая.

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

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

В своей немного устаревшей, но, тем не менее, сохраняющей значимость книге под названием «Managing the Software Process» Уотс Хэмфри (Watts Humphrey) сформулировал принцип, актуальный по сей день:

«Когда программисты берутся за оценку объема кода реализации какой-либо функции, результаты неизменно оказываются заниженными. Этому есть множество возможных объяснений. В этом контексте следует понимать, что их оптимизм есть относительно прогнозируемая функция состояния проекта»[35].

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

• любой процесс продлится дольше, чем вы надеетесь;

• всегда появляется что-то, о чем вы не подумали.

Вооружившись этими аксиомами и введенным Хэмфри понятием «состояния проекта», старайтесь контролировать разрастание и обязательно убедите ваших подчиненных в том, что вы человек проницательный, поскольку предсказывали такую возможность и учли ее в процессе тщательного планирования. «Тщательное планирование»! Звучит замечательно, но что же это означает в контексте выпаса котов? А вот что. Вернитесь к главам 1 и 2, еще раз пробегитесь по изложенным в них принципам и попытайтесь сделать их неотъемлемыми элементами своего характера. Помните, что лидерство происходит от сердца, а не от ума[36].

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

Задача……Время выполнения (произвольные интервалы)

Анализ требований……А

Создание проектного решения……В

Реализация проектного решения……С

Тестирование программного обеспечения……D

Исправление ошибок……Е

Развертывание программного обеспечения……F

Руководствуясь таким планом, вы рискуете нарваться на кучу неприятностей. Будучи глубоко убеждены, что конечная дата сдачи проекта будет равняться сумме временных интервалов A+B + C + D + E + F, вы немало удивитесь, обнаружив, что это совершенно не так.

Рассмотрим более реалистичный план, показанный в табл. 3.4.

Задача……Время выполнения (произвольные интервалы)

Анализ требований……А

Обсуждение результатов анализа с сотрудниками отдела……В

Создание проектного решения……С

Макетирование проектного решения……D

Оценка макетов……Е

Пересмотр проектного решения……F

Реализация высокоуровневых объектов проектного решения……G

Тестирование высокоуровневой интеграции……Н

Оценка системы на предмет соответствия требованиям……I

Создание компонентов системы……J

Интеграция и тестирование компонентов……К

Повторная оценка системы на предмет соответствия требованиям……L

Тестирование комплектной системы……М

Исправление неисправностей системы в преддверии альфа-тестирования……N

Начало альфа-тестирования……О

Исправление ошибок, выявленных на этапе альфа-тестирования……Р

Начало бета-тестирования……Q

Разработка стратегии развертывания……R

Исправление ошибок, выявленных на этапе бета-тестирования……S

Тестирование стратегии развертывания……Т

Тестирование конечного продукта……U

Развертывание программного обеспечения……V

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

По большей части, разрастание рамок проекта происходит по причине недоработок специалистов, отвечающих за планирование.

Каков механизм совершенствования навыков временной оценки? Он очень прост – поначалу вам предстоит неоднократно нарушать утвержденные графики сдачи проектов, но, в конце концов, вы научитесь им соответствовать. Практика эта довольно нервозная и даже угрожающая вашему карьерному росту. Возможно, это не лучший способ самосовершенствования, но что можно утверждать со всей определенностью, так это то, что в области управления проектом опыт играет огромную роль. А чтобы ускорить обучение, почитывайте анекдоты, относящиеся к руководству проектами. В своей леденящей душу коллекции очерков о неудавшихся программных проектах Роберт Гласе (Robert Glass) составил список наиболее распространенных «программных катастроф», который я привожу в порядке снижения значимости[37].

1. Неадекватное специфицирование задач проекта (51 %).

2. Неудовлетворительные планирование и оценка (48 %).

3. Применение новой для данной компании технологии (45 %).

4. Негодная/отсутствующая методология руководства проектом (42 %).

5. Нехватка ведущих специалистов группы (42 %).

6. Срыв договоренностей производителями аппаратного/программного обеспечения (42 %).

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

Речь не о кошках, а о программистах. О том, что они блуждают в потемках, можно судить по характеру их кода, – он начинает походить на огромный памятник их гениальности. Практика регулярного критического обзора кода помогает сносить подобные монументы еще до того, как самовлюбленные хозяева их окончательно возведут. Более подробно мы побеседуем об этом явлении в главе 6, полностью посвященной техническому руководству. Пока что запомните один замечательный принцип: творчество бесценно, а вот практичный и удобный в сопровождении код можно не только оценить, но и продать. В ваши обязанности как руководителя входит координация деятельности программистов, направленная на достижение максимальной функциональности за счет минимального объема кода. Усложнение – это то, с чем вам предстоит вести постоянную борьбу. К понятности кода придется идти мелкими шажками – благо, скорее всего, вам предстоит бороться со смертными грехами программистов, такими как[39]:

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

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

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

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

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

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

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

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

«Несколько лет назад, когда язык COBOL еще называли будущим программирования, очень активно обсуждался вопрос о том, умеют ли руководители читать программы. По прошествии времени кажется совершенно очевидным, что все эти разговоры были нацелены лишь на выбивание средств из руководителей, стремившихся свести свою зависимость от программистов к минимуму. На самом деле никто не верил, что руководители умеют читать программы. И с какой стати они должны это делать? Ведь даже программисты не читают программы!»[40].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«Возможно, они стоят значительно большего, чем получают в данный момент. Вероятно, они должны получать в пять или даже десять раз больше, чем среднестатистический разработчик… Чего на самом деле стоит человек, который «спас» проект? Для того чтобы ответить на этот вопрос, имеет смысл оценить последствия, которые могли бы наступить, если бы такой сотрудник перешел в другую компанию»[43].

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

Что?! Я только что получил эту работу и воспитывать себе смену не собираюсь! Этот ход мысли не отличается проницательностью. Никогда не забывайте о «факторе падающего кирпича». А вдруг вас приберет Бог или случится какое-то несчастье? Кто вас заменит (или сменит)? Как отдел продолжит работу? В некоторых ситуациях кому-то все равно придется исполнять ваши обязанности – для этого не обязательно попадать в беду. Выстраивая свой стратегический план, вы должны постоянно учитывать такие возможности и искать людей, способных время от времени подменять вас. Это помогает, с одной стороны, выявить сотрудников, заслуживающих более широкого круга обязанностей, с другой – определить набор высокоуровневых организационных задач, которые можно с уверенностью делегировать другим.

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

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

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

Если попробовать свести содержание этой главы к нескольким четким и удобоваримым принципам, получится, что руководитель:

• расставляет приоритеты и борется с раздражителями (фокусируется на поставленных задачах);

• совершенствует свои навыки в области руководства проектами и прорабатывает все их детали;

• пресекает низкое качество кодирования, пока оно не пустило в проекте корни;

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

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

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

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

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

Примечания:

3

Большинство этих терминов разъясняются в издании The New Hacker's Dictionary, Third Edition, by Eric S. Raymond (The MIT Press, 1998).

4

Ellen Ullman, Close to the Machine (San Francisco: City Lights Books, 1997), p. 20.

31

Термин «информационная мгла» (data smog) я позаимствовал у Дэвида Шенка (David Shenk).

32

В главе 1 я уже ссылался на труд Стивена Кави (Stephen Covey) под названием «The 7 Habits of Highly Effective People». Если у вас нет этой книги, идите в магазин, купите и прочитайте. Обязательно обратите внимание на то, что Кави думает по поводу организации времени и расстановки приоритетов.

Перевод на русский язык: http://www.ozon.ru/context/detail/id/2446031/ (прим. сост. FB2)

33

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

34

DeMarco and Lister, op. cit., p. 56.

35

Watts S. Humphrey, Managing the Software Process (New York: Addison-Wesley, 1989), p. 93.

36

Вспомните, что говорил Йода: «Сила Джедая есть результат его собственных усилий». У нас то же самое.

37

Robert L. Glass, Software Runaways (Upper Saddle River, NJ: Prentice Hall, 1998), p. 20.

38

См. также Robert L. Glass, ComputingFailure.com (Upper Saddle River, NJ: Prentice Hall, 2001).

39

Это лишь немногие грехи. Существует множество альтернативных перечней. Добротный пример см. в издании William Н. Brown ctal, AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (New York: John Wiley & Sons, 1998).

40

Gerald М. Weinberg, The Psychology of Computer Programming: Silver Anniversary Edition (New York: Dorset House Publishing, 1998), p. 5.

41

Достойные тесты оценки личности есть на сайте http://www.advisortcam.com.

42

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

43

Pete McBreen, Software Craftsmanship (New York: Addison-Wesley, 2001), p. 61.