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

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

Современная корпоративная культура зачастую не оставляет места для географической централизации групп разработчиков. Финансовые соображения, наличие выдающихся особо талантливых специалистов, равно как и традиции конкретной компании, – все это иногда приводит к тому, что ваши подчиненные, хотя и образуют единую группу, фактически работают в разных местах. Если сотрудники находятся в разных зданиях или даже в разных часовых поясах, обеспечить гармоничное сочетание сотрудничества с уединением, что является основным фактором продуктивной деятельности группы, не так-то просто[105]. Если среди ваших подчиненных есть такие, которые один или два раза в неделю общаются с остальными на телеконференциях, вам не обойтись без специальных методов, позволяющих контролировать их продуктивность.

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

Если вам удается успешно сочетать сотрудничество с уединением, процесс разработки существенно упрощается.

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

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

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

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

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

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

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

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

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

• Большую часть времени вы, руководитель, проводите с телефонной трубкой в руках.

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

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

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

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

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

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

Большое человеческое спасибо Александру Грэму Беллу (Alexander Graham Bell)! Телефон значительно облегчил для нас двустороннюю связь в реальном времени. Правда, полагаю, что Белл воскликнул «Поди-ка сюда, Ватсон!», просто утомившись от своего аппарата и решив, что лучше переговорить с помощником с глазу на глаз. Если бы все ваши подчиненные находились в одно время в одном месте, планировать распорядок дня было бы гораздо проще. Тем не менее, если, конечно, вы не сводите все взаимодействие к общению по электронной почте, имейте в виду, что в условиях децентрализации группы телефон представляет собой заметную ценность. Если вы можете себе позволить организацию регулярных видеоконференций, качество взаимодействия, несомненно, повысится. Впрочем, далеко не все компании на это способны. При наличии канала с достаточной пропускной способностью можно разориться на веб-камеры и соответствующее программное обеспечение. Замечу, что с этими средствами мне не удалось добиться сколько-нибудь заметных успехов.

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

Невзирая на все недостатки документно-ориентированного процесса проектирования, скорее всего, именно на нем вы остановите свой выбор. Кроме того, полезен в данном контексте метод проектирования по контракту, подразумевающий первоочередное (в самом начале периода проектирования) создание открытых интерфейсов объектов, с тем чтобы впоследствии их можно было без труда разработать. Этот метод полезен даже в условиях централизации группы, а уж если один разработчик трудится в Калифорнии, а другой – где-нибудь в Новой Англии, соглашение по части взаимодействия компонентов и их способности к взаимодействию выходит на первый план. Купите качественное программное обеспечение для совместной работы и задействуйте его в роли библиотеки документов. За рыночную нишу программных продуктов для совместной работы соревнуются несколько производителей, и это вам на руку – следите за их последними разработками[106].

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

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

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

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

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

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

Работая с представителями разных культур, вы должны привести свою речь к определенному стандарту. С чужаками нельзя общаться так же, как с корешами из соседнего двора, – не выйдет! Структуры речи, общераспространенные разговорные стили и даже язык тела – во всех этих отношениях между разными культурами наблюдаются серьезные различия. Заставьте себя говорить медленнее – поймите, что факт употребления английского как второго языка еще не означает знания американского сленга, адекватного восприятия привычки к небрежному построению предложений и следования вашему ходу мысли, выраженному в словах. Даже британский английский в некоторых моментах существенно (и радикально!) отличается от американского[107].

Нельзя общаться с чужаками так же, как с корешами из соседнего двора, – не выйдет!

Есть и другие культурные различия, которые иногда удивляют, а иногда кажутся достойными включения в стандартную корпоративную практику. Знаете ли вы, например, что среди филиппинцев публичное рукопожатие служит признаком дружбы? Когда индиец первый раз приходит в гости, он обязательно приносит подарок. Австралийская культура, на первый взгляд, во многом пересекается с американской, но знаете ли вы, в каких количествах австралийцы поедают овощную пасту?[108] А как насчет традиционных американских праздников? Уверяю вас: человек, родившийся в Бангалоре, в День благодарения будет, как обычно, работать. Вы должны выяснить все существующие различия и стать гражданином мира – усваивайте лучшие черты всех культур и включайте их в свой «джентльменский набор» лидера.

Мотивация программистов деньгами среди стандартного набора американских приемов менеджмента является «наименьшим общим кратным». С другой стороны, имейте в виду, что деньги – это наименее эффективный способ построения командной атмосферы в многокультурной среде. Что же делать? Проанализировать все факторы, способные стимулировать к работе существующую команду или новых сотрудников, которых вы только собираетесь привлечь. По результатам недавнего опроса 100 наемных работников, не являющихся гражданами США, Дин Бетменг (Dene Bettmeng) делает следующие выводы:

«Многие сотрудники рассматривают в качестве основных преимуществ работы в американских компаниях корпоративную культуру и корпоративные правила, а также технологическую оснащенность. В частности, их привлекают перспективы карьерного роста, заработная плата и льготы, равно как и возможность изучать и применять новые технологии. Все эти люди считают, что работать в компании, расположенной в США, в целом предпочтительнее, чем в какой бы то ни было другой стране. Помимо вышеперечисленных преимуществ, они ценят политическую стабильность, напряженный ритм деятельности и командный дух»[109].

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

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

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

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

Урок 2. Когда индиец кивает головой, он имеет в виду «нет», а не «да». Вы можете себе представить, как это сбивает с толку?! Ведь мы принимаем за аксиому, что кивок выражает согласие!

Урок 3. В большинстве случаев специалисты из Индии не препираются, не пытаются вас поправить и не подвергают сомнению авторитет начальства – по крайней мере публично. Таким образом, они согласятся со всем, что вы скажете, – пусть даже вы будете нести полную чушь. Некоторые из них после совещаний продолжают решать задачу по-своему, вне зависимости от того, что им сказали. Работая с индийцами, я возомнил себя великолепным лидером – ведь американские программисты ни за что не позволят достичь консенсуса так быстро и легко!

Урок 4. Как правило, если консультанты не понимали, что я им говорил, они даже не пытались дать об этом знать. Они несколько раз повторяли, что все мои предложения в высшей степени разумны, после чего продолжали кодировать так, как считали нужным.

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

Урок 6. Несмотря на то, что всех новоиспеченных сотрудников нам привело одно и то же агентство, все они работали на разные консалтинговые компании. Я платил за их услуги по 125 долларов в час, из которых самим исполнителям доставалось только от 15 до 55.

Но… все эти уроки я выучил слишком поздно. Лишь один из трех проектов был успешно завершен; остальные два постигла печальная судьба – немалые деньги оказались выброшенными. Ни за что больше не буду ввязываться в подобные авантюры.

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

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

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

В конце 1960-х годов, когда тогдашним инженерным гениям удалось высадить человека на Луну, располагая при этом меньшими вычислительными мощностями, чем любой современный калькулятор[110], в обиход вошел термин «программная инженерия». Эта концепция зиждется на представлении, согласно которому программное обеспечение можно разрабатывать средствами традиционных инженерных дисциплин. Применительно к сверхкрупным программным проектам, которые, как правило, заказывались правительством или крупными подрядчиками министерства обороны, эта методика несколько раз показала достойные результаты, но в остальных случаях потерпела фиаско[111]. Метод программной инженерии зачастую применялся в условиях одновременной разработки программного и аппаратного обеспечения. Кроме того, с его помощью удалось создать несколько коммерческих продуктов. IEEE определяет этот метод следующим образом:

«Программная инженерия – это систематический, структурированный, количественный подход к разработке, функционированию и сопровождению программных средств; иначе говоря, способ применения инженерных методов в разработке программных продуктов»[112].

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

Это не в меру сжатое определение, по-моему, можно расширить.

• Систематически – все аспекты разработки можно контролировать в едином процессе.

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

• Количественно – все требования известны и допускают отображение на методы реализации.

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

«Существует распространенное мнение, согласно которому несколько высококлассных специалистов, собранных вместе, способны сделать больше, чем стандартная группа разработчиков. Имеется в виду, что их знания о способах достижения высоких результатов интуитивны, а значит, потребность в систематизации процесса отпадает. Будь это действительно так, можно было бы предположить, что компании, у которых в штате числятся наиболее квалифицированные специалисты, не должны испытывать типичных проблем с качеством разрабатываемых программных средств и продуктивностью. Опыт же подсказывает нам, что это совершенно не так»[113].

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

Мнения на этот счет расходятся. Предположим, перед вами стоит задача конструирования системы управления воздушным движением. На первый взгляд, программная инженерия прекрасно подходит для ее решения. Но… стоит подумать еще раз. К провалу проекта комплексной системы автоматизации (Advanced Automation System, AAS) Федерального управления гражданской авиации США (Federal Aviation Administration, FAA), с помощью которого в 1980-х годах предполагалось модернизировать систему управления воздушным движением, методика программной инженерии имеет непосредственное отношение. Несмотря на миллионные затраты, проект так и не оправдал ожиданий[114].

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

Хотите – возмущайтесь, но в одном вы меня не переубедите: компании Microsoft удалось разработать крайне продуманный метод и успешно его разрекламировать. Несколько компаний[115] даже решили в приказном порядке отправить своих сотрудников на недельные курсы обучения предлагаемому Microsoft методу. Не сомневаюсь, что компании уровня Microsoft, специализирующейся на разработке коммерческих программных продуктов, есть что сказать на заданную тему.

Концептуальная основа метода MSF (Microsoft Solutions Framework – каркас решений Microsoft) предполагает координацию групп, тем или иным способом ответственных за процесс разработки. Вместо того чтобы воспроизводить яркие рекламные лозунги, я сосредоточу ваше внимание на отдельных деталях метода – по-моему, они лучше любых сообщений информационных служб и даже лучше научного изложения концепции отражают позицию Microsoft. Согласно выпущенному компанией руководству[116], предлагаемая методика основывается на «трех китах».

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

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

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

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

Что касается этапов MSF, то здесь группа разработчиков должна принять на вооружение ряд принципов.

1. Видение/рамки. Основное внимание уделяется не требованиям, а рамкам работ.

2. План проекта. Заказчики и участники группы должны договориться о поставках, приоритетах и ожиданиях.

3. Закрытые рамки/Первое применение. Первая бета-версия готового продукта.

4. Выпуск. Продукт или услуга предоставляется рабочей группе и группе поддержки.

Роли в MSF распределяются следующим образом.

1. Руководство продуктом. Особое внимание уделяется оценке продукта с коммерческой точки зрения.

2. Управление программой. Разработка функциональных спецификаций, утверждение и корректировка графика.

3. Разработка. Конструирование продукта (или услуги), соответствующего спецификации и ожиданиям заказчиков.

4. Тестирование. Выявление всех проблем перед выпуском программы.

5. Обучение пользователей. Каждый пользователь должен получать от продукта максимум возможностей.

6. Логистика. Обеспечение беспрепятственных выпуска, установки и миграции.

Все очень складно, не правда ли? На самом деле максимальной продуктивности, вооружившись методикой MSF, можно достичь лишь при наличии достаточно многочисленного персонала, который позволит сформировать группы и исполнять процессы согласно рекомендациям. Преподаватели на курсах утверждают, что метод MSF применяется в самой компании Microsoft. Учитывая характер литературы, выпущенной Microsoft Press за последние 10 лет, полагаю, что это действительно так[117].

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

С одной стороны, экстремальное программирование (Extreme Programming, ХР) позиционируется как новаторская методика; с другой – эта методика существует, пожалуй, с тех давних пор, когда в реле находили тараканов[118]. Позвольте пояснить. Основное внимание в ХР уделяется командному программированию с акцентом на код сам по себе. Последний понимается как средство передачи требований и изменений, а также ключ к пониманию задачи программного продукта. Один из ведущих проповедников ХР Кент Бек (Kent Beck) утверждает, что ХР обещает радужные перспективы двум группам заинтересованных лиц:

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

«При помощи ХР заказчики и руководители смогут каждую неделю разработки получать максимальный результат. С регулярностью в несколько недель они будут оценивать конкретный результат работы над решением задач, которые для них наиболее важны. Корректировать направление разработки проекта можно будет в самый разгар трудовой деятельности программистов, причем никаких сверхъестественных затрат на это не потребуется»[119].

Каким образом метод ХР реализует эти перспективы? Путем введения ряда принципов программирования, которым группы должны следовать неукоснительно. Вместо того чтобы перекладывать отдельные аспекты разработки на руководящее звено, метод ХР концентрируется на функциях собственно программистов, то есть на конструировании программных продуктов.

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

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

Буква «X» в аббревиатуре ХР означает «экстремальный». Эту характеристику многие деятели нашей индустрии признали вполне удачной. Впрочем, есть и такие, которые, уважая суть концепции, с некоторым презрением относятся к ее названию[120]. По-моему, в публикациях, посвященных этой «новой» методологии, равно как и в практической деятельности по реализации ее принципов, очень много полезного. Полагаю также, что материалы сайта http://www.extremeprogramming.org помогут вам сориентироваться в том, какие методы этого заметного (пожалуй, даже крикливого) течения стоит принять на вооружение. Хотя, если уж следовать духу ХР, получается, что вычленять из этой методологии отдельные элементы или смешивать ее с другими стилями нельзя – либо вы «экстремал», либо нет. Меня на это не купишь, хотя мотивация мне вполне понятна. Поборники экстремального программирования пытаются сказать примерно следующее: «Либо дисциплинируйтесь, либо убирайтесь из профессии – вам в ней нечего делать!» Вот это мне по душе – надеюсь, и вам тоже.

В поисках новых методов для себя и своей команды вам еще не раз предстоит столкнуться с термином «гибкий» (agile). Любой эффективный метод разработки программного обеспечения является таким по свой природе. Гибкость означает способность к адаптации, к изменяющимся требованиям и развивающейся технологии, в том числе на этапе конструирования проекта. Мнения большинства специалистов в области разработки программных средств сходятся в одном: гибкость – это священный Грааль всех методик разработки. Существует даже общественная организация, состоящая из ведущих специалистов по разработке программных продуктов и ставящая своей целью пропаганду концепции гибкости[121]. Эти деятели даже опубликовали манифест, в котором обозначены четыре основные проблемы, свидетельствующие, в зависимости от решения, о гибкости тех или иных методов[122].

1. Отдельные лица и взаимодействие или процесс и инструментальные средства.

2. Функционирующее программное обеспечение или комплексная документация.

3. Сотрудничество заказчиков или переговоры по контракту.

4. Реакция на изменения или следование плану.

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

Между так называемой «гибкой» школой и экстремальным программированием много параллелей. Действительно, в совещании, на котором был принят манифест гибкости, участвовали, помимо прочих, основатели концепции ХР. На самом деле методология гибкости – это, скорее, совокупность принципов, применимая к любым процессам и мероприятиям в области планирования, направленным на конструирование программных средств. В главе 6, рассуждая о методах технического проектирования, я упомянул термин[123] «адаптивная разработка программных средств», имея в виду деятельность, обусловливающую ваш успех в роли технического лидера. Так вот, адаптивная разработка тоже происходит от гибкости.

Мнения большинства специалистов в области разработки программных средств сходятся в одном: гибкость – это священный Грааль всех методик разработки.

В отличие от других методов, рассматривающих предвидение изменений как малозначащий фактор, на который не следует обращать внимания, или как тенденцию в процессе разработки, которой нужно сопротивляться, концепция гибкости призывает к конструктивному и адаптивному реагированию на изменения. В этом свете ХР трактуется как подготовительная стадия к внедрению философии гибкости. Любой метод, предусматривающий фиксацию требований и следование предопределенному процессу, приводит к созданию не вполне адекватного программного продукта. Приведу цитату из Кокберна (Cockburn):

«Некоторые считают, что необходимым условием успешности проекта является следование заданному процессу. Те, кто придерживается такого мнения, тратят уйму энергии на проверку его соблюдения. Человек, твердо убежденный в том, что именно в процессе вся суть, может очень долго не обращать внимания на несоответствие между практикой следования процессу и его исходом»[124].

Иначе говоря, методология гибкости снимает с нас шоры и открывает глаза на те вещи, которые рабы процесса не замечают.

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

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

Приведенный обзор методологий разработки приводит, как мне кажется, к единственному выводу – разрабатывать программы должны не инженеры, а мастера. Понятие мастерства не всегда легко поддается осмыслению. Я пришел из академической науки и на раннем этапе своей деятельности занимался инженерией; по этой причине я сперва отказывался признавать приоритет искусства перед наукой в процессе создания программных средств. Впрочем, вскоре я понял, что «сопротивление бессмысленно»[126]. Посмотрим, под каким заголовком вышел один из ведущих технических журналов в 1990 году[127]:

«Производители программных средств страдают от недостаточного контроля за качеством. По мере того как программные продукты становятся все более сложными, компаниям становится все сложнее контролировать миллионы строк кода сложных пакетов»[128].

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

Программные продукты создают люди, а отнюдь не процессы, исполняемые автоматами.

Кто создает программные продукты? Мастера. Осознав, что мастера совершенно не пренебрегают наукой и инженерией, вам будет легче признать, что искусство (мастерство) главенствует над научным подходом. Рекомендую поразмыслить над тем, как нам всем прийти к достойному балансу искусства и науки/инженерии в себе, чтобы обеспечить превращения кода в полезные и качественные программные продукты. Я абсолютно согласен с Питом Макбрином (Pete МсВгееп) в том, что он пишет в предисловии к своей книге по мастерству разработки программных продуктов:

«Мастерство знаменует собой возвращение к корням разработки программных средств. Хорошие разработчики понимают (и всегда понимали), что программирование – это деятельность из области искусства. Какими бы потаенными и подробными техническими знаниями ни обладал разработчик, в конечном итоге процесс разработки приложений сводится к ощущению и опыту. Можно знать самые изощренные детали языка программирования Java, но при этом, не чувствуя эстетической стороны программ, так и не стать достойным разработчиком. Если же человек чувствует процесс разработки программных средств, знание конкретных технических деталей уходит далеко на второй план. Лучшие разработчики постоянно учатся новым технологиям и методологиям; постижение очередной технологии для разработчика должно стать обыденным занятием»[129].

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

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

«Мыльные пузыри» в рядах программных продуктов регулярно создают излишний шум. Это явление я бы назвал «интеллектуальным зомбированием». Проекты, о которых шли беспрерывные разговоры, не приведшие, однако, к фактической реализации, весьма многочисленны. Упомяну лишь некоторые несбывшиеся обещания и беспочвенные заявления[131].

• Подключенный к сети компьютер за 500 долларов избавит мир от Windows.

• MSN уничтожит AOL (не так быстро – AOL нынче владеет Time-Warner).

• Intuit, несмотря на противостояние с Microsoft, удалось создать более удачный продукт – Quicken.

• OS/2 – это DOS лучше «настоящей» DOS и Windows лучше «настоящей» Windows.

• Разработчики настольных прикладных систем дружно перейдут на Java. (Ну это мы еще посмотрим!)

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

Революции в нашей отрасли, бесспорно, случаются. Впрочем, симптомы грядущих изменений, как правило, прослеживаются задолго до окончательного утверждения новых идей и их воздействия на процесс разработки. Вы должны научиться предсказывать тенденции, обещающие заявить о себе через некоторое время. В «Искусстве войны» Сун Цзу (Sun Tzu) писал:

«Не разбивайте лагерь на сложной местности. Объединяйтесь с союзниками на пересечении крупных путей. Не задерживайтесь на изолированных позициях. Находясь в окружении противников, старайтесь обмануть их. Деритесь только при крайней необходимости»[132].

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

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

• Объединяйте усилия. См. предыдущий пункт. Обращайтесь к зарекомендовавшим себя решениям от разных поставщиков – чем больше их будет, тем лучше. Время от времени привлекайте консультантов – пусть делятся с сотрудниками новыми знаниями. Стимулируйте процесс обучения за счет построения силами сотрудников компактных макетов, нацеленных на проверку применимости новых методик к разработке более крупных проектов.

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

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

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

Пожалуй, самый важный урок, которому нас учат многочисленные кризисы, состоит в следующем: если компания перестает приносить доход, значит, вероятно, конец близок[134]. Таким образом, лучший способ предотвратить наступление кризиса в компании – это следить за издержками разработки и стремиться к рентабельности. Признаю: совет не слишком оригинален – это все равно что сказать: «Если хотите заработать на Уолл-стрит, покупайте задешево, а продавайте втридорога». Совет на самом деле правильный, но лишь при условии верно выбранного времени. Таким образом, очевидно, что во главе угла находится именно время.

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

• Вы – не только технарь, но и бизнесмен. О стоимости, таким образом, нужно думать не меньше, чем о коде.

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

• Сравнивайте окончательную фактическую стоимость проекта с предварительными расчетами. Оценивайте расхождения между сметой и расходами и на основе этого опыта учитесь подходить к составлению смет с более реалистических позиций. Не забывайте поговорку: «День профилактики стоит года лечения».

• Держите зарплаты сотрудников под контролем. Платите им столько, сколько они заслуживают, сверяясь при этом с рыночной конъюнктурой[135].

Увольняя сотрудника, позаботьтесь о его дальнейшем трудоустройстве – пишите рекомендательные письма[136] и звоните работодателям. Почувствовав, что скоро могут уволить вас самого, немедля приступайте к поиску нового места работы (если, конечно, это возможно) – не ждите, пока извещение об увольнении придет по факсу. Перейти с одной работы на другую значительно проще, чем выбраться наверх из армии безработных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Технологические революции поддаются прогнозированию, а значит, к ним можно подготовиться. Стратегическое планирование на основе понимания предстоящих перемен – вот средство, позволяющее предотвратить излишнюю суету в случае их наступления.

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

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

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

Примечания:

1

Мои шутки, по большей части размещаются в сносках, так что они не будут вас отрывать от основной мысли. Ну вот, например: что значит «обратная совместимость»? Это значит, что новая операционная система с тем же успехом, что и старая, может грохнуть все ваши программы.

10

Frederick P. Brooks, The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (New York: Addison-Wesley, 1995), p. 230. Это действительно непреходящая классика. В нашей области очень мало книг, которые переиздаются через 25 лет после появления, и это – одна из самых стоящих.

Русский перевод книги доступен на http://lib.rus.ec/b/110948 (прим. сост. FB2)

11

Я имею в виду тех, кому пора готовиться к основательной порке.

12

Ну вообще-то в Библии это высказывание приписывается глупцу. Контекст смотрите в Экклезиасте 9:14–19. Только постарайтесь не слишком падать духом, когда будете читать.

13

См. Новый Завет, 1-е послание к Тимофею 6:10 – любовь, деньги и зло он виртуозно сводит в один силлогизм.

104

Помимо всего прочего, я опасался, что глава под названием «Разное» не вызовет должного читательского интереса.

105

О сотрудничестве и уединении мы говорили в главе 4.

106

См. http://www.erooni.com, http://www.fox.se/engiish/starteam/starteam_version_control.htm и другие предложения от IBM и Symantec.

107

Не говорите англичанину про богатый (rich) пользовательский интерфейс. Он обязательно подумает, что интерфейс слишком дорогостоящий.

108

Хотя она чем-то напоминает арахисовое масло, уверяю вас, совсем не так вкусна!

109

Из отчета наконференции Network World Fusion (http://vww.nwfusion.corn/careers/2001/0402mari.html).

110

Первый функционирующий микропроцессор появился в 1971 году.

111

См. Glass, Software Runaways, op. cit.

112

См. IEEE Standard Computer Dictionary (Institute of Electrical and Electronics Engineers, Институт инженеров по электротехнике и электропике, 1990).

113

Humphrey, op. cit., p. ix.

114

См. Glass, Software Runaways, op. cit., p. 56.

115

В том числе и моя, естественно.

116

Solutions Development Discipline Workbook (Redmond, WA: Microsoft Corporation, 1996), pp. 1-17.

117

В первую очередь, я имею в виду работу Jim McCarthy, Dynamics of Software Development (Microsoft Press, 1995). Вероятно, именно в ней впервые сформулированы некоторые основополагающие принципы MSF.

118

Термин «жучок» (bug), очевидно, появился еще в эпоху наиболее древних (до 1950-х годов) компьютеров, в которых реле выходили из строя вследствие попадания в них всякого рода насекомых.

119

Kent Beck, Extreme Programming Explained (Reading, MA: Addison-Wesley, 2000), p. xvi.

Русский перевод книги доступен на http://lib.rus.ec/b/101297 (прим. сост. FB2)

120

См. колонку «Feedback» в журнале Software Developments за ноябрь 2001 года.

121

См. http://www.AgileAlliance.org.

122

См. Alistair Cockburn, Agile Software Development (New York: Addison-Wesley, 2002), Appendix A.

123

Этот термин взят из одноименной книги Джима Хайсмита (Jim Highsmith). См. библиографию.

124

Cockburn, op. cit., p. 5.

125

Примеры приводятся в работе Cockburn, op. cit. Обзор имеющихся ресурсов имеется также на сайте http://www.adaptivesd.com.

126

Похоже на «Звездные войны» правда?

127

Как вы помните, тогда не было ни Windows, ни графических пользовательских интерфейсов.

128

Electronic Business, October 15,1990, p. 147.

129

МсВгeen, op. cit., p. xv

130

Такой подход рекомендовал сам Леонардо (см. главу 6).

131

Этот список я но большей части позаимствовал у Дэвида Корси (David Coursey) – редактора рубрики Anchor Desk на портале http://www.zdnet.com (конкретнее – из статьи, опубликованной им 12 октября 2001 года).

132

Цитирую по: Sun Tzu, The Art of War. Ed. James Clavell (New York: Dell Publishing, 1983), p. 37.

133

Как мне кажется, для начала подойдет сайт Tech Republic http://www.techrepublic.com). На нем публикуются вполне добротные тематические обзоры.

134

Интернет-компании славились (и славятся до сих пор) бездоходностью. Amazon.com вот уже несколько лет приносит прибыль, и, вероятно, эта компания – скорее исключение из общего правила; впрочем, время покажет. Лично мне будет жаль, если они обанкротятся. В конце концов, неужели многих сотен долларов, которые я перечислил им за годы нашего знакомства, недостаточно для выживания?!

135

Я уже высказывался на эту тему в главах 1 (см. подраздел «Мотивирование деньгами» в разделе «Слава, почет и деньги») и 3 (см. подраздел «Денежное поощрение и продвижение сотрудников по службе» в разделе «Как сформировать команду и как ее поддерживать»), но здесь имеет смысл повториться.

136

В некоторых случаях от такой помощи приходится отказываться по правовым причинам. По вопросам корпоративной политики в этой области вам стоит проконсультироваться у начальника.

137

См. главу 8 – в ней упоминается конструктивная трактовка слова «паранойя», приписываемая Энди Гроуву.