Как пасти котов. Наставление для программистов, руководящих другими программистами. — СПб.: Питер, 2016. — 256 с.: ил. — (Серия «Библиотека программиста»).
ISBN 978-5-496-01820-3
«Как пасти котов» — это книга о лидерстве и руководстве, о том, как первое совмещать со вторым.
Это, если хотите, словарь трудных случаев управления IT-проектами. Программист подобен кошке,
которая гуляет сама по себе. Так уж исторически сложилось. Именно поэтому так непросто быть
руководителем команды программистов. Даже если вы еще месяц назад были блестящим и дисциплинированным программистом и вдруг оказались в роли менеджера, вряд ли вы знаете, с чего надо
начать, какой выбрать стиль руководства, как нанимать и увольнять сотрудников, проводить совещания, добиваться своевременного выполнения задач. В таком случае без этой книги вам не обойтись.
А может быть, вы — опытный менеджер, желающий пересмотреть свои принципы лидерства? Тогда,
опять же, эта книга для вас. Вне зависимости от возраста, пола и социального статуса она поможет
вам укрепить свои позиции в роли лидера программистов. Материал изложен довольно компактно и
легко укладывается в голове. Стоя в книжном магазине и раздумывая, что же купить, задайте себе один
простой вопрос: «Нужно ли мне совершенствовать свои лидерские навыки?» Полагаю, вы ответите:
«Да», — а значит, данная книга окажется для вас небесполезной.
12+ (В соответствии с Федеральным законом от 29 декабря 2010 г. № 436-ФЗ.)
ББК 65.290-23
УДК 658.014.1
Права на издание получены по соглашению с Apress.
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме
без письменного разрешения владельцев авторских прав.
Информация, содержащаяся в данной книге, получена из источников, рассматриваемых издательством как надежные. Тем не менее, имея в виду возможные человеческие или технические ошибки, издательство не может
гарантировать абсолютную точность и полноту приводимых сведений и не несет ответственности за возможные
ошибки, связанные с использованием книги.
Посвящается Дэвиду, моему любимому сыну, —
память о тебе меня неизменно вдохновляет.
Жаль, что тебя нет,
и я никогда больше не увижу, как ты смеешься…
Ïðåäèñëîâèå
Прочитав замечательную книгу Хэнка, в которой он рассказывает о выпасе котов,
я вспомнил то время (а было это... ну очень давно), когда из программиста меня пе
ревели в менеджеры. Подобно вам, читатели, я был в высшей степени самоуверен
ным программистом аналитиком. Я специализировался на языке PLI и базах дан
ных IMS DB/DC. Прибавить к этому понемногу Ramis, FOCUS, Easytrieve Plus,
Datacom/IDEAL, CICS, VSAM — и получится вполне сформировавшийся про
граммист, пишущий для мэйнфреймов. Сегодняшние кодировщики могут с пол
ным правом относить эти технологии к древней истории, но, смею вас уверить,
в те времена по крайней мере некоторые из них были очень даже ничего!
Подобно Хэнку, я сначала взял на себя неофициальные обязанности коорди
натора и наставника своих коллег — в основном, молодых сотрудников. Впослед
ствии эти полномочия были закреплены за мной уже формально. Таким образом,
я начал сочетать полную ставку программиста аналитика с полноценным руко
водством. После этого мне открылись как положительные, так и отрицательные
стороны менеджмента. Помню, собрались мы — я и еще несколько таких же ме
неджеров — как то раз на совещание с начальником. Начальник говорил о том,
какие у него на наш счет большие ожидания, о необходимости повышать нашу
квалификацию как руководителей. Одна из моих коллег в ответной речи вырази
ла крайне распространенную среди молодых менеджеров позицию. Она заявила,
что могла бы стать значительно лучше как руководитель, будь у нее в подчинении
более приемлемый персонал.
Не всегда понятно, почему некоторые вещи крепко оседают в памяти на долгие
годы, и как раз ее фразу я никак не могу забыть. Полагаю, будь в нашем распоряже
нии тогда учебник вроде того, что написал Хэнк, переход к менеджерским обязан
ностям прошел бы значительно менее болезненно. В конце концов, кто мы такие
были? Программисты, которым поручили координировать деятельность других
программистов. В результате былые приятельские отношения испарились — буд
то их никогда и не было. Мне совершенно не хотелось менять свое отношение к кол
легам, но без этого контролировать их поведение я не мог. Мы остались друзьями,
но эти отношения перешли на другой уровень, что ли, и назад пути уже не было.
Сегодня, по прошествии многих лет, я счастлив, что в роли лидера команды
разработчиков, руководителя проектов, руководителя группы, руководителя от
дела и директора мне приходится координировать действия более чем 200 людей.
За счет посещения разного рода курсов и семинаров мне удалось усовершенство
Ïðåäèñëîâèå
13
вать навыки руководителя. Наконец, слава богу, что пользу от чтения книг по
менеджменту я осознал довольно рано. В конце концов, личность в сегодняшних
условиях — это опыт плюс прочитанная литература.
Мой опыт перехода из программистов в руководители позволяет в полной мере
оценить предложения, высказанные Хэнком в его книге. Его стараниями любой
специалист, находящийся в аналогичном положении, может рассчитывать на су
щественную помощь. Уже в первой главе Хэнк попадает в десятку утверждением:
«то, что делаешь ты, не обязательно буду делать я». В самом деле, не с этим ли
связаны все те разочарования, которые мы испытываем в период адаптации к роли
руководителя? Если вы принимаете эту проблему близко к сердцу, поверьте мне —
Хэнк поможет вам преодолеть подобного рода затруднения.
Попробую перефразировать мою бывшую коллегу: заниматься менеджментом
было бы значительно проще, если бы все подчиненные были как две капли воды
похожи на своего начальника. К счастью, это не так. Люди руководствуются раз
ными мотивами, у них разный уровень знаний, и понять, что движет тем или иным
деятелем, не так то просто. Различия не превозносят одного человека над дру
гим — просто все мы разные. Что делает руководитель? Он координирует и ведет
всех этих «котов», которые гуляют сами по себе. Понимать, как коты себя ведут и
как общаются между собой, совершенно необходимо — иначе эффективного ли
дерства не получится.
Вспоминается мой разговор с начальником о трудностях, причиной которых
стал еще один руководитель из числа бывших программистов. Начальник тогда
заявил мне буквально следующее: «Том, пока я сижу на этом месте, никто из про
граммистов больше не станет менеджером!» Где то через год, во время моего от
чета перед новым начальником, мы принялись обсуждать одного из технических
руководителей, которому удалось добиться поразительных успехов по части орга
низации и мотивирования своих сотрудников. Этот начальник резюмировал свои
соображения так: «Том, я думаю, что впредь всех руководителей нам следует на
бирать из числа технарей».
Эти диаметрально противоположные точки зрения лишний раз доказывают,
что нет двух совершенно одинаковых людей. У всех разные таланты, способности,
желания и наклонности. Вы, помимо других, должны разобраться в собственных
достоинствах и недостатках (см. главу 2) и задействовать свои навыки таким обра
зом, чтобы обеспечить успешную деятельность группы в целом (см. главу 3). Про
граммисты, которым приходится впервые брать на себя обязанности по руковод
ству другими программистами, обнаруживают себя на перекрестье профессий.
Некоторые на постоянной основе переходят к менеджерской деятельности. Другие
склоняются к программированию, поскольку в этой области от них больше толку.
Остальных устраивает промежуточная позиция между руководителем и кодиров
щиком.
Если оставить в этой книге только три первые главы, а все остальное выки
нуть, все равно ее стоило бы прочесть (ее объем, конечно, сильно бы уменьшил
ся). Однако и остальные главы тоже весьма интересны, поскольку Хэнк рассмат
ривает в них чрезвычайно актуальные для молодых руководителей вопросы.
С одной стороны, он говорит о том, что теперь у вас есть формальные администра
тивные обязанности. Навыки руководства людьми в контексте успешной деятель
ности компании очень важны, но, с другой стороны, именно административные
14 Ïðåäèñëîâèå
вопросы обеспечивают плавное вращение коммерческого маховика. Вам предсто
ит постоянно заниматься поиском информации и составлять рецензии на выпол
ненные задания. В рамках подведомственной группы вы находитесь на вершине
иерархии управления. Лишь за счет дисциплины и самоорганизации люди справ
ляются с административными функциями. Если эти качества в вашем характере
отсутствуют, вы станете слабым звеном административного механизма, и ваш соб
ственный начальник будет вынужден постоянно вас подталкивать. Скажите спа
сибо Хэнку за объяснение стандартной роли администратора — это объяснение
помогает понять, что такое же бремя несут многие ваши коллеги.
Глава 5, посвященная проведению совещаний, затрагивает очевидно недооце
ненный комплекс приемов. Сама постановка вопроса о продуманной организа
ции совещаний заслуживает уважения. Случалось ли вам посещать совещания,
не преследующие конкретной цели и никем не управляемые? (Вероятно, этот
вопрос лучше переформулировать так: «Каков процент посещенных вами сове
щаний, которые проводились подобным образом?») Если случалось, теперь вы
знаете, почему так происходит: на этих совещаниях никто не проявил активной
руководящей позиции. Если вам удастся при проведении совещаний взять на се
бя лидерство, сделав их тем самым более продуктивными и сориентированными
на конкретные задачи, скажите спасибо Хэнку.
Еще один раздел книги, который мне очень понравился, посвящен отношени
ям с начальством (см. главу 9). Ориентироваться в данной области очень важно,
хотя многие слишком поздно осознают это обстоятельство. Да, действительно, ваш
начальник должен руководить вами. В то же время активная роль в выстраива
нии ваших отношений может принадлежать вам. Занятно, но если вы нацелитесь
на то, чтобы успех был достигнут вашими подчиненными и начальством, успех
обязательно придет к вам самому.
У меня нет возможности углубляться в содержание всех глав и излагать свои
соображения по поводу собранного в них материала — в противном случае мое
предисловие грозит превысить по объему саму книгу. (Впрочем, позволю себе од
но, последнее замечание: обязательно прочтите разделы о многонациональных
и распределенных группах. Крайне ценные сведения!) Скажу лишь, что эта книга
может существенно облегчить жизнь тех программистов, которые в один пре
красный день обнаруживают себя на руководящих постах. Аналогия с выпасом
котов, по моему, вполне уместна. У многих видов животных развито стадное
чувство, и пасти их, соответственно, не так уж трудно. У меня дома два кота, и я на
своем опыте знаю, что у них этот инстинкт не просматривается. Вести в заданном
направлении даже одного кота (программиста) — нетривиальная задача. А для
того чтобы вести за собой четыре пять (или дюжину) этих упрямых тварей, тре
буется предельная концентрация и весьма специфический комплекс приемов.
На материале этой книги, я надеюсь, вы сможете ознакомиться с требованиями,
которые обычно предъявляют к людям, исполняющим вашу роль, и значительно
упростить для себя путь к успеху — по крайней мере, опыт Хэнка к этому рас
полагает!
Том Мокел (Tom Mochal),
создатель www.TenStep.com,
президент TenStep, Inc.
Îá àâòîðå
Хэнк Рейнуотер (Hank Rainwater) в настоящее время работает в Risk Sciences Group
(Атланта, Джорджия), где руководит группой программистов, разрабатывающих
программные продукты для страховых компаний. Его путь в науке и инженерии на
считывает более трех десятилетий. В разные периоды жизни он занимался программи
рованием на языке Фортран с использованием перфокарт; преподаванием математики
в колледже; исследованиями в областях радиоастрономии, систем наведения ракет
и телеметрических систем; координацией производства встроенных систем циф
рового управления. Как специалист в сфере разработки программных продуктов Хэнк
успел поработать консультантом, лектором, программистом и руководителем групп
разработки программ для самых разных областей человеческой деятельности.
Что касается образования, Хэнк окончил колледж с физическим уклоном и получил
диплом университета по специальности «математика и физика». Кроме того, Хэнк —
магистр теологии. Он несколько лет был пастором в разных приходах (как в США,
так и за рубежом), занимаясь попутно преподаванием теологических дисциплин.
Хэнк убежден, что основным условием успешного руководства про
граммистами является наличие лидерских навыков. До прихода в ин
дустрию разработки программных средств он не понимал истинного
значения этого утверждения. С опытом он стал более раскрепощенным,
отрастил длинные волосы
и теперь получает нескрываемое
ческими личностями, старающи
с радужными рыночными перспективами.
удовлетворение от общения с твор
мися превратить код в продукты
Без шевелюры его трудно выделить из уличной толпы.
Î íàó÷íîì ðåäàêòîðå
Дэйв Кристенсен (Dave Christensen) в настоящее время трудится на
посту старшего системно технического аналитика в целлюлозно
бумажном отделении корпорации Potlatch (штаб квартира нахо
дится в Клокете, штат Миннесота). В его обязанности входит обес
печение компании конкурентных преимуществ за счет разрабатывае
мых им веб приложений. Кроме того, он — президент Proxis Produc
tions (http://www.proxis-productions.com) — консалтинговой компании,
специализирующейся на проектировании распределенных корпоративных веб
приложений. В 1995 году, когда компания Proxis Productions только создавалась,
Дэйв предполагал заняться компьютерной графикой для видеоигр и других ком
мерческих предприятий, однако с утверждением графики в Интернете он получил
возможность свести свои графические и технические интересы воедино. У Дэйва
диплом по английской литературе; кроме того, он прослушал несколько медицин
ских курсов и занимался в театре в колледже St. Scholastica. Дэйв — счастливый
человек: свободное от работы время он проводит с прекрасной женой и двумя изу
мительными детьми, которые не перестают его удивлять. У них много живот
ных: две собаки и выводок кошек, которые, кстати, тоже поучаствовали в работе
над этой книгой. Кроме того, Дэйв — коллекционер редких рыбок и увлеченный
реставратор. Он обожает раскрывать в окружающих скрытый потенциал. В этом
отношении он успел поэкспериментировать на автомобилях, домах и людях.
Îá èëëþñòðàòîðå
Мелани Уэллс (Melanie Wells) — опытный графический дизай
нер с десятилетним опытом работы в самых разных областях: ил
люстрировании книг, разработке корпоративных логотипов, со
здании брошюр, проектировании выставочных стендов, оформле
нии почтовой атрибутики, журнальной рекламы, каталогов, ди
зайне упаковки, веб сайтов, спортивной одежды, товарном дизай
не и т. д.
Помимо собственно графического дизайна, Мелани увлекает
ся изобразительным искусством. Вне зависимости от текущего
занятия — разработки фирменного стиля или, например, рисования маслом на
холсте — она в первую очередь художник.
Áëàãîäàðíîñòè
Огромное спасибо Дэну Эплмену (Dan Appleman) из Apress — прочитав черно
вик первой главы, он по достоинству оценил замысел книги, в которой, в отличие
от многих, не рассматривается ни один из современных языков программирова
ния. Ты молодец, Дэн! Уже много лет ты вдохновляешь меня (и не только меня)
на новые достижения, и я надеюсь в этом отношении пойти по твоим стопам.
Карен Уоттерсон (Karen Watterson) — человек, чьи рекомендации в период
работы над проектом сыграли решающую роль в формировании многих идей, ко
торые ранее находились в зародышевом состоянии. Твои обширнейшие знания,
опыт и письма, приходившие в любое время дня и ночи, очень помогли мне. Спа
сибо, Карен!
Это мой первый опыт на поприще написания книг. В связи с этим не могу не
упомянуть Трейси Браун Коллинз (Tracy Brown Collins) — как руководитель про
екта она проявила себя с лучшей стороны. Спасибо тебе за проницательные лите
ратурные замечания и за то, что благодаря тебе вся наша команда успешно срабо
талась.
Дэйв Кристенсен — мой главный научный редактор — помог мне разобраться
со стилем изложения. Несколько раз я все же оплошал, но с его помощью многие
огрехи удалось ликвидировать. Кроме того, я обширно «одалживал» его коммен
тарии. Спасибо тебе, Дэйв, за недюжинные старания.
Я очень признателен Николь Леклерк (Nicole LeClerc) из Apress за граммати
ческую правку. Мы, программисты, далеко не всегда оказываемся на высоте, стал
киваясь со сложными синтаксическими конструкциями. Куда лучше мы ориен
тируемся в хитром и загадочном стиле кодирования. Николь восполнила мои
школьные пробелы в знаниях касательно орфографии, пунктуации и других ме
лочей, за счет которых эту книгу стало значительно проще читать.
Джессика Лендисман ( Jessica Landisman) провела долгие часы за аннотирова
нием, корректурой, составлением предложений и комментированием первых чер
новиков. Как опытному высококвалифицированному программисту ей нет рав
ных, и я действительно чрезвычайно благодарен за оказанную мне помощь.
Отдельное «мерси» Кэти Хейнс (Kathy Haynes), корпевшей над рукописью на
разных стадиях ее готовности, причем каждый раз после ее участия текст стано
вился неизмеримо лучше. Для меня она, уроженка Восточной Алабамы, — непре
рекаемый авторитет по диалекту американского Юга.
Îò èçäàòåëüñòâà
19
Все восторги по поводу графического оформления этой книги прошу перена
правлять Мелани Уэллс — замечательной художнице, работающей с самыми раз
ными материалами. У нее настоящий талант на выражение мыслей в визуальных
образах. Благодаря тебе, Мелани, коты вышли — круче некуда!
Наконец, я глубоко признателен своему отцу Джулиусу Рейнуотеру, набро
савшему кое какие из иллюстраций, ныне украшающие страницы этой книги. Ин
женер, предприниматель, замечательный отец, несомненный образец для подра
жания, обладатель многочисленных талантов — я перед тобой в неоплатном долгу.
Ну а без тебя, мама, я вообще ничего не смог бы сделать — даже написать эту книгу!
Îò èçäàòåëüñòâà
Ваши замечания, предложения и вопросы отправляйте по адресу электронной
почты comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
Все исходные тексты, приведенные в книге, вы можете найти по адресу http://
www.piter.com/download.
Подробную информацию о наших книгах вы найдете на веб сайте издатель
ства: http://www.piter.com.
Ââåäåíèå
Правды нет — о ней нам только рассказывают.
Анонимный автор с Юга
В этой книге я намерен рассмотреть весь комплекс задач, стоящих перед руково
дителем. Мужайтесь: решить эти задачи вполне реально, что бы вам ни говорили.
От вас требуется выстроить стройную систему мышления, эдакий гештальт. Что
такое «гештальт»? Согласно словарю Вебстера, это «структура со свойствами,
которые невозможно получить путем простого сложения ее элементов». Если пе
ревести это определение на язык объектно ориентированного программирования,
которым, полагаю, вы владеете лучше, чем стилем изложения Вебстера, получит
ся следующее: вашей мысленной архитектуре предстоит пройти серьезные пре
образования. Унаследовав навыки менеджера, вы должны будете перегрузить ти
пичные параметры мышления новыми типами и значениями — то есть, грубо
говоря, испытать полиморфизм собственного характера. За счет этого вы инкап
сулируете в своем программистском мозгу совершенно новый вид искусства —
искусство лидерства и руководства. Между руководством и лидерством просле
живаются существенные различия. Нужно то и другое, но лидерство все же имеет
приоритет — хотя крепкие руководящие навыки, естественно, помогают брать
новые высоты в роли лидера.
Своевременность производства и качество программных продуктов вашей ком
пании — теперь в ваших руках, и смею надеяться, что моя книга внесет некоторое
разнообразие в вашу деятельность. Нельзя же, в конце концов, проводить все ра
бочие дни совершенно одинаково!
Ñòðóêòóðà êíèãè
Посмотрим, какие сведения можно почерпнуть из составивших книгу глав.
Глава 1. Как привыкнуть к роли руководителя.
Для развития лидерских качеств нужны новые приемы — навыков, наработан
ных в бытность программистом, вам не хватит. В этой главе мы поговорим о том,
как адаптироваться к новой должности. Для этого я составил перечень наибо
лее распространенных личностных типов программистов, которые, естествен
но, оказывают то или иное влияние на способность управлять процессом раз
Ñòðóêòóðà êíèãè
21
работки и направлять его по заданному курсу. Вам надлежит осознать порази
тельную вариативность характеров подчиненных, попытаться проанализиро
вать их личные качества и найти к ним индивидуальные подходы. В конце кон
цов, вы же главный — что ж тут плохого?
Глава 2. Как руководить собой.
Здесь вам придется добраться до глубин своего сознания (не бойтесь — это не
так страшно) и самолично усвоить принципы руководства. Если вы не научи&
тесь управлять собой, занять лидерскую позицию среди коллег не получится.
Как говорил Уинстон Черчилль: «Чем пристальнее мы вглядываемся в про
шлое, тем проницательнее становимся, предсказывая будущее». Этот афоризм
рекомендую применить к вопросам самоанализа.
Глава 3. Как вести стаю за собой.
Лидерская роль предполагает приобретение новых навыков вдобавок к навы
кам чисто программистским. В этой главе дается обзор основных областей
деятельности лидера, на которые следует обратить особое внимание. В про
тивном случае вы рискуете, поддавшись внешним влияниям, пойти в невер
ном направлении, а сотрудники группы, подобно испуганным котам, от вас раз
бегутся. Мне совершенно не хочется, чтобы вы, как говаривал лорд Байрон,
оказались среди тех «немногих, чьи души всплывают после крушения надежд».
Глава 4. Как организовать успех.
Здесь мы прервем на некоторое время дискуссию о взаимоотношениях с окружа
ющими. Повысив уровень личностной организации, вы сможете взять новые
высоты по административной части. Кроме того, я советую вам изучить органи
зационную структуру своей компании и изыскать способы повышения эффек
тивности работы. Таким способом вы сможете выделить время на развитие ли
дерских качеств — иначе говоря, на выполнение своих основных обязанностей.
Глава 5. Как вести совещания.
В бытность программистом вы, вероятно, привыкли не советоваться ни с кем,
кроме самого себя. Теперь эту ситуацию придется менять. Никаких более со
вещаний во время утреннего бритья и любования на красавца в зеркале! Вам
предстоит обсуждать дальнейшие действия с себе подобными (разве что не
такими симпатичными, как вы) и, что гораздо страшнее, с людьми, которые,
как это ни странно, не зарабатывают на жизнь кодированием! В роли лидера
на совещаниях от вас потребуется терпение. Не отчаивайтесь и не забывайте
слова Леонардо да Винчи: «Нетерпеливость — мать глупости».
Глава 6. Философия и методы технического лидера.
В этой главе я рассмотрю некоторые технические принципы и их философ
ские обоснования. Одно дело принимать технические решения применитель
но к собственному кодовому заданию, и совсем другое — делать это за весь от
дел. Вполне возможно, что вы успели взойти на экспертный уровень в области
технологии, но это не отменяет необходимости анализа последствий приня
тия технических решений в корпоративном масштабе. Здесь мы обговорим во
просы архитектуры, проектирования и критических обзоров кода.
22 Ââåäåíèå
Глава 7. Закат лидера.
Все руководители (не только вы, но и ваше начальство) подвержены влиянию
упадочных стратегий лидерства, и иногда мы, к сожалению, этому влиянию
действительно поддаемся. Некоторые стили руководства не допускают кон
структивного лидерства, а значит, их следует избегать. Здесь я опишу возмож
ные варианты деградации лидерских качеств вследствие принятия неверной
стратегии и попутно предложу способы выхода из кризиса.
Глава 8. Восход лидера.
Подобно программным продуктам, которые конструируются на основе надеж
ной архитектуры, лидерские качества культивируются на основе присущих ли
деру черт характера. В этой главе я попытаюсь свести все аспекты лидерства
воедино. Если перефразировать Эмерсона, «многословие — бедствие для ав
торов, поощряемое издателями, читателями и книготорговцами». Что важнее,
здесь я излагаю базовые принципы успешного лидерства и демонстрирую ме
тоды их настройки как необходимое условие профессиональности руковод
ства.
Глава 9. Как ужиться с начальством.
Обратите внимание: глава называется «Как ужиться с начальством», а не «Как
руководить начальством», — последнее просто не представляется возможным.
Тем не менее налаживать отношения с теми сотрудниками, которым вы подот
четны, следует не менее тщательно, чем с собственными подчиненными. Су
бординация — это совсем не пустое слово. Здесь мы детально обговорим
методы формирования слаженной команды из двух человек: вас и вашего
босса.
Глава 10. Слова без песни.
В этой главе раскрываются самые разные, порой не связанные друг с другом,
темы, которые не всегда касаются ежедневных обязанностей лидера програм
мистов, но, тем не менее,представляют в контексте выпаса котов немалую важ
ность. Руководство распределенной группой разработчиков, оценка тенденций
развития методологий разработки программных средств и некоторые другие
темы рассмотрены в этой главе. С ее помощью, надеюсь, вам будет проще пре
вратить хаос в порядок и не сойти при этом с ума.
Послесловие. Снова в плавание…
В заключение я извергну из глубин сознания несколько мудрых наставлений —
по крайней мере, в нашем сдвинутом, но оттого не менее прекрасном мире раз
работки программного обеспечения мои слова, полагаю, сойдут за непреходя
щую мудрость.
Приложение А. Как ухаживать за живностью — электронный администратор.
В этом приложении речь пойдет о программе электронного администратора,
которая упоминается в главе 4. Мне совершенно не жалко делиться с вами ко
дом — надеюсь, что мои идеи не совсем бесполезны, и с их помощью вы сможете
Ñòðóêòóðà êíèãè
23
доработать решение под себя. Любой обладатель этой книги, написав секрет
ное слово, сможет скопировать код с сайта книги. Впоследствии, по мере мате
риализации моих идей в коде, у вас появится возможность оценить сте
пень их полезности.
Приложение Б. Как дать скотине в глаз — критический обзор кода электрон)
ного администратора.
Основной предмет обсуждения здесь — способы практического применения
принципов критического обзора кода, рассматриваемых в главе 6, к програм
ме, описанной в главе 4 и приложении А. Хотя мне приходится оценивать соб
ственный код, я стараюсь соблюдать объективность, указывая на его достоин
ства и недостатки. Тем самым я намерен продемонстрировать вам, как в реальных
условиях осуществляются функции кодового полицейского.
Библиография. Ресурсы для специалистов по выпасу котов.
В библиографии фигурируют все работы, на которые по мере изложения мате
риала я счел нужным сослаться, а также несколько других, заслуживающих
внимания с вашей стороны. Некоторым участникам нашей лидерской гонки
удалось вырваться далеко вперед, и я намерен вас с ними познакомить.
Алфавитный указатель.
Вы знаете, для чего нужна эта штука. Сюда можно заглянуть в поисках отдель
ных понятий или имен, чтобы не читать книгу целиком. Примерно по тому же
принципу обучаются языкам программирования по справочникам. Они дают
представление о синтаксисе, но в отсутствие контекста весьма высока вероят
ность концептуальных ошибок.
По всему тексту разбросаны небольшие врезки под общим заголовком «Коша
чьи разборки». В них я рассказываю реальные истории из жизни руководителей
программистов, призванные поучать вас и освещать явно неудачную практику.
Эти врезки иллюстрируют многие из представленных в книге принципов. Имена,
места, языки программирования и типы приложений, конечно, изменены — с тем,
чтобы защитить невинных и скрыть виновных. Эти истории легко читаются, а са
мое главное, наглядно демонстрируют примеры неверных действий. Похоже, мы
действительно лучше всего учимся на собственных ошибках. Здесь же, рассказы
вая об ошибках, совершенных другими людьми, я пытаюсь уберечь вас от повто
рения их печального опыта. Вспомним Альбера Камю: «Глупы те, кто считает, что
пессимистические мысли порождают отчаяние». За счет законов физики мы спо
собны превратить отрицательный опыт в обнадеживающие перспективы — ины
ми словами, опыт окружающих должен подтолкнуть вас к движению в правиль
ном направлении.
Есть и другие врезки, в которых выделены основные положения текущего текста.
Такой вариант верстки поможет вам изрядно сэкономить — теперь вам не нужно
разоряться на желтый маркер и выделять ключевые моменты изложения. Хотя
нет: прибегайте к маркеру ровно столько раз, сколько потребуется. По моему, са
мое важное в том, что эта книга открывает простор для осмысления ваших рабо
чих функций. Чем больше полезного вы в ней найдете, тем лучше — и мне и вам.
24 Ââåäåíèå
Êîìó è çà÷åì ñòîèò ïðî÷åñòü ýòó êíèãó
От чтения этой книги выиграют программисты, превратившиеся в менеджеров,
руководителей групп и, если вам по душе более высокие посты, директоров
по разработке программного обеспечения. Если вы руководите относительно не
большой группой программистов (состоящей, скажем, из четырех–семи человек),
работаете в мелкой или средней компании, заняты разработкой нескольких про
ектов одновременно — значит, вы выбрали издание правильно. Если же вы, ска
жем, собираетесь за 12 месяцев построить очередную глобальную систему бро
нирования авиабилетов, а в вашем подчинении 100 программистов, вероятно, эта
книга не будет соответствовать вашему размаху. В таком случае вам лучше за
щитить две магистерские диссертации: по управлению проектами и по психоло
гии. Удачи.
Если вы руководите программистами — именно руководите — и чувствуете,
что лидерство подменяется простым манипулированием проектами и людьми, вам
нужна помощь. Моя книга вам поможет.
Быть может, вы — опытный менеджер, желающий пересмотреть свои принци
пы лидерства. Тогда эта книга опять же для вас.
Не исключаю, что вы наконец таки получили повышение, на которое давно
рассчитывали или которого, наоборот, опасались. Итак, многолетние занятия по
написанию интеллектуального кода и конструированию выдающихся программ
принесли свои плоды. Начальство посчитало вас подходящим кандидатом на роль
руководителя программистов. Вероятно, в вас несколько меньше лунатизма, чем
в коллегах. Маловероятно, но все же возможно, что вы привыкли носить сорочки
с воротничками, и это обстоятельство сыграло вам на руку. Или кто то уволился.
Как бы там ни было, добро пожаловать в стройные ряды руководителей групп
программистов. Моя книга окажется в такой ситуации весьма кстати.
Вне зависимости от возраста, пола и социального статуса эта книга поможет
вам укрепить свои позиции в роли лидера программистов. Она довольно компакт
на, и материал достаточно легко укладывается в голове. Стоя в книжном магази
не и раздумывая, что же купить, задайте себе один простой вопрос: «Нужно ли
мне совершенствовать свои лидерские навыки?» Полагаю, вы ответите: «Да», —
а значит, моя книга окажется для вас небесполезной.
Ñòèëü è ïîçèöèÿ
Литература по менеджменту изобилует различного рода предложениями, реко
мендациями и научно подтвержденными методиками решения задач при помощи
других людей. В конце концов, именно в этом суть менеджмента: делегируя за
дания подчиненным, вы должны обеспечить мотивацию и проконтролировать
(в лучшем смысле слова) выполнение этих заданий ради достижения общей для
всей компании цели. Эта книга — отнюдь не очередной фолиант по дисциплине
«менеджмент». Скорее, это выраженная в словах концепция, согласно которой
для создания первоклассного программного обеспечения требуется мастерство,
а оно нарабатывается преимущественно с опытом. Именно из опыта — от этого
верного и преданного учителя — я почерпнул те идеи, которые здесь излагаю.
Ñòèëü è ïîçèöèÿ
25
Несомненно, что в моей работе фигурируют принципы, сформулированные в свое
время в академической среде. Поскольку, скорее всего, чтением вы занимаетесь
в перерывах между телефонными звонками и визитами в соседние комнаты к под
чиненным программистам, я постарался излагать материал кратко, в позитивном
тоне и с юмором — чтобы хоть как то развлечь вас посреди рабочего дня1.
В большинстве случаев я употребляю местоимения в мужском роде. Впрочем,
примечание в начале главы 9, надеюсь, прояснит для вас мою позицию в этом де
ликатном вопросе. Никаких предпочтений я здесь не высказываю — мне кажется,
лучше вникать в суть, чем заострять внимание на таких вещах.
В этом своем труде я концентрируюсь на двух основных областях руководства
программистами: людях и процессах. Из них люди, разумеется, важнее. При на
личии хорошей команды разрабатывать прекрасные программные продукты бо
лее чем возможно — даже несмотря на недостатки бизнес требований. А стоит
только подогнать требования, и в сотрудничестве с высококлассными специалис
тами вы сможете докодироваться хоть до Луны!
1
Мои шутки, по большей части размещаются в сносках, так что они не будут вас отрывать от основной
мысли. Ну вот, например: что значит «обратная совместимость»? Это значит, что новая операцион
ная система с тем же успехом, что и старая, может грохнуть все ваши программы.
Гл а в а
1
Êàê ïðèâûêíóòü ê ðîëè
ðóêîâîäèòåëÿ
Приступая к новым для нас обязанностям, мы всегда,
с одной стороны, питаем большие надежды, а с другой —
испытываем определенный страх неудачи. Как сформи
ровавшийся программист вы, конечно, успели приоб
рести опыт участия в проектах и работы в компаниях.
Теперь, получив должность руководителя группы про
граммистов, вы столкнулись с новой и, наверное, слегка
обескураживающей задачей. Чтобы преуспеть в неизве
стной доселе роли в процессе разработки программно
го обеспечения, вы должны как можно быстрее пройти
путь от программиста до руководителя. При этом вам
придется приспособиться к новым общественным усло
виям и новым механизмам взаимодействия — как с людь
ми, так и с процессами.
Как известно, совершить рывок чистой физиологии
к одухотворенному состоянию человеку помогла адаптация — ведущая сила био
логической эволюции. Этот процесс продолжался многие миллионы лет, но ре
зультат налицо — люди говорят на разных языках и оперируют абстрактными по
нятиями вроде компьютерных программ. Так как же мы до этого докатились?
Вообще то этот вопрос лучше задать биологу, но из содержания этой книги вы
убедитесь, что адаптация значительно упрощает задачи, стоящие перед руково
дителями программистов.
Речь в этой главе пойдет о людях. Мы поговорим о самом что ни на есть чело
веческом занятии — написании кода. В частности, мы разберемся в психологии
людей, посвящающих себя этому замечательному занятию. Чем лучше вы знаете
людей, которыми вам предстоит руководить, тем выше шансы на успех. Принци
пов и методик руководства программистами сегодня развелось великое множе
ство. Каждое поколение руководителей, естественно, отталкивается от собственно
го опыта и устраивает свою деятельность исходя из известных стилей руководства
и менеджмента. Лично я принадлежу к тому поколению, которое привыкло ору
довать логарифмическими линейками и перфокартами, и, конечно, это обстоя
Ïðàâäà ëè, ÷òî íàñòîÿùèå ðóêîâîäèòåëè õîäÿò â ÷åðíîì?
27
тельство накладывает некоторый отпечаток на мои рассуждения. Тем не менее,
проработав много лет с программистами значительно моложе себя, я понял, что
подходы, свойственные моему поколению, отнюдь не уникальны. Не раз сталкива
ясь с трудными задачами руководителя, я старался привыкать к новым направлени
ям бизнеса, к технологическим изменениям, да и просто боролся с собственным
упрямством. Этим своим опытом я намерен поделиться с вами, и очень хочется
надеяться, что вместе мы проведем замечательное исследование этого вопроса.
Ïðàâäà ëè, ÷òî íàñòîÿùèå ðóêîâîäèòåëè
õîäÿò â ÷åðíîì?
Некоторые — ходят. Иные даже носят на голове хвосты (хотя это, конечно, зависит
от того, сколько у них осталось волос). Так они пытаются повысить свой авторитет
в глазах подчиненных им придурков или «ботаников» — выберите тот эпитет, ко
торый вам больше нравится. Вполне возможно, вам не нравятся оба варианта, а се
бя вы ощущаете руководителем современного типа, организующим подобных вам
специалистов, которые искренне считают программирование пищей для ума. Что
я хочу сказать? Стереотипы (в том числе упомянутые в заголовке раздела) не сле
дует воспринимать слишком серьезно. О чем действительно стоит задуматься, так
это о личных взаимоотношениях с программистами и своем месте среди них. Став
руководителем, вы уже не имеете права вести себя так, как вели, будучи одним из
них. Кроме того, ваше положение шефа в процессе разработки программных про
дуктов иногда оказывается очень кстати. Как кто то когда то сказал: «Дайте мне
длинный рычаг, и я поверну Землю». Руководство — это как раз такой рычаг.
Вполне допускаю, что мои пассажи насчет несущественности имиджа вас не
убедили. Знаете, я сам довольно долго подходил к мысли о том, что мои внешние
атрибуты не обязательно отражают мою внутреннюю сущность. Мне до сих пор
нравится стиль «ботаника», но теперь я знаю, что для руководства моей группой
этого совершенно недостаточно. Иной руководитель чуть ли не полностью посвя
щает себя убеждению своих подчиненных в том, что он до сих пор один из них. Но
так ли это важно? Вспомните фильм «Сеть» (The Net). Сетевые приятели его глав
ной героини Анжелы (в исполнении Сандры Баллок) признали ее единомышлен
ницей и с готовностью приняли в свой странноватый круг общения. Только вот
в конце концов выяснилось, что ничего особо замечательного в этом кругу нет.
Отсюда урок: образ человека не может быть поверхностным. Что действительно
имеет значение, так это характер. Почему стандартные методики менеджмента
так часто на практике оказываются несостоятельными? Да просто потому, что
их последователи, вместо того чтобы выработать собственный индивидуальный
стиль, забивают методиками свои головы и действуют по ним как по шаблону.
Íàñêîëüêî âàæíî áûòü êðóòûì?
Итак, если мы заговорили в таком серьезном тоне, стоит ли все таки постоян
но ходить в черном и эксплуатировать стереотипы, которые, по вашему мне
нию, определяют уровень руководителя программистов? Чтобы оценить, на
сколько вы крутой, рекомендую пройти тест (см. ниже). Кстати, имейте в виду,
28
Ãëàâà 1 • Êàê ïðèâûêíóòü ê ðîëè ðóêîâîäèòåëÿ
что некоторые предпочитают термину «крутой» слово «нинджитсу»1, но я при
держиваюсь традиционных понятий.
Не забывайте, что моя книга предполагает некоторую работу над собой, — так
что не слишком расслабляйтесь. Неожиданные проверки не являются прерогати
вой старых и противных университетских профессоров — в реальной жизни они
подстерегают нас постоянно.
ÍÀÑÊÎËÜÊÎ ÂÛ ÊÐÓÒÎÉ?
Выберите один или несколько вариантов ответов на следующие вопросы.
1. «Хакер» — это тот, кто:
а) вырубает мебель топором;
б) не теоретизирует, а увлеченно программирует;
в) удовлетворяет свои интеллектуальные амбиции, творчески преодолевая или об
ходя препятствия;
г) руководствуясь злым умыслом, пытается похитить секретную информацию;
д) персонаж, сыгранный Анжелиной Джоли.
2. «Взломщик» — это:
а) человек, который взламывает системы безопасности компьютеров;
б) белый парень с Юга, вроде вашего автора;
в) нечто, еще более неуловимое, чем cookie (см. вопрос 6);
г) латентный хакер.
3. «Фрикинг» — это:
а) искусство и техника взлома телефонных сетей;
б) старый «ботаник», строящий из себя крутого.
4. «Пинг» — это:
а) отправка интернет пакетов;
б) писк ультразвукового прибора;
в) начальная часть названия игры «пинг понг»;
г) много счастья, и все сразу.
5. «Червь» — это:
а) оптический диск с однократной записью и многократным считыванием;
б) программа вирус, разрушающая данные в памяти или на диске;
в) двусторонне симметричное беспозвоночное.
6. «Cookie» — это:
а) маркер доступа, который передают друг другу взаимодействующие программы;
б) нечто, ставшее известным благодаря Амосу;
в) нечто, в чем хранятся (а иногда — анализируются) данные о поведении пользова
телей при посещении ими веб страниц.
1
Вы ведь знаете, что такое «ниндзя», правда? Это слово обозначает исключительность. Получается сво
его рода «черный пояс в программировании».
Ïðàâäà ëè, ÷òî íàñòîÿùèå ðóêîâîäèòåëè õîäÿò â ÷åðíîì?
29
Ну как, справились? Однажды мне пришлось читать лекцию по компьютер
ной безопасности студентам, имевшим к программированию весьма отдаленное
отношение. В тот момент я преследовал единственную цель — составить характе
ристику людей, которые, во первых, занимаются хакерством, во вторых, защи
щают компьютерные системы от потенциальных угроз. Они не слишком хорошо
справились с заданием — держу пари, у вас получилось значительно лучше. Дело
в том, что все варианты ответов на все вопросы правильны1 — ну разве что вари
ант б ответа на вопрос 3 я выдумал. Но на самом деле этот тест успешно подтвер
ждает то обстоятельство, что традиционно программистов приписывают к опре
деленной субкультуре. Иногда ее называют (да не обидятся на меня специалисты)
«хакерской» культурой (хотите убедиться? взгляните на варианты ответов на во
прос 1 еще раз — они довольно забавны, не правда ли?). Сегодня стереотипы, свя
занные с хакерством, понемногу уходят. Даже начинающий программист в сегод
няшних условиях — это, как правило, выпускник колледжа или университета, да
еще к тому же обладатель магистерского диплома по экономике и управлению.
В то же время в каждой компании своя культура, и группа, которой вы руководи
те, — не исключение. Она в целом не менее уникальна, чем каждый из работающих
в ней специалистов. Вне зависимости от определения культуры, она в любом слу
чае совпадает с контекстом ваших обязанностей как руководителя программистов.
Стоит хотя бы немного разобраться в культуре ваших подчиненных (в частности,
в том, как они мыслят и выстраивают свое взаимодействие), и качество ваших
отношений, равно как и эффективность исполняемых вами руководящих функ
ций, сразу возрастет. Так что, если очень хочется, вы, конечно, можете носить чер
ную футболку с таинственным посланием на груди, но имейте в виду, что, под
страиваясь под стереотип руководителя и всемерно подкрепляя его собственным
примером, вы сознательно выбираете далеко не самый эффективный стиль уп
равления. Значительно более эффективным механизмам руководства как раз и по
священа эта глава.
Ñòåðåîòèïû, ñâÿçàííûå ñ õàêåðñòâîì, ïîíåìíîãó óõîäÿò. Äàæå íà÷èíàþùèé ïðîãðàììèñò â ñåãîäíÿøíèõ óñëîâèÿõ — ýòî, êàê ïðàâèëî, âûïóñêíèê êîëëåäæà èëè
óíèâåðñèòåòà, äà åùå ê òîìó æå îáëàäàòåëü ìàãèñòåðñêîãî äèïëîìà ïî ýêîíîìèêå
è óïðàâëåíèþ.
Ìàëî áûòü êðóòûì — ñìîòðè â îáà!
Конечно, если вы сами отъявленный хакер, проблем по части общения с программис
тами у вас не возникнет. Тем не менее возьму на себя смелость вас предостеречь:
становясь руководителями, даже самые крутые программисты не всегда идеально
справляются со своими новыми обязанностями. У них возникает непреодолимое же
лание самим работать над проектами, которые, по идее, нужно делегировать под
чиненным. Они тратят уйму времени на обзоры кода, хотя на это хватит и часа.
Они пытаются вылизать все комментарии и отступы. Иногда они бросают попыт
ки объяснить окружающим, что они от этих окружающих хотят, и пытаются все
1
Большинство этих терминов разъясняются в издании The New Hacker’s Dictionary, Third Edition,
by Eric S. Raymond (The MIT Press, 1998).
30
Ãëàâà 1 • Êàê ïðèâûêíóòü ê ðîëè ðóêîâîäèòåëÿ
делать сами. Я хочу, чтобы вы меня правильно поняли: вы действительно должны
держать в голове как можно больше подробностей, касающихся разработки кода,
за который несете ответственность, но также вы должны уметь мыслить глобаль
но, чего, к сожалению, программисты менеджеры зачастую делать не умеют.
Âû äîëæíû äåðæàòü â ãîëîâå êàê ìîæíî áîëüøå ïîäðîáíîñòåé, êàñàþùèõñÿ ðàçðàáîòêè êîäà, çà êîòîðûé íåñåòå îòâåòñòâåííîñòü, íî òàêæå âû äîëæíû óìåòü
ìûñëèòü ãëîáàëüíî, ÷åãî, ê ñîæàëåíèþ, ïðîãðàììèñòû-ìåíåäæåðû çà÷àñòóþ äåëàòü
íå óìåþò.
Бывает и другая крайность. Некоторые менеджеры днем руководят, а ночью
пишут код, — как вы понимаете, ни на что другое у них не остается времени. В та
ком случае кодирование воспринимается как главная ценность в жизни, а руко
водство — как неприятная обязанность. Такая схема, в принципе, срабатывает, но
лишь до тех пор, пока не пропадает всякое желание работать. С моей точки зре
ния, любой профессиональный руководитель программистов обязан лелеять в себе
страсть к работе, не давать этой страсти исчезнуть. В этой и нескольких следую
щих главах мы рассмотрим ряд приемов, к которым менеджерам рекомендуется
обращаться, чтобы гармонизировать свою работу и в то же время не потерять же
лания трудиться. Один из таких приемов, позволяющий выделять время на вы
полнение руководящих функций, — делегирование. Поскольку делегирование есть
краеугольный камень всякой руководящей деятельности, ему полностью посвя
щена глава 8. Пока что вы должны четко уяснить себе, что делегирование невоз
можно без доверия к своим подчиненным. Для того чтобы построить доверитель
ные отношения, требуется некоторое время, но без них деятельность руководителя
обречена на провал. Не следует также забывать, что доверие предполагает взаим
ность. Мне очень хочется, чтобы, прочитав эту главу, вы научились доверять сво
ему интуитивному представлению о людях и путем некоторого анализа интел
лектуальных способностей и личностных характеристик своих программистов
смогли лучше в них разбираться.
Êàê ðóêîâîäèòü ÷îêíóòûìè, ÷óäàêîâàòûìè,
ñòðàííûìè è îáû÷íûìè ïðîãðàììèñòàìè
Не хотелось бы говорить об управлении программистами исключительно в иро
ническом тоне — хотя надо заметить, что этот вид деятельности кто то очень удач
но сравнил с выпасом котов, имея в виду, конечно, творческий характер людей,
занятых написанием кода. Проблема в том, что управлять этими иногда беспо
койными, неизменно нужными и, как правило, очень интересными сотрудниками
крайне трудно. Чем лучше вы будете их знать, тем совершеннее станет ваш стиль
руководства.
Если вы программист эстет, то выражение «быть на короткой ноге с кодом»
вам, конечно, известно, — код в таком случае оказывается чуть ли не второй нату
рой программиста. Элен Алман (Ellen Ullman) в своей книге «Close to the Machine»
выражается по этому поводу следующим образом.
«Один из моих знакомых руководителей проектами однажды сравнил процесс
управления программистами с выпасом котов. Он хотел сказать, что песики,
Êàê ðóêîâîäèòü ÷îêíóòûìè, ÷óäàêîâàòûìè, ñòðàííûìè è îáû÷íûìè ïðîãðàììèñòàìè
31
преданно заглядывающие в глаза, нам совершенно не нужны. Хорошего про
граммиста нужно ценить вместе со всеми его странностями. С другой сторо
ны, всех этих хороших программистов нужно каким то образом заставлять
двигаться в одном направлении»1.
Вот это «одно направление» отражает задачу, которая стоит перед каждым
руководителем проекта. Но ведь двух одинаковых программистов не существует,
и поэтому для каждой группы специалистов нужно выбрать индивидуальный
стиль руководства. Управлять программистами невозможно, если в них не разби
раться. Поэтому в следующем разделе я привожу перечень характерных «типов»
программистов и для каждого из них обозначаю отличительные характеристики.
Скорее всего, в них вы узнаете кого то из своих подчиненных. Поскольку наша
книга о котах, типы я называю «породами».
Êàêèå áûâàþò ïîðîäû ïðîãðàììèñòîâ
На что похож типичный программист? Можно ли построить шаблон программи
ста, хотя бы для того, чтобы понять мотивы его поведения? Может быть. В психо
логической науке существуют так называемые тесты оценки личности. Здесь тот
же принцип — достаточно разобрать отличительные черты программистов в от
дельности, и вы поймете, что многие из этих характеристик (даже если они на
первый взгляд кажутся взаимоисключающими) могут существовать в одном лице.
Я разделяю породы на три категории: распространенные, редкие и дворовые. Рас&
пространенные породы встречаются чаще всего. Редкие породы встречаются не
так часто, но иногда с ними все таки приходится сталкиваться. Дворовые породы,
как и следует из их названия, приносят не слишком много пользы, но знать о них
нужно, хотя бы в силу того, что они существуют. Если регулярно помогать двор
нягам повышать уровень знаний и, соответственно, преодолевать слабости, кото
рые они по определению привносят в процесс кодирования, они могут стать очень
достойными исполнителями.
Как я уже говорил, любой отдельно взятый человек может заключать в себе
характеристики сразу нескольких пород. Конечно, разобраться в таких людях
труднее, но это того стоит. У программистов на редкость богатое «наполнение».
Различия между породами и индивидуальные стили, характерные для каждой из
них, как мне кажется, нужно смаковать. Вполне возможно, что в следующий раз
вы столкнетесь с этими характеристиками, невзначай взглянув в зеркало.
Ðàñïðîñòðàíåííûå ïîðîäû
Ниже я перечисляю распространенные породы и их характеристики.
Архитектор2.Большинство руководителей обожают этот тип программистов —
и, действительно, любой такой деятель окажется ценным приобретением для
вашей команды. В основном архитекторы концентрируются на общей структу
ре кода. Они мыслят объектами, а их лучший друг — лист белой бумаги. Посвя
щая себя без остатка решению бизнес задач, они строят абстракции, проводят
1
Ellen Ullman, Close to the Machine (San Francisco: City Lights Books, 1997), p. 20.
2
Термином «архитектор» я в данном случае обозначаю один из личностных типов программистов и совер
шенно не имею в виду полноценного программного архитектора. О том, какую роль играет архитек
тура в общей схеме разработки, говорится в главе 6.
32
Ãëàâà 1 • Êàê ïðèâûêíóòü ê ðîëè ðóêîâîäèòåëÿ
анализ систем, после чего переходят к кодированию конкретных решений. Слов
нет — все это очень важные элементы программирования, но для комплексного
выполнения задач их еще не достаточно. Зачастую в высшей степени разумные
замыслы архитектора воплощаются в настолько общем и непонятном коде, что
людей, могущих разобраться в нем и продолжить начинание, просто не нахо
дится. Особи, способные генерировать удачную идею в голове (а лучше в Visio),
а затем выполнить ее полноценную конкретизацию в коде, становясь, таким
образом, единственными участниками процесса, встречаются очень редко. Не
достаток архитекторов в том, что их код часто служит только одному хозяину,
а исполнять чужие команды категорически отказывается1. Некоторые архитек
торы очень любят набросать структуру кода, с тем чтобы впоследствии пере
дать его на растерзание программистам более «низкой» квалификации. Иногда
в коде, написанном архитекторами, встречаются весьма странные конструк
ции — например, окна с сообщениями о системных прерываниях из за ошибок,
появляющиеся по той лишь причине, что код предполагалось исполнять в виде
библиотеки DLL на сервере.
Конструктивист. Конструктивисты получают удовольствие от процесса напи
сания кода и его результата. Стратегическим планированием они себя утруж
дают не всегда, но факт в том, что с написанием кода они справляются быстро,
причем в большинстве случаев ошибок в нем не обнаруживается даже на этапе
альфа тестирования. Код конструктивисты пишут по наитию, а потому их ло
гика не всегда понятна. У некоторых конструктивистов все в порядке и с ин
туицией, и со стратегическим планированием, поэтому код выступает естес
твенным продолжением хода их мыслей. Но стоит попросить конструктивиста
составить документацию, он обязательно ответит, что код самодокументируе
мый. Впрочем, если на него немного надавить и дать понять, что без документа
ции никуда не деться, он, вероятно, согласится ее составить — и сделает это
качественно. Кто спорит — код должен быть самодокументируемым, но следу
ет иметь в виду, что основное внимание программисты этого типа уделяют про
цессу создания кода, поэтому остальное для них не так уж важно. Количеству
сборок, которое конструктивист выдает за день, позавидует даже Microsoft.
Соответственно, их код обычно отличается надежностью. Однако же по мере
разбухания (а этот процесс неизбежен) надежность улетучивается, а конструк
тивист начинает судорожно искать новые, «заплаточные» решения — ведь для
него очень важно видеть результат и пребывать в уверенности в том, что он
справился с поставленной задачей. Конструктивист в сочетании с архитекто
ром имеют все шансы стать прекрасной командой. Если же вы умудритесь отыс
кать конструктивиста и архитектора в одном лице, считайте, что львиная доля
кадровых проблем решена.
Художник. На самом деле, искусства в написании кода не меньше, чем науки, —
не зря же университеты часто сводят оба направления в одной структуре и на
зывают ее как нибудь вроде «факультета свободных искусств и наук». Не будь
в программировании художественного аспекта, может быть, оно приносило бы
1
А ведь это очень важно — согласно авторитетным оценкам, по меньшей мере 70 % стоимости программ
ного обеспечения приходится на сопровождение. См. William H. Brown et al, AntiPatterns: Refacto
toring Software, Architectures, and Projects in Crisis (New York: John Wiley & Sons, 1998), p. 121.
Êàê ðóêîâîäèòü ÷îêíóòûìè, ÷óäàêîâàòûìè, ñòðàííûìè è îáû÷íûìè ïðîãðàììèñòàìè
33
нам гораздо меньше морального удовлетворения. Художник как тип програм
миста сконцентрирован на процессе создания кода — переносе коммерческих
требований на программные конструкции и искусном сведении объектов пользо
вательского интерфейса в одну изящную структуру. Работая с компонентами
без видимого интерфейса, художники обнаруживают тенденцию к правильной
и логичной организации. Недостаток художника в том, что очень часто он затяги
вает кодирование, пытаясь выяснить, сколько знаков равенства можно устано
вить в одной строке, не нарушив при этом правильность результата булева опе
ратора. С другой стороны, если программист не культивирует в себе художника,
результаты его деятельности зачастую отрываются от реальности, теряют «изю
минку». Стоит отнять у художника все его отличительные качества, и в резуль
тате получится мина замедленного действия, которая обязательно взорвется
под пальцами пользователей. Разделяя некоторые характеристики конструк
тивистов и архитекторов, художники активно претендуют на собственный стиль.
Инженер. Инженеры вам понравятся. Эти ребята имеют обыкновение скупать
все возможные средства сторонних производителей, писать десятки COM
объектов и сводить их воедино, так что они прекрасно работают в версии 1.
Присущая им тяга к усложнению проявляется лишь тогда, когда речь заходит
о версии 1.1. Программирование часто приравнивают к инженерии программ
ных средств — и, действительно, многие стороны нашей профессии подчиня
ются этой методологии. Но давать инженерам карт бланш нельзя. В программ
ных продуктах, выстроенных инженерными методами, нет ничего предосуди
тельного — в конце концов, согласно классическому определению, инженерия
есть научные принципы, задействованные при решении программных задач.
Нам нужны программисты, которые не боятся сложностей, но те из них, кото
рые любят усложнять все и вся, представляют серьезную опасность. Поймите
меня правильно: я совершенно не собираюсь бросать камень в огород инжене
ров. В конце концов, я сам многие годы трудился над аппаратным обеспечени
ем компьютеров. Но аппаратная направленность иногда входит в противоре
чие с теми аспектами программного обеспечения, благодаря которым оно стано
вится программируемым (то есть гибким и многократно используемым). Лю
бое аппаратное устройство обычно служит одной, четко определенной цели,
а для программного обеспечения такой подход неприемлем.
Ученый. Ученые — это мальчики и девочки, которые считают себя последова
телями Бэббиджа и Тьюринга. Никогда в жизни они не вставят в код инструк
цию GoTo. Отодвигая художественную составляющую программирования на
второй план, они делают все в соответствии с фундаментальными принципами
компьютерных наук. И как раз в этом обычно и заключается проблема. В то
время как они одержимы безупречностью своих трудов, ваша главная забота
как руководителя состоит в том, чтобы разработать доброкачественный про
дукт и сдать его к установленному сроку. Программисты такого типа на самом
деле очень полезны, и когда речь заходит об особо трудных задачах кодирова
ния, их идеям нет цены. Вы просто должны следить за тем, чтобы их педантич
ность не перевесила практические соображения. У инженеров и ученых есть
одна общая черта — те и другие очень любят все усложнять. Иногда даже кажет
ся, что они все поклоняются богу сложности (и даже приносят ему жертвы!).
34
Ãëàâà 1 • Êàê ïðèâûêíóòü ê ðîëè ðóêîâîäèòåëÿ
Отдавая должную оценку глубочайшим познаниям ученых и по мере необхо
димости обращаясь к ним, руководитель не должен допускать их полновластия
в вопросах написания кода — иначе они сделают его слишком сложным.
Лихач. Лихачи — это те товарищи, которые делают все быстро. Забывая о ком
ментариях, отступах и соглашениях об именовании переменных, они, тем не
менее, умудряются достигать результата очень оперативно — и, что самое заме
чательное, вплоть до первой неперехваченной ошибки их продукты вполне
успешно работают. Иногда такое поведение характерно для молодых програм
мистов, горящих желанием впечатлить вас, — они опрометчиво считают, что
оперативность в достижении результата в полной мере соответствует вашим
ожиданиям. Признайтесь: мы часто сами выстраиваем у них столь ложное пред
ставление, а значит, веди мы себя по другому, никаких лихачей не было бы.
Наши собственные начальники устраивают совещания, на которых устанавли
вают контрольные сроки, а потом сообщают их нам. Как мы добьемся выполне
ния поставленных временных задач — это уже наша проблема. Вспомните, как
часто идут разговоры о бессмысленности установления крайних сроков коди
рования до окончательного выяснения всех требований! Так вот, вам придется
к этому привыкнуть. К сожалению, такова реальность — пользователи и рыноч
ные соображения часто принуждают нас сперва давать обещания, а потом уже
приступать к планированию. Именно по этой причине вы читаете мою книгу —
вам нужны советы по поводу того, как выжить в динамичном, жестоком и суро
вом мире разработки программных средств.
Ðåäêèå ïîðîäû
Далее я привожу список редких пород и их отличительных черт.
Волшебник1. Каким то загадочным образом те, кого я называю волшебниками,
регулярно решают самые трудные задачи программирования, причем идут та
кими путями, которые раньше никому и в голову не приходили. Более того —
волшебники делают все это вовремя, и иногда у них получаются вполне дос
тупные для понимания программы, которые даже можно сопровождать. Немного
волшебства в нашем деле не помешает. Но стоит распустить подобным деятелям
руки, и вскоре вы превратитесь из здравомыслящего руководителя работоспо
собной группы программистов в обычного подмастерье. Кроме того, если вы
будете слишком полагаться на волшебника, в один прекрасный день он вас разо
чарует — в конце концов, постоянно творить чудеса никому еще не удавалось.
Минималист. Несмотря на удивительно скромный объем кода, производимого
минималистами, код обычно оказывается очень функциональным. Каждая про
цедура умещается в редакторе кода на одном экране. Объекты стройны, вы
строены четко и недвусмысленно сообщают о своем назначении. Звучит непло
хо, не правда ли? В общем, да, только стоило бы учитывать мотивы такого
поведения. Ведь иногда они кроются в том, что человеку хочется побыстрее
разобраться с текущим проектом и перейти к следующему, который его больше
захватывает. Иногда (кстати говоря, эта характеристика распространяется и на
1
Некоторые предпочитают называть программиста этого типа «гуру» или «спецом». А мне больше нра
вится «волшебник».
Êàê ðóêîâîäèòü ÷îêíóòûìè, ÷óäàêîâàòûìè, ñòðàííûìè è îáû÷íûìè ïðîãðàììèñòàìè
35
архитекторов) минималисты, решив поставленную задачу, быстро теряют к ней
всякий интерес, и уж, конечно, при обнаружении в ходе альфа тестирования
каких либо проблем выказывают устойчивое нежелание их исправлять. Иног
да минималисты капризны и очень придирчиво выбирают область приложе
ния своих сил. С сопровождением кода дела у них обстоят хуже всех.
Аналогист. Ну ладно, ладно — слово «аналогист» я взял с потолка. Только не
подумайте, что это медсестра, которая делает наркоз перед операцией. Нет —
это программист, который не слишком силен в абстракциях, но прекрасно справ
ляется с аналогиями. Во время проектных совещаний аналогисты, постоянно
выдумывающие все новые и новые аналогии, способны свести с ума любого. Но
при этом нельзя не признать, что, как правило, они очень быстро схватывают
суть задачи и в результате создают удобный (в том числе и для сопровожде
ния) код. У некоторых аналогистов есть любимые аналогии, которые они норо
вят применить ко всем без исключения проблемам разработки программных
продуктов. Они воображают компоненты маховиками, а успешно справившись
со своей задачей, хвалятся тем, что их код «воспламеняется во всех цилинд
рах». Их аналогии всегда привязаны к осязаемым объектам, поскольку, как я уже
говорил, с абстрагированием дела у них обстоят неважно. Ну, в общем, вы меня
поняли. Посадите аналогиста вместе с архитектором, и если они сразу друг друга
не прикончат, скорее всего, у них получится превосходный продукт. Правда,
поскольку аналогисты не дружат с абстракцией, создавать объекты с четкими
межуровневыми интерфейсами у них получается не всегда. Дело в том, что воз
можность создания в достаточной мере абстрактного интерфейса объекта — это
одно из величайших преимуществ объектно ориентированного программиро
вания, и поэтому конкретное мышление иногда мешает успешно справляться
с поставленными задачами.
Трюкач. Трюкачи слишком увлекаются разными технологическими трюками.
Они постоянно осваивают разные новинки, но результат от этого не улучшается.
По правде говоря, всех нас в той или иной степени привлекают забавные техноло
гические приемы. Я вот, например, помню мой первый компьютер. Он был
аналоговым, и, поворачивая диски, я переключал ветви в предустановленном
аппаратном алгоритме. Эта штука была похожа на гипертрофированную лога
рифмическую линейку. В общем, я до сих пор люблю забавляться со всякими
высокотехнологичными штуковинами. Если вам приходится работать с трюка
чами, попытайтесь направить их увлечение игрушками на решение их перво
очередной задачи, а именно на производство бизнес решений. Если им удалось
втиснуть на экран, который, как предполагается, будет отображаться с разре
шением 800 × 600, 30 разных элементов пользовательского интерфейса, это еще
совершенно не означает, что они решили свою задачу в соответствии с реаль
ными потребностями пользователей1. Трюкачи, при всех их познаниях в техно
логии, часто не могут усвоить конечное назначение программы. Полагая, что
их функции ограничиваются забавами с разными инструментальными средства
ми, они отказываются учитывать те аспекты программирования, благодаря ко
торым мы не затрачиваем на сопровождение титанических усилий.
1
Вы тоже ненавидите пользователей?! Представляете, как было бы здорово писать программы толь
ко для программистов?
36
Ãëàâà 1 • Êàê ïðèâûêíóòü ê ðîëè ðóêîâîäèòåëÿ
Äâîðíÿãè
Остановимся теперь на дворовых породах и их отличительных чертах.
Разгильдяй. Что сказать о разгильдяях? Некоторые люди небрежны, и это про
является в коде, который они создают. Они не обращают внимания на такие ме
лочи, как правильное написание имен переменных и правила венгерской нотации.
Зачастую качественно выполнять свои обязанности им мешают проблемы лич
ного плана. Тому, как пишется эффективный код, их нужно учить. Они любят
начать с одного стиля, а через процедуру другую перейти к новому. Читать их
код очень утомительно — иногда поздними ночами его приходится переписывать,
поскольку иначе есть риск не успеть к сроку сдачи проекта. Если вы не справи
лись с задачей по их вине, прошу вас: отнеситесь к ним снисходительно. В кон
це концов, они просто отъявленные разгильдяи, которых лучше всего переса
дить в отдел бета тестирования. Хотя нет — так вы просто заморозите проблему,
в итоге она все равно может проявиться. Если разгильдяй действительно лю
бит писать код, при условии, что вы уделяете ему достаточно внимания, он имеет
шансы реабилитироваться. Всех, кому это не удается, нужно просто пнуть под
зад или познакомить с консультантом по трудоустройству.
Тормоз. Тормоз — это программист, который не знает, с чего начать. Он посто
янно ищет спецификацию (или ожидает, пока ему дадут), отчаянно надеясь,
что она станет для него отправной точкой. Нерешительность в чем то хороша,
поскольку в некоторых случаях она повышает качество кода. Однако иной раз
она свидетельствует о низкой квалификации программиста, который не хочет
лишних ошибок на этапе прогона. Предоставьте этим ущербным образец кода,
чтобы они могли разобраться, с чего начинать, и выбрать стиль, которого им
нужно будет придерживаться. Нерешительность часто характерна для неопыт
ных программистов, и, воспользовавшись некоторыми воспитательными мето
дами, вы можете наставить их на путь истинный. Кроме того, нерешительно
стью иногда страдают программисты, у которых по тем или иным причинам не
слишком впечатляющий послужной список. Ну, скажем, в прошлый раз их ре
зультаты разнесли в пух и прах, а теперь они хотят исправиться, но очень боят
ся наступить на те же грабли. Действительно, низкая самооценка часто проявля
ется в форме нерешительности. С такими типажами нужно проявлять терпение.
Помогите тормозу регулярно добиваться небольших успехов, и тогда все нала
дится. Наставничество (лучший, кстати говоря, способ перевоспитания нере
шительного программиста) рассматривается в главе 8. В ней я утверждаю, что
роль наставника — это одна из основных ролей руководителя программистов,
которая при должных вложениях обязательно окупится.
Любитель. Любители очень хотят стать настоящими программистами. Тщатель
но изучив какой нибудь инструмент написания макрокоманд, они возводят себя
в ранг хакеров. Единственная причина, по которой они бросают уютные места
в отделах поддержки пользователей и тестирования, заключается в том, что,по
их мнению, быть программистом — это очень круто. Да, мы, действительно,
крутые, но, по большому счету, это лишь побочное следствие нашей основной
деятельности. Любителям не хватает образования, но по мере их обучения вы
должны пристально за ними следить и лишь при условии определенных дости
жений с их стороны поручать им работу над критически важными приложениями.
Узнав на собственном опыте, как трудно заниматься программированием и какое
Êàê ðóêîâîäèòü ÷îêíóòûìè, ÷óäàêîâàòûìè, ñòðàííûìè è îáû÷íûìè ïðîãðàììèñòàìè
37
серьезное внимание к деталям требуется от программистов, любители часто разо
чаровываются в своем выборе. Они отказываются признавать превосходство
объектно ориентированных методов над процедурной парадигмой — и все пото
му, что нужное прозрение их еще не посетило. В защиту любителей вспомним за
мечательное высказывание: «любители построили ковчег, профессионалы постро
или ”Титаник“». На самом деле иногда свежий, незашоренный взгляд начи
нающего программиста очень помогает нам — старым брюзгливым технарям.
Профан. Программист профан — это тот, кого называют тупицей. Хуже всего,
когда профан не догадывается о своей тупости. Остерегайтесь таких людей.
Иногда они могут достаться вам в наследство от предыдущих руководителей,
но сами, я вас прошу, никогда их не нанимайте. У меня нет никаких предубеж
дений относительно умственно ущербных людей, но я твердо уверен, что в про
фессии, требующей постоянного самосовершенствования и обучения, таким не
место. Если человек невежда, но хочет стать лучше, — дайте ему шанс. Отправьте
его, например, в отдел тестирования — иногда не отличающиеся выдающимися
умственными способностями пользователи находят себя в отлове жучков1. Еще
одно соображение насчет глупости: на самом деле все мы постоянно страдаем
от несовершенства того, что находится между клавиатурой и стулом. Но, в кон
це концов, если бы для написания кода не требовались мозги, этим занимались
бы все без разбору, так ведь? Я советую не путать невежество с глупостью. Не
вежество исправимо, а с глупостью лучше просто не связываться. Если вы уна
следовали кадры, подобранные не программистом, вполне возможно, что среди
ваших подчиненных есть такие типажи. Руководители, имеющие весьма отда
ленное представление о технологии, иногда покупаются на необоснованные
заверения бездарных претендентов на место.
Эклектик. Можно сказать, что эклектики просто стряпают программные продук
ты. Представитель этой породы сочетает в себе качества инженера, разгильдяя
и не слишком талантливого художника, причем упомянутые ингредиенты нахо
дятся в чудовищной диспропорции. Результат их деятельности представляет
собой винегрет из стилей кодирования и подключаемых модулей при невероят
ной путанице в коде. Все это выглядит довольно привлекательно, но стоит лишь
попробовать кусочек, как наступят необратимые последствия. Отправьте такого
программисты на кулинарные курсы и обязательно проверьте, не скрывается
ли за внешней оболочкой талантливости банальный разгильдяй. В классическом
виде эта дворянская порода встречается довольно редко, а упомянул я ее по той
причине, что отдельные ее черты проявляются в стилях кодирования самых раз
ных типов программистов. Если они не считают нужным следовать корпоратив
ным стандартам, вам придется посвящать все рабочее время напряженным попыт
кам выяснить, что же они все таки имели в виду и как сопровождать их код.
Основным средством реабилитации эклектиков служит критика кода (см. главу 6).
Óìåíèå îáðàùàòüñÿ ñ ïðåäñòàâèòåëÿìè ðàçíûõ ïîðîä
Программисты — это в первую очередь люди. Поэтому в одном человеке могут быть
в большей или меньшей степени выражены все перечисленные характеристики.
Некоторые из них как будто исключают друг друга, но на самом деле это не так.
1
Лично я предпочитаю термину «жучок» (bug) словосочетания «программная аномалия» (program ano
maly) и «открытие недокументированной характеристики» (Undocumented Feature Offering, UFO).
38
Ãëàâà 1 • Êàê ïðèâûêíóòü ê ðîëè ðóêîâîäèòåëÿ
Все люди сотканы из противоречий, и ваши подчиненные — не исключение. От
вас как от человека, осуществляющего руководство этими чудесами природы, тре
буется понимание, умение мотивировать и, прежде всего, мудрость, которая нара
батывается только с опытом. Мнение о программистах нужно составлять по тем
граням их характера, которые ярче других сверкают в свете новых начинаний и ос
лепляющих вспышек проектов, приближающихся к сдаче.
Ìíåíèå î ïðîãðàììèñòàõ íóæíî ñîñòàâëÿòü ïî òåì ãðàíÿì èõ õàðàêòåðà, êîòîðûå
ÿð÷å äðóãèõ ñâåðêàþò â ñâåòå íîâûõ íà÷èíàíèé è îñëåïëÿþùèõ âñïûøåê ïðîåêòîâ,
ïðèáëèæàþùèõñÿ ê ñäà÷å.
Предположим, у вас есть счастливая возможность набрать сотрудников в свой
отдел с «чистого листа». Какие породы сочетаются удачнее? По моему, лучше все
го соблюдать баланс между архитекторами и конструктивистами. Эти две породы
привносят в процесс создания программных продуктов наиболее востребованные
навыки — первые мыслят стратегически, вторые прекрасно ориентируются в де
талях. К этому альянсу время от времени имеет смысл подключать художников.
К сожалению, скорее всего, подобрать группу из идеальных кандидатов не удаст
ся. Работать вам придется с тем, что есть. Потому успех вашего взаимодействия
с людьми, сочетающими в себе вышеупомянутые характеристики, зависит от ва
шей проницательности, терпения и умения быть для подчиненных наставником —
то есть от трех универсальных качеств руководителя.
Есть еще один тип личности, на который следует обращать особое внимание.
Я имею в виду программистов ковбоев. Этот тип плохо согласуется с перечислен
ными породами, а описывать его лучше в соответствии с тем мнением, которое ков
бой о себе формирует. Итак, программист ковбой обычно в совершенстве владеет
своим ремеслом, но при этом управлять им практически невозможно. Ковбои глубо
ко убеждены, что могут работать только над теми проектами, над которыми хотят,
делать это на собственных условиях, согласуясь исключительно с собственными пла
нами и обращаясь только к подходящим по их мнению средствам. Такой програм
мист — своеобразный волк одиночка (или, если придерживаться терминологии
этой книги, — кот, который гуляет сам по себе). В зависимости от того, что вам нужно,
и вашей готовности терпеть своеобразие их личности, ковбои могут творить либо
чудеса, либо хлам. С ковбоями надо держать ухо востро: они ни при каких обсто
ятельствах не станут частью вашей команды. Прибегать к их услугам стоит либо
в безвыходных ситуациях, либо если разрабатываемый проект должен радикаль
но отличаться от всех других, а сопровождать его будут сторонние специалисты.
Почему в программистах сочетаются все эти чрезвычайно занимательные лич
ностные характеристики? Мне кажется, связано это с тем, что сам характер дея
тельности разработчика программного обеспечения привлекает людей совершен
но определенного рода. В своем классическом труде «The Mythical Man Mouth»
Фредерик Брукс (Frederick Brooks)1 утверждает, что наше ремесло приносит лю
дям удовольствие пяти видов.
1. Радость созидания.
2. Радость созидания полезных для других людей продуктов.
1
Frederick P. Brooks, The Mythical Man Month: Essays on Software Engineering, Anniversary Edition (New
York: Addison Wesley, 1995), p. 230. Это действительно непреходящая классика. В нашей области очень
мало книг, которые переиздаются через 25 лет после появления, и это — одна из самых стоящих.
Êàê ðóêîâîäèòü ÷îêíóòûìè, ÷óäàêîâàòûìè, ñòðàííûìè è îáû÷íûìè ïðîãðàììèñòàìè
39
3. Привлекательность процесса упорядочивания головоломных объектов, состо
ящих из взаимосвязанных динамичных элементов.
4. Радость от постоянного обретения новых знаний и решения нестандартных
задач.
5. Интерес к работе с продуктами, созданными исключительно путем приложе
ния интеллектуальных усилий человека, которые, тем не менее, существуют,
развиваются и делают совершенно непередаваемые вещи.
Все эти факторы кажутся тем людям, которыми вы руководите, чрезвычайно
привлекательными. Разобравшись в их мотивации (да и в своей тоже), вы сможе
те серьезно усилить свои позиции как руководителя.
ÊÎØÀ×ÜÈ ÐÀÇÁÎÐÊÈ — ÑÎÐÅÂÍÎÂÀÍÈÅ
ÏÎ ØÈÏÅÍÈÞ È ÖÀÐÀÏÀÍÈÞ
Проектное совещание превратилось в словесную схватку между Джоном и Кевином. Мы
уже перешли к обсуждению регистрации пользователей в системе, а они все еще спори
ли насчет низкоуровневых подробностей методик конструирования. Дискуссия засто
порилась — ведь, несмотря на отсутствие четкого плана обсуждения, все мы были увере
ны в том, что поговорить есть о чем. Джон и Кевин спорили без перерыва. Дело в том,
что Джон (консультант) и Кевин (опытный сотрудник и талантливый программист)
руководствовались совершенно разными мотивами и планами относительно этого сове
щания. Каждый из них считал своим долгом доказать другому, что он умнее, и вопросы
проектирования системы их в тот момент не интересовали. А все потому, что Джона
назначили руководителем проекта — он занял должность, на которую очень хотел по
пасть Кевин. Нашего начальника на совещании не было, и ни одного желающего высту
пить в роли посредника не нашлось.
На следующий день в центре внимания опять оказались Джон и Кевин — они соба
чились за каждое проектное решение, и все остальные сотрудники отдела предпочитали
помалкивать. К концу второго дня мы сумели согласовать значительно меньше вопро
сов, чем планировались, а то, что нам удалось, оказалось результатом ожесточенной бой
ни между двумя воинственными котами — Джоном и Кевином. Остальная часть группы
чувствовала себя совершенно дезориентированной. Люди начали сомневаться, удастся
ли вообще закончить работу над системой. Значительно осложняло ситуацию то обсто
ятельство, что перед группой поставили задачу сделать систему как можно быстрее, ибо
та ее версия, которая в тот момент находилась на рынке, негативно сказывалась на репу
тации компании.
Этой короткой историей я хотел обозначить трудности, связанные с введением в одну
команду консультантов и программистов. Особенно их отношения осложняются в от
сутствие начальника. Вы могли бы справедливо поставить под сомнение разумность
выбора в качестве руководителя проекта консультанта. Кроме того, как видите, за не
имением четкого плана и механизма разрешения противоречий на проектном совещании
сотрудники просто убивают время, подрывая тем самым принцип «сначала проектиро
вание — потом кодирование». Развитие межличностных отношений в группе разработ
чиков подтверждает мою мысль о необходимости психологического анализа подчинен
ных для повышения качества руководства.
Конец этой истории довольно печален. Проект закрыли, а проектирование и кон
струирование продукта поручили группе разработчиков из другого отдела. Пропустив
шему основные «военные действия» руководителю отдела по возвращении пришлось
в течение нескольких дней с большими трудностями объяснять начальству, почему пос
ле всех обещаний и заверений, предшествовавших началу работу над проектом, разра
ботчики так и не сдвинулись с мертвой точки.
40
Ãëàâà 1 • Êàê ïðèâûêíóòü ê ðîëè ðóêîâîäèòåëÿ
Ñëàâà, ïî÷åò è äåíüãè
Любой сотрудник жаждет признания своей деятельности, хочет ощущать весо
мость своего вклада в общее дело. Быть оцененными по достоинству стремятся
и некомпетентные сотрудники — даже несмотря на то, что их вклад в деятельность
компании исключительно негативный. Все мы любим поразглагольствовать на
счет того, что создание кода для нас — это уже своего рода награда. Но хотелось
бы мне знать, сколько мы проработаем, если нам не будут за это платить. Но даже
если будут платить, и платить хорошо, мы в любом случае будем требовать при
знания со стороны наших товарищей и надеяться, что начальник между делом
похлопает нас по плечу. Настоящие кошки предпочитают спокойно дремать в углу,
не заботясь о том, кто и как на них смотрит; кошки программисты в этом отноше
нии, напротив, проявляют некоторый эксгибиционизм. Ярким подтверждением
того, что и программистам нужно признание, служит практика встраивания в код
своеобразных «пасхальных яиц» (хотя сегодня она считается несколько вульгар
ной). Вас, начальника, они воспринимают как зрителя, сидящего в переднем ряду,
и, конечно же, ожидают аплодисментов. Причем ожидают все — даже те, над ко
торыми впору начинать читать молитву1.
Расхваливать своих сотрудников — это, конечно, замечательно, но иной раз
стоит на секунду остановиться и поразмыслить, отрабатывают ли они те деньги,
которые получают. Ведь это входит в вашу задачу как руководителя. Если хотите
похвалить человека, сделайте это на виду у всех. Если считаете нужным покрити
ковать его, не выносите свои оценки на суд публики. Дело не просто в вежливос
ти — эти правила поведения важны в том смысле, что как похвала, так и порица
ние одного человека на самом деле оказывают грандиозное влияние на всю группу.
Поверьте мне, публичное унижение не способствует повышению продуктивнос
ти работы группы. Напротив, похвала, высказанная при всех, причем искренне
и по заслугам, способна творить чудеса. Не надо кричать о том, что ребята пре
красно поработали, выходя из комнаты для совещаний. Выберите такое время,
когда слова благодарности окажут наибольшее воздействие. Четко определитесь
с тем, за что вы хвалите человека, и обязательно сделайте так, чтобы сотрудники
группы это знали.
Ðàñõâàëèâàòü ñâîèõ ñîòðóäíèêîâ — ýòî, êîíå÷íî, çàìå÷àòåëüíî, íî èíîé ðàç ñòîèò
íà ñåêóíäó îñòàíîâèòüñÿ è ïîðàçìûñëèòü, îòðàáàòûâàþò ëè îíè òå äåíüãè, êîòîðûå
ïîëó÷àþò.
И еще немного о поощрении. Кто знает — может быть, у вас у самого такой
начальник, который никогда вам слова доброго не скажет. Тогда и вам будет не до
комплиментов подчиненным. Роль лидера предполагает стремление к успеху под
чиненной вам группы. Когда группа добивается успеха, вы ее хвалите. Кто же
хвалит вас? Иногда никто, хотя время от времени вы сами хотите получить от
начальника хлопок по плечу. Роль руководителя, которая предусматривает при
ложение некоторых усилий для улучшения репутации подчиненных, превратит
ся в сущий ад, стоит вам попытаться искать почестей для самого себя. Не стоит
1
Я имею в виду тех, кому пора готовиться к основательной порке.
Ñëàâà, ïî÷åò è äåíüãè
41
забывать, что любой руководитель должен оценивать свои успехи исключитель
но по тому, насколько эффективно работают его подчиненные.
Если вы выдвинулись в руководители из программистов, задача усложняется,
поскольку теперь вам придется принять ответственность за профессиональную
судьбу ваших друзей. Но не позволяйте дружбе мешать делам. Лучше используй
те ее как средство достижения общей цели. Я вас уверяю, что если вы, в конечном
итоге, все вместе добьетесь успеха, ни один из ваших подчиненных не осмелится
утверждать, что вы манипулируете дружескими отношениями.
Ìîòèâèðîâàíèå äåíüãàìè
Кажется, я уже поднимал денежный вопрос? Лучше было бы его как то обойти,
поскольку, как сказано в Библии, «…ответом всему — монеты»1. Согласно послед
нему статистическому исследованию, почасовая ставка программистов составля
ет от 30 до 150 долларов, причем большинство из них находится где то посереди
не этого спектра. Как определить, стоит ли платить вашим сотрудникам именно
столько, сколько вы им платите? Среди факторов, которые нужно учесть, — про
изводительность, опыт, результативность, своевременность исполнения задач, те
кущая средняя ставка, экономическая конъюнктура и корпоративные стандарты,
касающиеся оплаты труда сотрудников в области высоких технологий. Подбирая
новых сотрудников и повышая оплату старым, вы должны быть справедливым
и бережливым одновременно.
Справедливым и бережливым. Хм, это довольно трудно — можно поддаться со
блазну разбрасываться деньгами, как будто они растут на деревьях, опрометчиво по
лагая, что оплата повышает производительность. На самом деле здесь стоит хо
рошенько подумать, ведь сегодняшняя роскошь есть завтрашняя потребность. Деньги,
подобно власти, оказывают на человека самое что ни на есть деструктивное влия
ние. И не заставляйте меня цитировать еще одно известное высказывание из Но
вого Завета2. Так все таки, возвращаясь к теме, как соблюсти баланс в вопросах
денежных выплат? Представим себе весы правосудия. На одну чашу положим
справедливость, на другую — бережливость. Вес чаши справедливости равен опы
ту и производительности программиста. Вес чаши бережливости состоит из стан
дартных коммерческих хитростей, таких как соблюдение баланса доходов и рас
ходов и статистика средней заработной платы программиста. Принимая решение
о денежных выплатах, имейте в виду эту аллегорию — она очень действенна.
Но ведь это все теория. А что на практике? Именно из за несоответствия тео
рии и практики денежный вопрос в деятельности руководителя становится од
ним из самых сложных. Вам известны принципы, следуя которым вы теорети
чески должны принимать решения относительно вознаграждения персонала.
С другой стороны, существенные коррективы в планирование вносят экономи
ческие аспекты — в частности, текущая коммерческая конъюнктура и корпора
тивная политика. В некоторых компаниях, помимо оклада, сотрудники получают
бонусы, которые выписываются в соответствии с личными заслугами каждого.
1
Ну вообще то в Библии это высказывание приписывается глупцу. Контекст смотрите в Экклезиас
те 9:14–19. Только постарайтесь не слишком падать духом, когда будете читать.
2
См. Новый Завет, 1 е послание к Тимофею 6:10 — любовь, деньги и зло он виртуозно сводит в один
силлогизм.
42
Ãëàâà 1 • Êàê ïðèâûêíóòü ê ðîëè ðóêîâîäèòåëÿ
Этот стимул действует лишь тогда, когда сотрудники оказываются в состоянии
выполнять то, за что они теоретически заслуживают дополнительного вознаграж
дения. В принципе, можно ввести практику выплаты ежеквартальных бонусов,
но, по моему опыту, это не самый лучший выход — однажды начав их выплачи
вать, вы обязательно столкнетесь с тем, что сотрудники будут на них надеяться.
Касательно денежного вопроса вам лучше проконсультироваться со своим началь
ником — скорее всего, вместе вы сможете разработать оптимальный для своей ко
манды план. Если решения о вознаграждении принимаете только вы, действуйте
так, как считаете нужным, и не забывайте правило справедливости и бережливости.
Óðîâåíü ìûøëåíèÿ1
Ну что, вам интересно? Вы заинтригованы тем, что будет дальше? Думаю, что
нет. Скорее всего, вы пребываете в полной уверенности, что дальше я разражусь
мириадами советов о том, каких действий лучше избегать, а на каких делать упор,
и все эти сведения будут представлены в виде маркированных списков. Действи
тельно, в последующих главах таких списков будет немало, но в данный момент я
хочу обратить внимание на то, как важно в вашей новой роли думать. Поэтому
с перечислением рекомендуемых и не рекомендуемых приемов руководства пока
что повременим. Возможно, необходимость думать — это самая сложная обязан
ность менеджера. Тем не менее это абсолютно необходимое условие нашего успе
ха. Как пишет в книге «Dynamics of Software Development» Джим Маккарти ( Jim
McCarthy):
«Основная задача руководителей процесса разработки программных средств
состоит в том, чтобы аккумулировать как можно больше интеллектуальных
ресурсов и направить их на создание конечного продукта»2.
Стоя в душе — думайте. Катаясь на велосипеде, прогуливаясь по парку, выде
лывая невообразимые трюки на роликах — думайте. Сталкиваясь с дилеммами,
которые обусловлены принятыми проектными решениями, — думайте. Думать
значительно полезнее, чем смотреть телевизор или бесцельно бродить по Сети, —
пусть даже там 500 каналов, но на самом деле на них ничего не происходит, и то,
что они как будто избавляют человека от необходимости мыслить, совершенно не
здорово. Думайте напряженно, до изнеможения, а когда не останется сил — начи
найте заново. Результат вас удивит.
Ну а теперь подумаем о том, как справляться с некоторыми типичными ситуа
циями.
Предположим, в вашем подчинении кот породы минималист, но при этом весь
ма профессиональный. Вы хотите поручить ему модернизацию продукта, который
писал кто то другой, но доработать который в контексте текущих коммерческих
задач совершенно необходимо. Взглянув мельком на код, который вы собирае
тесь вменить ему в обязанность, он говорит: «Нет, это слишком сложно — код нуж
но переписать». Естественно, речь идет о коде, который писался два года и кото
рый уже сейчас приносит компании неплохие деньги. Ситуация осложняется тем,
1
Игра слов «шлюзовой уровень» — thunking layer, «уровень мышления» — thinking layer. — Примеч.
перев.
2
Jim McCarthy, Dynamics of Software Development (Redmond, WA: Microsoft Press, 1995), p. 5.
Óðîâåíü ìûøëåíèÿ
43
что человек, который этот код написал, у вас больше не работает и поэтому физи
чески не может помочь новому сотруднику в нем разобраться. Итак, у вас два
выхода. Первый: пасть под давлением минималиста, сделав его самым счастли
вым человеком, но загубив последний шанс сдать проект в срок. Второй: напра
вить его на путь изучения существующей архитектуры и дать ему впоследствии
возможность внести в нее весомый вклад. Поиграйте с его пристрастием к четкой
архитектуре — попросите документировать существующий код с тем, чтобы в бу
дущем, если позволит время, он смог бы переписать некоторые объекты, сделать
их более удобными. Если он профессионал, не сомневайтесь — он обязательно
разберется в том, что написал его предшественник. Не стесняйтесь использовать
в своих целях дух соревновательности. С точки зрения минималиста все, что на
писал не он, — полная туфта. На самом деле вполне возможно, что он боится, будто
не сможет разобраться в существующем коде, и просто не хочет в этом признать
ся. Всегда ищите скрытые мотивы, которыми руководствуются все без исключе
ния представители рода человеческого. Поймите: программисты, не готовые при
знать, что их компетенции не хватит для решения поставленной задачи, очень
любят выискивать своему бездействию высокоинтеллектуальные оправдания.
Как поступить с архитектором, который уверен, что созданные им объектные
решения превосходят все созданное ранее, а вы, тем не менее, усматриваете в них
некие слабые стороны? Не надо ему ничего говорить про врожденные недостатки
решений — ничего не добьетесь, зато наживете себе врага. Лучше попросите его
объяснить предполагаемый механизм функционирования всех динамичных эле
ментов и построить несколько прототипов, или тестовых программ, которые смог
ли бы наглядно продемонстрировать действие заложенных в решении функций.
Если он создаст эти прототипы и никаких проблем не возникнет, значит, воз
можно, вы были неправы, и изъянов в найденном решении нет. Если архитектура
кажется вам слишком громоздкой и монолитной, попросите разбить ее на ком
поненты. Если окажется, что они прекрасно друг с другом работают, значит, архи
тектор вполне адекватно представляет себе, что он хочет. Если объекты излишне
взаимосвязаны и взаимозависимы, это свидетельствует о пристрастии архитек
тора к усложнению, которое способно существенно удорожить сопровождение
продукта. Что отличает высокопрофессионального архитектора? То, что он спо
собен создать конструкцию, которую сможет обслуживать и расширять любой его
последователь. Такая конструкция не рассыплется при первой же модернизации
кода. На код при работе с архитектором нужно смотреть его глазами — даже если
он слеп на один глаз и не видит другим.
Åñòü òâåðäîå ïðàâèëî: ïðåæäå ÷åì ïûòàòüñÿ óòâåðäèòü òî èëè èíîå ðåøåíèå, èñïîëüçóÿ
ñâîå ïîëîæåíèå ðóêîâîäèòåëÿ, îáÿçàòåëüíî âûñëóøàéòå ÷åëîâåêà è ïîïðîáóéòå åãî
ïîíÿòü.
Какие еще рекомендации я мог бы дать по поводу такого рода ситуаций меж
личностного общения? Есть твердое правило: прежде чем пытаться утвердить то
или иное решение, используя свое положение руководителя, обязательно выслу
шайте человека и попробуйте его понять. В том, что касается конфронтации, про
граммисты ничем не отличаются от остальных людей — они хотят, чтобы их вы
слушали. Как пишет в своей книге «The 7 Habits of Highly Effective People» Стивен
44
Ãëàâà 1 • Êàê ïðèâûêíóòü ê ðîëè ðóêîâîäèòåëÿ
Кави (Stephen Covey), «сначала старайтесь понять… и только после этого — быть
понятым». Поиск консенсуса при принятии технических решений есть не что иное,
как вид искусства, основывающийся на готовности выслушивать чужие идеи. Для
того чтобы выстроить такую основу для взаимодействия с сотрудниками, требу
ется терпение, и проявлять его необходимо — хотя иногда нам кажется, что вре
мени нет даже на конструирование, а насчет методов все вроде бы согласны. Вы
можете так считать, но это не отменяет постановку задачи по достижению кон
сенсуса1. О том, как достичь консенсуса, мы еще поговорим в главе 5, которая по
священа проведению проектных совещаний. Возможно, вы удивитесь, когда
узнаете, что консенсус нельзя строить на основе компромисса.
И еще один пример, иллюстрирующий принцип «услышь, прежде чем судить».
Некоторые языки программирования — и, в частности, Visual Basic (VB) — не
предусматривают полноценных конструкторов объектов. Недавно я столкнулся
с тем, как один художник с помощью события инициализации класса VB пытался
организовать обращения к набору объекта со стороны (родительского) класса
потребителя2. Если объект VB не удается конкретизировать, перехватить ошибку
становится очень трудно. Когда я спросил этого деятеля, почему для обработки
подверженной ошибкам операции он выбрал упомянутое событие, в ответ он со
общил, что его решение изящно, понятно и не требует от вызывающего объекта
подготовки обращения к интерфейсу. Я, естественно, посчитал, что надежная об
работка ошибок значительно важнее любых попыток вылизать текст. Но промол
чал. Ознакомившись с его аргументацией, я объяснил ему, с какими трудностями
может столкнуться такой объект, и подкрепил свои соображения наглядным при
мером в коде. Если бы я сразу сказал что нибудь вроде «это не есть правильно —
разберись!», то не смог бы образумить его своим примером, и он так бы не понял,
чего от него хотят. Повторюсь: если дать человеку возможность высказать его точ
ку зрения, он в ответ проявит понимание к вашей позиции.
Êàê âû àäàïòèðóåòåñü
Из этой главы вы почерпнули множество новых идей. Возможно, вам немного не
по себе от масштаба изменений, которые приходятся на долю руководителя на
пути самосовершенствования. Не беспокойтесь. В конце концов, на 99 % люди до
сих пор генетически идентичны обезьянам, а оставшийся процент сформировал
ся далеко не сразу. Последующие главы, в которых раскрываются другие аспекты
руководства и менеджмента, помогут вам адаптироваться, преодолеть трудности
и достичь успеха.
Теперь повторим пройденный материал — благо основные принципы руковод
ства должны обосноваться в вашей голове надолго.
Вы должны уметь адаптироваться. Нарабатывая навыки руководства, чело
век должен приспосабливаться к новому для него социальному контексту. Вы —
1
Существует мнение, согласно которому полное и всеобщее согласие приводит лишь к тому, что
в случае неудачи не остается никого, кого можно было бы в ней обвинить. Может, это и так, но, буду
чи руководителями, мы не должны увлекаться поиском виновных — значительно полезнее посвятить
свое время решению проблем.
2
Событие инициализации в VB не принимает и не возвращает никаких параметров.
×òî äàëüøå
45
начальник, а потому ваши взаимоотношения с подчиненными должны серьез
но измениться.
Самосовершенствование важнее, чем имидж. Лидерство есть внутреннее каче
ство человека, оно ни в коем случае не обусловливается внешними признака
ми. Оставаясь программистом, вы как руководитель должны работать над реше
нием сложных проблем, предусматривающих анализ поведения подчиненных
(и, конечно же, собственного поведения).
Изучайте своих сотрудников. Станьте исследователем культуры и личностей
программистов. Разберитесь, почему ваши подчиненные пишут код именно так,
как пишут; подумайте, как использовать их положительные качества и улуч
шить положение вещей в неблагополучных с точки зрения производительнос
ти областях. Пасти котов — значит заставлять их двигаться в одном направле
нии. Это основная задача руководителя.
Вознаграждайте сотрудников согласно их заслугам. В вопросах устного и де
нежного поощрения действуйте по ситуации. Принимая во внимание все фи
нансовые ограничения, старайтесь быть одновременно справедливым и береж
ливым. Не забывайте, что хвалить подчиненных лучше публично, а ругать
индивидуально.
Думайте. Мобилизуйте ваши знания о людях и на их основе старайтесь нахо
дить консенсус. Прежде чем судить, выслушивайте аргументацию собеседника.
Воспитывайте свой мозг — поскольку вы теперь руководитель, размышления
должны стать вашей второй натурой. Готовые варианты решения личностных
проблем не способны заменить ваших стараний, направленных на устранение
трудностей и развитие возможностей, характерных именно для вашей ком
пании.
×òî äàëüøå
В этой главе мы анализировали ваши кадры; в следующей будем изучать вас. Я за
дам несколько довольно трудных вопросов, призванных выявить ваше отноше
ние к роли руководителя в высшей степени важного процесса конструирования
программного обеспечения в контексте текущей конъюнктуры. Чтобы стать хо
рошим руководителем, вы прежде всего должны научиться управлять собой.
Гл а в а
2
Êàê ðóêîâîäèòü ñîáîé
Создание в срок качественного программного обеспе
чения — ваша цель, а управление процессом — ваша рабо
та, так что же вы делаете в свободное время? Вероятно,
пишете код. Если вы доросли до начальника из програм
мистов, вам стоит продолжить программировать, в про
тивном случае ваше увлечение этим ремеслом будет ос
лабевать, и ваши навыки постепенно «сойдут на нет».
Другой возможной причиной для того, чтобы искать
и находить время для кодирования, является удоволь
ствие, которое оно доставляет. Если возглавлять коман
ду программистов — для вас дело новое и вы пока еще
адаптируетесь к этой роли, то кодирование доставит вам
удовольствие, поскольку именно это вы хорошо знаете
и умеете делать продуктивно. Я полагаю, что продолжать писать код абсолютно
необходимо, поскольку это занятие связывает вас с прошлой жизнью, с вашими
корнями. Корни очень важны, ведь они определяют ваше отношение к своему ре
меслу, и как руководителю вам придется пустить в грунт своей жизни несколько
новых корней.
Исследование самого себя даст начало этим корням, так что занимайтесь са
моанализом во время ваших ночных бдений над кодом. В предыдущей главе мы
рассмотрели принципы взаимодействия с подчиненными, теперь пришло время
взглянуть на того, кто ими руководит, — на вас. В этой главе рассматриваются
вопросы руководства собой. Каким руководителем я являюсь? Под кого надо под
страиваться, под начальников или под подчиненных? А может, одновременно под
тех и других? Ответы на эти вопросы чрезвычайно важны для вашего роста и ус
пеха как руководителя.
Âçãëÿä â çåðêàëî
Исследование вашей объективности может оказаться трудной задачей, посколь
ку в этом процессе существенную роль играет субъективность. Для того чтобы
Âçãëÿä â çåðêàëî
47
облегчить самопроверку, взгляните на следующий перечень вопросов и обдумай
те их по ходу чтения этой главы. В ее конце я предложу свои ответы на них. Эти
ответы я считаю естественными для управленца, и они помогут вам стать лучшим
руководителем, чем вы есть. Как теннисист, вы не можете сделать хороший замах,
не сжав рукоять ракетки. Управление — это ракетка, так что предложенные во
просы требуют ваших ответов. Итак:
Считаете ли вы, что предельные сроки завершения проекта — это рекламный
прием, на самом деле не имеющий большого значения?
Позволяете ли вы программистам самим принимать основные архитектурные
решения, если вы слишком утомлены или заняты?
Надеетесь ли вы, что ваши опытные программисты и без вас все сделают пра
вильно, поскольку у вас просто нет времени на то, чтобы нянчиться с ними?
Полагаете ли вы, что при приближении срока сдачи проекта все проблемы
в конце концов решатся1?
Считаете ли вы, что пользователи никогда не сделают ничего, что привело бы
к программному сбою, просто потому, что у них не хватит ума для этого?
Предпочитаете ли вы при управлении коллективом искать консенсус, даже если
это требует массы времени и терпения?
Считаете ли вы электронную почту эффективным средством общения при ра
боте над проектом?
Согласны ли вы проговорить по телефону несколько часов кряду, только что
бы убедиться, что все идет как надо?
Считаете ли вы, что с помощью комитетов и комиссий невозможно вырабо
тать адекватные бизнес требования?
Считаете ли вы себя самым умным программистом в компании?
Чувствуете ли вы ревность и страх, когда смотрите на действительно хороший
код, который написан не вами?
Делаете ли вы все возможное, чтобы успеть закончить проект в срок2?
Ответы, которые вы даете на эти вопросы, могут меняться в зависимости от
обстоятельств3. Тем не менее некоторые из ответов правильны вне зависимости
от текущей ситуации на административном поприще. Надеюсь, что последующие
разделы подготовят вас к тому, чтобы отвечать не задумываясь. Возможно, с не
которыми истинами вам будет трудно согласиться, но я полагаю, что, познав са
мого себя, вы сможете принять их и действовать в соответствии с ними.
1
2
3
Это то же самое, что предпочесть синюю пилюлю красной в «Матрице», культовом фильме многих
программистов.
Южанин бы сказал: «Я пойду за этим в пасть дьявола». Это значит, что вы ни перед чем не останови
тесь ради того, чтобы достичь своих целей. Природа этой аллегории происходит от изображения ада
в виде ужасной разинутой пасти, готовой поглотить вас, — очень напоминает срок сдачи проекта, к ко
то рому невозможно успеть. Вы проявляете твердость и с мечом в руках рубитесь у врат ада, преодо
левая силу, стремящуюся вас уничтожить.
Помните «Звездные войны»? Что Оби Ван, говоря об отце Люка, сказал о природе правды и точки
зрения? (Когда умер Йода.)
48
Ãëàâà 2 • Êàê ðóêîâîäèòü ñîáîé
Ðàé, àä, ÷èñòèëèùå è âàøå ìåñòî âî âñåëåííîé
Наиболее существенное усовершенствование, которое вы можете сделать, ру
ководя разработкой программного обеспечения, — усовершенствовать руково
дителя.
Íàèáîëåå ñóùåñòâåííîå óñîâåðøåíñòâîâàíèå, êîòîðîå âû ìîæåòå ñäåëàòü, ðóêîâîäÿ
ðàçðàáîòêîé ïðîãðàììíîãî îáåñïå÷åíèÿ, — óñîâåðøåíñòâîâàòü ðóêîâîäèòåëÿ.
Уильям Блейк (William Blake) писал: «Тот, кто желает, но не действует, рас
пространяет чуму»1. Если вы не исправите слабые места в вашем стиле руковод
ства, вы распространите чуму среди своих программистов. Продолжая наш по
этический экскурс (поэзия — близкая родственница программирования), отметим
следующие строки:
…в сердце взгляни,
Растет в нем святое древо,
Листья дрожат, как огни,
Питает их радости чрево2.
Вы должны ухаживать за этим «деревом». Как Вергилий, ведший Одиссея
сквозь чистилище3, я здесь для того, чтобы провести вас к вашему новому месту
во вселенной программного обеспечения.
Осознание вашего места в происходящих вокруг вас событиях поможет вам
стать лучшим руководителем, чем вы были прежде. Давайте оглядимся в этой но
вой и прекрасной вселенной.
Âàøà ðàáîòà â êîðíå ìåíÿåòñÿ
Ну что ж, вы не в раю, это уж точно. Наверняка вы осознали это в первый же
месяц, распределяя задачи в коллективе. Хотя вы можете подумать, что в раю
живет ваш начальник, смею вас уверить, что и это не так. Вы видите, как он
планирует текущие задачи и проводит планерки на уровне компании, касающи
еся отдаленного будущего, но вы никогда не видели, чтобы он делал что то, имею
щее какую либо ценность само по себе. Ваше впечатление ошибочно и пока
зывает, насколько вы нуждаетесь в изменении точки зрения на выполняемую
работу. Вскоре мы подробнее поговорим об этом, в особенности в главе 9, где
1
2
3
Эту и многие другие прелестные вещи, в равной степени поучительные и гнетущие, можно найти в поэ
мах Блейка «Marriage of Heaven and Hell». Упомянутая выше цитата взята из «Proverbs
of Hell» — William Blake, The Complete Poetry and Prose of William Blake, ed. David Erdman (Derkeley,
CA: University of California Press, 1982).
Уильям Батлер Йейтс (William Butler Yeats), избранные поэмы (New york: Collier Books, 1986). Пе
ревод В. А. Савина (http://zhurnal.lib.ru/s/sawin_w_a/rtfrtf.shtml).
Вы можете освежить ваше классическое образование, прочтя современный перевод Чистилища Дан
те. Когда вы окажетесь в роли руководителя, вам может показаться, что вы находитесь где то между
раем и адом, однако в действительности это не так — это наше видение обычной жизни.
Ðàé, àä, ÷èñòèëèùå è âàøå ìåñòî âî âñåëåííîé
49
наше внимание будет сфокусировано исключительно на отношениях с началь
ством.
Вы уже поняли, что кодирование больше не ваш хлеб. Иногда вы относитесь
к этому как к «программистскому аду», поскольку получаемые вами задания дол
жны быть выполнены к нереальным срокам, и вам не с кем посоветоваться, кроме
себя. Как программист вы привыкли к жаре, получали удовольствие от общения с
вашими собратьями программистами и считали программирование основным де
лом своей жизни.
Теперь у вас появилось другое место — место начальника программистов. Вы
где то посередине между раем и адом и поэтому наслаждаетесь преимуществами
обоих. В мифологии такое промежуточное место между раем и адом называется
чистилищем. Именно в нем устраняются последние преграды на пути в рай.
В чистилище грешник также получает свою долю мук, но не таких ужасных, как
в аду. На первых порах вы можете не почувствовать, что в этом новом месте
страдаете меньше, но когда вы однажды к нему привыкнете, оно вам покажется
совсем неплохим. На самом деле я не знаю лучшего места: вы по прежнему мо
жете писать код, но у вас также есть возможность помочь другим делать ту же
работу.
Âàì íóæíî çàíîâî ó÷èòüñÿ îöåíèâàòü ñâîè óñïåõè,
óâëå÷åíèÿ, àìáèöèè
Геометрические аспекты рая, чистилища и ада вполне применимы к вашему мес
ту в иерархии управления компанией. Представьте себе, что с каждой ступенькой
вверх по административной лестнице растет и высота, с которой вам, возможно,
придется падать. Если ваша лестница правая (прислонена к правой стороне стен
ки), мужайтесь: в конце концов, вы знаете, что ваше дело правое. Кстати говоря,
а куда вы движетесь как программист начальник? Будем надеяться, по направле
нию к успеху — как личному (персональному), так и общему (корпоративному).
Хотя успех и определяется по разному, одно из определений я нахожу наиболее
полезным и практичным: это способность радоваться своему труду и не терять
своего увлечения. Может показаться, что при такой оценке увлечение ставится
слишком высоко, однако оно может зажечь огонь у вас внутри и помочь вам поко
рить столь непредсказуемый мир разработки программного обеспечения. Увле
чение — это топливо, которое может раскрутить «мотор» вашего руководства. Тре
буйте от своих программистов во всем добиваться безупречности, чего бы это ни
стоило. Если они считают, что изящество и безупречность — это те две вещи, ко
торые затягивают время кодирования, напомните им, что элегантность — это до
стижимое совершенство. Увлечение побудит их добиться этих целей. Лелейте свое
увлечение — ведь для вас это единственный способ расти, приспосабливаться, пре
возмогать, достигать цели. Это часть обязанностей по уходу за деревом, на кото
ром распускаются цветы успеха.
Ëåëåéòå ñâîå óâëå÷åíèå — âåäü äëÿ âàñ ýòî åäèíñòâåííûé ñïîñîá ðàñòè, ïðèñïîñàáëèâàòüñÿ, ïðåâîçìîãàòü è äîñòèãàòü öåëè. Ýòî ÷àñòü îáÿçàííîñòåé ïî óõîäó çà
äåðåâîì, íà êîòîðîì ðàñïóñêàþòñÿ öâåòû óñïåõà.
50
Ãëàâà 2 • Êàê ðóêîâîäèòü ñîáîé
Учитесь обживать свое место, а не рваться вперед. Амбиции могут быть
чрезвычайно разрушительной силой, если они отрывают вас от реальности и ре
шаемых задач. Быть амбициозным — значит преуспевать в вашей новой роли
руководителя и отчасти программиста. Если в будущем вам выпадет продвинуть
ся по служебной лестнице, вы должны быть уверены, что продвижение по служ
бе — совсем не то, к чему вы активно стремитесь, а просто лучший способ реа
лизовать свои амбиции. Вы сможете делать эту амбициозную работу, если у вас
сердце программиста и при этом вы сумели развить в себе мышление руководи
теля.
Âû ñìîæåòå äåëàòü ýòó àìáèöèîçíóþ ðàáîòó, åñëè ó âàñ ñåðäöå ïðîãðàììèñòà è ïðè
ýòîì âû ñóìåëè ðàçâèòü â ñåáå ìûøëåíèå ðóêîâîäèòåëÿ.
Åñòåñòâåííûé îòáîð è âðåìÿ
Из наблюдений за миром живой природы мы знаем, что для естественного отбо
ра, искореняющего недостатки и повышающего выживаемость, время — один из
необходимых ингредиентов. В мире программного обеспечения у вас нет такой
роскоши, как тысячелетия. Потребителям программного обеспечения может по
казаться, что на создание новой версии уходит бездна времени, но они ведь про
сто не знакомы с процессом. Вы разбираетесь в процессе и должны учитывать
время в повседневной деятельности. В революционной книге, посвященной во
просам управления разработкой программного обеспечения, пустая трата време
ни персоналом упоминается как величайший грех управленца1. А как вы тратите
ваше собственное время руководителя?
Время — это либо союзник, либо враг. Взвесьте, что сказал Френсис Бэкон
(Francis Bacon) — один из отцов основателей современной науки:
«Тот, кто не ищет новых лекарств, должен ожидать появления новых бед, ведь
время — величайший новатор»2.
Немного помогите процессу естественного отбора:продумывайте админист
ративные вопросы, которые грозят обернуться потерей времени, вносите измене
ния и работайте на опережение, иначе вы рискуете оказаться в их власти. В этом
разделе я опишу несколько проблем подобного рода. Я не стану останавливаться
на деталях управления, они будут обсуждаться в следующих главах. На данный
момент я хочу только, чтобы вы поняли: сознательно или нет, но некоторые мето
дики вы уже применяете. Время, растрачиваемое впустую, должно быть вашей
постоянной головной болью.
1
2
Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams, Second Edition (New York:
Dorset House Publishing, 1999).
См. эссе Бэкона «Of Innovations» (1625). Еще одна занятная цитата: «Время — это огонь, в котором
мы горим». Это, возможно, взято из произведения какого нибудь великого классического писателя,
но черт меня возьми, если я смогу выяснить, кого именно, так что нам пришлось ограничиться Бэко
ном.
Åñòåñòâåííûé îòáîð è âðåìÿ
51
Èçáåãàéòå íåíóæíûõ, íåýôôåêòèâíûõ ñîâåùàíèé
Как менеджер и руководитель вы будете участвовать в куда большем количестве
встреч, чем в бытность свою программистом. Глава 5 целиком посвящена этому
предмету. Давайте обсудим сейчас, какие из этих встреч действительно необхо
димы, и постараемся сделать их эффективными.
Для общения вашего коллектива вполне достаточно одной встречи в неделю.
Остерегайтесь тратить чересчур много времени на разговоры и мало на решения
и действия. Не устраивайте встречу только ради того, чтобы получить одобрение
своих решений. Поощряйте дискуссию, но ищите решения. И помните, что дья
вол — в деталях, а цель любой встречи — это изгнание этих дьяволов. Если вы
контролируете ход встречи, вы контролируете время. Установите предел для лю
бой встречи: 45 минут общения обычно более чем достаточно. Зачастую могут быть
нужны и 8 часовые обсуждения проекта, однако всегда имейте подробную повест
ку дня и следуйте ей, если вы собираетесь выдержать такую длительную мозго
вую атаку.
Íå óñòðàèâàéòå âñòðå÷ó òîëüêî ðàäè òîãî, ÷òîáû ïîëó÷èòü îäîáðåíèå âàøèõ ðåøåíèé.
Ïîîùðÿéòå äèñêóññèþ, íî èùèòå ðåøåíèÿ.
Íå ïëàíèðóéòå ñëèøêîì ìàëî èëè ñëèøêîì ìíîãî
Не верьте теории, утверждающей, что чистый стол — признак скудоумия. При
взгляде на рисунки Эйнштейна может показаться, что на столе у него царил ужас
ный беспорядок, но я ручаюсь, что в его голове — нет. Вам необходимо в достаточ
ной мере организовать процесс, но не тратить все время на планирование. Дос
тичь равновесия трудно, но необходимо. Тема организации, необходимой для
успеха, затронута глубже в главе 4. Не путайте вопросы организации работы с
вопросами ее выполнения. Организация — это начальная стадия плана. Разраба
тывайте план. Вспомните, что сказал Спок (Spock): «Логика — начало мудрос
ти»1. Аналогично, планирование — начало выполнения.
Áåññìûñëåííî îæèäàòü ÷åãî-ëèáî
ïðè îòñóòñòâèè êîíòðîëÿ
Вы роздали задания, вернулись к вашим обязанностям и надеетесь, что все заня
ты выполнением заданий. Однако после ваших подробнейших объяснений Джо
спокойно отправляется бороздить Интернет, даже не попытавшись заставить про
граммный интерфейс приложения работать правильно. Если вы думаете, что про
межуточные этапы не являются неотъемлемой частью поставленной вами задачи,
то вы понятия не имеете о том, как работает голова программиста, даже несмотря
1
Помните как в «Звездном пути» Спок напился с Валарисом после их беседы об изгнании людей из рая?
Гм, возможно, рай — это просто работа программиста в сравнении с работой руководителя, — вам ре
шать.
52
Ãëàâà 2 • Êàê ðóêîâîäèòü ñîáîé
на то, что вы — один из них. Это вполне в человеческой природе: если до срока
сдачи остается месяц, времени на то, чтобы сделать работу, вполне достаточно.
Время можно считать потерянным, если нет очевидного продвижения. Работа над
частью нового продукта — это поступательный итерационный процесс, не подчи
няющийся булевой логике и предполагающий много возможностей для провер
ки. Предположим, вы сообщили отделу тестирования, что дата завершения кода —
ХХ е января. Лучше, если эта дата не будет рабочей датой окончания работы над
кодом! Вы не сможете сделать работу Х, если сначала не будет выполнена часть
X – Y, где Y — еженедельно определяемая часть работ. (Вы можете сказать, что
«сделано за день»?) Вы наверняка слышали, что цена свободы — это постоянная
бдительность, ценой же вовремя сделанного программного обеспечения является
неизменное усердие.
Âû íàâåðíÿêà ñëûøàëè, ÷òî öåíà ñâîáîäû — ýòî ïîñòîÿííàÿ áäèòåëüíîñòü, öåíîé
æå âîâðåìÿ ñäåëàííîãî ïðîãðàììíîãî îáåñïå÷åíèÿ ÿâëÿåòñÿ íåèçìåííîå óñåðäèå.
Ïðîåêòèðóéòå àðõèòåêòóðó,
ïðåæäå ÷åì âûáèðàòü òåõíîëîãèþ
Технология волшебной пули или золотого молотка (как бы вы ее ни назвали) не
может решить бизнес проблем, это делают люди. Уверен, вы применяете техно
логию для реализации решений, но вы тратите время попусту, если думаете, что
покупка последнего дополнения к среде разработки даст скачок производитель
ности. Следующая версия языка программирования также не решит ваших про
блем. Конкурирующие производители средств разработки программного обеспе
чения обещают многое. Наша отрасль разделена надвое: Microsoft и все остальные.
Я, конечно, понимаю, что это слишком упрощенное разделение, но оно послужит
иллюстрацией моего утверждения: продукты Microsoft могут оказаться не опти
мальными для решения ваших конкретных задач, так как Microsoft слишком боль
шая и многоплановая корпорация. Не важно, много или мало у Microsoft возмож
ностей влиять на всю отрасль и каковы эти возможности, — технология Microsoft
построена на базе заранее определенного архитектурного плана. Мир Java, оли
цетворяемый Sun, слегка отличается, и хотя он более фрагментирован по сравне
нию с Microsoft, Sun также создает свои продукты на основе конкретной архитек
турной схемы. Вы можете использовать Enterprise JavaBeans или .NET сколько
душе угодно, но в любом случае вам придется принять внутренние архитектур
ные ограничения. Я призываю определить ваши архитектурные задачи и планы
до того, как вы выберете технологию реализации. Вам придется все переделать,
если с новым инструментом дело «не выгорит». Вы уже много раз слышали: если
у вас не хватает времени даже на то, чтобы сделать все правильно, где же вы его
найдете на то, чтобы все переделать?
Åñòåñòâåííûé îòáîð è âðåìÿ
53
Áàëàíñ ìåæäó ÷èñòîòîé è ïðàêòè÷íîñòüþ
Поиск равновесия между чистотой и практичностью — трудное дело для чело
века, влюбленного в программирование. Концепция «хорошего программного
обеспечения нужно в меру», возможно, впервые открытая Microsoft, имеет свои
достоинства. Вы можете тратить очень много времени, добиваясь чистоты кода
в ущерб практичности. Что действительно нужно, так это удобство эксплуатации
программного обеспечения, и практичность больше соответствует этой цели, чем
чистота. Конечно, чистота может быть полезной, но какой ценой? Я не говорю
о создании неряшливого или непродуманного кода, я имею в виду программное
обеспечение, которое может дополняться и расширяться не только его создате
лем, но и другими программистами. Проблема чистоты кода состоит в том, что
она подобна красоте — ее воспринимают глазами. Вашим глазам постоянно нуж
но носить очки практичности.
Íå âûïîëíÿéòå çàäàíèÿ, à ðàñïðåäåëÿéòå èõ
Классическая управленческая ловушка для начальника, вышедшего из програм
мистов, касается распределения заданий. Вы понимаете, каким образом реализо
вать определенное решение, а обучение членов команды, которые вовсе не обяза
тельно видят это решение, требует времени. Здесь применима старая китайская
поговорка: «Дайте человеку рыбу, и он будет сыт один день; научите его ловить
рыбу, и он будет сыт всю жизнь». Если бы все стали столь же сообразительны, как
вы, было бы вам проще работать? Возможно. Потратьте время на обучение сей
час, и вы сэкономите его потом, поскольку ваши сотрудники научатся решать про
блемы без вашей помощи. Тогда вы сможете эффективно распределять задания,
а не давать объяснения.
Äîêóìåíòèðóéòå òî, ÷òî âû äåëàåòå
èëè ïëàíèðóåòå äåëàòü
Трудным заданием для тех, кто любит программировать или управлять по наи
тию, является документирование. При необходимости можно «опередить собы
тия» и сделать экранный прототип, но экранные снимки делаются только ради
конкретизации проектной документации. Не отдавайте прототип напрямую про
граммисту, который должен завершать проект. Может показаться, что такой про
тотип сэкономит время, но он может просто повести программиста неверным
путем и спровоцировать фальстарт. Не думайте, что для написания кода бизнес
требований достаточно. Бизнес требования — только начальный этап разработки
документа, позволяющий обрисовать архитектуру, а дальше вы можете говорить
о реализации решения в объектах кода. У вас всегда будет искушение, когда под
жимает время (а разве бывает иначе?), слепить все «по быстрому», однако надо
быть настоящим счастливчиком, чтобы, не имея четкого плана, создать программ
ный продукт, который можно будет в дальнейшем дополнять и обновлять.
54
Ãëàâà 2 • Êàê ðóêîâîäèòü ñîáîé
Вы можете время от времени ощущать себя во власти блок схем и диаграмм,
но это лучше, чем код, хранящийся в корпоративной базе данных без какого либо
указания на то, как он работает и какую проблему он призван решать. Докумен
тирование радикально отличается от программирования, но это необходимый
первый шаг на пути превращения идей в продукты. Следующим шагом может быть
прототип, но смотрите на прототип как на продолжение документа, а не как на
начало проекта. Прототипы служат для обоснования готовой концепции, в то
время как программные продукты представляют собой реализацию готового про
екта.
Ïðîòîòèïû ñëóæàò äëÿ îáîñíîâàíèÿ ãîòîâîé êîíöåïöèè, â òî âðåìÿ êàê ïðîãðàììíûå
ïðîäóêòû ïðåäñòàâëÿþò ñîáîé ðåàëèçàöèþ ãîòîâîãî ïðîåêòà.
Îöåíêà âàøåé ïðîèçâîäèòåëüíîñòè
Как я упомянул в этой главе ранее, в момент, когда вы впервые превращаетесь из
программиста с полной занятостью в начальника с полной занятостью и одновре
менно программиста с частичной занятостью, административная деятельность
кажется не столь продуктивной, как кодирование. Учитесь различать просто тра
ту нервной энергии и настоящее творчество. Что я имею в виду? Если вы привык
ли кодировать часами, то вы поймете, что такое нервная энергия. Это то состояние
вашего ума, когда вы прикончили уже три чашки кофе1, вам еще писать и писать,
но вы уже чувствуете приближение результата. Настоящее творчество — это ощу
щение, когда вы видите и конечный результат, и все ступени его достижения, но
при этом знаете, что должное качество будет достигнуто далеко не так быстро.
Я знаю, что все сказанное трудно переварить, но вам действительно нужно как
следует обдумать эту концепцию.
Как программист вы привыкли измерять свою производительность числом
работоспособных объектов, созданных вами в течение дня. Подобный метод
оценки может стать причиной вашего провала как руководителя. Вы будете разо
чарованы и не удовлетворены тем, как вам приходится проводить время, пока не
примете новый образ мышления. Как начальнику вам следует оценивать свою
производительность объемом работы, которую выполняет ваш коллектив. Вы не
можете оценивать этот объем каждый день, и это может стать серьезной про
блемой, если вам требуются постоянные подтверждения того, что вы работаете
хорошо. Как ежедневно решать эту проблему? Заходите к своим программистам
каждый день или звоните им и проверяйте, как идут дела. Когда они привыкнут
ждать этих ежедневных встреч, произойдут две вещи: они никогда не будут знать,
когда вы появитесь, и, таким образом, постараются быть в «постоянной готов
ности», а вы сможете оценить их ежедневный прогресс и соответствующим об
разом подстроить под него свой график работы. При этом обе стороны прекрасно
1
Подставьте сюда любую любимую вами жидкость, содержащую кофеин. Я предпочитаю кофе програм
мистской крепости, светонепроницаемый и способный почти стоять на столе без всякой чашки.
Êîíòðîëèðóéòå ñâîè ñëàáîñòè
55
понимают, что происходит, однако приятно притворяться, что никто ничего не
замечает.
Êàê íà÷àëüíèêó âàì ñëåäóåò îöåíèâàòü ñâîþ ïðîèçâîäèòåëüíîñòü îáúåìîì ðàáîòû,
êîòîðóþ âûïîëíÿåò âàø êîëëåêòèâ.
В своей крайне проницательной книге «The End of Patience» Дэвид Шенк
(David Shenk) пишет:
«Что касается гипертекста, окончания излишни, поскольку никто никогда их
не достигнет. Чтение открывает дорогу к катанию на волнах информационно
го океана, извилистому, бесконечному странствию через лабиринт тем. Стран
ник создает собственную повесть, выбирая наиболее привлекательную ссыл
ку, которая всегда доступна. Как техника поиска — это роскошно. Однако как
способ мышления это имеет серьезные пороки»1.
По аналогии с приведенной цитатой, не оценивайте вашу производительность
тем, насколько быстро вы можете перепрыгнуть от одного проекта (или сотруд
ника) к другому. Не теряйте из виду масштабные цели и оценивайте небольшие
шаги, необходимые для успешного достижения цели. Не занимайтесь самообма
ном — пусть реальное положение дел диктуется фактами, а не вашим оптимис
тичным воображением. Ключевые слова из предшествующей цитаты — «привле
кательный» и «мышление». Не соблазняйтесь непосредственным удовольствием
от кодирования; лучше поразмыслите, как помочь остальным получать это удо
вольствие под вашим руководством.
Как я уже упоминал, управление программистами и разработка программного
обеспечения требуют серьезных размышлений. Добавьте к этому перечню настойчи
вость, качество, которое отнюдь не всегда присуще душе программиста, но которое
в случае крайней необходимости может быть привито ей программистом началь
ником. Примените часть этой настойчивости к самому себе — и вы обна ружите,
что она нужна как программисту, так и его начальнику. Системность — внутрен
няя дисциплина, привнесенная вами в работу, — помогает быть настойчивым.
Если вы новичок в деле управления, не ожидайте, что почувствуете себя ком
фортно ранее, чем через 6 месяцев. Пусть этот дискомфорт напоминает вам о не
обходимости многому научиться, а также о том, что изучение новых способов быть
полезным и чувствовать себя полезным требует времени, но за это воздастся в бу
дущем.
Êîíòðîëèðóéòå ñâîè ñëàáîñòè
Вы великий программист, правда? Я уверен в том, что так оно и есть, а также
в том, что вы все же еще не совершенны. Остерегайтесь, что ваши слабости как
программиста заставят вас смотреть сквозь пальцы на тех в вашем коллективе,
1
David Shenk, The End of Patience: Cautionary Notes on the Information Revolution (Bloomington, IN: Indiana
University Press).
56
Ãëàâà 2 • Êàê ðóêîâîäèòü ñîáîé
кто похож на вас. Если вы сами не любили документировать и проектировать,
прежде чем начать кодировать, тогда вы, вероятно, можете позволить другим это
го не делать.
Åñëè âû íå ëþáèòå äîêóìåíòèðîâàòü è ïðîåêòèðîâàòü, ïðåæäå ÷åì íà÷àòü êîäèðîâàòü,
òîãäà âû, âåðîÿòíî, ìîæåòå ïîçâîëèòü äðóãèì ýòîãî íå äåëàòü.
Такие вещи вряд ли могут быть полезными. Если вы минималист, то в случае
когда дело доходит до обработки ошибок (которых в идеале не бывает), вы може
те не заметить отсутствия процедур обработки ошибок в коде Салли, считающей
все настолько очевидным, что обработка ошибок — это просто трата места.
Я могу продолжить перечень слабостей программистов, но оставлю это вам.
Тем не менее вам требуется осознать необходимость постоянно быть вниматель
ным к своим недостаткам как программиста, поскольку нельзя прощать другим
то, что вы могли бы простить себе. Это может выглядеть противоречиво, и так оно
на самом деле и есть, так что продолжайте работу над исправлением своих недостат
ков как программиста, чтобы не заразить ваших подчиненных теми же слабостями.
Чтобы вам было легче преодолевать свои слабости, представьте себе, что мно
гие люди прошли тот же путь, что и вы. Некоторые из них проложили на этом
пути вехи для вас — это книги и иногда URL адреса. Другими словами, для того
чтобы заполнить пробелы в знаниях и/или опыте, рекомендую побольше читать.
Вам нужно читать по многим причинам. Вот некоторые из них.
Читайте, чтобы оставаться «на уровне». Сюда можно отнести чтение отрас
левых журналов, книг, посвященных вашему основному языку программиро
вания, и журналов, касающихся методов, применяемых в вашей работе. Это
вы должны делать почти каждый день, просто чтобы не потерять необходимые
навыки.
Читайте, чтобы быть в курсе. Такое чтение расширит ваши познания, причем
некоторые из источников, используемых для сохранения вашей квалифика
ции (чтобы оставаться «на уровне»), применимы и в этом случае. Здесь вам
надо сфокусироваться на том, что, возможно, не требуется прямо сейчас, но
может понадобиться в ближайшем будущем. Интернет рассылки, форумы
и прочие чудеса информационной эры могут быть необычайно полезными. Не
забывайте, однако, что эра информации — это совсем не то же самое, что эра
знаний.
Читайте, чтобы углубить свои знания. Подобное чтение может быть сложным,
но вы должны находить для него время, чтобы достичь более полных знаний
по технологии и методикам, с которыми сталкиваетесь в своей повседневной
работе. Здесь вам придется внимательно изучить книжные шкафы в вашей ме
стной библиотеке, книжном магазине или Интернете в поисках книг, которые
действительно могут помочь. Для того чтобы углублять свои знания, в выборе
книг избегайте характерного для поваренной книги подхода к изложению. Вам
нужно нечто большее, чем просто набор рецептов; вам нужно «откусывать боль
ше того, что вы, как вам кажется, можете прожевать».
Êîíòðîëèðóéòå ñâîè ñëàáîñòè
57
Читайте, чтобы стать мудрее. Умные люди встречаются не только в нашей
области. Другие научные дисциплины, а также художественная литература
могут научить вас подходить к любому вопросу с разных сторон. Очень часто
в нашей профессии мы ограничиваемся вертикальным мышлением. Вертикаль
ное мышление подразумевает поступательное движение от одного логическо
го умозаключения к следующему и отбрасывание того, что не укладывается
в рамки заранее имеющихся у нас представлений о наиболее подходящем.
Разностороннее мышление — это то, что приносит оригинальные идеи и зача
стую является признаком гениальности.
Хочу специально сообщить приверженцам технологии: бизнесмены — тоже
умные люди. Под бизнесменами я подразумеваю тех, кто многие годы участвует
в строительстве крупных корпораций и правительственных органов. Должен
признать, что мне далеко не сразу удалось научиться уважать навыки, необхо
димые для ведения бизнеса. Я был интеллектуальным снобом, считавшим, что
если кто то не понимает всех деталей технологии, то он по определению не может
принадлежать к когорте ярчайших и лучших. Это было проявлением слабости.
Вы можете многому научиться у руководителей в различных областях, не только
связанных с технологией. Расширьте ваши интеллектуальные поиски, включив
в них области деятельности, в большей степени связанные с применением не тех
нологии, а деловой хватки. Концентрировать усилия людей на решении бизнес
проблем — ваша основная работа как начальника, а технология — это только
одно из возможных решений. Вам нужно ознакомиться с другими путями решения
проблемы, так что читайте книги, в том числе и не относящиеся к области тех
нологии.
Вот пример того, что я имел в виду, говоря о деловом подходе. Джек Уэлч ( Jack
Welch), бывший долгое время главой General Electric, пишет:
«Я полагаю, что бизнес во многом похож на ресторан мирового класса. Если
вы заглянете в двери кухни, пища никогда не будет выглядеть так же хорошо,
как на вашем столе, куда она попадает великолепно украшенной, в красивой
посуде. Бизнес беспорядочен и хаотичен. Я надеюсь, что вы сможете найти на
нашей кухне что нибудь, что могло бы быть полезным в достижении вашей
мечты»1.
Не правда ли, сказано будто про бизнес в области программного обеспечения?
Уэлчу есть много чего сказать, причем вполне уместного и для руководителя про
граммистов, поскольку он пишет о руководстве в течение 20 лет одной из круп
нейших и доходных компаний. Учитесь у тех, кто проделал путь наверх до вас.
Идите по их следам.
Многочисленные ссылки на литературу, встречающиеся на страницах этой
книги, призваны помочь вам лучше ориентироваться. Выберите полезные для вас
издания и прочитайте их. Книги нужны не только для того, чтобы украшать пол
ки или произвести впечатление на ваших друзей. Хорошие книги — это жизнен
ные откровения. Научитесь определять, кто из авторов обращается непосредствен
но к вам, и слушайте то, что он пытается до вас донести.
1
Jack Welch, Straight from the Gut (New York: Warner Business Books, 2001), p. xv.
58
Ãëàâà 2 • Êàê ðóêîâîäèòü ñîáîé
Îòâåòû
Вопросы, с которых начиналась эта глава, были задуманы как трамплин для само
анализа. Теперь, когда вы, оттолкнувшись двумя ногами, прыгнули в глубину сво
ей души, давайте познакомимся с ответами на эти вопросы.
Считаете ли вы, что предельные сроки завершения проекта — это рекламный
прием, на самом деле не имеющий большого значения?
На самом деле сроки всегда имеют значение. Ваша компания может распро
странять программное обеспечение с целью продажи предоставляемых им ус
луг, и информация о товаре должна содержать описание его свойств. Даже если
пользователи не задействуют все возможности вашего продукта, они должны
быть представлены в рекламном буклете. Некоторым состоятельным клиен
там может потребоваться лишь одна деталь, которая не нужна остальным, и ее
поддержка программным обеспечением может стать причиной ощутимой вы
годы. Маркетинг может оказывать опасное влияние на разработку программ
ного обеспечения, однако он необходим. Даже если вы не хотите, чтобы весь
цикл разработки определялся отделом продаж, все равно для вас он будет од
ной из движущих сил в определении даты окончания работы над проектом.
Постарайтесь узнать продавцов поближе, стать их другом. Заслужите их дове
рие пунктуальностью и узнайте от них положение вашего продукта на рынке.
(См. далее врезку «Кошачьи разборки», непосредственно связанную с этим
вопросом и ответом на него.)
Позволяете ли вы программистам самим принимать основные архитектурные
решения, если вы слишком утомлены или заняты?
Вам, скорее всего, придется перепоручать принятие некоторого количества не
простых решений, особенно в первые дни вашей карьеры руководителя. Это
может сработать, особенно если вы руководите хорошими людьми, однако по
мните, что возможность перепоручить принятие решений есть у вас не потому,
что вы устали, а потому, что лучшие решения могут рождаться не только в ва
шей голове. Отказ от принятия решения — тоже решение. Пассивности на са
мом деле не существует, а если она имеет место, то скоро может потребоваться
кто то еще, кто бы мог делать вашу работу.
Надеетесь ли вы, что ваши опытные программисты и без вас все сделают пра
вильно, поскольку у вас просто нет времени на то, чтобы нянчиться с ними?
Этот вопрос тесно связан с предыдущим — и опять же: если вы руководите
квалифицированными людьми, то им может не требоваться ваше постоянное
внимание. Только не забудьте о том, что я говорил относительно ожидания
результатов без проведения проверок.
Полагаете ли вы, что при приближении срока сдачи проекта все проблемы
в конце концов решатся?
Назовите это принятием желаемого за действительное или, на языке детей,
ожиданием чуда. Как вы это ни назовете, полагаться на чудо опасно, и такая
надежда обычно является результатом стресса. Многие видят в стрессе обыч
Îòâåòû
59
ное жизненное явление, не всегда приводящее к пагубным эффектам. Стресс
может быть мощным фактором, направляющим ваши усилия, если вы привык
ли постоянно быть под напряжением и не сдаваться. Если вас не заводит ваша
работа, возможно, вы выбрали не ту работу. Не бойтесь неудач, они когда ни
будь обязательно случаются; не бойтесь не успеть к сроку, это тоже когда ни
будь произойдет. Учитесь на своих ошибках; не научившись стойко перено
сить неудачи, вы никогда не будете знать, что делать с успехами.
Считаете ли вы, что пользователи никогда не сделают ничего, что привело бы
к программному сбою, просто потому, что у них не хватит ума для этого?
Это тоже вопрос принятия желаемого за действительное. Из программистов
получаются плохие бета тестеры — поскольку мы подсознательно знаем, что
определенные функции при проверке «грохнутся», мы и не пытаемся их про
верять. В конечном счете ошибки всегда проявляются, так что не позволяйте
поспешности влиять на качество. Как руководителю проекта вам стоит само
му включиться в рабочий процесс на этапе альфа тестирования, дабы выявить
небрежности в программировании.
Предпочитаете ли вы при управлении коллективом искать консенсус, даже если
это требует массы времени и терпения?
Я коснулся этого вопроса в конце предыдущей главы, а в этой подробно осве
тил роль времени и необходимость сохранять терпение, поэтому полагаю, что
ответ очевиден. Если ваша интуиция вас иногда подводит, скажу прямо: кон
сенсус должен быть вашей постоянной целью, и вы должны делать все, чтобы
его достичь. Более подробное обсуждение этого вопроса вы можете найти в гла
вах 5 и 6.
Считаете ли вы электронную почту эффективным средством общения при ра
боте над проектом?
Ну конечно, она таковым не является, но если ваш коллектив пространствен
но разделен, она иногда остается единственно доступным средством общения.
Совместное редактирование документа куда проще, чем запутанная перепис
ка по электронной почте, однако электронная почта необычайно удобна, по
этому люди в первую очередь стремятся использовать именно ее. Только убе
дитесь, что у вас не накапливается непрочитанных сообщений, — лучше всего
создать из них один документ, содержащий все, что имеет отношение к разра
ботке.
Согласны ли вы проговорить по телефону несколько часов кряду, только что
бы убедиться, что все идет как надо?
Через это надо пройти. В вашей работе телефон — необходимое зло, если толь
ко все, с кем вы работаете, не находятся от вас дальше предела слышимости.
В некоторых случаях телефон — ваше единственное средство проведения еже
дневных проверок. Программы общения в режиме реального времени, наподо
бие ICQ, иногда заменяют телефон, но отнимают слишком много времени.
Считаете ли вы, что с помощью комитетов невозможно выработать адекват
ные бизнес требования?
60
Ãëàâà 2 • Êàê ðóêîâîäèòü ñîáîé
Иногда комитеты и комиссии бесполезны, но обычно в большой и сложной
организации они необходимы. Теперь, когда вы стали ответственным лицом,
вам, возможно, предстоит быть членом или председателем большего числа раз
нообразных комитетов и комиссий, так что будет лучше, если вы научитесь их
использовать. При удачном стечении обстоятельств комиссии могут быть мощ
ным средством объединения интеллектуальных ресурсов, так что не надо не
дооценивать их значение. Как никак, ни один человек не обладает всей необ
ходимой информацией, а без знания бизнес требований ваше программное
обеспечение сгодится разве что для забавы.
Считаете ли вы себя самым умным программистом в компании?
Возможно, вы ответили на этот вопрос положительно. Причиной его задать
было желание помочь вам побороть свое самомнение. Всегда, когда это воз
можно, старайтесь окружать себя теми, кто умнее. Никогда не обманывайте
себя надеждой, что вы единственный, у кого есть все ответы. В конце концов,
любое, даже самое оригинальное мышление — это просто химические процес
сы в мозгу, и чьи то молекулы всегда могут быть лучше ваших.
Чувствуете ли вы ревность и страх, когда смотрите на действительно хороший
код, который написан не вами?
Это вопрос ловушка. Если вы гордитесь тем, что делаете, то вполне нормально
чувствовать легкую ревность при виде чего то, что сделано кем то лучше. Под
маской этой ревности обычно скрывается страх, что вас перехитрили или, что
хуже, кто то достиг чего то, чего вы даже не в силах понять. Этот вид внутрен
него эмоционального состояния «невовлеченности» часто поражает целые от
делы. Осознайте эти ощущения и их причину и двигайтесь дальше. Ваша рабо
та — качественно и в срок завершить проект, поэтому используйте все, что
может помочь вам в этом.
Делаете ли вы все возможное, чтобы успеть закончить проект в срок?
Это возвращение к первому вопросу. Несоблюдение сроков может нанести
убытки вашей компании и похоронить вашу карьеру. Нужны ли здесь еще
какие нибудь слова? Да. Лейтмотивом хорошего руководства разработкой про
граммного обеспечения является прилежание, бдительность, внимание к дета
лям. Определение крайнего срока лежит в рамках этих составляющих руко
водства. Вы, может быть, вспомните, как Скотти из «Звездного пути» заслужил
свою репутацию уникального работника1, и примените схожий метод. Только
не умножайте вашу исходную оценку времени, необходимого для завершения
работ, на произвольное число, а назовите вашим людям какую нибудь вымыш
ленную дату, предшествующую дате, которую вы сообщите отделу тестирова
ния. Чем больше вы будете практиковаться в оценке сроков, тем больших ус
пехов вы достигнете в этом виде искусства.
Эти вопросы не были тестом — это были размышления о вашем положении
начальника, позволившие выявить слабости, которые могли бы помешать ваше
му успеху.
1
Скотти просто умножал оценочное время ремонта на 4.
Îòâåòû
61
ÊÎØÀ×ÜÈ ÐÀÇÁÎÐÊÈ — ÏÎÕÎÐÎÍÍÛÉ ÌÀÐØ
Несколькими днями ранее этого прекрасного весеннего майского дня прошел последний
срок сдачи, а работа над кодом еще не была завершена. Пение птиц и свежесть чистого
неба напомнили Роджеру о прекрасном, он даже на секунду забыл о проблемах программ
ного обеспечения встроенного процессора.
Поставив машину на свое вице президентское место парковки в недавно построенном
здании штаб квартиры корпорации, Роджер обратил внимание, что на парковке не было
машины Джеффа. Ну что же, еще один разговор о своевременности этим утром будет
весьма кстати. Эти разговоры между Джеффом и Роджером за последние несколько ме
сяцев случались часто. Они оба отдавали себе полный отчет в важности завершения но
вого программного обеспечения в срок. Казалось, что Джефф всегда будет отвечать, что
он сожалеет и приложит максимум усилий, для того чтобы система заработала на этой
неделе. Вице президент по продажам уже подписал со многими компаниями по всей
стране контракты на установку новой системы контроля и управления, которую Джефф
и Роджер должны были наконец то завершить. Президент дал ясно понять, что посколь
ку несколько крайних сроков уже прошли, работа обязательно должна быть закончена
к этому новому крайнему сроку.
Роджер размышлял о том, что он мог бы сказать Джеффу такого, что было бы внове
для него и могло бы заставить его наконец то завершить работу. Он знал, что Джефф
подолгу задерживается на работе вечерами и в выходные, — он звонил ему на всякий
случай. Хоть бы код был написан не на С, тогда, может быть, Роджер смог бы помочь. Ну
что ж, думал Роджер, он сделал все, что мог.
Прошло около тридцати минут рабочего дня, когда президент заглянул в простор
ный кабинет Роджера и сказал: «Спуститесь в мой кабинет на несколько минут. Вы мне
нужны для небольшого разговора». Роджер поежился и подумал, что «небольшой разго
вор» — это обычная словесная выволочка от вышестоящего начальства. Когда Роджер
присел напротив письменного стола руководителя компании, секретарь закрыла дверь
в кабинет. Президент посмотрел в глаза Роджеру и произнес: «Вы догадываетесь, зачем
я вас позвал?» Роджер не имел ни малейшего понятия, но пробормотал несколько слов о
том, что сожалеет. Президент, как казалось, был в затруднении и просто сказал: «Соби
райте ваши вещи. Вы уволены. Я вам месяц назад сказал, что к этому последнему сроку
мы должны закончить. Чек с вашим выходным пособием получите у моего секретаря.
Я хочу, чтобы вы покинули здание до полудня. До свидания».
Чему вы можете научиться из этой истории? Многому — в ней на каждом шагу намеки.
Речь идет об очевидно успешной и богатой компании, отделом продаж в которой руководит
очень напористый вице президент. Он уже подписал контракты на систему, которая даже
не была закончена. Другой же неудачливый вице президент, ответственный за разработ
ку программного обеспечения, на самом деле не имел необходимых технических навыков
для того, чтобы понять, с какими затруднениями столкнулся программист Джефф. Вдоба
вок вместо того, чтобы сидеть вместе с Джеффом вечерами и в выходные и убедиться, что
работа действительно сделана, он ограничивался телефонными «проверками» Джеффа.
Этот уволенный вице президент совершил много ошибок. Во первых, он не ощущал
важности окончания работы в срок. Это проистекало из неуважения к деловым обяза
тельствам. «Я сделал все, что мог», — замечательные последние слова, достаточно ирра
циональные и произнесенные исключительно для самоутверждения. Во вторых, он был
некомпетентен в данной проблеме. Этот вице президент не знал С, но управлял про
граммистом, который знал этот язык (но, очевидно, не очень хорошо). В третьих, этот
вице президент не смог определить, в чем настоящая причина проблемы, — в програм
мисте или в программном обеспечении. Он так и не выявил истинных причин надвига
ющегося бедствия. Итак, итоги вскрытия таковы: его уволили, и рассказанная история
была реквиемом по делу, которое он делал.
62
Ãëàâà 2 • Êàê ðóêîâîäèòü ñîáîé
×òî äàëüøå
На протяжении всей этой главы я держал перед вами зеркало (зеркало — метафо
ра самопроверки и самонаблюдения). Глядеться в него было, возможно, неприят
но и даже болезненно, но без боли вам не удастся вырасти до руководителя муж
чин и женщин, разрабатывающих программное обеспечение в условиях жестких
временных рамок. Есть ли секреты в управлении самим собой? Я не знаю ни од
ного, но точно знаю, что мое определение «сделаю все, что смогу» в контексте
руководства программистами имеет другое значение. Бывает, когда фраза «я сде
лал, что смог» произносится под конец, в случае неудачи. Не думайте об этих сло
вах в таком ключе. Эти слова означают приложение максимума усилий — их мож
но оценивать каждодневно, успех же иногда приходит только в самом конце. Так
что если секрет и есть, то он таков: каждый день проверяйте себя как руководите
ля и старайтесь стать лучше уже на следующий день. Ваш перечень вопросов к са
мому себе мог бы выглядеть так:
1. Подвергаю ли я качество своего управления ежедневной оценке?
2. Действительно ли я с каждым днем руковожу все лучше или я постоянно от
кладываю совершенствование стиля и сути моего управления на потом?
3. Нравится ли мне то, что я делаю?
4. Теряю ли я попусту время при выполнении своих служебных обязанностей?
5. Оцениваю ли я свою производительность тем, сколько сделали мои подчинен
ные под моим руководством, или у меня есть ощущение, что сам я не сделал
ничего?
6. Как мои слабости дали себя знать сегодня (по отношению ко мне самому или
другим)?
7. Чему я научился сегодня, чтобы оставаться в курсе, чтобы быть осведомлен
ным, чтобы углубить и расширить свои знания?
Этот перечень содержит семь пунктов; число семь древние считали совершен
ным. Вы не достигнете совершенства ни сегодня, ни назавтра, ни, возможно, в те
чение всей вашей жизни, но вы можете сделать максимально эффективными свои
усилия, направленные на самосовершенствование, делая все, что нужно, еже
дневно.
В следующей главе, в которой мы узнаем, как повести котов за собой, вам
придется еще раз взглянуть в зеркало. Пускай самоанализ станет для вас остров
ком безопасности, но не тайником. Выполняя вашу работу, вы должны предви
деть будущее и глядеть по сторонам, но при этом всегда необходимо иметь в ви
ду тот факт, что становление вашего характера руководителя — процесс длиною
в жизнь.
Гл а в а
3
Êàê âåñòè ñòàþ çà ñîáîé
Навыки руководителя нельзя выработать исключитель
но силой воли. Для того чтобы они появились, вы дол
жны овладеть некоторыми, возможно, еще неизвестны
ми вам принципами менеджмента. Эта глава как раз
и посвящена ряду важных областей менеджмента, ко
торые вам предстоит контролировать, ибо в противном
случае они будут контролировать вас. Я намерен позна
комить вас с теми аспектами вашей новой работы, кото
рые непосредственно позволяют заставить двигаться
ваших программистов в одном направлении — а, как я
уже говорил, именно эта задача в процессе выпаса котов является для руководи
теля основной. Конкретнее, мы поговорим об организационном управлении, про
низывающем всю вашу рабочую деятельность. Я расскажу, что делать с раздра
жителями, которые имеют обыкновение постоянно отвлекать от работы. Этими
навыками вы должны овладеть в обязательном порядке — вне зависимости от того,
как они повлияют на ваши отношения с окружающими. Управление проектами —
еще одно важное направление деятельности руководителя — рассматривается
в этой главе в контексте остальных ваших обязанностей. Мы также поговорим
о том, как формировать группы и как работать с персоналом, — теми людьми, ко
торые определяют конкретный результат ваших усилий. Короче говоря, матери
ал, содержащийся в этой главе, совершенно необходим для любого, кто хочет до
стичь совершенства в деле выпаса котов.
Êàê ñïðàâèòüñÿ ñ àäìèíèñòðàòèâíûìè ôóíêöèÿìè
С тех пор как вы стали руководителем, ваше мировоззрение начало кардинально
меняться. Будучи программистом, вы привыкли непринужденно общаться с себе
подобными. Так вот, имейте в виду, что милые беседы по поводу того, как лучше
организовать системное прерывание из за ошибки, понемногу уходят в прошлое.
Теперь вам придется обсуждать тонкости форматирования коммерческих требо
ваний, без чего вы просто не сможете составить спецификацию проекта. Конечно,
64
Ãëàâà 3 • Êàê âåñòè ñòàþ çà ñîáîé
для написания такой документации существует огромное количество разных шаб
лонов, но проблема то в том, что для решения этой и множества аналогичных за
дач, с которыми постоянно сталкивается руководитель, необходимо изменить
стиль мышления.
Координация информационных потоков — это тот род деятельности руко
водителя, который требует отдельного рассмотрения. Как вы, я надеюсь, помни
те, согласно методике объектно ориентированного (OO) анализа и проектирова
ния, для формулирования проектного решения и разрешения проблем, связанных
с конструированием программного продукта, вы должны иметь в виду три перс
пективы. Если хотите освежить память, взгляните на табл. 3.1.
Òàáëèöà 3.1. Êîíöåïöèÿ îáúåêòíî-îðèåíòèðîâàííîãî ïðîåêòèðîâàíèÿ
Ïåðñïåêòèâà
А теперь попробуйте привязать эту объектно ориентированную концепцию
к вашему повседневному общению с различными подразделениями компании, на
правленному на решение программных и управленческих задач. Вероятно, у вас
получится своего рода программа интеллектуального анализа, похожая на пока
занную в табл. 3.2.
Òàáëèöà 3.2. Àäìèíèñòðàòèâíûé ôèëüòð
Ïåðñïåêòèâà
Предлагаемый мною административный фильтр в первую очередь призван
помочь вам сориентироваться в информационной мгле1, которая нас ежедневно
окружает. Мгла эта состоит из электронных сообщений, телефонных звонков, тех
нических условий, маркетинговых сведений, планов Microsoft на следующий год,
вашей вечной головной боли в лице разгильдяя программиста Джорджа и т. д.
Другими словами, пытаясь вести свою стаю, вы ежедневно, если не ежечасно, по
падаете в ситуацию информационной перегрузки. Все поступающие сведения на
первый взгляд кажутся важными, однако без фильтра не обойтись. Смысл этого
фильтра можно выразить одним словом (кстати, это еще один удачный термин из
области объектно ориентированного программирования):
ФОКУСИРОВКА
1
Термин «информационная мгла» (data smog) я позаимствовал у Дэвида Шенка (David Shenk).
Êàê ñïðàâèòüñÿ ñ àäìèíèñòðàòèâíûìè ôóíêöèÿìè
65
Помните ваш первый поход к врачу, когда еще ребенком вы выяснили, что дол
жны носить очки? (Я задаю такой вопрос исходя из того, что вы — главный про
граммист; следовательно, у вас большой опыт борьбы с мелочами жизни, а зна
чит, вам, скорее всего, нужны очки.) Правда, замечательное ощущение, когда, надев
линзы, вы понимаете, что теперь оптометрическая таблица вам нипочем? Это и оз
начает умение сфокусироваться — отбросить все раздражающие факторы, кото
рые неизменно сопровождают деятельность руководителя, и выявить первооче
редные задачи.
Намотайте себе на ус: если уж у вас есть задача организовать производство
программного продукта, остальные сведения, отвлекающие от этой задачи, неза
висимо от того, насколько важными они кажутся, нужно отложить1.
Åñëè óæ ó âàñ åñòü çàäà÷à îðãàíèçîâàòü ïðîèçâîäñòâî ïðîãðàììíîãî ïðîäóêòà,
îñòàëüíûå ñâåäåíèÿ, îòâëåêàþùèå îò ýòîé çàäà÷è, íåçàâèñèìî îò òîãî,íàñêîëüêî
âàæíûìè îíè êàæóòñÿ, íóæíî îòëîæèòü.
Вот некоторые ситуации раздражители, часто встречающиеся в повседневной
деятельности руководителя.
Кто то из числа опытных пользователей вашего продукта придумал замеча&
тельную новую функцию и считает, что обязан рассказать вам о ней прямо
сейчас.
Сотрудник группы поддержки продукта в очередной раз сообщает вам о том,
что количество записей в журнале ошибок с каждой неделей растет в геометри
ческой прогрессии, и потому вы просто обязаны расставить в нем приоритеты.
Проектировщик продукта испытывает страстное желание узнать, можно ли
будет в обозримом будущем реализовать в коде желаемую функцию. По этой
причине он пишет очередное письмо с настоятельной просьбой ответить на все
предыдущие.
Обратите внимание на слова, выделенные курсивом: «замечательный», «обязан»,
«просьба». Смахивает на основной принцип подготовки вечерних теленовостей —
«чем больше крови, тем лучше». Большинство раздражителей не так важны, как
кажутся. Однако если их формулируют с помощью эпитетов типа «замечатель
ный» и «обязан», а также с добавлением просьб, вы, скорее всего, не удержитесь,
отвлечетесь от основной задачи и потеряете фокусировку. В этом то и состоит
проблема. Учитесь систематизировать те действия, которые вам рано или поздно
придется выполнить, но не забывайте о том, что ваша главная задача — выпустить
программный продукт. Иногда человеку, который обратился к вам с просьбой,
полезно быстро ответить и, соответственно, дать знать, что вы его просьбу полу
чили. Но при этом ответ должен выглядеть примерно так: «Я обязательно включу
вашу проблему в график и позже рассмотрю, но в данный момент у меня очень
много обязательств, и пока что я не могу этого сделать».
1
В главе 1 я уже ссылался на труд Стивена Кави (Stephen Covey) под названием «The 7 Habits of Highly
Effective People». Если у вас нет этой книги, идите в магазин, купите и прочитайте. Обязательно обра
тите внимание на то, что Кави думает по поводу организации времени и расстановки приоритетов.
66
Ãëàâà 3 • Êàê âåñòè ñòàþ çà ñîáîé
Какое отношение, спросите вы, все эти разговоры о фокусировке имеют к ве
дению стаи в нужном направлении? Ну, если вы действительно хотите, чтобы коты
за вами шли — а их, как известно, сложно заставить это сделать, — придется про
демонстрировать им ваши лидерские качества. Не нужно разглагольствовать о ли
дерстве — вы обязаны показать программистам решимость выпустить общими
усилиями качественный код. Естественно, руководитель, помимо прочего, дол
жен учитывать все тонкости (в частности, те, что перечислены выше), которые
помогают укомплектовать код. Фокусироваться — значит расставлять приорите
ты среди тех сведений, которые претендуют на значимость наравне со сведения
ми, действительно значимыми для завершения текущих проектов.
Ôîêóñèðîâàòüñÿ — çíà÷èò ðàññòàâëÿòü ïðèîðèòåòû ñðåäè òåõ ñâåäåíèé, êîòîðûå
ïðåòåíäóþò íà çíà÷èìîñòü íàðàâíå ñî ñâåäåíèÿìè, äåéñòâèòåëüíî çíà÷èìûìè äëÿ
çàâåðøåíèÿ òåêóùèõ ïðîåêòîâ.
Предположим, например, такую ситуацию: в ходе написания кода вы замечае
те в одном из объектов, который предполагаете расширить (или добавить интер
фейс), некую аномалию. Искушение приняться за исправление такого объекта —
по большому счету, попавшегося вам на глаза случайно — велико. Что сделает
хороший программист? Он примет аномалию во внимание, но продолжит зани
маться текущей процедурой. Вспомните, как просто потерять концентрацию при
кодировании, отвечая на телефонный звонок. На то, чтобы в подобных ситуациях
вернуться в колею (и восстановить в сознании логику кода), уходит битый час.
В организационном управлении действует тот же принцип: либо вы решаете пер
воочередные задачи, либо теряете последние шансы укладываться в график. Ко
времени, выделяемому на решение административных задач, нужно относиться
так же трепетно, как и ко времени, выделяемому на кодирование.
Êî âðåìåíè, âûäåëÿåìîìó íà ðåøåíèå àäìèíèñòðàòèâíûõ çàäà÷, íóæíî îòíîñèòüñÿ
òàê æå òðåïåòíî, êàê è êî âðåìåíè, âûäåëÿåìîìó íà êîäèðîâàíèå.
Êàê íå îòâëåêàòüñÿ íà ðàçäðàæèòåëè
Не позволяйте своему почтовому ящику влиять на ваш распорядок дня. С одной
стороны, электронная почта — самое полезное в мире изобретение после хлеба
в нарезке, но, с другой — есть в ней что то от нечистого. Как средству оперативного
обмена информацией ей нет равных; проблема в том, что в условиях географиче
ской рассредоточенности она становится основным носителем информационно
го потока. Позволив почте влиять на повседневные приоритеты, вы рискуете по
терять концентрацию. Разрастание рамок проекта часто начинается с почтового
сообщения, отправитель которого пытается уточнить коммерческие требования.
Если дискуссия разрастается до трех сообщений, беритесь за телефонную трубку.
Если звонок не решает проблему, попробуйте встретиться с собеседником лично.
Если и это не принесет желаемого результата — бросайте все попытки его достичь.
Êàê íå îòâëåêàòüñÿ íà ðàçäðàæèòåëè
67
Главное — чтобы электронная переписка не мешала решать задачи, включенные
в график. Если в вашей компании имеется какая то программа руководства про
ектами, опирайтесь на эту программу, собирая информацию по конкретным зада
чам; не загромождайте ее почтовым мусором, поскольку, если только не включать
переписку в проектную документацию, она все равно, скорее всего, затеряется.
Еще один дьявольский инструмент уточнения — служба мгновенных сообще
ний. Пользоваться ею нужно с умом. Не тратьте на нее свое время впустую и не
позволяйте ее значку на рабочем столе постоянно отвлекать вас от дела. Не пы
тайтесь с ее помощью проверять, находятся сотрудники на рабочих местах или
нет, — никто не любит, когда за ним открыто наблюдают. В деле слежки нужно
проявлять изобретательность — об этом, кстати, я говорил в главе 2 в подразделе
«Бессмысленно ожидать чего либо при отсутствии контроля» раздела «Естествен
ный отбор и время».
Привыкая к решению организационных проблем, вы обнаружите, что раздра
жители влияют не только на вас — программисты подвержены им не меньше. Одна
из главных ваших обязанностей заключается в том, чтобы приучить сотрудников
концентрироваться на работе.
Îäíà èç ãëàâíûõ âàøèõ îáÿçàííîñòåé çàêëþ÷àåòñÿ â òîì, ÷òîáû ïðèó÷èòü ñîòðóäíèêîâ
êîíöåíòðèðîâàòüñÿ íà ðàáîòå.
Как справиться с этой задачей? Лучше всего еженедельно назначать всем про
граммистам перечни задач, аннотируя их приоритетами и сроками завершения.
Поскольку цикл разработки всегда отличается непостоянством, перечни эти мо
гут меняться каждую неделю, а иногда — даже каждый день. Ответственность за
составление и корректировку этих списков ложится, опять же, на вас1. Вы себе не
представляете, сколько менеджеров считают программистов чуть ли не телепата
ми и пребывают в уверенности, что график работы они составляют с помощью
интуиции. Таких убеждений придерживаются даже некоторые директора. Подоб
ный подход регулярно приводит к тому, что вместо работы во имя пользователей
программисты трудятся для программистов, а руководители обнаруживают свою
бесполезность в контексте упрочения позиций компании.
Если вы унаследовали персонал от предыдущего руководителя, попросите каж
дого сотрудника в письменном виде сформулировать его текущие задачи. Это
очень эффективный прием — вы не только узнаете, что программисты думают
о своих обязанностях, но и составите представление о том, как руководство осу
ществлялось ранее. Просмотрев перечни задач, составленные самими сотрудни
ками, вы сможете оптимизировать их функции. Однажды приняв решение о ру
ководстве методом перечней задач, вы не сможете от него отказаться. Все будут
ждать новых заданий, и чем последовательнее вы себя проявите в деле их назна
чения, тем очевиднее станут ваши лидерские навыки. И еще один момент. Пере
1
Ряд предложений касательно программных продуктов, помогающих составлять для программистов
перечни задач, содержится в главе 4. Но не торопитесь переходить к этому материалу — иначе пропус
тите все мои подготовительные пассажи о том, в какую путаницу вы рискуете попасть, если не призо
вете на помощь инструменты электронной организации рабочего процесса.
68
Ãëàâà 3 • Êàê âåñòè ñòàþ çà ñîáîé
чень задач — это лишь первое звено в процессе ведения стаи в нужном направле
нии. По меньшей мере раз в неделю, а то и каждый день вам придется доносить до
сотрудников дополнительные сведения, инструктировать их и помогать двигаться
к намеченной цели, соблюдая при этом установленные временные ограничения.
Скорее всего, вам не удастся сильно продвинуться в вопросах физического раз
мещения программистов, но все таки при любой возможности требуйте, чтобы
каждый сотрудник вместо отгороженной кабины имел отдельное помещение. Если
руководство вашей компании больше думает не о продуктивности, а об арендной
плате, у вас мало шансов — и, тем не менее, гните свою линию. Один из наиболее
заметных раздражителей в деятельности программистов создают инженеры тех
нологи компаний с их квадратно гнездовым мышлением. Фильм «Office Space»,
в котором, так сказать, «в естественном виде» изображены программисты в своих
кубышках, должен стать обязательным для просмотра вредителями, планирую
щими офисное пространство. Факторы, влияющие на «отупение» сотрудников,
на примере 32 346 компаний изучили Том Димарко (Tom DeMarco) и Тимоти
Листер (Timothy Lister). На составленной ими диаграмме видна четкая обратная
зависимость между степенью отупения сотрудников и объемом выделяемого каж
дому из них офисного пространства1. О чем это говорит? О том, что шум, отвлека
ющие факторы и все прочие побочные эффекты политики снижения затрат серь
езно снижают продуктивность работы.
Так пусть ваши программисты работают дома — это один из лучших способов
исключить раздражающие факторы и поднять продуктивность. Но и здесь не все
так просто! Некоторым сотрудникам такой режим работы подходит лучше всего;
другим полезно появляться на работе хотя бы раз в неделю; в любом случае, эф
фективной деятельности в режиме «на дому» достигают только самые дисципли
нированные. Выбрав этот путь, вы будете вынуждены уделять довольно много
времени проверкам. Опытным и надежным сотрудникам можно доверить работу
на дому; что касается остальных — дайте им возможность попробовать, но обяза
тельно проверяйте новые показатели продуктивности. Если отделения компании,
в которой вы работаете, рассредоточены по всему земному шару, и у вас факти
чески нет выбора, будьте готовы к тому, что с прижатой к уху телефонной труб
кой придется проводить по 10 часов в неделю, а от электронных сообщений не
будет отбою. Схема работы на дому очень перспективна, но чтобы заставить ее
приносить плоды, вы должны учесть все тонкости.
Êîãäà ïðîåêò ðàçðàñòàåòñÿ
Я имею в виду классическое понятие разрастания проекта. Если аналитик биз
нес требований утверждает, что занимается уточнением рамок, знайте: он их раз&
двигает. Не важно, как этот процесс называть. Факт тот, что специфицировать
и сконструировать программу, избежав разрастания требований, не удавалось еще
никому. Объясняется это натурой человека — невозможно с первой попытки сфор
мулировать все функции, которые предполагаемой программе предстоит выпол
нять.
1
DeMarco and Lister, op. cit., p. 56.
Êîãäà ïðîåêò ðàçðàñòàåòñÿ
69
Рассмотрим типичный процесс производства программного продукта. Вне за
висимости от того, что вы предпочитаете — стремительный напор или постепенные
итерации, — процесс этот всегда состоит из нескольких фиксированных этапов.
1. Замысел. У кого то появляется блестящая идея.
2. Специфицирование. Куча людей пытаются описать эту идею.
3. Проектирование. Высокоинтеллектуальные товарищи решают, как сконстру
ировать предполагаемый программный продукт.
4. Конструирование. Бессонными ночами и нескончаемыми днями программис
ты программируют.
5. Тестирование. Обнаруживается, что конечная реализация блестящей идеи не
так хороша, как хотелось бы, или, еще хуже, что идея то отнюдь не блестящая.
6. Все начинается заново со второго этапа, пока вы не почувствуете, что все нор
мально, всего хватает, или, наоборот, не придете к заключению, что идея, вы
сказанная на первом этапе, ужасна и вам срочно требуется новый блестящий
замысел (в последнем случае, опять же, все начинается со второго этапа).
А теперь подумайте: таким ли уж неожиданным станет разрастание рамок
в контексте отраженного в этом списке реального сценария? Мне так не кажется,
и вам тоже не должно так казаться. И тем не менее, если речь об этом зайдет, воя и
зубовного скрежета программистов не избежать. Как заставить их поверить, что
вы во всеоружии и ваша позиция правильна? Лучше всего поставить их перед
фактом, что разрастание неизбежно, и научить их справляться с этой проблемой.
Вы руководитель, и это — ваша обязанность. Не поддавайтесь соблазну разнести
«крайних» в других отделах — этим вы не приблизите завершение работы и не
исправите ситуацию.
В своей немного устаревшей, но, тем не менее, сохраняющей значимость книге
под названием «Managing the Software Process» Уотс Хамфри (Watts Humphrey)
сформулировал принцип, актуальный по сей день:
«Когда программисты берутся за оценку объема кода реализации какой либо
функции, результаты неизменно оказываются заниженными. Этому есть мно
жество возможных объяснений. В этом контексте следует понимать, что их оп
тимизм есть относительно прогнозируемая функция состояния проекта»1.
На самом деле, разрастание рамок объясняется очень просто — сказать, сколь
ко времени и сил уйдет на создание очередной сногсшибательной программы,
вплоть до ее первого выпуска и критической оценки, не может никто. Многие про
граммисты соглашаются с двумя соображениями относительно проводимых ими
первоначальных оценок, согласующихся с принципом Хэмфри; я сформулирую
их в виде аксиом:
любой процесс продлится дольше, чем вы надеетесь;
всегда появляется что то, о чем вы не подумали.
Вооружившись этими аксиомами и введенным Хэмфри понятием «состояния
проекта», старайтесь контролировать разрастание и обязательно убедите ваших
1
Watts S. Humphrey, Managing the Software Process (New York: Addison Wesley, 1989), p. 93.
70
Ãëàâà 3 • Êàê âåñòè ñòàþ çà ñîáîé
подчиненных в том, что вы человек проницательный, поскольку предсказывали
такую возможность и учли ее в процессе тщательного планирования. «Тщатель
ное планирование»! Звучит замечательно, но что же это означает в контексте вы
паса котов? А вот что. Вернитесь к главам 1 и 2, еще раз пробегитесь по изложен
ным в них принципам и попытайтесь сделать их неотъемлемыми элементами
своего характера. Помните, что лидерство происходит от сердца, а не от ума1.
Конечно, и для мозга найдется работа — в частности, ему предстоит разработать
методы контроля над разрастанием рамок проекта. Давайте рассмотрим типичный
план проекта. Предположим, что, исходя из заданного набора требований, вы дол
жны разработать проектное решение с расчетом на его последующую реализацию
программными средствами. Элементарный, но наивный план иллюстрирует табл. 3.3.
Òàáëèöà 3.3. Íåðåàëèñòè÷íûé ïëàí ïðîåêòà
Çàäà÷à
Руководствуясь таким планом, вы рискуете нарваться на кучу неприятностей.
Будучи глубоко убеждены, что конечная дата сдачи проекта будет равняться сум
ме временных интервалов A + B + C + D + E + F, вы немало удивитесь, обнару
жив, что это совершенно не так.
Рассмотрим более реалистичный план, показанный в табл. 3.4.
Òàáëèöà 3.4. Ðåàëèñòè÷íûé ïëàí ïðîåêòà
Проводить арифметические операции я, пожалуй, не буду, поскольку в табли
це мне еле хватило букв латинского алфавита. В общем, вы все поняли. Помните
также, что приведенный план не учитывает тех индивидуальных этапов, которые
обусловливаются особенностями проекта, равно как и зависимости между раз
личными этапами цикла разработки. В то же время он успешно иллюстрирует
причины разрастания рамок проектов, позволившие мне сформулировать две вы
шеупомянутые аксиомы: это, во первых, недостаточный анализ подробностей,
и, во вторых, излишне оптимистические оценки длительности конструирования
программных продуктов. Чем больше опыта вы наработаете в деле выявления по
добных деталей, тем точнее вы сможете оценить время работы над проектом и тем
больше вы будете убеждаться в том, что разрастание рамок проекта происходит
в результате недоработок специалистов, отвечающих за планирование.
Ïî áîëüøåé ÷àñòè, ðàçðàñòàíèå ðàìîê ïðîåêòà ïðîèñõîäèò ïî ïðè÷èíå íåäîðàáîòîê
ñïåöèàëèñòîâ, îòâå÷àþùèõ çà ïëàíèðîâàíèå.
Каков механизм совершенствования навыков временной оценки? Он очень
прост — поначалу вам предстоит неоднократно нарушать утвержденные графики
сдачи проектов, но, в конце концов, вы научитесь им соответствовать. Практика
эта довольно нервозная и даже угрожающая вашему карьерному росту. Возмож
но, это не лучший способ самосовершенствования, но что можно утверждать со
всей определенностью, так это то, что в области управления проектом опыт игра
ет огромную роль. А чтобы ускорить обучение, почитывайте анекдоты, относя
щиеся к руководству проектами. В своей леденящей душу коллекции очерков о не
удавшихся программных проектах Роберт Гласс (Robert Glass) составил список
наиболее распространенных «программных катастроф», который я привожу в по
рядке снижения значимости1.
1. Неадекватное специфицирование задач проекта (51 %).
2. Неудовлетворительные планирование и оценка (48 %).
1
Robert L. Glass, Software Runaways (Upper Saddle River, NJ: Prentice Hall, 1998), p. 20.
72
Ãëàâà 3 • Êàê âåñòè ñòàþ çà ñîáîé
3. Применение новой для данной компании технологии (45 %).
4. Негодная/отсутствующая методология руководства проектом (42 %).
5. Нехватка ведущих специалистов группы (42 %).
6. Срыв договоренностей производителями аппаратного/программного обеспе
чения (42 %).
Процентные показатели, приведенные для каждой из вышеупомянутых причин
несостоятельности, выведены Глассом в ходе специального исследования с целью
выявить основную причину выхода процесса разработки программных продуктов
из под контроля. Я очень рекомендую ознакомиться с этой и другими подобными
работами1. В результате вы поднимете процесс обучения на более осмысленный
уровень, получите определенное представление о реалистичном планировании
проекта, овладеете методикой контроля над разрастанием рамок проекта.
Êàê îáúåäèíèòü óñèëèÿ òåõ, êòî ãóëÿåò
ñàì ïî ñåáå
Речь не о кошках, а о программистах. О том, что они блуждают в потемках, можно
судить по характеру их кода, — он начинает походить на огромный памятник их
гениальности. Практика регулярного критического обзора кода помогает сносить
подобные монументы еще до того, как самовлюбленные хозяева их окончательно
возведут. Более подробно мы побеседуем об этом явлении в главе 6, полностью
посвященной техническому руководству. Пока что запомните один замечатель
ный принцип: творчество бесценно, а вот практичный и удобный в сопровожде
нии код можно не только оценить, но и продать. В ваши обязанности как руко
водителя входит координация деятельности программистов, направленная на
достижение максимальной функциональности за счет минимального объема кода.
Усложнение — это то, с чем вам предстоит вести постоянную борьбу. К понятно
сти кода придется идти мелкими шажками — благо, скорее всего, вам предстоит
бороться со смертными грехами программистов, такими как2:
недостаточное функциональное разделение при создании объектов и стыков
ке логических уровней;
непродуманные интерфейсы объектов;
чрезмерная взаимозависимость объектов;
пристрастие к усложнению внутреннего устройства объектов.
В попытках исцелить молодых и неопытных программистов проявляйте такт.
Упираются рогом? Ради бога — пусть некоторое время поучатся на собственных
ошибках; при этом не забывайте регулярно показывать им правильное направле
ние. Естественно, прежде чем допустить их код до компиляции, предложите свои
коррективы. Мы, программисты (впрочем, как и все человеческие существа), име
ем обыкновение совершать ошибки, лицезреть их последствия и только после
1
2
См. также Robert L. Glass, ComputingFailure.com (Upper Saddle River, NJ: Prentice Hall, 2001).
Это лишь немногие грехи. Существует множество альтернативных перечней. Добротный пример см.
в издании William H. Brown et al, AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis
(New York: John Wiley & Sons, 1998).
Îïàñíîñòü!
73
этого искать лучшие пути достижения тех же целей — так мы учимся. При том
условии, что допущенные ошибки будут исправлены до альфа тестирования, в них
нет ничего страшного.
 îòëè÷èå îò ïëîäîâ òâîð÷åñòâà, êîòîðîå áåñöåííî, ïðàêòè÷íûé è óäîáíûé â ñîïðîâîæäåíèè êîä ìîæíî íå òîëüêî îöåíèòü, íî è ïðîäàòü.
Îïàñíîñòü!
Если навыки программистов, которыми вы руководите, отличаются от ваших соб
ственных, скорее всего, возникнут трудности. Ну, скажем, вы специализируетесь
на VB, а сотрудники ваши делятся на приверженцев ASP и тех, кто пишет на тра
диционных языках. В таких условиях проводить критические обзоры кода вам
будет непросто, а это уже порождает некоторую опасность. Возможно, оконча
тельно определиться с тем, насколько качественно поработали ваши сотрудники,
удастся только на этапе итогового тестирования. Скорее всего, вам придется ос
новательно взяться за изучение новых языков и методов. Лишь в этом случае вы
сможете выполнять свои обязанности эффективно и не станете предметом насме
шек для программистов, которые, решая поставленные вами задачи, задействуют
в своих решениях кучу незнакомых понятий.
Если хотите снизить риск, связанный с попытками управлять кодом, который
вы не понимаете, заведите себе помощника, разбирающегося в неподвластных вам
языках. Проведение критических обзоров кода предполагает элементарное уме
ние его, скажем так, читать. В своем классическом труде о том роде человеческой
деятельности, который мы называем кодированием, Джеральд Вейнберг (Gerald
Weinberg) пишет:
«Несколько лет назад, когда язык COBOL еще называли будущим программи
рования, очень активно обсуждался вопрос о том, умеют ли руководители читать
программы. По прошествии времени кажется совершенно очевидным, что все
эти разговоры были нацелены лишь на выбивание средств из руководителей, стре
мившихся свести свою зависимость от программистов к минимуму. На самом
деле никто не верил, что руководители умеют читать программы. И с какой ста
ти они должны это делать? Ведь даже программисты не читают программы!»1.
Естественно, дальше по тексту автор утверждает, что руководитель обязан
уметь читать программы, и даже если не умеет, должен обязательно привлечь кого
то, кто с этой задачей справляется. В цитате упомянута зависимость от програм
мистов — это та самая вещь, от которой вы всеми силами будете стараться изба
виться. Найдите среди своих сотрудников кого то, кто смог бы помочь вам свести
к минимуму ущерб от недостатка знаний в тех или иных областях. Время от вре
мени вам придется сталкиваться с устаревшими технологиями, поскольку для
решения отдельных проблем они вполне адекватны. У руководителя есть еще одна
цель: состоит она в том, чтобы разрушать новые (и даже старые) границы,
1
Gerald M. Weinberg, The Psychology of Computer Programming: Silver Anniversary Edition (New York:
Dorset House Publishing, 1998), p. 5.
74
Ãëàâà 3 • Êàê âåñòè ñòàþ çà ñîáîé
открывая при этом новые пути в программировании, — те, по которым ранее ник
то не додумался пройти. Имейте в виду, что невежество очень опасно. Самое
страшное — это когда человек упорствует в своем невежестве, выдавая его за прин
цип; такое поведение иначе как глупостью не назовешь.
Готовность к постоянному углублению своих знаний есть одна из самых вы
годных черт руководителя. Если это не про вас, советую переосмыслить ваши ра
бочие обязанности или поискать новую работу. Дело в том, что в условиях посто
янного изменения технологий вы должны быстро схватывать новые идеи и трезво
оценивать их достоинства. Возможно, вы и не станете экспертом, но ориентиро
ваться в профессиональном сленге и специальных понятиях совершенно необхо
димо — в противном случае вы просто не сможете успешно проводить своих со
трудников через технологические джунгли.
Ãîòîâíîñòü ê ïîñòîÿííîìó óãëóáëåíèþ ñâîèõ çíàíèé åñòü îäíà èç ñàìûõ âûãîäíûõ ÷åðò
ðóêîâîäèòåëÿ. Åñëè ýòî íå ïðî âàñ, ñîâåòóþ ïåðåîñìûñëèòü ñâîè îáÿçàííîñòè èëè
ïîèñêàòü íîâóþ ðàáîòó. Äåëî â òîì, ÷òî â óñëîâèÿõ ïîñòîÿííîãî èçìåíåíèÿ òåõíîëîãèé
âû äîëæíû áûñòðî ñõâàòûâàòü íîâûå èäåè è òðåçâî îöåíèâàòü èõ äîñòîèíñòâà.
Êàê ñôîðìèðîâàòü êîìàíäó
è êàê åå ïîääåðæèâàòü
Еще одна неотъемлемая черта хорошего руководителя — это умение находить хо
роших сотрудников. Имейте в виду, что подчиненные судят о ваших лидерских
качествах исходя из того, каких новых специалистов вы приводите и от каких
избавляетесь. Вскоре вы, вероятно, обнаружите, что вопросы найма, увольнения
и вознаграждения из всех областей деятельности руководителя наиболее сложные.
С другой стороны, действия подобного рода обогащают ваш опыт как специалиста,
поскольку люди — это основной элемент процесса разработки программных средств.
Чем лучше ваши сотрудники, тем более грандиозных целей вы сможете достичь.
Если же вам придется иметь дело с персоналом уровня «ниже среднего», то боль
шую часть рабочего времени вы будете вынуждены посвящать решению тех за
дач, которые совершенно не способствуют достижению поставленных целей.
Êàê íàíèìàòü ñîòðóäíèêîâ
В процессе поиска новых сотрудников следует проявлять здравомыслие — в кон
це концов, вам самому придется сосуществовать с новыми людьми и помогать им
адаптироваться в команде. На это уходит много сил и времени, однако взвешенный
подход к вопросам найма гарантирует решение задач. Далее я привожу ряд фак
торов, которые обязательно нужно учитывать при поиске новых программистов.
Заставьте кандидата выполнить тестовое задание. Поставьте перед потенци
альным сотрудником задачу, которую он должен будет либо решить сразу, либо
взять на дом и решить к установленному сроку.
Обязательно проводите устную проверку навыков кандидата. Если у него есть
сертификаты, протестируйте его по одному из них и оцените полученные канди
датом знания, а заодно и его способность решать задачи в стрессовой ситуации.
Êàê ñôîðìèðîâàòü êîìàíäó è êàê åå ïîääåðæèâàòü
75
Если вам удастся убедить кандидата в том, что ему следует пройти сетевой
тест оценки личности, зная, что возможности такого рода проверки весьма ог
раничены, значит — действуйте.1
Составьте письменное описание предполагаемых функций кандидата и попро
сите его ознакомиться с ними непосредственно во время интервью. В отсут
ствие такого списка кандидат может подумать, что вы не знаете, что вам нуж
но, и будет говорить лишь то, что вы ожидаете от него услышать.
Не ограничивайтесь одним интервью. Если возможно, попросите одного из
ваших лучших и доверенных подчиненных провести с кандидатом еще одну
беседу. В то же время не позволяйте потенциальному сотруднику общаться со
всем персоналом — таким способом вы не добьетесь взвешенного решения.
Если вам доведется нанимать консультанта на ограниченный срок (а по дру
гому консультанты не работают), проблема вхождения в команду, по большому
счету, отпадет; тем не менее некоторые из вышеприведенных инструкций подхо
дят и для таких случаев. Остерегайтесь консультантов, которые демонстрируют
желание остаться у вас на постоянную работу. Преданные сотрудники, успевшие
поучаствовать в достижениях компании, в любом случае лучше, чем консультан
ты, которые думают в основном о том, сколько им будут платить за час работы
и как долго они смогут на ней продержаться.
В защиту консультантов скажу, что если в вашей команде не находится чело
века, способного принять в связи с какой то проблемой компетентное решение,
а такой человек вам необходим, смело обращайтесь к консультанту. Попытайтесь
сделать так, чтобы он как можно быстрее поделился своими знаниями с постоян
ными сотрудниками отдела. Хороший консультант должен быть нацелен на кон
структивное взаимодействие с вашими сотрудниками, анализ предложенной вами
проблемы, предложение идей, о которых вы по тем или иным причинам не поду
мали, и завершить на этом свою миссию. Иногда хорошие отношения с консуль
тантом позволяют предложить ему постоянную позицию в команде. Во многих
случаях такая возможность исключается договором о консультировании, однако
если таких ограничений нет, не упустите возможность проверить, как консуль
тант взаимодействует с сотрудниками, и только после этого принимайте оконча
тельное решение.
Обычно консультанты не заинтересованы в том, чтобы передавать клиентам
свои знания, — ведь это гарантия их дальнейшего пребывания на своей позиции.
В таких случаях сотрудникам приходится проводить дизассемблирование кода,
созданного консультантом, — это единственный способ разобраться в предложен
ном им решении. Подобная практика довольно распространена — в конце концов,
многие из нас учатся на примере мастеров программирования, результаты работы
которых можно встретить в книгах, существующих проектах, Интернете. Учиться
нужно при любой возможности и на любом примере. Старайтесь только не пасть
жертвой консультанта, оставившего вас, выражаясь словами Черчилля, лицом
к лицу с загадкой, которая завернута в головоломку, а головоломка — в ребус.2
1
2
Достойные тесты оценки личности есть на сайте http://www.advisorteam.com.
Это знаменитая фраза Черчилля — так он охарактеризовал Советский Союз перед началом Второй
мировой войны. Если будущее вашего продукта зависит от результатов работы скрытного консультанта,
будьте готовы к тому, что на его сопровождение уйдет много усилий.
76
Ãëàâà 3 • Êàê âåñòè ñòàþ çà ñîáîé
ÊÎØÀ×ÜÈ ÐÀÇÁÎÐÊÈ — ÁËÞÇ ÎÄÈÍÎÊÎÃÎ ÔÅÐÇß
Фрэнку жутко хотелось нанять нового сотрудника. Лишь недавно поднявшись до руко
водителя группы программистов, он горел желанием внести в ее кадровый состав свой
посильный вклад. Преклоняясь перед программистами из страны — королевы шахмат,
он нашел первое резюме с устраивавшими его характеристиками и назначил интервью.
Итак, перед ним сидел Алекс — человек, который, как Фрэнк вскорости узнал, мог иг
рать в шахматы без ферзя и при этом побить любого противника. Фрэнка совершенно не
смущали напряженные отношения Алекса с английским, ибо он был твердо уверен, что
этот программист способен создавать сногсшибательный код. Итак, Фрэнк нанял Алек
са, и с этого момента началась многолетняя история их занимательных профессиональ
ных и личных отношений.
В большинстве проектов Алекс проявлял себя исключительно творческим челове
ком. Он ухитрился организовать полноценный графический интерфейс пользователя
на черно белом жидкокристаллическом экране, на котором можно было вывести всего
четыре строки по 80 символов в каждой. В общем, остальные сотрудники группы оста
лись под впечатлением. В свободное время он смастерил для разрабатываемых продук
тов внутрисхемный эмулятор, с помощью которого значительно сократил продолжи
тельность отладки. Тем не менее с английским у Алекса так и не сложилось, и хотя Фрэнк
помог ему получить вид на жительство, нового сотрудника, по большому счету, так и не
приняли в свой круг его коллеги.
Понимая, что Алекс находится в изоляции, Фрэнк стал все чаще назначать его на
проекты, рамки которых не предполагали участия нескольких разработчиков. В течение
нескольких лет Фрэнк не мог нарадоваться результатам Алекса. Только вот остальные
сотрудники, которым приходилось сопровождать созданный Алексом код и которые по
этой причине постоянно на него жаловались, надоедали Алексу все больше. Он объяс
нял такое отношение профессиональной завистью и потому с легкостью отвергал все
возмущенные высказывания.
Через некоторое время Фрэнк ушел из родного банка и пустился в свободный полет.
Еще через несколько лет он пересекся с неким Бобом — владельцем конкурирующего
банка, который нанял Алекса по рекомендации Фрэнка. Боб тут же разразился ужасны
ми историями о том, как трудно ему пришлось с Алексом, которого в конечном итоге
уволили. Дело в том, что никто не мог справиться с расширением продуктов, которые
Алекс штамповал с большим апломбом и претензией на стиль.
Что стало с Алексом, неизвестно. Обе компании, в которых ему довелось работать,
потерпели значительные убытки, так как созданные им программные продукты так и не
продвинулись дальше первой версии. Парадоксально то, что Алекс в этом не виноват.
Все началось с ошибки Фрэнка, который предпочел «гениальные» программные мону
менты возможности работы в команде и потребности в практичном и допускающем со
провождение коде. Нанимая к себе в группу Алекса, Фрэнк поступил необдуманно —
в тот момент он делал то, что нужно было ему самому, и этот поступок не имел никакого
отношения к перспективам деятельности его компании. Поддерживая изоляцию Алекса
от других сотрудников, Фрэнк привел подведомственную ему группу к расколу — и все
из за того, что, по его мнению, выдающиеся способности могут компенсировать нечеткие
проектные решения. Делайте выводы. Нанимать умных людей недостаточно — их нужно
нанимать с умом!
Êàê óâîëüíÿòü ñîòðóäíèêîâ
Увольнение — это обратная сторона найма. Она в не меньшей степени выражает
ваши лидерские качества. Один единственный некомпетентный или просто про
Êàê ñôîðìèðîâàòü êîìàíäó è êàê åå ïîääåðæèâàòü
77
блемный сотрудник способен разрушить всю команду. При отсутствии ограниче
ний правового характера не стесняйтесь — если человек не попытался исправить
ся, смело увольняйте его. Если условия найма предполагают прохождение канди
датом испытательного срока, в продолжение которого он показал себя неспособ
ным к решению поставленных задач, обязательно воспользуйтесь законной воз
можностью его выгнать и действуйте, пока не поздно. Чем дольше в вашем окру
жении останется плохой программист, тем хуже для вашей команды, поскольку
сотрудники рискуют заразиться его вредными привычками. Кроме того, не забы
вайте, что судят о вас в том числе и по тому, как вы обращаетесь с людьми, кото
рые, по всеобщему мнению, должны уйти. Бездействие — тоже действие, причем
отрицательного характера. Не забывайте, что с тем, кто боится принимать реше
ния, когда ситуация совершенно ясна, случаются большие неприятности.
Если вы подумываете о том, чтобы уволить какого то сотрудника, спланируй
те свои действия заранее. Зафиксируйте в письменном виде те неверные действия,
которые предпринял сотрудник, и те трудности, причиной которых он стал. Пред
ложите ему один, последний, шанс исправиться. Некоторые специалисты утвер
ждают, что одного шанса мало, но, по моему опыту, даже две таких возможности —
это непозволительная роскошь. От вас как от человека, курирующего исправи
тельный период, потребуется слишком много сил; остальным же сотрудникам,
если им придется с ним работать, придется очень трудно. Тем не менее просчи
тайте возможные последствия увольнения для компании в целом. Попросите сво
его начальника оценить принятое вами решение. Какие проблемы, связанные с не
разглашением конфиденциальных сведений, могут появиться у компании в связи
с увольнением? Быть может, программист, от которого вы намерены избавиться,
обладает обширными знаниями и просто не успел их проявить. На эти и другие
связанные с увольнением вопросы вам придется ответить.
Кроме того, обязательно обдумайте влияние сокращения отдельного програм
миста на всех остальных сотрудников отдела. Им, скорее всего, захочется узнать,
по какой причине одному из их друзей дали «от ворот поворот». Впрочем, не сто
ит сообщать им все подробности — достаточно сказать, что уволенный специа
лист демонстрировал недостаточную продуктивность, в связи с чем его последу
ющее пребывание на должности противоречит интересам отдела. Помните, что
увольнение, помимо прочего, приводит к положительному эффекту — вы избав
ляетесь от проблемных сотрудников, а все остальные понимают, что присутствия
подобных деятелей в отделе вы не потерпите. Иногда подать сотрудникам такой
сигнал совершенно нелишне.
Äåíåæíîå ïîîùðåíèå è ïðîäâèæåíèå
ñîòðóäíèêîâ ïî ñëóæáå
Вопросов денежного вознаграждения я касался в главе 1. Скорее всего, именно
в этой области управления вы столкнетесь с наибольшими трудностями. Некото
рые предпочитают награждать новыми должностями, но никому пока что не уда
валось избежать практики денежного поощрения. Какую тактику избрать вам?
Одно из возможных решений нашло в 1960 х годах руководство Bell Labs — все
исследователи в этой лаборатории получали должность «научно технического со
трудника», и более высоких почестей, нежели вхождение в эту закрытую группу,
78
Ãëàâà 3 • Êàê âåñòè ñòàþ çà ñîáîé
в компании просто не существовало. Такая схема работает лишь в том случае,
если штат вашей организации набран исключительно из высококвалифицирован
ных сотрудников. В сегодняшних условиях обращение к ней зачастую не оправ
дано — с одной стороны, из за того, что должности в компании устанавливаете не
вы, с другой — из за стремления отдельных специалистов к звучным званиям. Есть
такая закономерность: чем моложе сотрудник, тем большее рвение он проявляет
в погоне за высокой должностью. У людей постарше другие приоритеты — им нуж
на интересная работа и хорошие деньги. Если сотрудник хочет всего вместе зна
чит — он либо действительно этого заслуживает, либо несколько неадекватно
оценивает свои способности. Поскольку интересную работу получают большин
ство программистов, вам придется довольствоваться вариантами вознаграждения
должностями и деньгами, основываясь при принятии решений на достоинствах
и опыте конкретного человека.
Продвигая сотрудников ввысь по должностной лестнице, делайте это с осто
рожностью. Обязательно оценивайте, по силам ли им новые обязанности. Мно
гие программисты, да и технари в целом, готовы всю жизнь довольствоваться ин
тересной и творческой работой, даже не задумываясь о том, чтобы принять на себя
руководящие функции. Учитесь определять максимальный доступный сотрудни
ку уровень обязанностей. Возможно, программист, за которым вы наблюдаете, смо
жет в будущем достичь большего, но обычно для этого человек должен в течение
определенного времени привыкать к выполняемому им уровню обязанностей. Как
только вы поймете, что со своими нынешними функциями он справляется впол
не успешно, можете поднять его еще на ступеньку вверх. Процесс продвижения
сотрудников, как правило, носит итерационный характер — подобно определе
нию коммерческих требований и макетированию. Прежде чем нагружать сотруд
ника более серьезными функциями, необходимо убедиться в том, что он справля
ется с текущими. Некоторые считают, что чем больше обязанностей выполняешь,
тем больше денег получаешь. В некотором отношении это так. В то же время сле
дует помнить, что жалование нужно увеличивать в ответ на повышение продук
тивности и эффективности выполняемой работы, а не просто за расширение ра
мок проекта и распределение обязанностей между подчиненными.
Некоторые компании выстраивают четкую иерархию технических сотрудни
ков, поднимаясь по которой любой квалифицированный специалист может полу
чать зарплату, сопоставимую с окладами высшего руководящего звена. Если вы
работаете в такой организации — что ж, здорово! Эта политика исключает стрем
ление технических специалистов получить руководящие должности лишь для
того, чтобы заработать больше денег. В таком случае не удивляйтесь, что некото
рые специалисты будут получать больше, чем вы. В организациях, где такая сис
тема практикуется, высокие зарплаты выдаются в основном тем сотрудникам,
которые помогли компании удержаться на плаву в трудные дни. Действительно
ли подобных передовиков, работающих в вашей компании, стоит оценивать фи
нансово выше, чем вас? Вполне может быть, что стоит, и вы должны ценить таких
людей, радоваться, что они есть в вашем распоряжении. В своей книге,восхваляю
щей искусство кодирования, Пит Макбрин (Pete McBreen) поднимает вопрос о ре
альной финансовой оценке ведущих разработчиков:
«Возможно, они стоят значительно большего, чем получают в данный момент.
Вероятно, они должны получать в пять или даже десять раз больше, чем сред
Íó õâàòèò óæå!
79
нестатистический разработчик… Чего на самом деле стоит человек, который
«спас» проект? Для того чтобы ответить на этот вопрос, имеет смысл оценить
последствия, которые могли бы наступить, если бы такой сотрудник перешел
в другую компанию»1.
Оценивайте своих сотрудников по достоинству. Платите им столько, сколько они
заслуживают. Не нужно чрезмерно экономить, иначе вы можете их потерять. Скорее
всего, вы слышали о классическом треугольнике «дешево — быстро — качественно»
применительно к процессу разработки программных средств. Так вот, из этих трех
качеств сочетаться могут только любые два. Если вы придерживаетесь практики при
влечения низкооплачиваемых сотрудников, то результат получите соответствую
щий — дешевое (во всех смыслах) программное обеспечение. Если хотите получить
качественный конечный продукт, имейте в виду, что за качество нужно платить.
Êàê ãîòîâèòü ïðååìíèêà
Что?! Я только что получил эту работу и воспитывать себе смену не собираюсь!
Этот ход мысли не отличается проницательностью. Никогда не забывайте о «факто
ре падающего кирпича». А вдруг вас приберет Бог или случится какое то несчастье?
Кто вас заменит (или сменит)? Как отдел продолжит работу? В некоторых ситуаци
ях кому то все равно придется исполнять ваши обязанности — для этого не обяза
тельно попадать в беду. Выстраивая свой стратегический план, вы должны посто
янно учитывать такие возможности и искать людей, способных время от времени
подменять вас. Это помогает, с одной стороны, выявить сотрудников, заслуживаю
щих более широкого круга обязанностей, с другой — определить набор высокоуровне
вых организационных задач, которые можно с уверенностью делегировать другим.
С поиском преемника тесно связана проблема углубления познаний сотруд
ников и формирования своеобразной «скамейки запасных». Если каждый из ва
ших программистов специализируется на определенном проекте, в случае его от
сутствия на рабочем месте вас ожидают серьезные неприятности.
В подготовке спортсменов широко применяется методика обучения смежным
видам; так почему бы не опробовать ее на программистах? Согласно распростра
ненному мнению, зрелость в профессии программиста наступает тогда, когда он
овладевает вторым языком. Таким образом, нужно стремиться к повышению ком
петенции персонала, с тем чтобы, переходя от одного проекта к другому, специа
листы не теряли темп работы и концентрацию. С вашей стороны для достижения
этой цели потребуется серьезное планирование, но, по большому счету, проблема
эта не нова — думать о том, как распределить задачи между программистами, ру
ководитель должен постоянно. Некоторые легко переходят от задачи к задаче,
у других такой мобильности не получается. Изучайте сильные и слабые стороны
своих подчиненных и пользуйтесь этими знаниями в интересах общего дела.
Íó õâàòèò óæå!
Полагаю, именно так вы сейчас мыслите. Действительно, быть руководителем
непросто — с вашей стороны требуются определенные усилия. Организационные
1
Pete McBreen, Software Craftsmanship (New York: Addison Wesley, 2001), p. 61.
80
Ãëàâà 3 • Êàê âåñòè ñòàþ çà ñîáîé
вопросы, которые вам предстоит решать, изрядно выматывают нервы. Впрочем,
эффективность ведения стаи в конечном итоге дает свои плоды, и немалые. В лю
бом случае команда значительно более продуктивна, чем отдельный человек, —
каким бы талантливым и работоспособным он ни был. Все те области деятельно
сти руководителя, которых я касался в этой главе, имеют отношение к вашим обя
занностям по эффективному кадровому обеспечению. Именно в этом и состоит
цель руководителя — сформировать группу сотрудников, способную последова
тельно проводить в жизнь крупные проекты. Мощь и энергия группы накаплива
ется путем совершенствования руководящих навыков.
Если попробовать свести содержание этой главы к нескольким четким и удо
боваримым принципам, получится, что руководитель:
расставляет приоритеты и борется с раздражителями (фокусируется на постав
ленных задачах);
совершенствует свои навыки в области руководства проектами и прорабаты
вает все их детали;
пресекает низкое качество кодирования, пока оно не пустило в проекте корни;
стремясь по достоинству оценивать технологические новинки, учится быстро
усваивать неизвестную информацию;
благоразумно относится к кадровому обеспечению и понимает, что именно от
людей зависит конечный успех проекта.
Посмотрите — я ухитрился уместить смысл всей главы в нескольких фразах.
Следуйте моему примеру: вместо того чтобы скверно делать множество дел, скон
центрируйтесь на нескольких задачах, но доведите их решения до совершенства.
Многозадачность — свойство микропроцессоров, но никак не людей.
×òî äàëüøå
Вам еще многое предстоит. Если бы руководить было так просто, этим занима
лись бы все без исключения. В следующей главе мы рассмотрим еще один аспект
лидерства, конкретнее — разберемся с тем, как усовершенствовать ваши органи
зационные навыки. А пока что отдохните. Заканчивайте с чтением на сегодня.
Займитесь чем нибудь приятным, уважьте свой ум и сердце.
Когда после этого вы с новыми силами возьметесь за книгу, мы разберемся,
как организовать вашу административную деятельность так, чтобы она принесла
успех. Можно сказать и так: с помощью следующей главы вы сможете превратить
теорию в практику. Для четкой постановки задач и их решения зачастую требует
ся пройти довольно болезненный этап изменения своих привычек. Прежде чем
менять свои действия, нужно исправить мышление; иначе без активных действий
вы рискуете превратиться в руководителя теоретика. В процессе выпаса котов вам
предстоит столкнуться с жесткими реалиями, набить себе шишек, поучиться на
собственных ошибках и, наконец, систематизировать тот хаос, который зачастую
царит среди находящихся в свободном полете программистов. Оставайтесь со
мной, и у вас все получится.
Гл а в а
4
Êàê îðãàíèçîâàòü óñïåõ
Первоочередная задача и желательный результат де
ятельности любого хорошего менеджера заключает
ся в обеспечении условий для достижения успеха
подведомственной ему группой разработчиков. Впро
чем, некоторые специалисты, занимающие ответствен
ные должности, позиционируют себя «всего лишь»
менеджерами и абстрагируются от лидерских аспек
тов деятельности. Если и вы придерживаетесь того
же мнения, значит, вы, возможно, перегружены повседневными задачами и вам
просто не хватает времени для стратегического планирования развития своей
группы. Поймите меня правильно — менеджер действительно должен следить за
тем, чтобы все текущие задачи своевременно исполнялись; лидер же, помимо ре
шения повседневных задач по повышению продуктивности сотрудников, концен
трируется на стратегических задачах своей группы и не ограничивает себя соблю
дением контрольных сроков. Менеджеры иногда погрязают в хитросплетениях
своей работы; лидеры, напротив, всегда стремятся разработать новые приемы, по
зволяющие подчиненным брать все более высокие планки. Этот своеобразный
конфликт между функциями менеджера и качествами лидера напоминает хожде
ние по канату — в том смысле, что нам все время приходится уравновешивать две
в равной степени значимые для нашей профессии роли.
Если бы перед нами стояла проблема однозначного выбора, наверное, можно бы
ло бы сказать, что лидерство важнее руководства. С другой стороны, если не уделять
внимания не слишком связанным, на первый взгляд, с практикой аспектам руко
водства (в частности, организационным навыкам), времени на реализацию лидер
ских качеств просто не останется. Чем более организованным вы станете — как
с личностной, так и с профессиональной точки зрения, — тем легче будет поддер
живать баланс между руководством и лидерством. Организованный менеджер сам
создает для себя условия, в которых лидерские качества начинают расцветать.
Îðãàíèçîâàííûé ìåíåäæåð ñàì ñîçäàåò äëÿ ñåáÿ óñëîâèÿ, â êîòîðûõ åãî ëèäåðñêèå
êà÷åñòâà íà÷èíàþò ðàñöâåòàòü.
82
Ãëàâà 4 • Êàê îðãàíèçîâàòü óñïåõ
Нарабатывая личностные и профессиональные организационные навыки, ни
когда не забывайте о конечной цели, — она состоит в том, чтобы заставить время
работать на вас, а не против вас. Если время — ваш союзник, у вас появляется
возможность уделять лидерским качествам больше внимания — просто по той при
чине, что в таком случае вы сами управляете организационными вопросами, а не
они направляют вашу деятельность. Когда вам кажется, что задач слишком мно
го, а времени слишком мало, знайте: время работает против вас. Неорганизован
ность приводит к развитию фобий, происходящих от опасения забыть подробно
сти многочисленных задач, которые вам предстоит решить.
Стремиться к самоорганизации мало — вы должны помогать компании совер
шенствовать организацию действий и процессов, которые непосредственно каса
ются разработки программных средств. Если вы будете действовать подобным
образом, сотрудники подведомственной группы поймут, что вы способны ими
руководить, — и, соответственно, будут нацелены на достижение результата. Имен
но это и является основной целью любой организационной схемы — сделать ус
пех ожидаемым результатом рутинной работы. Так оно и происходит, поcкольку
вся деятельность сотрудников становится более эффективной, а значит, ресурсы
персонала используются по максимуму.
Êàê ïðåâðàòèòü èíôîðìàöèþ â çíàíèÿ è äåéñòâèÿ
Возможно, это слишком упрощенный взгляд на повседневные обязанности ме
неджера, но мне кажется, что все ваши действия правомерно рассматривать как
отдельные проекты по преобразованию информации в знания и действия. Неко
торые из этих проектов чрезвычайно просты — к таким, к примеру, относится от
вет на письмо, полученное по электронной почте. Иные, напротив, отличаются
сложностью — отнесем к ним разработку плана модификации принятой в компа
нии программной архитектуры. Во всех подобных проектах есть детали — иначе
говоря, поток информации и знаний, которые требуется отслеживать, совершен
ствовать и каким то образом структурировать с целью выстраивания плана по
следующих действий. Как правило, все действия по реализации этих ваших мел
ких проектов производятся за рабочим столом и за компьютером, который с ним
неразрывно связан.
Теперь скажите мне: как в данный момент выглядит ваш рабочий стол? Ско
рее всего, он завален бумагами и папками. Это совершенно нормально и вполне
допустимо, если они не лежат на одном месте неделями. Чем более запущен рабо
чий стол, тем больше опасность забыть о каком то проекте, который требуется
выполнить незамедлительно. Попробуйте его почистить — и, скорее всего, вы на
ткнетесь на информацию, которая подразумевает оперативную реакцию с вашей
стороны. Наверное, вы слышали выражение «найдите для всего место и разложи
те все по своим местам». Это очень достойное правило; однако, следуя ему, не
стоит забывать, что задача по организации «мест» является приоритетной. Со
знайтесь самому себе в том, что награда «лучшей домохозяйке» за поддержание
рабочего места в порядке вам не светит и стремиться к ее завоеванию бессмыс
ленно. Что вам действительно нужно, так это создать для себя функциональные
рабочие условия, не позволяющие забывать повседневные задачи, связанные с ру
ководством группой разработчиков.
Êàê ïðåâðàòèòü èíôîðìàöèþ â çíàíèÿ è äåéñòâèÿ
83
Некоторые считают прибранный рабочий стол свидетельством того, что у его
хозяина не все в порядке с головой. Мне так не кажется, хотя вы имеете полное
право на собственную точку зрения. Впрочем, я не могу не согласиться с тем,
что если вы не способны держать свой дом в чистоте и порядке, у вас ни за что
не получится руководит деятельностью других людей. Как происходит уборка
дома? Вы протираете пол, пылесосите, поднимаете вещи, которые свалились на
пол и мешают проходу, — иначе говоря, создаете условия, способствующие ком
фортному проживанию. Не кажется ли вам, что рабочее место должно быть при
мерно таким же? Я глубоко убежден, что удобное рабочее место является пред
посылкой успешной, продуктивной работы. Вы прекрасно знаете, что неупоря
доченный код существенно затрудняет процесс разработки и сопровождения
программного продукта; аналогичным образом неприбранный рабочий стол дос
тавляет руководителям немало неприятностей. Под «неприбранностью» я в дан
ном случае имею в виду бессистемность в деле организации ваших повседнев
ных задач, которая произрастает от неверного управления информационным
потоком.
Åñëè âû íå ñïîñîáíû äåðæàòü ñâîé äîì â ÷èñòîòå è ïîðÿäêå, ó âàñ íè çà ÷òî íå
ïîëó÷èòñÿ ðóêîâîäèòü äåÿòåëüíîñòüþ äðóãèõ ëþäåé.
Áóìàæíàÿ âîëîêèòà
Несколько десятилетий назад, прежде чем персональные компьютеры стали не
отъемлемым атрибутом нашей рабочей деятельности, все детали проекта фикси
ровались в тетрадях и папках для документов. Сегодня — в условиях, когда ос
новным средством структурирования выступают компьютеры, — роль бумажных
носителей до известной степени снизилась, и в процессе повседневного руковод
ства деятельностью специалистов в рамках проекта бумага уже не играет такой
роли, как раньше. Тем не менее, поскольку концепция безбумажного делопроиз
водства далека от реализации, скорее всего, иметь дело с бумагой нам предстоит
еще очень долго. Несмотря на некоторые недостатки, бумажные носители в це
лом неплохо справляются со структурированием информации. Если взвесить все
сильные и слабые стороны бумаги, то можно утверждать (и вы, наверное, со мной
согласитесь), что:
бумажные носители очень удобны в тех случаях, когда информацию требуется
изучить именно в то время и в том месте, в котором вам удобно;
на бумаге удобно фиксировать ход дискуссии на совещании и в телефонном
разговоре — писать на листке бумаги чуть проще, чем набирать текст на ноут
буке;
бумажные носители не адаптированы для хранения, поиска, сортировки и мно
гих других операций, с которыми блестяще справляются программные про
дукты;
многие из нас воспринимают важную информацию лучше, считывая ее с бу
мажного носителя, и хуже, считывая ее с монитора;
84
Ãëàâà 4 • Êàê îðãàíèçîâàòü óñïåõ
заложники собственной культуры, мы привыкли воспринимать информацию,
зафиксированную на листах прямоугольной формы размером 210 × 297 мм.
Вполне возможно, что в будущем планшетные компьютеры смогут объединить
в себе достоинства бумаги с широчайшими возможностями программного обес
печения. Лично я все жду, когда же появятся жидкокристаллические экраны тол
щиной с лист бумаги, на которых можно будет писать ручкой и карандашом,
стирать записанную информацию, сохранять ее в электронном виде, а затем пере
загружать на тех же листах уже другие данные. Не знаю, дождусь ли, — ведь хо
чется, чтобы такие экраны продавались в магазинах пачками по 500 штук и сто
или не более 3,95 доллара.
В защиту бумаги отмечу, что на протяжении большей части XX века она оста
валась основным носителем коммерческой информации и, скорее всего, в бли
жайшее время все еще будет играть важную роль. Скорее всего, вы поняли, к чему
я это все говорю. Да, действительно — управляться с горами листов очень непро
сто. Они постоянно устаревают, вам вечно приходится думать о том, как бы не
обанкротиться на одних только картриджах и т. д., и т. п.
Как же справиться с бумажной неразберихой? Придется усвоить несколько
основополагающих принципов. Они излагаются на всех учебных курсах по осно
вам бизнеса, но, по моему, их стоит вспомнить и здесь1. Может быть, вам пока
жется, что принципы, которые я здесь излагаю, самоочевидны, но вы не представ
ляете, какое количество менеджеров испытывают страшные мучения в попытках
как то упорядочить кипы бумаг — и все по той простой причине, что они игнори
руют правила систематизации.
Итак, в том, что касается структурирования бумажных материалов, я предла
гаю соблюдать нижеследующие принципы.
Создайте стройную систему хранения документов. Для каждого проекта заве
дите отдельный набор папок для документов или тетрадей. В любой папке про
екта нужно держать только наиболее важные бумаги и все их снабжать датой
и ссылкой на источник. Папки проекта имеет смысл делить на разделы в соот
ветствии с типами информации, как то: область действия, проектное решение,
ошибки, обмен информацией, материалы совещаний и т. д.
Следуйте системным правилам хранения документов. По завершении проекта
сдайте относящиеся к нему папки в архив. Под рукой должны быть только те
материалы, которые относятся к текущим проектам, а информацию о выпол
ненных проектах следует незамедлительно перемещать в другое место.
Каждый листок бумаги, который по тем или иным причинам появился на ва
шем рабочем столе, необходимо переложить в соответствующую папку. Не
доводите дело до появления на столе груды бумаг. Не забывайте, что папка
для входящих документов — это лишь временный резервуар и ни в коем случае
не постоянное хранилище. Стоит на вашем столе появиться кипам бумаг, как
вы незамедлительно начнете опаздывать с выполнением организационных
функций, которые, вполне возможно, необходимы для достижения успеха.
1
Я просмотрел несколько изданий по бизнесу и кое какие из них мне понравились. В частности, возь
мите на заметку издание Ronni Eisenberg. Organize Your Office (Hyperion, 1998).
Êàê ïðåâðàòèòü èíôîðìàöèþ â çíàíèÿ è äåéñòâèÿ
85
Заведите для каждого проекта несколько папок различных цветов; каждый та
кой цвет должен указывать на срочность действий, связанных с хранящимися
в папке документами. К примеру, в красных папках можно собирать информа
цию, которая требует с вашей стороны незамедлительных действий. В синих пап
ках имеет смысл хранить документы, с которыми можно ознакомиться чуть
позднее, а в зеленых — все документы, связанные с денежными вопросами. Все
эти правила просты и очевидны; если их не забывать, то даже после беглого про
смотра документов вы сможете определиться с тем, что делать в первую очередь.
Организуйте отдельное место для хранения литературы и соблюдайте в нем
порядок. Скажем, профессиональные журналы нужно хранить отдельно от
каталогов производителей. Все эти материалы следует сортировать по дате
выхода и не слишком загромождать ими рабочее пространство. Если из целого
журнала вашего внимания заслуживает единственная статья, вырежьте ее, по
ложите в стопку, а от остальных страниц избавьтесь. Не стоит копить макула
туру лишь с той целью, чтобы удивить самого себя.
Скорее всего, в том, что касается систематизации бумажных документов, у вас
есть какие то собственные приоритеты и методы; возможно также, что в вашей
компании существует четкая политика по этой части. Если вы не справляетесь
с постоянно поступающими бумажными документами, скорее всего, это приведет
к смещению приоритетов. Если бы безбумажное делопроизводство уже превра
тилось в реальность, то никому не нужно было бы подключать к корпоративным
сетям многочисленные принтеры. Однако если уж вы ими пользуетесь, будьте
любезны, разберитесь в своих распечатках.
Áåçáóìàæíàÿ âîëîêèòà
Бумажные документы — это не единственная область, которую вам как менеджеру
придется приводить в порядок. Несмотря на то что личные информационные сек
ретари (Personal Information Managers, PIM) представлены на рынке в большом
количестве, большинство руководителей до сих пор испытывают серьезные труд
ности в попытках организации электронных документов. Вполне возможно, что
вы уже пользуетесь тем или иным программным продуктом для руководства про
ектом, он принят в вашей организации — и от него есть прок; если так, вы — счаст
ливый человек. В то же время, по моим наблюдениям, многие компании и, в особен
ности, отдельные лица подходят к задаче систематизации электронных документов
крайне индивидуально. Я неоднократно пытался приучить себя к применению раз
нообразных программ для руководства проектами и в результате понял, что все
они оставляют желать лучшего. Я, пожалуй, не буду их называть. Выражусь так:
все продукты одной компании, весьма популярной в северо западных штатах Аме
рики, оказались, с моей точки зрения, либо слишком сложными, либо чересчур
ограниченными по своим возможностям, либо элементарно не соответствующи
ми моим потребностям по части отслеживания организационных вопросов. Ну
ладно, я назову имена — Microsoft Project, Team Manager (этот продукт постав
ляется на компакт дисках MSDN). Не подошли мне и многочисленные видоиз
мененные (в плане объектной модели) версии Outlook. Lotus Notes, ACT!
и многие другие личные информационные секретари вместе с программными
продуктами для групповой работы также показались мне недостаточно гибкими
86
Ãëàâà 4 • Êàê îðãàíèçîâàòü óñïåõ
и не подошли для систематизации моих рабочих процессов. Я вполне допускаю,
что один из этих продуктов подойдет вам. Если так случится, вы получите шанс
заметно продвинуться в деле ведения стаи за собой. Если же чуда не произойдет,
придется обратиться к другому методу.
Так что же делать? Ведь я программист; все продукты, которые мне не понра
вились, созданы программистами; кроме того, я ностальгирую по тем временам,
когда писал гораздо больше кода, чем сегодня. Таким образом, ответ для меня
очевиден — нужно создать собственную программу управления проектами.
Ýëåêòðîííûé àäìèíèñòðàòîð
Итак, я поставил перед собой задачу создать программный продукт, с помощью ко
торого мне было бы удобно справляться со своими организационными обязаннос
тями. Он должен был стать чем то средним между личным информационным сек
ретарем и полноценной программой управления проектами; естественно, я также
намеревался избавиться от излишнего усложнения и ограничений, присущих обо
им названным типам программных продуктов. Работать над своим проектом мне
пришлось по ночам, в нерабочее время и в гордом одиночестве. За первые полго
да применения своего детища я скомпоновал более 200 исполняемых версий —
все это время я обнаруживал очередные ошибки и подстраивал продукт под свои
потребности. Несколько раз он очень помог мне справиться с административны
ми задачами. По крайней мере, теперь, когда он у меня есть, я четко знаю, на сколь
ко опаздываю, мне не приходится постоянно трястись от неопределенности и со
знания груза несделанных дел. У меня хотя бы есть возможность измерить этот
самый груз и распечатать соответствующий отчет — из него я узнаю, сколько но
чей придется провести без сна, чтобы успеть все сделать к установленному сроку.
У моего личного проекта было несколько очевидных преимуществ. Во пер
вых, мне не пришлось собирать коммерческие требования, поскольку сценарии
вариантов действий проявлялись регулярно. Во вторых, в роли пользователя вы
ступал я сам, а значит, реализация потребностей пользователя ограничивалась
конструированием подходящего мне интерфейса. Это ведь мечта программиста —
писать программы для самого себя. На этапе бета тестирования я также не встре
тил никаких особых проблем. Обнаруживая ошибки, я брал исходный код и ис
правлял их. Помимо прочего, при работе над этим проектом я не испытывал син
дромов, часто встречающихся у нагруженных административными функциями
программистов, у которых не находится достаточного времени для кодирования.
Оторваться от клавиатуры ведь довольно трудно, не так ли?
Итак, далее я познакомлю вас с собственноручно разработанным программ
ным продуктом, который, по моему скромному мнению, помогает успешно орга
низовать производственный процесс, направленный на достижение результата.
Если этот продукт вам понравится (или вы осмелитесь адаптировать его к соб
ственным потребностям), обратитесь к приложению А. В нем приводится более
подробная информация, а также сведения о том, как получить исходный код.
Çàäà÷à êàê îáúåêò — îñíîâíîé îðãàíèçóþùèé
ïðèíöèï ýëåêòðîííîãî àäìèíèñòðàòîðà
По большому счету, все задачи, которые решаются в ходе разработки программ
ных продуктов и соответствующей административной деятельности, можно раз
делить на три типа.
Êàê ïðåâðàòèòü èíôîðìàöèþ â çíàíèÿ è äåéñòâèÿ
87
1. Проекты. Все задачи аккумулируются в рамках проекта — довольно удобной
классификационной конструкции, связывающей те виды деятельности, кото
рые направлены на производство качественного кода и зарабатывание денег
для компании. Отдельные проекты, впрочем, не связаны с созданием продук
та, предназначенного для продажи; однако если основным приоритетом для
вас является успех компании на занятых ею рынках, вы, вероятно, согласитесь
со мной в том, что любые продукты воплощаются в жизнь лишь благодаря спо
собности группы разработчиков к созданию успешного программного обе
спечения.
2. Источники. В качестве источника — то есть субъекта, поставившего задачу, — в за
висимости от ситуации может выступать человек (зачастую вы сами), процесс
или комитет (члены которого обычно не в меру ворчливы). Классификация
задач по источникам помогает следить за выполнением собственных обещаний —
в особенности если вы имели неосторожность дать их своему начальнику.
3. Назначенные задания. За распределение заданий между сотрудниками рабо
чей группы ответственны вы. О тех людях, с которыми вам приходится рабо
тать, я говорил на протяжении трех предшествующих глав. Теперь же мы об
ратимся к более приятной теме неодушевленных объектов. Обычно они молчат,
хотя наличие на моем компьютере синтезатора речи лишает их этой замеча
тельной особенности. Я немного отвлекся, хотя здесь тоже прослеживается
важный принцип, касающийся перевода из рядов программистов в менедже
ры. Мы лучше обращаемся с «вещами», чем с людьми.
Ну ладно, хватит разглагольствовать! Лучше взгляните на рис. 4.1 — он пред
ставляет собой графическую иллюстрацию представленной выше концепции.
Ðèñ. 4.1. Çàäàíèå
88
Ãëàâà 4 • Êàê îðãàíèçîâàòü óñïåõ
Как и обещано, на этой схеме изображены все три отношения между задачей,
с одной стороны, и информационным потоком и процессом администрирования,
с другой.
За утверждением задачи — в том виде, в котором она представлена на нашей
схеме — следует этап ее реализации в программном продукте. На рис. 4.2 в тра
дициях классического двухзвенного1 MDI приложения с нагруженной клиент
ской частью (в эпоху веб приложений2 такая схема кажется очевидно устарев
шей) изображен графический пользовательский интерфейс, реализующий пред
ставленный выше принцип.
Ðèñ. 4.2. Ðåàëèçàöèÿ çàäà÷è
Согласно моей задумке, в окне, показанном на рис. 4.2, должны умещаться все
данные, с помощью которых можно идентифицировать задания и отследить их
выполнение. Три основных отношения — источник, назначенные задания и про
ект — дополняются стандартными и вполне ожидаемыми параметрами: состоя
нием, сроками начала и завершения, а также приоритетом. Кроме того, в моей
версии программы присутствует запись ссылка на область действия3. В некото
рых компаниях она может сослужить хорошую службу. Среди прочих нелишних
характеристик стоит упомянуть возможность создания документа с данными по
конкретной задаче и, естественно, возможность сохранения собранной информа
ции в базе данных. Раздел Details я выполнил в виде форматируемого поля, в ко
1
2
3
Имеются в виду не логические, а физические звенья.
Я пробовал структурировать электронного администратора в качестве веб приложения, но такая схе
ма не подходит моим программистам. Я их не виню; в конце концов, я должен давать задания, а они —
выполнять их. Кроме того, мне не нравится ограниченность веб интерфейса.
Присутствие этой записи подразумевает наличие документации относительно области действия, в ко
торой характеристики конструируемого продукта представлены в виде нумерованного списка.
Êàê ïðåâðàòèòü èíôîðìàöèþ â çíàíèÿ è äåéñòâèÿ
89
торое можно встраивать внешнюю графику, — как известно, один рисунок спосо
бен сообщить программисту больше, чем тысяча слов.
Îòîáðàæåíèå è ñèñòåìàòèçàöèÿ çàäàíèé
После того как сведения о задании зафиксированы, их, конечно, нужно отобра
зить — да так, чтобы из них можно было делать какие то выводы. Как менеджер
вы, естественно, вынуждены ежедневно составлять список заданий, требующих
безотлагательного выполнения; кроме того, вы стремитесь к тому, чтобы каким
то образом отслеживать выполнение срочных заданий теми сотрудниками, кото
рым вы их поручили.
Решение, к которому я обратился, предполагает наличие дочернего MDI ин
терфейса, способного собирать в одном месте всю информацию о критически важ
ных заданиях на сегодняшний день. Повторюсь: для того чтобы обеспечить соот
ветствие конструируемого программного продукта задачам, которые он должен
решать, необходимо постоянно подгонять самого себя и отслеживать работу под
чиненных. В противном случае вы рискуете не справиться со своими функциями.
Вспомните меткий призыв из главы 2 относительно ожидания результатов без
проведения проверок, который я позаимствовал у какого то университетского про
фессора. Отталкиваясь от его смыслового наполнения, я сконструировал пока
занный на рис. 4.3 экран.
Ðèñ. 4.3. Ýêðàí ðàáî÷åãî äíÿ
90
Ãëàâà 4 • Êàê îðãàíèçîâàòü óñïåõ
Среди прочих элементов экрана рабочего дня есть календарь. Он помогает мне
вспомнить, какой сегодня день, что после долгих бессонных ночей, проведенных
в праведном труде, бывает довольно сложно. Кроме того, есть на этом экране и об
ласть встреч, тесно связанная со схемой задания. Строго говоря, встреча — это
тоже задание, предусматривающее очное или заочное общение с людьми. Посколь
ку моя система включена постоянно, с помощью таймера каждую полночь пред
ставление экрана рабочего дня в ней обновляется.
В программе присутствует средство генерации отчетов о задачах и встречах
руководителя, а также списках назначенных заданий. Их можно как распечаты
вать, так и экспортировать. Любой список заданий предусматривает возможность
фильтрации по сроку завершения в виде функции текущей даты; переключатели
позволяют оперативно устанавливать разные режимы: режим сегодняшних зада
ний и всех долгов с предыдущих дней, режим заданий до 5 дней, начиная от теку
щей даты, а также представление всех заданий. Каждую полночь таймер в этой
форме переустанавливает заголовки фильтров, чтобы они все всегда соответство
вали заданному диапазону в 5 дней от текущей даты. Для того чтобы ввести новое
задание с помощью предварительно выделенного комбинированного окна Assigned,
щелкните на кнопке Add Mng Task. Для назначения нового задания щелкните на
кнопке Add Asg Task.
В приложении А приводятся более детальные сведения об электронном адми
нистраторе (эта программа стала моим любимым проектом), а также о применен
ных в ходе его конструирования методиках и компонентах.
Êàê âûðàáîòàòü ñîáñòâåííûå
íàâûêè àäìèíèñòðèðîâàíèÿ
Я уже перечислил несколько принципов организации информационного потока
в пределах вашего рабочего стола. В то же время я не рекомендую слепо копиро
вать мои методы. К ним стоит обращаться лишь в том случае, если они соответ
ствуют конкретным организационным потребностям или имеют шанс стать хоро
шей отправной точкой для создания ваших собственных методик. Как сортировать
бумаги по папкам, вы, вероятно, знаете, так что на этом я останавливаться не буду.
Вполне возможно, что вы уже пользуетесь одним из многочисленных представ
ленных на рынке продуктов управления проектами. Если он отвечает вашим по
требностям — замечательно. С другой стороны, довольно часто недостаток гибко
сти применяемых инструментальных средств принуждает руководителей адап
тироваться к процессам, которые не слишком согласуются с их повседневной
деятельностью. По моим наблюдениям, гибкость инструментов, которые приме
няются для систематизации информации, вносит существенный вклад в дости
жение успеха. Очевидно, что возможность создания собственного программного
продукта предоставляет вам максимальную гибкость по части решения организа
ционных вопросов. Вашей задачей в этом контексте должна стать корректировка
своей организационной деятельности, направленная на точное соответствие кон
кретным функциональным обязанностям. От этого во многом зависит способность
достижения качественных результатов, причем со временем, по мере изменения
условий, организационные методы нужно регулярно пересматривать.
Êàê îðãàíèçîâàòü êîíòðîëü
91
Не следует питать иллюзий — комплексный проект с многочисленными взаи
мозависимостями нельзя вести исключительно средствами простых программных
продуктов вроде того, что я описал в предыдущем разделе. Решение о том, подхо
дит ли тот или иной продукт для конкретного проекта, всецело зависит от вас.
Более того, вы должны сами себя оценивать по части ведения всех организацион
ных вопросов в своем отделе. Слово «администрирование» (administration) про
исходит от словосочетания «добавочное министерство» (added ministry); в неко
тором смысле, администрирование по отношению к основным задачам не является
приоритетной областью вашей деятельности. Вопрос в том, сколько сил и энер
гии вы затрачиваете на улаживание организационных вопросов. Необходимо все
гда иметь в виду, что в процесс вашей повседневной деятельности постоянно бу
дут вмешиваться разного рода проблемы, которые придется решать дополнительно
к выполнению ваших непосредственных функций. Повышая уровень своей лич
ностной организации, вы фактически сокращаете сроки исполнения своих перво
очередных заданий.
«Непосредственные функции» — выражение весьма двусмысленное. Адми
нистрирование — это полноценная область деятельности, и заниматься ею не
обходимо. В то же время программисты менеджеры воспринимают администра
тивные функции в штыки. Здесь можно провести параллель с кодированием
и комментированием. Код без комментариев трудно читать. Аналогичным об
разом руководство без администрирования становится неорганизованным и да
же (иногда) неверным по своей сути. В этой книге я исхожу из того, что вы обя
заны вести сотрудников своего отдела к намеченным целям. При этом ключевую
роль как в чисто внешнем, так и в фактическом аспекте лидерства играет эф
фективная и стройная система администрирования.
Êëþ÷åâóþ ðîëü êàê â ÷èñòî âíåøíåì, òàê è â ôàêòè÷åñêîì àñïåêòå ëèäåðñòâà èãðàåò
ýôôåêòèâíàÿ è ñòðîéíàÿ ñèñòåìà àäìèíèñòðèðîâàíèÿ
Дирижер и оркестр — еще одна подходящая аналогия. Музыкальные произве
дения исполняются оркестрантами, однако не будь дирижера, любая симфония
превратилась бы в какофонию. Если вам доводилось наблюдать за тем, как орке
странты перед выступлением настраивают свои инструменты, вы понимаете, что
такое какофония. Администратор действительно имеет много общего с дириже
ром. Поэтому вы должны стремиться к тому, чтобы стать почтенным маэстро.
Учтите также, что в своей деятельности дирижер исходит из отличительных осо
бенностей оркестра, которым дирижирует. Если в вашем подчинении опытные
и профессиональные сотрудники, административным вопросам не понадобится
уделять много времени. Если же вам приходится руководить новичками, то вы
вряд ли обойдетесь без формальной организационной структуры.
Êàê îðãàíèçîâàòü êîíòðîëü
«Контролировать или не контролировать?» — Гамлет тоже пытался решить подоб
ную дилемму. Правда, в его случае онтологические последствия решения оказались
92
Ãëàâà 4 • Êàê îðãàíèçîâàòü óñïåõ
куда более серьезными. Ваши мучения обещают оказаться не столь жизненно важ
ными. В то же время имейте в виду, что достижение результата в компании зави
сит от самых разных процессов. Некоторые из них поддаются контролю с вашей
стороны, другие — нет. Именно поэтому важно, как вы организуете процессы, как
справляетесь с теми процессами, которые можно контролировать. Личностная
организация позволяет справляться с внешними дезорганизующими факторами,
какими бы серьезными они ни казались. Будьте уверены — остальные сотрудни
ки компании отчаянно борются с организационными хитросплетениями так же,
как и вы. Присмотритесь к ним. Перенимайте у них удачные идеи и не забывайте
предлагать им свои.
Рассмотрим список подконтрольных и неподконтрольных областей (табл. 4.1).
Òàáëèöà 4.1. Ïîäêîíòðîëüíûå è íåïîäêîíòðîëüíûå îáëàñòè
Ïîäêîíòðîëüíûå îáëàñòè
Íåïîäêîíòðîëüíûå îáëàñòè
Ìåòîäû è äåéñòâèÿ, íàïðàâëåííûå
íà óïîðÿäî÷åíèå è ñèñòåìàòèçàöèþ
èíôîðìàöèè
Ðàñïðåäåëåíèå êîíêðåòíûõ çàäà÷
ìåæäó ñîòðóäíèêàìè îòäåëà
Этот список можно расширять очень долго и довести до нескольких страниц.
Мне хочется, чтобы вы осознали важность проблем, связанных с контролем, и по
няли, что самоорганизация, направленная на достижение результата, заключает
ся в достижении максимального контроля над рабочей ситуацией. Стоит немного
углубиться в проблемы контроля, и вы поймете, почему так происходит.
Èíôîðìàöèîííûé ïîòîê
Все мы живем в информационную эпоху, в которую для успешного производства
программного обеспечения необходима способность концентрироваться на реше
нии той или иной коммерческой задачи. Процесс этот предполагает анализ ин
формационного потока, проходящего через компанию и относящегося к опреде
ленным коммерческим потребностям, и усвоение этой информации. Ответить на
все вопросы сразу и самостоятельно никогда не удается — следовательно, отдель
ные проблемы приходится решать с помощью других людей. Иногда объем дан
ных, с которыми мы регулярно сталкиваемся, буквально сводит с ума. Впрочем,
не зря в предыдущих разделах я говорил об организации деталей проекта — эти
действия способны не допустить ступор, наступающий при организационной пе
регрузке.
Êàê îðãàíèçîâàòü êîíòðîëü
93
Как получилось, что традиционные мифы и суеверия эволюционировали до
состояния современной науки? Дело в том, что со временем к изучению природы
во все большем объеме стали привлекаться научные методы. Поскольку природа
в высшей степени информативна, первым этапом любого исследования является
классификация. Отсюда проводим прямую параллель с организационными мето
диками. Вы имеете полное право не понимать какую то часть тех данных, с кото
рыми сталкиваетесь; однако если вы сумеете классифицировать их, разбить на
отдельные тематические группы, считайте, что первый шаг по направлению к зна
ниям сделан.
Объем воспринимаемой информации часто не поддается контролю, однако ме
тоды, применяемые для ее систематизации, вполне управляемы. Отчасти работа
руководителя напоминает труд библиотекаря; хочу, впрочем, заметить, что при
менительно к хорошему руководителю эта аналогия носит исключительно пози
тивный характер. Зная, куда обратиться в поисках необходимой информации, вы
получаете неоспоримое преимущество перед теми руководителями, которые под
ходят к своим обязанностям неорганизованно и потому не ориентируются в ин
формационном пространстве.
Столкнувшись с новым информационным блоком проекта, задайте себе не
сколько вопросов.
Как новые данные отражаются на области действия проекта, на проектном ре
шении, на конечном сроке сдачи проекта?
Надежен ли источник информации; если нет, то можно ли его проигнориро
вать?
Следует ли реагировать на поступление информации незамедлительно или
можно немного подождать?
Где и как сохранить информацию с тем, чтобы при необходимости к ней мож
но было бы оперативно обратиться?
Каков срок действия информации? Когда она становится неактуальной?
Как данная информация соотносится с тем, что уже известно о проекте?
Эти и подобные вопросы направлены на систематизацию данных. Системати
зируя данные, вы обретаете контроль над ними, и, соответственно, они теряют
контроль над вами.
Íàçíà÷åíèå çàäàíèé
Правда, было бы замечательно, если бы мы могли работать только над теми проек
тами, которые нам лично интересны? К сожалению, в долгосрочной перспективе
такой подход нежизнеспособен. Иногда задачи, которые ставит перед нами наше де
ло, идут вразрез с нашей эмоциональной реакцией на них. Таким образом, тщатель
ное распределение заданий есть наилучший метод поддержания заинтересованнос
ти в их исполнении со стороны ваших сотрудников (да и с вашей стороны тоже).
Люди бывают разные: одни лучше приспособлены к одним проектам, другие —
к другим. В главе 1 эта проблема обсуждалась в контексте пород программистов.
Следует, правда, учитывать, что ваши возможности по наделению всех сотруд
ников интересной работой ограничены. Если вы хотите остаться на работе,
94
Ãëàâà 4 • Êàê îðãàíèçîâàòü óñïåõ
придется выполнить всепроекты, отведенные вашему отделу. В частности, вам не
избежать необходимости разработки проблем, которые вам совершенно безраз
личны. Как преодолеть упаднические настроения, которые часто сопровождают
начало очередного нудного проекта по сопровождению кода? Попробуйте пере
распределять задания. В результате вы сможете избежать ситуации, при которой
все самые утомительные функции ложатся на одного человека. Эти вопросы на
ходятся в зоне вашего контроля. Варьируйте задания, перераспределяйте их меж
ду сотрудниками ежедневно или еженедельно — для этого у вас есть все возмож
ности. Многие усматривают в разнообразии смысл жизни; по моему мнению,
программистам разнообразие совершенно необходимо — оно помогает выводить
наши мозги «на пик формы».
Не зная индивидуальных пристрастий сотрудников, вы не сможете обеспечить
их заинтересованность. Помните, что качественный код пишут заинтересованные
программисты. Впрочем, у дисциплинированных программистов код получается
еще лучше. Сделать программистов счастливыми не всегда в ваших силах (в кон
це концов, это не ваша работа), однако сформировать из своих сотрудников дис
циплинированную группу, готовую к работе над трудными проектами, вы може
те. Для этого необходимо поддерживать разнообразие функций, которые они
регулярно выполняют.
Àðõèòåêòóðà
Поскольку вы являетесь техническим руководителем процесса разработки про
граммных продуктов, очертания архитектуры системы в значительной степени
зависят от вашей воли. Задачи, решаемые в контексте архитектуры, не всегда под
даются контролю, но, в конце концов, в нашем деле это вполне предсказуемая
ситуация. Как я уже говорил, функции менеджера не всегда доставляют удоволь
ствие. Реализовать себя помогает способность получить удачное решение с помо
щью имеющихся технических навыков и вывести свою компанию, исходя из ее
коммерческих потребностей, на достойное положение в занимаемом ею сегменте
рынка.
Роль технического лидера подробно рассматривается в главе 6. Вы еще успе
ете ее прочитать, а пока запомните, что контроль над программной архитектурой,
применяемой в компании, в значительной степени определяет успешность конеч
ного результата вашей деятельности. Какое отношение, спросите вы, имеют орга
низационные навыки к архитектуре? Непосредственное, отвечу я. Методики, при
меняемые при систематизации потока административной информации, полностью
применимы к проектированию программных средств. Подумайте, как классифи
цируются программные требования в расчете на их реализацию в объектах кода.
Не кажется ли вам, что инкапсуляция кода во многих отношениях подобна на
полнению папки для документов проекта? Я считаю, что совершенствование орга
низационных навыков в одной области помогает добиться лучших результатов
в другой.
Традиционно считается, что левое полушарие у программистов развито луч
ше, чем правое, и что они соответственно ориентированы на логическое и анали
тическое мышление. Естественно, без мозговой деятельности в нашей работе не
обойтись. Организационные способности родственны логике программирования.
Êàê îðãàíèçîâàòü êîíòðîëü
95
Так что не стоит думать, что структурирование рабочих функций — это деятель
ность, не предполагающая приложения мыслительных усилий. Аналогичным об
разом для создания качественной программной архитектуры требуются органи
зационные навыки и умение мыслить абстрактно.
Ðàáî÷èå ÷àñû
На продолжительность вашего рабочего дня влияет великое множество факто
ров. Скорее всего, вы уже свыклись с тем, что сверхурочные (помимо стандарт
ных 40 часов в неделю) в вашем положении есть неизбежное зло. Возможно, это
действительно так. Когда компьютерная революция только начиналась, все мы
надеялись на то, что она приведет к повышению производительности труда, что,
в свою очередь, облегчит планирование продолжительности рабочей недели. Ре
волюция подошла к концу, но результаты в этом отношении двойственны. С од
ной стороны, с помощью компьютеров мы действительно сумели повысить эф
фективность своего труда. Часто это означает, что более серьезные результаты
достигаются за меньшее время. С другой стороны, исходя из собственного опыта,
я могу заключить: возможность выполнения большего числа заданий приводит
к тому, что мы начинаем больше работать, в результате рабочая неделя неизбеж
но удлиняется, и вести нормальную жизнь вне рабочего пространства становится
все труднее. Если вы будете работать дольше, чем обычно, вашему примеру обя
зательно последуют подчиненные. Эффект подобного рода изменений неодно
значен. Если вы человек несемейный, то, скорее всего, продление рабочего време
ни никак не скажется на вашей личной жизни. Те же ваши сотрудники, у которых
есть семьи (а им, как известно, неплохо бы уделять определенное внимание), вряд
ли будут радоваться удлинению рабочей недели. При принятии решения о том,
какой пример подавать подчиненным, этот фактор нужно обязательно учитывать.
В отрасли производства программного обеспечения переработка встречается
сплошь и рядом. В то же время вы должны учитывать, что продолжительная
беспрерывная рабочая деятельность неизбежно ведет к снижению производи
тельности.
Постарайтесь находить баланс между тенденцией к переработке и щадящим
распределением времени. Повышение дисциплины устраняет необходимость в пе
реработке, и, таким образом, к удлинению рабочего дня приходится прибегать все
реже. Именно в этом состоит одна из многочисленных задач высокоорганизован
ной административной деятельности — повысить эффективность работы в стан
дартные рабочие часы и тем самым сократить переработку.
Естественно, я отдаю себе отчет в том, что современная производственная дей
ствительность отнюдь не способствует сохранению стандартной 40 часовой ра
бочей недели. Но это совершенно не означает, что у вас нет ресурсов для сопро
тивления этой тенденции. Уверяю вас: люди, лежащие на смертном одре, редко
сожалеют о том, что проводили в офисе слишком мало времени. При планирова
нии переработки это обстоятельство нужно обязательно иметь в виду. Кроме того,
чутко следите за признаками изнеможения — как своих сотрудников, так и само
го себя. Учтите, что восстановление после года напряженной работы проходит
значительно болезненнее и занимает значительно больше времени, чем усилия
по самоорганизации в роли менеджера.
96
Ãëàâà 4 • Êàê îðãàíèçîâàòü óñïåõ
Âîññòàíîâëåíèå ïîñëå ãîäà íàïðÿæåííîé ðàáîòû ïðîõîäèò çíà÷èòåëüíî áîëåçíåííåå
è çàíèìàåò çíà÷èòåëüíî áîëüøå âðåìåíè, ÷åì óñèëèÿ ïî ñàìîîðãàíèçàöèè â ðîëè
ìåíåäæåðà.
Îæèäàíèÿ
Не сомневаюсь, что вы предъявляете к себе самые что ни на есть высокие требо
вания, — в противном случае вы вряд ли стали бы руководителем. Все это замеча
тельно, ставить перед собой масштабные цели очень полезно. В то же время вы
просто обязаны сопоставлять свои амбиции с реальностью. Реалист четко осозна
ет, что время от времени он может действовать не лучшим образом. Реалист так
же понимает, что контролировать ожидания окружающих относительно него
самого невозможно — если только он не сторонник раздачи невыполнимых обе
щаний. Кстати, об обещаниях — с ними нужно соблюдать осторожность. Именно
от них зависит, какие требования к вам будут предъявлять ваши сотрудники и ва
ши коллеги. Держать чужие ожидания относительно себя самого под контролем
вы сможете лишь в том случае, если будете благоразумны в своих обещаниях.
Ричард Карлсон (Richard Carlson), заслуживший за свою книгу «Don’t Sweat the
Small Stuff» исключительной похвалы, рассуждает об обещаниях следующим об
разом:
«Некоторые обещания, которые мы даем окружающим людям, на первый взгляд,
и не кажутся таковыми. Иногда мы даем их, сами того не сознавая. Чего стоят
выражения типа «я тебе перезвоню позже», «я подъеду к тебе на работу», «на
следующей неделе я вышлю тебе экземпляр моей книги», «я с удовольствием
куплю ее тебе», «если тебя понадобится сменить, дай мне знать». Даже невин
ные в первом приближении фразы типа «без проблем» представляют для ска
завшего некоторую опасность — дело в том, что их часто воспринимают как
предложение выполнить некоторое действие, хотя на самом деле вы либо не
хотите этим заниматься, либо не располагаете для этого достаточными ресур
сами. Фактически, сказав так, вы позволили собеседнику высказать к вам бо
лее серьезную просьбу, чем раньше, — ведь это не проблема!»1
Отдельные личности склонны ожидать от руководителей больше, чем те способ
ны сделать. С такими ожиданиями нужно смириться. Некоторые начальники —
я имею в виду тех, кто находится выше вас в руководящей иерархии — предъяв
ляют к своим подчиненным чрезмерно высокие требования, но при этом не удо
суживаются посвящать их в подробности своих замыслов. Если это именно ваш
случай, не вините себя. На самом деле виноват ваш начальник, а читать его мысли
вы пока не научились, так? О том, как взаимодействовать с начальником, мы по
говорим более подробно в главе 9. Пока что запомните: дать отпор несбыточным
ожиданиям можно за счет ваших организационных способностей. Обязательно
уточняйте, что от вас хотят. Если ваш начальник темнит относительно того, чего
он от вас ожидает, поднажмите на него, заставьте четко сформулировать требова
ния. Без четко определенных исходных данных добиться успеха в области конст
1
Richard Carlson, Don’t Sweat the Small Stuff at Work (New York: Hyperion, 1998), p. 74.
Êàê îðãàíèçîâàòü êîíòðîëü
97
руирования программных средств невозможно. Организованность в этом процес
се есть лучший способ избежать ситуаций, при которых первая версия продукта
оказывается для остальных подразделений компании неожиданным и нежелатель
ным сюрпризом.
Âçàèìîîòíîøåíèÿ
Возможно, вы слышали такое высказывание: «контролировать проблему труд
но, но контролировать отношение к проблеме в ваших силах». Для того чтобы
осознать справедливость этой мысли, мне потребовалось довольно много време
ни. А как думаете вы? Если ваше отношение к этому принципу скептическое,
скорее всего, во взаимоотношениях с трудными людьми вам суждено проигры
вать. Организованность отнюдь не ограничивается умением раскладывать до
кументы по папкам и вводить данные в программу управления проектом. Куда
важнее уметь должным образом обращаться с трудными подчиненными. Ларри
Константайн (Larry Constantine) — ведущий исследователь проблем персонала
в проектах по разработке программных средств — мыслит в этом контексте сле
дующим образом:
«Попытки справиться с трудными ситуациями следует начинать с постановки
ряда вопросов. По моему опыту, задав нужный вопрос, вы кардинально повы
шаете шансы на получение нужного ответа. Вместо того чтобы возмущаться,
почему с тем или иным сотрудником так сложно говорить, я предпочитаю за
даться вопросом о том, почему у меня возникают трудности во взаимодействии
с ним. Я прекрасно понимаю, что вылавливать мелкие недочеты в деятельнос
ти коллег значительно проще, чем устранять собственные недостатки, — даже
если они очень существенны. И все же я утверждаю, что любая нервотрепка
в процессе общения с трудным человеком — это одновременно возможность
лучше узнать самого себя. Придерживаясь этого принципа, вы, скорее всего,
со временем обнаружите, что людей, с которыми вам трудно общаться, остает
ся все меньше»1.
Какими методами бороться с трудностями во взаимодействии с персоналом?
Мне кажется, метод, предложенный в предыдущей цитате, полностью себя оп
равдывает. В вашей административной деятельности он должен занять не менее
значимое место, чем умение приводить в порядок свой рабочий стол. Поскольку
самые трудноразрешимые и далеко идущие проблемы, которые приводят к дезор
ганизации, порождаются самими людьми, конструктивный подход к решению
проблем персонала представляется мне основной предпосылкой успешной орга
низаторской деятельности.
Ïîñêîëüêó ñàìûå òðóäíîðàçðåøèìûå è äàëåêî èäóùèå ïðîáëåìû, êîòîðûå ïðèâîäÿò
ê äåçîðãàíèçàöèè, ïîðîæäàþòñÿ ñàìèìè ëþäüìè, êîíñòðóêòèâíûé ïîäõîä ê ðåøåíèþ
ïðîáëåì ïåðñîíàëà ïðåäñòàâëÿåòñÿ ìíå îñíîâíîé ïðåäïîñûëêîé óñïåøíîé îðãàíèçàòîðñêîé äåÿòåëüíîñòè.
1
Larry L. Constantine, Beyond Chaos: The Expert Edge in Managing Software Development (New York: Addi
son Wesley, 2001), p. 4.
98
Ãëàâà 4 • Êàê îðãàíèçîâàòü óñïåõ
Êàê ïîâûñèòü îðãàíèçîâàííîñòü
â ìàñøòàáàõ âñåé êîìïàíèè
Вплоть до этого момента мы говорили об организационных навыках индивиду
ального характера, основываясь при этом на принципе, согласно которому чем
лучше человек организован, тем более эффективно он выполняет свои руководя
щие обязанности. В масштабе организации как целого этот принцип играет даже
большую роль. В большинстве случаев вы вместе со своими подчиненными входи
те в состав более крупной организационной структуры; по этой причине степень
вашего влияния на деятельность компании обусловливается тем, насколько успеш
но вы реализуете общие для компании цели. В том случае, если программное обес
печение является основным продуктом компании, руководимый вами отдел может
играть одну из двух взаимоисключающих ролей: узкого места или источника по
стоянного корпоративного успеха. Решение о том, какая роль предпочтительнее,
принимаете вы, не забывая при этом, что ваша деятельность требует взаимодей
ствия с другими менеджерами компании.
Какова основная причина, по которой ваш отдел выделен в самостоятельную
структурную единицу? При выборе организационной схемы, направленной на до
стижение поставленных целей, вы должны исходить из ответа на этот вопрос. Рас
смотрим несколько возможных мотивов к выделению вашей рабочей группы и вы
явим варианты логического воздействия этих факторов на организацию программ
ных процессов и процедур. Возможные мотивы в расчете на их дальнейший ана
лиз приведены в табл. 4.2.
Òàáëèöà 4.2. Ìîòèâû, îïðåäåëèâøèå íåîáõîäèìîñòü âûäåëåíèÿ âàøåãî îòäåëà
â àâòîíîìíîå ñòðóêòóðíîå ïîäðàçäåëåíèå êîìïàíèè
Ìîòèâ
Âîçäåéñòâèå
Ïðîèçâîäèòü ãåíèàëüíûå
ïðîäóêòû è òåì ñàìûì
çàðàáàòûâàòü äëÿ êîìïàíèè
äåíüãè
Ïóòåì ïðîäóêòèâíîãî è ýôôåêòèâíîãî èñïîëüçîâàíèÿ
êîìïåòåíòíûõ ñïåöèàëèñòîâ è ïðî÷èõ ðåñóðñîâ ñâåñòè
íåïðîèçâîäèòåëüíûå èçäåðæêè ê ìèíèìóìó
Çàáàâëÿòüñÿ ñ òåõíîëîãèåé
Îïòîì ñêóïàòü ñâåæèå ïðîãðàììíûå ñðåäñòâà è áåñöåëüíî
ãåíåðèðîâàòü çàáàâíûå ïðîãðàììû
Ïðîéòè î÷åðåäíîé ýòàï
ê ðåàëèçàöèè âàøèõ íåïîìåðíûõ
àìáèöèé
Ðàáîòàòü áåç îòäûõà â íàäåæäå íà ïîâûøåíèå èëè,
ïîëüçóÿñü ñâîèì ïîëîæåíèåì, ó÷àñòâîâàòü â èíòðèãàõ
è äîáèâàòüñÿ ïîâûøåíèÿ âî ÷òî áû òî íè ñòàëî
ëþáûìè ñðåäñòâàìè
Лишь первый мотив из трех вышеперечисленных можно признать допусти
мым. Остальные либо вторичны, либо в корне неверны. О существе третьего мо
тива я расскажу в главе 7, посвященной обратной стороне лидерства. Вы должны
четко уяснить, что амбиции вполне допустимы, но лишь в том случае, если на
первое место вы ставите планы компании и лишь на второе — свои планы. Второй
мотив, приведенный в табл. 4.2 (забавы), при удачном стечении обстоятельств ста
новится побочным продуктом первого.
Чтобы направить вас в верном направлении в смысле совершенствования орга
низации в масштабах всей компании, необходимо более детально ознакомиться
с первым мотивом. Организованность прежде всего проявляется в наиболее ви
Êàê ïîâûñèòü îðãàíèçîâàííîñòü â ìàñøòàáàõ âñåé êîìïàíèè
99
димой, осязаемой области вашей деятельности — а именно в процессе создания
и руководства разработкой программного обеспечения. Обрести полный контроль
над этой сферой вам вряд ли удастся, однако в том, что в планировании и осуще
ствлении соответствующих операций вы исполняете ключевую роль, сомневать
ся не приходится.
Мою книгу трудно отнести в одну категорию с формализованными учебника
ми по руководству проектами. Но факт остается фактом — для того чтобы преус
петь в области лидерства, вы должны стать хорошим руководителем проекта. В ли
тературе, имеющейся на рынке, эта область описана очень комплексно, и ряд
рекомендуемых работ по данной теме есть в разделе «Библиография». Шаг за ша
гом вам предстоит овладевать все новыми и новыми навыками руководства про
ектами и в особенности — специальными методиками управления проектами по
разработке программного обеспечения. По словам автора одной из моих самых
любимых книг на эту тему: «основная причина неудач в процессе разработки про
граммных продуктов заключается в неадекватном руководстве проектами»1. Об
ратите внимание на ключевое слово — «адекватность». Действительно, наличие
организационных навыков, ориентированных на управление проектами, есть ос
новной залог успешной реализации последних. На первый взгляд приведенная
цитата кажется чрезмерно упрощенной. В то же время, если вы ознакомитесь с ре
комендуемыми мною литературой и предложениями по руководству проектами,
многочисленные причины, по которым это высказывание представляется спра
ведливым, станут для вас очевидными.
Ðóêîâîäñòâî ïðîäóêòàìè
Вы заняты в процессе разработки программного продукта (или программной ус
луги), необходимость в котором обусловливается коммерческими потребностя
ми компании. Вы ответственны за разработку; в то же время есть специалисты,
которые занимаются определением, специфицированием, маркетингом и многи
ми другими аспектами создания программных продуктов. Нет сомнений, что в про
цессе специфицирования продукта вы принимаете непосредственное участие, но
все же ваша основная обязанность заключается в том, чтобы его создать. Тем со
трудникам, которые больше склонны к работе с клиентами и распутыванию хит
росплетений бизнеса, поручают общие полномочия по координации производства,
включая принятие решений по содержанию последующих версий, по расстанов
ке приоритетов, по исправлению найденных в программе ошибок, по совершен
ствованию или корректировке механизмов взаимодействия пользователя с про
дуктом. Конечно, во всех этих областях у вас есть собственное мнение, и, скорее
всего, вы можете оказаться полезным людям, которые занимаются ими вплотную.
И все же координаторами и инициаторами всех этих процессов должны высту
пать другие.
На протяжении нескольких десятилетий существовал определенный тип про
граммистов, представители которого предпочитали делать собственными силами
все — от формулирования концепции продукта до его выпуска. В условиях со
временных американских корпораций такие индивиды встречаются крайне редко.
1
William H. Brown et al, AntiPatterns in Project Management (New York: John Wiley & Sons, 2000), p. xxi.
100 Ãëàâà 4 • Êàê îðãàíèçîâàòü óñïåõ
К величайшему сожалению некоторых разработчиков (в основном тех, которых
я отношу к породе ковбоев), программы больше не пишутся в гаражах и спаль
нях. То время, когда сногсшибательный программный продукт могли создать двое
или даже один программист, ушло в историю. В современном мире программное
обеспечение из категории занимательных новинок перешло в категорию продук
тов первой необходимости.
Òî âðåìÿ, êîãäà ñíîãñøèáàòåëüíûé ïðîãðàììíûé ïðîäóêò ìîãëè ñîçäàòü äâîå èëè
äàæå îäèí ïðîãðàììèñò, óøëî â èñòîðèþ.  ñîâðåìåííîì ìèðå ïðîãðàììíîå îáåñïå÷åíèå èç êàòåãîðèè çàíèìàòåëüíûõ íîâèíîê ïåðåøëî â êàòåãîðèþ ïðîäóêòîâ ïåðâîé
íåîáõîäèìîñòè.
Если вы работаете в небольшой компании, скорее всего, выделение в ней отде
ла руководства продуктами будет связано с большими трудностями или просто
окажется слишком дорогим и неэффективным. Это, впрочем, не отменяет необ
ходимости в выполнении функций таких отделов. Возможно, они даже войдут
в ваши обязанности. В таком случае мои вам соболезнования — мне приходилось
заниматься обоими видами деятельности, и, скажу я вам, переключаться между
двумя ролями очень трудно. В идеале вам следует сориентировать своих подчи
ненных не на описание продуктов, а на их разработку. Я совершенно не хочу ска
зать, что программисты не способны к восприятию коммерческих потребностей, —
напротив, чем больше осведомлен программист, тем лучше. Тем не менее нужно
иметь в виду, что программист призван реализовать существующее описание; пе
ределывать его заново совершенно не стоит. По моим наблюдениям, даже без уча
стия сотрудников из других отделов программисты способны мгновенно органи
зовать разрастание области действия. Продукт легче всего разработать, если он
четко описан. Более того, им удобнее управлять — по крайней мере, по сравнению
с не в меру инициативными кодировщиками, бредящими очередной специальной
функцией.
Насколько тесно вы должны взаимодействовать с группой руководства про
дуктами? В общем то довольно тесно. Вы или один из ваших ведущих сотрудни
ков должны сверять свои действия со специалистами по коммерческим аспектам
на каждом этапе описания продукта. Мало того, что эта схема способствует более
полной передаче знаний между двумя группами; следуя ей, вы обеспечиваете бо
лее высокое качество специфицирования. Связано это с тем, что с самого начала
процесса все неоправданные или нереализуемые характеристики из проекта ис
ключаются. Сложно представить себе более бессмысленную ситуацию, чем та, при
которой срок завершения работы над проектом и коммерческие требования про
сто передаются из одной комнаты в другую. Классический процесс следует на
правлять таким образом, чтобы все сотрудники компании в своей деятельности
руководствовались едиными коммерческими задачами и решениями.
Êëàññè÷åñêèé ïðîöåññ ñëåäóåò íàïðàâëÿòü òàêèì îáðàçîì, ÷òîáû âñå ñîòðóäíèêè
êîìïàíèè â ñâîåé äåÿòåëüíîñòè ðóêîâîäñòâîâàëèñü åäèíûìè êîììåð÷åñêèìè çàäà÷àìè è ðåøåíèÿìè.
Êàê ïîâûñèòü îðãàíèçîâàííîñòü â ìàñøòàáàõ âñåé êîìïàíèè 101
Îïðåäåëåíèå ïðîåêòà
Обратите внимание: речь идет не о «руководстве проектом». Представить себе
неопределенный проект довольно сложно. Процесс определения проекта следует
непосредственно за описанием продукта. В этом контексте вам придется прило
жить свои административные способности. В предыдущей главе, как вы помните,
мы говорили о том, чем нереалистичный цикл разработки продукта отличается от
реалистичного. В основном различия между проектом, организованным по принци
пу Алисы в Стране Чудес, и проектом, который имеет шанс увенчаться созданием
качественного продукта, кроются в деталях. За этапом определения следуют эта
пы специфицирования, проектирования, макетирования и многие другие итера
тивные процессы, формирующие очертания процесса в целом. Все эти процессы
можно отнести к разработке, однако следует иметь в виду, что цикл разработки
выводится исходя из контекста различных мелких элементов проекта.
При организации проекта вы должны отталкиваться от опыта работы с преды
дущими проектами — вне зависимости от того, насколько они были успешными
или, наоборот, провальными. Наибольший воспитательный эффект мы получаем
от неудач (хотя и успехи в этом отношении очень полезны). Прежде чем подпи
саться на методику программной инженерии, основательно подумайте. Методика
эта полностью применима к некоторой части крупных проектов, однако в том, что
касается программного обеспечения, мастерство оказывается важнее инженерии.
Это мое мнение. Его разделяют многие другие специалисты, но как к нему отно
ситься — решайте сами. В конце концов, купив эту книгу, вы заплатили за мое
мнение определенную цену. Выражусь иначе: если ваша группа сможет догово
риться со спонсорами по поводу этапов работы над проектом, то при утвержде
нии сроков завершения работы вряд ли вам придется тыкать пальцем в небо. Дата
выпуска программных продуктов часто рассматривается как движущаяся цель;
чтобы справиться с неопределенностью, постарайтесь уяснить одну простую вещь —
выпуск невозможен без предварительного комплексного тестирования. Очевид
но, что тестирование проводится после кодирования, кодирование после проек
тирования и т. д. Я совершенно не хочу навязать вам какой бы то ни было проце
дурный шаблон с условием обязательного применения во всех проектах. Я просто
пытаюсь напомнить о том, что прежде конструирования нужно тщательно опре
делить и структурировать процессы, реализуемые в рамках проекта.
Если к руководству группой программистов вы приступили совсем недавно, чи
тайте как можно больше литературы (а именно этим вы сейчас занимаетесь) и регу
лярно советуйтесь с начальником. Наличия технических навыков еще недостаточ
но для разработки проекта создания программного обеспечения. Эта деятельность
требует некоторого опыта работы на руководящих должностях и коммерческого
благоразумия. Помните, что ваши ресурсы ограничены; соответственно привы
кайте к тесному сотрудничеству с другими подразделениями вашей компании.
Ðóêîâîäñòâî ïðîöåññàìè
Как известно, изменения в нашей жизни есть единственное постоянное явление.
Этот принцип вы слышали не раз, не так ли? Даже в курсе по основам физики
102 Ãëàâà 4 • Êàê îðãàíèçîâàòü óñïåõ
утверждается, что в замкнутых системах следует ожидать повышения энтропии.
Так почему же тогда мы пишем книги, читаем код, занимаемся другими структу
рированными видами деятельности? Надо полагать, что то (или Кто то) способ
ствует упорядочению, которое противостоит естественной, присущей всей Все
ленной тенденции к дезорганизации. «Что это он такое мелет? — спросите вы. — Уж
не хочет ли он сказать, что мне предстоит стать ”Богом управления процессами“?»
Да, именно это я и имею в виду. Хотите более замысловатый титул — можете на
зывать себя «владыкой изменений». Главное, как вы понимаете, — не наименова
ние, а действие. В рамках общей, единой для вашей компании стратегии вы долж
ны руководить процессом определения продуктов и проекта.
Изменения делятся на два основных типа: намеренные и случайные. Изменения,
относящиеся к первому типу, обычно планируются; вторые же, как правило, не
предсказуемы. Если вы ориентированы на успех, старайтесь тщательно управлять
ся с намеренными изменениями — тогда вы сможете получить определенный кон
троль над случайными изменениями. Подумайте, какое воздействие модификация
продукта окажет на сетевую инфраструктуру? А как насчет изменения механиз
ма взаимодействия с пользователем во второй версии продукта? Учитываете ли
вы все эти моменты? Кодирование не есть изолированный процесс. По словам
Томаса Мертона (Thomas Merton), «нас согревает огонь, а не дым; через океан мы
плаваем на кораблях, а не на волнах, которые они оставляют за собой»1. К сожале
нию, слишком часто программные продукты создаются без достаточного анализа
воздействия технических решений на окружающую среду — «дым» и «волна» на
ших усилий в таких случаях приводят к дестабилизации деятельности компании.
Äåÿòåëüíîñòü ïî îðãàíèçàöèè èçìåíåíèé íóæíî âåñòè íà âñåõ áåç èñêëþ÷åíèÿ ýòàïàõ
ðàçðàáîòêè ïðîåêòà — îò çàðîæäåíèÿ çàìûñëà äî çàâåðøåíèÿ.
Выражаясь более приземленно, деятельность по организации изменений нужно
вести на всех этапах разработки — от зарождения замысла до завершения. Если
никто не позаботился о том, чтобы построить хотя бы общий шаблон для получения
информации о воздействии ожидаемого (или неожиданного) изменения, в про
цессе разработки вас ждут серьезные трудности. Чтобы выявить подводные кам
ни изменений, достаточно задать ряд простых вопросов. Имейте в виду: задавать
их следует применительно к любой предполагаемой модификации продукта.
Каким представляется воздействие изменения на архитектуру системы и про
цесс сопровождения?
Как предполагаемое изменение воздействует на сетевую инфраструктуру, в ко
торой оно будет проводиться?
Как предполагаемое изменение повлияет на способность пользователя эффек
тивно и продуктивно взаимодействовать с данным программным продуктом?
Какое влияние предполагаемое изменение окажет на действия сотрудников
отделов, которым его придется испытать на собственной шкуре?
1
Thomas Merton, No Man Is an Island (New York: Harcourt Brace Jovanovich, 1955), p. 117.
Êàê ïîâûñèòü îðãàíèçîâàííîñòü â ìàñøòàáàõ âñåé êîìïàíèè 103
Получив ответы на все эти вопросы, считайте, что вам удалось наладить про
цесс организации изменений, и исходя из результатов в рамках разработки про
граммного продукта можно будет уже принимать те или иные решения. Мне ка
жется, что совещания с руководителями других отделов, выступающими в роли
заинтересованных в успехе компании лиц, по вопросу об организации изменений
следует проводить еженедельно. Координируя изменения систематически, вы об
ретаете контроль над дальнейшей судьбой разрабатываемых продуктов и культи
вируете ресурсы их поддержки. Чем тушить пожары, их лучше предотвращать, не
так ли? Согласно этому принципу наличие стройной политики организации из
менений позволит вам выстроить стратегические планы и отказаться от практики
еженедельного созыва экстренных совещаний.
Òåñòèðîâàíèå
Не сомневаюсь, что вы слышали знаменитый слоган Java: «что написано однаж
ды, исполняется везде». На самом деле, «что написано однажды, придется тести
ровать везде». Это правило применимо ко всем без исключения языкам. Не стоит
доверять завершающий этап тестирования исключительно сотрудникам своей
группы. Если в вашей компании нет специальной группы тестирования, органи
зуйте ее. В крайнем случае сделайте так, чтобы сотрудники проверили код друг
друга. Старайтесь, чтобы в ходе цикла разработки программисты новички зани
мались тестированием не меньше, чем кодированием. Это позволит им перенять
ценный опыт своих более квалифицированных собратьев.
Если программист считает, что справился со своим кодом «неплохо», насторо
житесь! Дело в том, что эпитет «неплохо» можно трактовать по разному. В любом
случае в деле выявления ошибок контрольный сценарий, написанный бизнес эк
спертом, приносит большую пользу, чем программист, просматривающий функ
цию собственного сочинения. Ни один человек не способен в одиночку адекватно
оценить последствия побочных изменений в программном продукте. Наличие
группы тестирования, сотрудники которой также ответственны за развертывание,
есть необходимое условие достижения успеха. Тестеры должны быть вашими луч
шими друзьями. Именно они помогают выпускать качественные продукты; они
же составляют первую линию защиты от некачественных графических пользова
тельских интерфейсов.
Ðóêîâîäñòâî èíôðàñòðóêòóðîé
Многие считают, что физические условия, в которых ежедневно трудятся сотруд
ники компании, не слишком существенны. Если и вы придерживаетесь этого мне
ния, подумайте еще раз. В главе 3, рассуждая о том, как разбираться с внешними
раздражителями, я мельком упомянул проблему рабочего пространства. Стандарт
ные офисные клетушки не подходят для программистов. Совместное пользова
ние одним компьютером — это тоже не про нас. Не менее разрушительной в кон
тексте деятельности программистов представляется практика непрекращающихся
боевых действий с системными инженерами с целью получения доступа к важ
ным системным ресурсам. Все эти элементы физического окружения, которые со
вершенно необходимы для успешной деятельности группы программистов, стоят
денег, и немалых. Задарма ничего не выйдет. С другой стороны, если сопоставить
104 Ãëàâà 4 • Êàê îðãàíèçîâàòü óñïåõ
продуктивность (в категориях времени и стоимости) работы в плохих условиях
с продуктивностью в нормальной рабочей среде, мы придем к выводу, что вложе
ния в физическую инфраструктуру вполне оправданы.
Îðãàíèçóéòå ñîòðóäíè÷åñòâî è óåäèíåíèå
На то, чтобы говорить, и на то, чтобы думать, у программистов должно быть вре
мя. Некоторые утверждают, что тем и другим они могут заниматься одновремен
но; впрочем, исходя из результатов многолетних наблюдений, я с подозрением
отношусь к подобного рода заявлениям. По моему мнению, для того чтобы про
граммисты достигали в своей деятельности определенных успехов, у них должна
быть возможность, с одной стороны, некоторое время поработать в коллективе,
с другой — пораскинуть мозгами в полном одиночестве. У каждого программиста
должно быть собственное помещение с дверью, которая действительно закрыва
ется. Конкретный метраж обусловливается теми средствами, которые вы готовы
вложить в улучшение физических рабочих условий. Скажу лишь, что если на каж
дого программиста будет приходиться менее 130 квадратных футов, вы рискуете
нарваться на неприятности. Как мне удалось вычислить эту величину с такой точ
ностью? Дело в том, что 130 квадратных футов — это средний метраж спальни
американского подростка. Если уж подростки, проводящие свои юные годы на
таком пространстве, способны добиваться определенных успехов, то же можно
сказать о программистах.
Äëÿ òîãî ÷òîáû ïðîãðàììèñòû äîñòèãàëè â ñâîåé äåÿòåëüíîñòè ñåðüåçíûõ óñïåõîâ,
ó íèõ äîëæíà áûòü âîçìîæíîñòü, ñ îäíîé ñòîðîíû, íåêîòîðîå âðåìÿ ïîðàáîòàòü
â êîëëåêòèâå, ñ äðóãîé — ïîðàñêèíóòü ìîçãàìè â ïîëíîì îäèíî÷åñòâå.
Поскольку в ваши обязанности входят регулярные встречи с сотрудниками
в формате «один на один», пространство вашего кабинета следует немного уве
личить по сравнению со средним показателем. Не обольщайтесь — роль руко
водителя сама по себе не дает вам права на большую площадь; она нужна лишь
для того, чтобы вы более эффективно выполняли свои функции. Кроме того, для
проведения полноценных собраний с участием всех сотрудников отдела вам ну
жен конференц зал, оснащенный электронным табло. Все мы наслушались ис
торий о том, как легенды нашей высокотехнологичной отрасли регулярно режутся
друг с другом в видеоигры. Вот и вам, если, конечно, позволят ресурсы, желатель
но организовать отдельное пространство для отдыха сотрудников. Если же сред
ства не позволяют завести такое помещение исключительно для программистов
вашего отдела, постарайтесь решить эту проблему совместно с другими подраз
делениями.
Удаленная работа, о которой мы также упоминали в предыдущей главе, — это
хороший способ свести к минимуму влияние внешних раздражителей и решить
проблему уединения; в то же время с точки зрения сотрудничества такая практи
ка дает не слишком хорошие результаты. В процессе разработки программных
средств почтовые сообщения и телефонные звонки на самом деле не компенсиру
ют недостаток личного общения. Поэтому вы должны сочетать возможность уда
ленной работы с потребностью в работе совместной. Когда ответственные лица
находятся в одном месте в одно время, на принятие решений у них уходят считан
 êîíöå ðàáî÷åãî äíÿ 105
ные минуты. Если же они находятся в разных местах, на решение аналогичных
проблем могут уходить часы, а то и целые дни.
Ïðåäîñòàâëÿéòå ëó÷øèé èíñòðóìåíòàðèé
В распоряжении любого программиста должен быть быстродействующий ком
пьютер с максимально возможным объемом памяти. Кроме того, программисту
нужна тестовая машина, воспроизводящая стандартные характеристики пользова
тельских компьютеров. Вполне вероятно, что в вашей компании наличествует сете
вая инфраструктура, призванная обеспечивать поддержку разрабатываемых про
дуктов (веб серверы, метафреймы Citrix Metaframe и т. д.). Соответственно, для
тестирования результатов разработки эти продукты следует дублировать зер
калами. Иногда они могут использоваться совместно с группой тестирования,
однако имейте в виду, что отделение сред разработки и тестирования от непо
средственного производства себя оправдывает. Мне приходилось встречаться
с компаниями, которые бездумно разрешали программистам напрямую редакти
ровать веб сайты путем удаленной загрузки файлов. Это самый неудачный метод,
какой только можно себе представить. Он, конечно, удобен, но чрезвычайно опасен.
Если вашим сотрудникам приходится переходить с места на место (или сверх
урочно работать дома), лучше всего приобрести для них ноутбуки. Сегодня они
практически не уступают по своим возможностям настольным компьютерам, по
этому экономить не стоит. Не забывайте к тому же, что программисты предъявля
ют к своим машинам значительно более высокие требования, чем средние поль
зователи. Возможно, вам придется скорректировать принятую в компании политику
технического обеспечения с учетом потребностей ваших подчиненных. Програм
мистам нужно предоставить полномочия администратора в отношении прав дос
тупа и конфигурирования их собственных машин. Если кто то из них запутается
в конфигурации, покажите, как решить проблему, которую он сам себе создал.
Прибегать к услугам специалистов следует лишь в крайнем случае. Программис
ты, которые не знают, как сконфигурировать операционную систему или устано
вить ее с чистого листа, просто недостаточно научены. Их уровень владения по
нятиями TCP/IP не должен уступать уровню системных инженеров.
 êîíöå ðàáî÷åãî äíÿ
Скорее всего, вы уже предвкушаете разговоры насчет наведения порядка на рабо
чем столе и перекладывания вещей с места на место. Это все хорошо, но мне хо
чется сказать кое что более важное. Каких бы высот по части организованности
вы ни достигли, чувства усталости и переутомления не избежать. Таков уж харак
тер деятельности менеджера. Производство программных средств, руководство
людьми и лидерские функции в их среде, равно как и все другие действия, осуще
ствляемые руководителем, иногда приводят его в состояние прострации. Как бы
то ни было, обобщая все вышесказанное, надеюсь, что вы запомните несколько
принципов, способствующих достижению успеха.
Допускают ли ваши собственные рабочие условия оперативность при пре
вращении информации в действия? Если нет, постарайтесь систематизиро
вать делопроизводство в соответствии с рекомендуемыми методиками в этой
106 Ãëàâà 4 • Êàê îðãàíèçîâàòü óñïåõ
области — так, чтобы, помимо просто руководства, вы могли взять на себя ли
дерские функции.
Работайте над теми сферами своей деятельности, которые поддаются контро
лю, и смиритесь с тем, что некоторые из сфер неконтролируемы.
Наладив активное взаимодействие с другими отделами, всеми силами способ
ствуйте повышению организационного уровня компании в целом. Держите дела
в своем отделе под контролем и будьте в этом отношении примером для дру
гих руководителей.
Большие задания следует дробить на более мелкие и лучше управляемые. Во
оружившись этим подходом, можно с готовностью приниматься за решение гло
бальных задач. Иначе говоря, выводите вторичные задачи, которые предусматри
вают возможность решения в течение одного непрерывного промежутка времени.
Так вы сможете организовать свои временные ресурсы и решать по одной задаче
за раз. Ничто так не поднимает уровень самооценки, как наличие структуриро
ванного плана и его последовательное выполнение. Уверенность в своих силах,
в свою очередь, приводит к достижению успеха, снижению стрессовых нагрузок
и к удовлетворению собственной деятельностью, подпитываемой помощью в до
стижении результата окружающим вас людям.
×òî äàëüøå
В следующей главе мы поговорим о том, какую роль вы должны исполнять на
совещаниях. Организационные навыки, проявляемые на совещаниях, вносят су
щественный вклад в достижении поставленных целей. В идеале совещания с дру
гими группами (и, в особенности, с собственными сотрудниками) должны про
водиться исходя из четко сформулированных целей и не менее определенных
представлений о предполагаемых результатах. По мере ознакомления с материа
лом моей книги вы постепенно придете к мысли, что решить все проблемы сразу
не получится. Вряд ли, к тому же, вам удастся извлечь из этой книги точные схе
мы действий в тех или иных ситуациях. Темы, которые я поднимаю, придется
переосмыслить — так, чтобы выстроить материал согласно специфике исполняе
мых вами функций. Итак, вперед — читайте сердцем! Делайте с моим материалом
все, что сочтете нужным, — я не обижусь.
Гл а в а
5
Êàê âåñòè ñîâåùàíèÿ
Почему совещания нужно вести? Дело в том, что когда
программисты, намереваясь обсудить ту или иную про
блему, собираются вместе, их личностные качества име
ют обыкновение вступать в конфликт, который, есте
ственно, достижению поставленных целей совещания
не способствует. Привыкнув заниматься кодированием,
вы, скорее всего, перед проведением первого (или пя
тидесятого) совещания будете испытывать неприятные
опасения1. Не беспокойтесь, эта глава, посвященная про
ведению совещаний, призвана повысить вашу подготов
ленность в этой области. Именно от вашей разумности
зависит успех в деле ведения совещаний.
Технари вроде нас с вами часто страдают аллергией на совещания. Нам кажет
ся, что, кроме потери времени, от них нет никакого толку, и значительно эффек
тивнее лишний час повисеть над клавиатурой и попытаться написать приемле
мый код. Как руководитель вы действительно ожидаете, что сотрудники будут
проводить драгоценные рабочие часы за компьютером, но в то же время вы долж
ны контролировать их деятельность. Совещания помогают координировать ре
зультаты ваших собственных усилий. Рассматривать совещания как неизбежное
зло не следует, ибо они таковым не являются. Собираясь вместе со своими со
трудниками, можно обсуждать идеи друг друга и тем самым совершенствовать
представления рабочей группы о выбранных стратегии и тактике.
Åæåíåäåëüíûå ñîâåùàíèÿ
Я рекомендую проводить совещания с сотрудниками каждую неделю в одно и то же
время. Не стоит отлынивать от этих встреч, даже если вы плохо себе представляете,
1
Получилось масло масляное — ведь опасения не бывают приятными. Не стоит, впрочем, излишне пер
сонифицироваться — скорее всего, сотрудники вашей группы, общаясь с вами на совещании, испыты
вают аналогичные чувства. Вряд ли вас это успокоит — помните, чтоза лидерство тоже нужно платить.
108 Ãëàâà 5 • Êàê âåñòè ñîâåùàíèÿ
что на них можно обсудить. На самом деле предмет для обсуждения найдется —
нужно только каждую неделю придерживаться на совещании четкой повестки дня.
Что вы делали на прошлой неделе?
Что вы собираетесь делать на этой неделе?
Что мешает вам выполнить ваши задания в назначенное время?
Заставьте своих сотрудников приносить на совещания списки поставленных
перед ними задач и просите их каждый раз отвечать на эти три простых вопроса.
При формулировании заданий вы устанавливаете для них сроки завершения, не
так ли? Задания программистам нужно давать в письменном виде, даже если текст
задания ограничивается высокоуровневым описанием очередной характеристи
ки программного продукта. Зачастую выполнение основного задания предпола
гает предварительное решение ряда вспомогательных задач. На все эти задачи —
основные и второстепенные — нужно обращать внимание; вы должны постоянно
напоминать сотрудникам о том, что от них требуется. В зависимости от уровня
руководства проектом, который вам доступен и которому вы симпатизируете, спи
сок задач может выглядеть совершенно по разному — в диапазоне от простого опи
сания задачи с указанием срока ее решения до комплексной временной схемы про
екта с детальной росписью подзадач для каждого значимого объекта поставки.
О назначении заданий я говорил в предыдущей главе. Попробуйте придумать соб
ственный метод составления списков заданий. Адаптируйте его к индивидуаль
ным характеристикам компании и к собственному стилю руководства. Наличие
списков заданий должно стать обязательным условием проведения еженедельно
го собрания персонала.
Во время совещания делайте акцент на понятии «объектов поставки». Этим
понятием обозначаются характеристики или продукты, поставляемые вашими
подчиненными программистами для публичного потребления. Избегайте призрач
ных намеков на результат. Не надо говорить программистам о том, что они долж
ны «исправить ошибки» или «внести некоторые доработки».
Если в вашей компании есть мощная группа с сильными маркетинговыми
ресурсами, в задачу которой входит исчерпывающее описание продукта, ваши
функции заметно упрощаются. Повторюсь: на совещаниях, вместо того чтобы спо
рить с программистами о хитросплетениях кода, вы должны проверять сотрудни
ков и обеспечивать их готовность в срок решить задачи, поставленные в связи
с производством программного продукта. С другой стороны, иногда легкомыслен
ное отношение к коду способствует его более успешной разработке; поэтому ста
райтесь не предстать в глазах сотрудников тираном.
Достоинство предложенной мной программы совещания состоит в том, что она
проста, предполагает диалог с сотрудниками и обеспечивает возможность выяв
ления трудностей, с которыми они сталкиваются. Заставляя программистов фор
Åæåíåäåëüíûå ñîâåùàíèÿ 109
мулировать достигнутые цели и ставить перед собой цели на неделю, вы укрепля
ете в их сознании мысль о том, что они работают ради создания конкретного про
дукта. С другой стороны, вам нужно, чтобы программисты, копаясь в деталях
реализации, держали в голове все вспомогательные задачи, направленные на ре
шение более общей (высокоуровневой) задачи. Сначала полезно определить в кон
тексте проекта высокоуровневую задачу — например, «реализовать модуль, вы
ражающий функцию X», а затем, исходя из имеющихся ресурсов, сформулировать
вспомогательные, зависимые задачи. В процессе администрирования за этим так
же придется следить. Если бы мы, руководители, могли держать в голове все де
тали, связанные с реализацией любой конкретной характеристики программного
продукта, было бы, конечно, замечательно; впрочем, в таком случае мы утратили
бы потенциал делегирования и фактически отказались бы от обращения к интел
лектуальным ресурсам и техническим навыкам своих сотрудников. Скажем по
другому: пытайтесь держать в голове как можно больше деталей, и если ваша ко
манда состоит из профессионалов с достаточной мотивацией, они помогут вам
справиться с задачей.
В конце концов, над результатом работает вся группа, а ваша цель заключает
ся в том, чтобы ставить планки и проверять результаты.
Время от времени к своей повестке дня я прибавлял разбор литературы. Выбе
рите добротную книгу о методиках программирования, принципах проектирова
ния или по какой либо другой теме, связанной с будущим развитием нашей от
расли, и попытайтесь совместно с подчиненными разобраться в ее материале.
Попросите каждого выступить на следующем совещании с устным докладом по
ее содержанию. Создайте атмосферу университетского семинара, только не пы
тайтесь казаться слишком серьезным. Эта методика здорово стимулирует потреб
ность в дальнейшем обучении.
Не сомневаюсь, что при необходимости вы учтете этот мой опыт; однако осте
регайтесь растягивать совещания и обсуждать предметы слишком детально. Дело
в том, что при продолжительности более 45 минут результат совещания может
оказаться отрицательным. Совещание сотрудников способствует углублению ин
теграции в команде и предоставляет возможность специалистам, столкнувшимся
с особо трудными задачами, обращаться к коллективному интеллекту. К тем, кто
не справляется со своей работой в срок, следует относиться довольно жестко. За
ставьте их объяснить остальным членам группы, по какой причине они опаздыва
ют с решением поставленной задачи. Впрочем, не переусердствуйте в своих ма
нипуляциях с групповым поведением. Публичное унижение сложно признать
эффективным средством повышения производительности — поэтому, критикуя
сотрудников, будьте сдержанны; в том же, что касается похвал (по крайней мере,
на публике), не скупитесь.
Особое значение совещания персонала приобретают при приближении срока
завершения работы над кодом. В такие моменты внимание группы следует обра
тить на особо нудные задачи и внесение в текст программы последних коррек
тив — эти вопросы всегда необходимо решать с особой тщательностью. Проводя
еженедельные совещания сотрудников, вы сможете поддержать их внимание, ког
да на подходе будут наиболее критичные этапы процесса разработки.
Каждую неделю при проведении совещаний будьте готовы к тому, что сотруд
ники станут оценивать ваши лидерские качества. Не стоит забывать, что, проводя
110 Ãëàâà 5 • Êàê âåñòè ñîâåùàíèÿ
еженедельные совещания, вы нарабатываете соответствующий навык. Полжизни
мы работаем на публику — а если серьезно, то, что бы там ни говорил Эмерсон
(Emerson)1, мне сложно представить себе ситуацию, в которой последовательный
человек выглядел бы глупо. Еженедельно выискивая пути углубления коопера
ции между сотрудниками, вы формируете полноценную команду. Не стоит пре
пятствовать проявлению соревновательного принципа — впрочем, в этом контек
сте вы должны играть уравновешивающую роль. Время от времени сотрудников
следует ненавязчиво сдерживать или, напротив, побуждать к активным действиям.
Если вы хорошо разбираетесь в своих подчиненных, то те действия корректирую
щего характера, которые вам предстоит предпринять, подскажет ваша интуиция.
Эта роль напоминает позицию родителей по отношению к своим подросткам от
прыскам (слава Богу, на эту тему мне писать не придется).
Ïðîåêòíûå ñîâåùàíèÿ
Будь вы хоть во сто крат талантливее лучшего программиста своей группы, ско
рее всего, всех ваших навыков, не говоря уже о времени, не хватит, чтобы само
стоятельно реализовать все характеристики разрабатываемых программных про
дуктов. Даже если бы у вас нашлось время, разрабатывать все самому не имеет
особого смысла — ведь тогда коллеги программисты не смогут ощущать себя со
участниками творческого процесса. Иногда на проектных совещаниях нам прихо
дится иметь дело с социально пассивной группой2, которую неплохо бы превра
тить в команду активных, мотивированных и рвущихся к действию специалистов,
готовых проектировать и реализовывать очередные характеристики вовремя
и практически безошибочно. Такого рода индивидуальные особенности сотруд
ников зачастую довольно причудливо проявляются в контексте поведения груп
пы в целом. Как настроить людей, с которыми приходится работать, на позитив
ный лад? Кто знает — может быть, вам и удастся достичь цели колдовскими чарами
и материальным поощрением, но на самом деле эти способы неэффективны. Что
вам действительно нужно, так это разум опытного психолога и душа дипломата
карьериста. Добро пожаловать в чрезвычайно запутанный, но в не меньшей сте
пени притягательный мир группового поведения!
Ïðîåêòèðîâàòü ïðîãðàììíûå ïðîäóêòû ñàìîìó íåðàçóìíî — âåäü òîãäà êîëëåãèïðîãðàììèñòû íå ñìîãóò îùóòèòü ñåáÿ ñîó÷àñòíèêàìè òâîð÷åñêîãî ïðîöåññà.
Так как же стать блистательным лидером проектной группы, если в данный
момент вы таковым не являетесь? Без мыслительной деятельности и постоянной
1
2
«Дурацкий принцип последовательности есть прерогатива ограниченных умов, побуждаемых не ме
нее ограниченными политиками, философами и священниками. В оковах последовательности широ
кой душе негде развернуться…», — Ральф Уолдо Эмерсон (Self Reliance, 1841).
Я отнюдь не утверждаю, что все программисты социально пассивны, — мы просто, скажем так, осо
бенные, и именно в этом кроется наша индивидуальность и благодаря этому мы способны проводить
долгие часы в умственном напряжении, размышляя о том, как решить поставленные программные
задачи.
Ïðîåêòíûå ñîâåùàíèÿ 111
практики ничего не выйдет. Рассмотрим, однако же, некоторые проблемы и явле
ния, наблюдаемые на стандартном проектном совещании.
Ваша задача — сделать так, чтобы все функции были корректно спроектирова
ны и впоследствии качественно разработаны.
У каждого участника группы могут быть собственные представления относи
тельно проектного решения одной и той же функции.
Программисты склонны проектировать лишь те функции, которые они могут
или хотят разрабатывать.
У некоторых программистов могут быть планы, отличные от ваших; трудно
выявляемые, такие бунтари способны привести к саботажу совещаний.
Единодушная поддержка сотрудниками высказанных вами идей (если только
они не объективно гениальны) наводит на грустные размышления.
В процессе проектирования вы обязаны пытаться достичь консенсуса — это
трудная задача, но усилия, поверьте мне, окупаются. Достичь компромисса
несколько легче, но если кто то выступит со своей вымученной идеей и не по
лучит поддержки, вы рискуете создать себе врага.
Совещания либо осложняют существующую в группе разработчиков ситуа
цию, либо разрешают кризис. В каком направлении пойдете вы, всецело зависит
от вашей воли. Силами наличествующего персонала и с учетом предъявленных
требований вы должны создать работоспособные спецификации, на основе кото
рых впоследствии можно будет писать качественный код.
В большинстве компаний достичь этой цели довольно сложно. Слава Богу, моя
книга — не более чем скромное руководство, и я совсем не претендую на то, чтобы
осветить все мыслимые вопросы. (Молодец, Хэнк! Избавился от ответственнос
ти.)
Шучу. Если серьезно, обратите внимание на следующие рекомендации.
Вы должны знать сильные и слабые качества участников своей команды. Не
менее важно осознавать собственные достоинства и недостатки. Именно об этом
я говорил в первых трех главах книги.
Документацию с требованиями имеет смысл разбить на разделы по схожей
функциональности, допускающие решение средствами объектно ориентиро
ванного проектирования.
Делайте заметки. Если можете себе это позволить, заведите электронное таб
ло. Зафиксируйте совещание на видеопленке, оцифруйте ее, а после создания
первого черновика проектной спецификации покажите отснятый материал чле
нам группы.
Подключите ноутбук к большому монитору и демонстрируйте сотрудникам
группы примеры готового кода, указывая на те его аспекты, которые считаете
удачными или, напротив, неудачными.
Уберите из помещения, в котором проводите совещания, телефонный аппа
рат. Этого можно не делать лишь в том случае, если во время совещания вы
собираетесь обратиться к какому нибудь удаленному абоненту за свежими
идеями.
112 Ãëàâà 5 • Êàê âåñòè ñîâåùàíèÿ
Работайте в удобном и изолированном от шума помещении. Делайте переры
вы, чтобы усталость организмов присутствующих не мешала деятельной рабо
те их мозгов.
Составьте план действий на каждый день; при необходимости вносите в него
коррективы и отталкивайтесь от него в деле реализации проектных заданий.
Отведите последний день на критический обзор и обобщение результатов со
вещания.
Как я только что сказал, вести заметки совершенно необходимо. Если вы регу
лярно выходите к электронному табло с предложением новых идей по проекту,
что то писать на бумажке становится довольно проблематично. В таком случае
имеет смысл попросить одного из сотрудников выполнять эту функцию за вас.
Представляете, как будет обидно, если, проведя плодотворное совещание на про
шлой неделе, вы забудете о принятых на нем решениях уже через несколько дней!
Для человека, которому вы намерены поручить протоколирование совещания,
можно составить специальный шаблон. Пример такового показан на рис. 5.1.
Несколько замечаний по поводу шаблона. Большая часть информации, кото
рая в нем фиксируется, очевидна. Самая пространная область шаблона — «Заме
чания» — предусматривает запись информации в свободной форме. В ней можно,
скажем, начертить блок схему (если электронное табло неисправно) или просто
зафиксировать какие то идеи, которые во время совещаний часто появляются
спонтанно. Раздел «Влияние на проектное решение» тоже довольно важен. По
чти всегда артефакты проектирования оказывают влияние на существующее про
граммное обеспечение, равно как и на другие аспекты деятельности компании.
Вот эти то варианты воздействия вам и предстоит зафиксировать. Область «Не
обходимые действия» ориентирует в последующих действиях, направленных на
реализацию проектного решения. Ведь действительно совещание без реализации
принятых решений на практике есть не более чем потеря времени. Кроме того,
имеет смысл составить краткое письменное резюме проблем, обсуждавшихся на
совещании, и присовокупить его к базе знаний группы разработчиков. Эта ин
формация может понадобиться тем сотрудникам, которые по той или иной при
чине не смогли присутствовать на совещании, а также специалистам, только что
присоединившимся к вашей группе и считающим необходимым ознакомиться
с историей проекта.
В целях соблюдения четкости формулировок постарайтесь, чтобы размер шаб
лона не превысил одной страницы. Если относительно какого то конкретного про
ектного решения увеличить размер шаблона все таки потребуется, возьмите до
полнительный лист и соответствующим образом пронумеруйте его. Полагаю, вы
поняли, что я имею в виду. Не сомневаюсь также, что вы сможете придумать бо
лее удобный метод. Главное — сделать так, чтобы при переходе на следующий этап
проектирования (а именно к спецификации проектного решения) вы не опира
лись лишь на свою память. Ну ладно, я закругляюсь с этой темой — все таки мою
Ïðîåêòíûå ñîâåùàíèÿ 113
книгу сложно причислить к комплексным исследованиям по управлению проекта
ми и, тем более, к монографиям по объектно ориентированному проектированию.
Не углубляясь в дебри программного проектирования, отмечу один момент,
касающийся персонала. Вы должны осознать, что несмотря на ваши функции ру
ководителя, совершенно не факт, что из всех сотрудников группы у вас самые
яркие архитектурные способности. Как вы знаете, программисты все разные, и за
частую в одном человеке мирно уживаются характеристики разных типов. (Вспом
ните мою классификацию пород, приведенную в главе 1.) Если вы отдаете себе
отчет в том, что ваши возможности по части глобального архитектурного мышле
ния весьма ограниченны, выделите среди своих сотрудников тех людей, которые
способны достигнуть в этом отношении более серьезных результатов, и позволь
те им принимать в процессе как можно более деятельное участие. Следует быть
готовым к непреодолимому желанию тоже поучаствовать в процессе генерации
идей, однако имейте в виду, что ваша основная задача — справляться с отбором
предлагаемых идей, а не генерировать свои. Быть пропагандистом хороших идей,
уверяю вас, обычно не менее почетно, чем быть их генератором. В этой области
вам придется пустить в ход свои дипломатические способности.
114 Ãëàâà 5 • Êàê âåñòè ñîâåùàíèÿ
Вы говорите, что у вас нет дипломатических навыков? Что я могу сказать?
Учитесь! Дипломатия — это искусство выслушивать, прежде чем говорить, ду
мать, прежде чем предлагать, и постоянно искать консенсус.
Äèïëîìàòèÿ — ýòî èñêóññòâî âûñëóøèâàòü, ïðåæäå ÷åì ãîâîðèòü, äóìàòü, ïðåæäå
÷åì ïðåäëàãàòü, è ïîñòîÿííî èñêàòü êîíñåíñóñ.
Задача не из простых, кто бы спорил, но ведь деньги, которые вам платят, надо
отрабатывать! Рекомендую прочесть несколько книжек по поводу формирования
команды (см. библиографию). Но это не главное. Основная предпосылка к дости
жению желаемого результата — сильное желание. Стремление добиться общего
для всех участников группы успеха вы должны ставить выше искушения выиг
рать случайный спор. Запомните, выиграть спор невозможно! В условиях команд
ной работы все вместе либо выигрывают, либо проигрывают.
Я упомянул, что основной целью проектного совещания является выработка
консенсуса. Я совершенно не имею в виду голосование по предложенным идеям.
Демократия — система, прекрасно подходящая для наций, — не приживается в тех
ническом проектировании1. Отдав предпочтение идеям одного человека и, соот
ветственно, отказавшись от предложений другого, вы не добьетесь продуктивно
го мышления. Консенсус достигается за счет синтеза идей. Торг по принципу «я
соглашусь на твою характеристику, если ты согласишься на мою», здесь неумес
тен. Что я понимаю под синтезом? Это процесс, в ходе которого путем проработ
ки конкурирующих идей выкристаллизовываются их наилучшие качества. С ва
шей стороны для достижения этой цели требуется терпение и настойчивость. Ведь
вы как руководитель должны стремиться к тому, чтобы вычленить наилучшее из
всех возможных проектных решений. Это та цена, которую приходится платить
за успех. В своем потрясающем сборнике статей по кадровому обеспечению Лар
ри Константайн высказывает следующие соображения:
«Синтез приводит к появлению оригинальной концепции, в которую входят сущ
ностные характеристики всех представленных идей и предложений… Консенсус,
построенный на основе синтеза, не только включает в себя лучшие из предложен
ных альтернатив, — он, как правило, вводит новые характеристики и возможнос
ти, являющиеся логическим продолжением объединения высказанных идей»2.
ÊÎØÀ×ÜÈ ÐÀÇÁÎÐÊÈ — ×ÓÆÀÊ
Работать с Полом было чрезвычайно трудно. Он меня ужасно раздражал. То обстоя
тельство, что директор переманил его от нашего главного конкурента, назначив ему зар
плату больше моей, а затем поручил мне им руководить, ничуть не способствовало смяг
чению наших отношений. Ну и что, что он доктор физических наук и единолично написал
1
2
Мне очень понравилась фраза, которую в фильме «Crimson Tide» Джин Хэкман сказал Дэнзелу Вашинг
тону: «Мы должны не заниматься демократией, а оберегать ее». Аналогичным образом, проводя про
ектное совещание, лучше воздерживаться от реверансов в пользу той или иной обсуждаемой идеи —
как бы красноречиво ее ни защищали приверженцы. Ваша цель заключается в том, чтобы поощрять
активный и плодотворный мыслительный процесс.
Larry L. Constantine, The Peopleware Papers (Upper Saddle River, NJ: Yourdon Press, 2001), p. 10.
Ïðîåêòíûå ñîâåùàíèÿ 115
потрясающую программу, которая заставила нашу компанию заметно потесниться на
рынке? С ним было невозможно работать. Он был полностью уверен в своей неизмен
ной правоте и воспринимал коллег как молокососов. Естественно, собственные пред
ставления о совершенстве были для него единственной точкой зрения на все предпола
гаемые функции программы. Он не хотел ничего знать ни о компонентной разработке,
ни о программировании в команде. Передо мной стояла невыполнимая задача — задей
ствовать Пола в процессе разработки нового поколения программных продуктов, с по
мощью его идей побудить к действию остальных специалистов и при этом умудриться
сделать так, чтобы они тоже почувствовали свою причастность к проектному решению.
Итак, я принялся за планирование первого проектного совещания, на котором дол
жен был появиться Пол. По моему плану на совещании предполагалось описать те архи
тектурные методики, которые мы применяли ранее, и показать их в роли проводника
нашей компании в будущее. У Пола была другая точка зрения. Он заявил мне буквально
следующее: «Ральф, неужто ты действительно думаешь, что на этих изношенных време
нем идеях можно построить революционный продукт?» Вопрос был, конечно, ритори
ческий — по крайней мере, мне хватило мозгов, чтобы прийти к тому же выводу. Что же
мы имели после недели проектных совещаний? А ничего, кроме критических коммента
риев Пола и полного недоумения остальных сотрудников, искавших поддержки с моей
стороны. Впрочем, это обстоятельство не повергло меня в уныние. И хотя неделька вы
далась совершенно ужасной, я не придумал ничего лучшего, чем позволить Полу спо
койно заниматься разработкой, надеясь, что все, в конечном итоге, образуется.
Через месяц я пришел к директору и заявил, что, не имея возможности распоряжать
ся рабочим режимом Пола (его зарплатой, вопросами его повышения, увольнения и
проч.), я не могу им управлять и, соответственно, не беру на себя ответственность за
результаты его дальнейшей деятельности. К сожалению для меня, директор согласился
с этими доводами; только после этого я осознал, в какой кошмарной ситуации оказался.
Получалось, что если результаты деятельности Пола окажутся неудовлетворительны
ми, винить в этом можно будет только меня. Была и другая трудность — я начал нра
виться Полу. Он то думал, что я изолировал его от группы по той причине, что оценил
его способности, а совсем не потому, что с учетом его кошмарного характера у меня не
было другого выхода. Как впоследствии выяснилось, никаких особых способностей у По
ла не было. Ему просто один раз повезло. Как я узнал после многочисленных и продол
жительных ужинов с этим деятелем, за долгие годы он сменил уйму должностей и успел
позаниматься самыми разными делами, для всех он оказывался чужаком.
Конец истории взаимоотношений Ральфа и Пола неутешителен. В конце концов,
Ральфу пришлось уволить Пола — по той лишь причине, что выхода его следующего
чудо продукта из стадии альфа тестирования никто так и не дождался. Остальные чле
ны группы, ощущая свою полную невостребованность, замкнулись в себе, и я их прекрас
но понимаю. Большую часть своего времени Ральф тратил на то, чтобы изолировать
Пола от каких бы то ни было других контактов с остальными специалистами, поскольку
совещания тот неизменно превращал в сеансы разгромной критики их работы. Из этой
истории мы можем сделать несколько выводов.
Прошлые достижения отдельного сотрудника группы совершенно не гарантиру
ет успешной деятельности группы в целом.
Формированием группы должен заниматься только ее руководитель. В этом от
ношении он должен пользоваться полным доверием своего начальника.
Нельзя оценивать потенциал сотрудника, отталкиваясь только от его последних
достижений. Необходимо тщательно изучить весь опыт его работы.
Некоторые люди просто не способны работать в команде, и не стоит заставлять их
учиться этому. Возможно, они просто не подходят для работы в вашей компании.
116 Ãëàâà 5 • Êàê âåñòè ñîâåùàíèÿ
Áåñåäû îäèí íà îäèí
Время от времени имеет смысл общаться с каждым из сотрудников в отдельно
сти. Разумно также отвести некоторое время на консультирование новичков и по
пытки помочь тем квалифицированным специалистам, которые, несмотря на ква
лификацию, завязли в своем проекте. К подобным беседам следует относиться
с не меньшей серьезностью, чем к любым другим разновидностям совещаний. Пла
нируйте их, делайте заметки и учитывайте специфику межличностных отноше
ний с конкретным сотрудником. Результатом беседы должна стать выработка
плана действий. Положительных эмоций, почерпнутых от общения с хорошим
человеком, в данном случае недостаточно.
Ê âñòðå÷àì îäèí íà îäèí ñëåäóåò îòíîñèòüñÿ ñ íå ìåíüøåé ñåðüåçíîñòüþ, ÷åì ê ëþáûì
äðóãèì ðàçíîâèäíîñòÿì ñîâåùàíèé. Ïëàíèðóéòå èõ, äåëàéòå çàìåòêè è ó÷èòûâàéòå
ñïåöèôèêó ìåæëè÷íîñòíûõ îòíîøåíèé ñ êîíêðåòíûì ñîòðóäíèêîì. Ðåçóëüòàòîì
áåñåäû äîëæíà ñòàòü âûðàáîòêà ïëàíà äåéñòâèé. Ïîëîæèòåëüíûõ ýìîöèé, ïî÷åðïíóòûõ
îò îáùåíèÿ ñ õîðîøèì ÷åëîâåêîì, â äàííîì ñëó÷àå íåäîñòàòî÷íî.
Попытайтесь собраться (как вы понимаете, дисциплина — это одно из тех ка
честв, которое вам как лидеру постоянно придется совершенствовать) и выдели
те один день в неделю на плотное взаимодействие с каждым из подчиненных. Не
всем требуется консультация один на один, но, с другой стороны, если вы будете
помогать своим сотрудникам, они станут более серьезно относиться к поставлен
ным вами задачам и, осознавая свою значимость для вас, постараются их решить.
Нужно сделать так, чтобы ваши цели стали их целями. Уделяя сотрудникам вре
мя, вы сможете выработать в них чувство групповой ответственности за решение
поставленных перед вашим отделом задач. Эта цель лучше всего реализуется при
общении один на один.
Специалисты — это ваш самый ценный ресурс. С другой стороны, они способ
ны создавать самые неприятные проблемы. Следовательно, построение устой
чивых, профессиональных отношений с подчиненными есть залог вашего преу
спеяния в роли лидера. Остерегайтесь переводить отношения с сотрудниками на
личностную основу. Это довольно трудно — в конце концов, любое общение между
двумя людьми проходит на личностном уровне. Тем не менее в общении с сотруд
никами вы должны поддерживать профессиональную направленность, подкреп
ляя тем самым свое лидерское положение. Спору нет — друзья нужны любому,
однако в бизнесе такие отношения не всегда хороши. В дело вмешивается слиш
ком много внешних обстоятельств — хотя бы тот факт, что благополучие подчи
ненных всецело зависит от вас. Если в какой то момент вам придется принять
решение об увольнении сотрудника, с которым вы установили личные дружеские
отношения, такой поступок рискует оказаться слишком трудным. Если же отно
шения с ним строго профессиональны, вы сможете проявлять большую объек
тивность.
Такие вопросы, как повышение заработной платы, повышение по службе, ре
шаются исключительно в ходе бесед один на один. Если в вашей компании утвер
ждена формальная процедура критического анализа, у вас есть шанс остаться
объективным. Следует отдавать себе отчет в том, что любой критический анализ
Ñîâåùàíèÿ ñ äðóãèìè ãðóïïàìè 117
субъективен по своей сути, что, впрочем, нисколько не умаляет важности этого
процесса. Исполняя роль лидера, вы должны постоянно наблюдать за результата
ми сотрудников. Попытки вспомнить о прошлых достижениях и неудачах сотруд
ника при проведении критического анализа его текущей деятельности — не слиш
ком удачный подход. Один из вариантов оценки продуктивности сотрудника
(либо на бумаге, либо в электронном виде) предполагает еженедельный сбор ин
формации о результатах его работы. Если вы ведете личные дела, отмечайте в них
успехи и затруднения каждого работника. В частности, в этих документах следу
ет указывать адрес электронной почты сотрудника, динамику соблюдения или,
напротив, нарушения им сроков сдачи работ, участие в выработке проектных ре
шений, предложения по решению проблем.
Помимо прочего, во время встреч с сотрудниками «один на один» вы получае
те возможность отслеживать работу над проектом и препятствия, с которыми под
чиненные сталкиваются в своей деятельности. Этот процесс можно формализо
вать. К примеру, можете завести стандартный опросник и попросить сотрудников
группы раз в неделю заполнять его. Информация, содержащаяся в анкетах, по
зволит вам выявлять трудности и своевременно направлять усилия на их преодо
ление. При просмотре анкеты конкретного сотрудника пригласите его к себе в ка
бинет и обсудите варианты разрешения возникших проблем. Решать проблемы
по мере их появления, на ранних этапах значительно эффективнее, чем биться
с проектом, разъедаемым проблемами, не выявленными вовремя.
Ñîâåùàíèÿ ñ äðóãèìè ãðóïïàìè
Итак, вы получили новую должность. Теперь вам предстоит существенно расши
рить границы своего общения. На эту тему есть иллюстрация Скотта Адамса (Scott
Adams) — обратите внимание на позицию руководителя (рис. 5.2).
Ðèñ. 5.2. Ïðîãðàììèñò, òîëüêî ÷òî óçíàâøèé î ïîâûøåíèè
Надеюсь, что вы запуганы чуть меньше, чем изображенный на рисунке програм
мист. Мы, технари, сталкиваясь с необходимостью взаимодействия с группами раз
работчиков, с которыми в обычных условиях не общаемся, чувствуем себя не слиш
ком уверенно. Будьте готовы к тому, что «обычный» круг общения начнет расши
ряться. Далеко не все совещания, которые вам предстоит провести, предполагают
118 Ãëàâà 5 • Êàê âåñòè ñîâåùàíèÿ
присутствие исключительно подчиненных программистов. На них, скорее всего,
будут приходить сотрудники нетехнического профиля, равно как и специалисты
в тех технических дисциплинах, в которых вы не слишком смыслите. Определен
ного внимания к себе будут требовать сотрудники, ответственные за формули
ровку бизнес требований, люди из отделов поддержки и тестирования, специали
сты по проверке качества, финансовые сотрудники и многие другие.
Как вести себя на таких совещаниях? На некоторые из них придется прихо
дить в официальном наряде — поэтому пополните свой гардероб хотя бы одним
хорошим костюмом. Помните, люди не вашего круга ожидают, что вы покажете
себя немного странноватым; постарайтесь, впрочем, держать эту наигранную при
дурковатость в рамках стереотипа творческой личности и сделайте так, чтобы
люди, привыкшие считать доходы и далекие от логических выражений, воспри
нимали вас адекватно.
Всегда обрисовывайте ваш отдел в идиллических тонах. Никогда не сваливай
те вину за срыв сроков на своих подчиненных. Такую позицию очень не любят,
и подобными действиями вы только подогреваете нашу и без того пожароопас
ную индустрию, в которой программисты при оценке своих попыток соблюдения
контрольных сроков проявляют себя убежденными идеалистами. Мы можем сколь
угодно пребывать в уверенности, что программирование есть искусство (а это дей
ствительно так). При этом не стоит забывать, что ваш начальник мыслит по дру
гому; по его мнению, программирование есть наука с присущей этому понятию
предсказуемостью. Выслушивая похвалы, считайте, что вам повезло, но реагируй
те на них скромно и достойно; делайте акцент на том, что если бы не ваша коман
да, никаких достижений не было бы в помине. Хотите высказать сотруднику свои
претензии — ради бога, но только в приватной обстановке.
Íèêîãäà íå ñâàëèâàéòå âèíó çà ñðûâ ñðîêîâ íà ñâîèõ ïîä÷èíåííûõ. Òàêóþ ïîçèöèþ
î÷åíü íå ëþáÿò, è ïîäîáíûìè äåéñòâèÿìè âû òîëüêî ïîäîãðåâàåòå íàøó è áåç òîãî
ïîæàðîîïàñíóþ èíäóñòðèþ, â êîòîðîé ïðîãðàììèñòû ïðè îöåíêå ñâîèõ ïîïûòîê
ñîáëþäåíèÿ êîíòðîëüíûõ ñðîêîâ ïðîÿâëÿþò ñåáÿ óáåæäåííûìè èäåàëèñòàìè.
Успешное взаимодействие с остальными подразделениями компании заста
вит сотрудников уважать вас. Уважению не будет предела, если вы позволите им
не присутствовать на длительных и иногда утомительных совещаниях, которых
вам самому никак не избежать.
Одна из основных ваших задач в процессе взаимодействия с другими группа
ми заключается в том, чтобы обеспечить своевременное получение бизнес требо
ваний в как можно более завершенном состоянии. Разбухание области действия,
как известно, начинается со скверно определенных требований. Ситуация ухуд
шается, когда программисты, столкнувшись с плохим описанием продукта, начи
нают фантазировать, и с этого момента разрастание области действия уже прак
тически невозможно контролировать. Этапу описания продукта следует уделять
не меньше времени, чем этапам проектирования и программирования. Такие вре
менные затраты окупаются — дело в том, что, чем более комплексной информа
цией вы обладаете по части коммерческих приоритетов компании, тем лучше себе
представляете, какой продукт ей необходим для того, чтобы занять достойную
позицию на рынке.
Ðåòðîñïåêòèâíûå ñîâåùàíèÿ 119
Еще несколько слов о требованиях. Будучи программистом, вы, естественно,
любите разрабатывать программные продукты. Отталкиваясь от идеи, вы преоб
разуете ее в виртуальную реальность. Согласитесь, есть некое волшебство в со
здании выверенного пользовательского интерфейса, который, к тому же, грамот
но состыкован с прикладной частью. Скорее всего, лучшим из всех созданных вами
программных продуктов был тот, относительного которого вы четко представля
ли себе бизнес требования. Думаю также, что как программист вы получили от
разработки этого приложения больше всего приятных минут. Постарайтесь доне
сти это чувство до группы описания продукта, и по мере сбора требований очер
чивайте ее сотрудникам пределы возможного. За счет своих технических способ
ностей вы сможете на корню избавляться от всех неудачных идей; навыки же
сотрудников группы описания продукта в области бизнеса помогут вам генери
ровать новые идеи. Учитесь организовывать сотрудничество технологии и бизне
са; при этом не забывайте, что доминирующую роль в этом союзе играет именно
бизнес. Вряд ли вам как технарю это понравится, но такова реальность, и подход,
о котором я говорю, себя окупает.
Ðåòðîñïåêòèâíûå ñîâåùàíèÿ
Будем надеяться, что поминки проектов вам проводить не придется. Совещания,
тип которых обозначен в заголовке, не должны представлять собой арену для
выражения недовольства; на самом деле это лишь формальный способ обучения
на собственном опыте. Как писал Норман Кит (Norman Keith):
«Степень эффективности и успеха ретроспективных совещаний обусловлива
ется безопасностью сотрудников. Под безопасностью я имею в виду защищен
ность сотрудников от критики в рамках их группы. Лишь при таком условии
они смогут обсуждать собственные результаты и даже признаваться в том, что
поставленных целей можно было достичь по другому, более оптимальными
способами — иначе говоря, учиться анализировать выполненные проекты. Без
опасность необходимо культивировать и поддерживать. Несмотря на то, что,
по большому счету, безопасность выражает ответственность всех участников
ретроспективного совещания, его руководитель призван создавать условия для
безопасности, следить за ее поддержанием и контролировать это ощущение.
Чтобы сотрудник чувствовал себя в безопасности, он должен быть уверен, что
за проявленную честность он не получит по ушам (например, не нарвется на
отрицательную оценку во время следующего критического обзора). В ходе рет
роспективного совещания не обойтись без постоянного и должным образом
поощряемого взаимодоверия»1.
Проведя ретроспективное совещание в «безопасном» формате, вы получаете
хорошие шансы почерпнуть довольно существенные сведения относительно не
давно завершенного проекта. Эти знания, в свою очередь, позволят вам усовер
шенствовать процесс разработки. Необходимость соблюдения на ретроспектив
ных совещаниях ощущения безопасности связана с тем, что иногда сотрудникам
на них приходится отвечать на неприятные вопросы.
1
Norman L. Kerth, Project Retrospectives (New York: Dorset House Publishing, 2001), p. 7.
120 Ãëàâà 5 • Êàê âåñòè ñîâåùàíèÿ
В ходе ретроспективного совещания, помимо прочего, полезно определиться
с ответами на нижеследующие вопросы.
Насколько четко была сформулирована спецификация продукта? Другой ва
риант того же вопроса: не случилось ли так, что в силу многократного пере
смотра спецификации этап проектирования пришлось отложить на слишком
долгий срок?
Нашлось ли у вас время на макетирование проектного решения или же вы сра
зу приступили к кодированию?
Трудно ли было расширять существующую архитектуру новыми функциями?
Внес ли руководитель проекта весомый вклад в его успешную реализацию?
Как можно оценить его организованность, компетентность и готовность к уча
стию в проекте?
Если бы вам представилась возможность написать тот же код снова, сделали
бы вы что нибудь по другому?
Находились ли в вашем распоряжении все программные инструменты, необ
ходимые для решения поставленных задач?
Как вы думаете, какие составляющие процесса разработки имеет смысл изме
нить?
Последний вопрос, естественно, открывает возможности для обсуждения ши
рокого круга разнообразных проблем. Такие дискуссии только приветствуются —
правда, проводить их следует как можно ближе к предмету обсуждения, то есть
к выполненному проекту, и поощрять конструктивные предложения.
Òåëåêîíôåðåíöèè
Телеконференции отличаются от традиционных совещаний лишь тем, что не пред
полагают применения языка жестов и обычно проводятся в соответствии с чет
ким планом в приличных акустических условиях. Впрочем, стоит заметить, что
невозможность использования языка жестов существенно снижает эффектив
ность совещаний. Несмотря на это, географические факторы иногда принуждают
руководителей проводить совещания именно по телефону. В нашей отрасли они
на сегодняшний момент довольно распространены. Если во время совещания пла
нируется обсудить те или иные зрительные образы, не забудьте предварительно
разослать экземпляры соответствующих изображений и попросите участников
с ними ознакомиться. Не нужно зачитывать на совещаниях какие бы то ни было
документы — ваши сотрудники взрослые люди, они умеют читать; соответствен
но, проводя время таким образом, вы его попросту убиваете.
При проведении телеконференций опасайтесь безоговорочно полагаться на
принцип «молчание — знак согласия». Иначе говоря, если на принятое вами ре
шение или донесенную вами информацию не поступает никаких комментариев,
считается, что слушатели согласны с вашей позицией. В целом, действие этого
принципа следует оценивать положительно — в конце концов, он способствует
проявлению участниками совещания активной позиции. Поскольку в данных ус
ловиях вам не известно ни выражение лица, ни мимические реакции собеседни
Âðåìÿ ìåæäó ñîâåùàíèÿìè 121
ков, молчание действительно правомерно воспринимать как знак согласия. Тем
не менее применимость этого принципа во многом зависит от специфики той груп
пы людей, с которыми вы общаетесь. Если вам приходится проводить телеконфе
ренции с людьми, с которыми вы ни разу не встречались, принимать молчание
за согласие как минимум опрометчиво. Совещание с незнакомыми людьми, по
строенное на селекторной связи, эффективным сделать довольно трудно. По этой
причине, если вы можете себе позволить проводить видеоконференции, лучше
всего остановиться именно на них.
Растягивать телеконференцию более чем на час не имеет смысла. Чрезмерная
продолжительность такого совещания свидетельствует либо о его перенасыщен
ности, либо о неудачной повестке дня. Начинать совещание следует в оговоренное
время, причем ждать, пока к нему подключатся все предполагаемые участники,
не нужно. Если уж они пропускают важные сведения из за собственной медлитель
ности, пусть учатся на своих ошибках. Не стоит также и опаздывать с открытием
совещания — во первых, тем самым вы проявляете неуважение к собеседникам,
во вторых, демонстрируете непрофессионализм, в третьих, подаете косвенный
сигнал о том, что обсуждаемые вопросы на самом деле не так уж важны.
Помните, что при проведении телеконференций вашим единственным ин
струментом оказывается голос. Пользоваться им стоит разумно и осмысленно.
Фиксируйте на бумаге основные моменты совещания (или поручите эту функ
цию одному из своих сотрудников); не забывайте также и о том, что после окон
чания совещания вы должны как можно быстрее отправить всем его участникам
стенограмму с четкими указаниями к действию. Во время телеконференций сле
дует избегать лишней болтовни. В умеренном остроумии нет ничего предосуди
тельного, однако излишне усердствуя в этом отношении, вы рискуете растянуть
совещание.
Âðåìÿ ìåæäó ñîâåùàíèÿìè
Не слишком удивляйтесь тому, что я сейчас предложу. Сотворите про себя «ле
генду». Она обязательно должна основываться на реальных фактах, однако если
окружающие вас люди будут проявлять стремление к приукрашиванию вашей
преданности работе, не мешайте им в этом. Впрочем, каких то особых шагов в этом
направлении предпринимать не стоит. Пусть за вас говорят результаты. О чем
должна быть ваша легенда? Всего навсего о том, что вы последовательно придер
живаетесь принципов эффективного лидерства — не больше и не меньше.
Не путайте преданность с плохим планированием. Большинство менеджеров
работаютбольше стандартных 40 часов в неделю. При этом переработка не всегда
свидетельствует о том, что руководитель предан своей деятельности. Вполне воз
можно, он просто не слишком организованный человек, не справляющийся со сво
ими обязанностями в разумное время. Кроме того, если вы пренебрегаете личной
жизнью и ставите работу во главу угла, вполне вероятно, что в легенде вы пред
станете отъявленным фанатиком. Работая больше, чем требуется, вы вольно или
невольно заставляете окружающих вас людей также стремиться к увеличению сво
его рабочего времени. Иногда это действительно необходимо. Однако, делая из этого
привычку, имейте в виду, что ваши лидерские качества развиты недостаточно
122 Ãëàâà 5 • Êàê âåñòè ñîâåùàíèÿ
и ваш персонал страдает. Как я говорил в предыдущей главе, контролировать ра
бочее время и определить роль работы в контексте своего существования вполне
в ваших силах.
Наверное, я излишне перехожу на личности, но факт остается фактом — руко
водитель, действующий эффективно, оказывает на своих подчиненных опреде
ленное влияние. То, каким будет это влияние, зависит от вашей меры ответствен
ности. О том, каким вы останетесь в памяти людей, с которыми работаете, нужно
думать не меньше, чем о взаимоотношениях внутри семьи. Если у вас целостный
характер, ваш публичный образ станет отражением личностных характеристик.
Поймите меня правильно: я не призываю к самолюбованию. Мне просто хочется,
чтобы вы осознали некоторые особенности роли лидера и попытались правильно
ими воспользоваться. Всем содержанием главы о совещаниях я хотел побудить
вас сфокусироваться на отношениях с окружающими.
Êîíñåíñóñ è äåéñòâèÿ â ðåçóëüòàòå ñîâåùàíèé
В этой главе я упомянул о нескольких типах совещаний. Все они характеризуют
ся единой целью, которая состоит, во первых, в достижении консенсуса среди
участников, и, во вторых, в составлении плана дальнейших действий. Эти задачи
решаются за счет профессионального поведения на любых совещаниях, вне за
висимости от того, насколько формальный или неформальный характер они но
сят. Что я имею в виду под профессиональным поведением? Согласно Вебсте
ру (Webster), одним из аспектов профессионализма является «последовательное,
методичное проведение каких либо действий». Так и в нашем случае. После
довательность в деле проведения совещаний в конечном итоге приведет вас к ус
пеху. Дискуссии на совещаниях следует поощрять, поскольку на их основе рож
даются идеи. Ваша компетенция — еще один аспект профессионализма — в ходе
дискуссий, призванных перетекать в конкретные действия, должна быть оче
видной.
Попробуем обобщить все вышесказанное. Итак, участвуя в совещаниях или
ведя совещания, придерживайтесь следующих принципов.
Не превращайте совещание в партсобрание. Участие в совещаниях — это тоже
работа, и цель состоит в том, чтобы приступить к новой рабочей неделе осмыс
ленно.
При проведении проектных совещаний обязательно подготавливайте четкий
план действий. Руководите разумно и учитывайте фактор группового пове
дения.
Проводя беседы с сотрудниками один на один, следуйте принципам, характер
ным для совещаний в более крупном составе: пытайтесь достичь консенсуса
и выстроить план действий.
Проводя совещания с нетехническими специалистами, помните, что вы оли
цетворяете образ технаря. Пытайтесь доносить сложные идеи простым язы
ком. Попытки произвести на бухгалтерских работников впечатление, жонгли
руя таинственными сокращениями, вряд ли прибавят вам уважения. На таких
×òî äàëüøå 123
совещаниях ведите себя как педагог. В то же время исполняйте эту роль пре
дусмотрительно, избегайте высокомерия.
Проводя ретроспективные совещания по проекту, не поддавайтесь соблазну
свалить все грехи на другие отделы. Попытайтесь выяснить, в каких областях
вы сами и ваши сотрудники могли бы добиться более высокой продуктивности.
Старайтесь свести количество телеконференций к минимуму. Путем тщатель
ной подготовки и составления четкого плана старайтесь делать их как можно
насыщеннее.
×òî äàëüøå
Многое из того, что я рассказываю в этой книге, носит личностный оттенок. Дей
ствительно, трудно придумать тему более личностную, чем лидерство при прове
дении совещаний. В следующей главе я расскажу, как исполнять роль техниче
ского лидера. Здесь вам также потребуются навыки группового общения, хотя,
располагая обширным опытом взаимодействия с технологиями (по крайней мере,
большим, чем общения с людьми), вы, скорее всего, будете чувствовать себя в этой
роли более комфортно. Поймите меня правильно — я даже мысли не допускаю,
что всю свою жизнь вы прожили в изоляции от общества. Просто технические
навыки составляют основу вашего участия в общей деятельности. Не бросайте
чтение — следующая глава вам, скорее всего, понравится больше, чем все пре
дыдущие.
Гл а в а
6
Ôèëîñîôèÿ è ìåòîäû
òåõíè÷åñêîãî ëèäåðà
Весьма высока вероятность того, что причина, по ко
торой вас сделали руководителем, заключается в ва
ших успехах на поприще техники. Это свое предполо
жение я уже ранее высказывал. И хотя технические
навыки далеко не всегда гарантируют качество руко
водства, для исполнения роли, которую я намерен опи
сать в этой главе, вы подходите идеально. Многое из
того, о чем я рассказывал в предыдущих главах, пола
гаю, привело вас в уныние своей новизной; материал
же этой главы, напротив, скорее всего, покажется вам
знакомым и, может быть, даже тривиальным. Это со
вершенно не означает, что читать главу не надо, — не
зря же я ее написал, в конце концов! На самом деле взглянуть на технические
проблемы с точки зрения технического лидера очень полезно. Ведь теперь вы не
просто «технический руководитель» группы; вы — лидер с большой буквы. При
нятие решений — это ваша прерогатива. За последствия принятых решений,
сказывающихся на разрабатываемых программных продуктах, вы также несете
ответственность, поэтому проблема выбора и принятия решений выходит на пер
вый план.
Каким образом в процессе принятия решения вам поможет эта глава? В ней
мы рассмотрим некоторые технические принципы и порассуждаем о деталях —
тем самым я попытаюсь привить вам уверенность в своих действиях. С моей точ
ки зрения, главное в нашей высокотехнологичной профессии — сделать так, чтобы
лидерство осуществлялось на основе некоего философского видения, раскрыва
ющего технические навыки ведущих программистов. Этой философской основой
мы займемся в первую очередь. Не стоит, правда, забывать, что без принципов ее
практической реализации полноценное лидерство невозможно, и, соответствен
но, успешно пасти котов вам также не удастся.
Êàê óðàçóìåòü ñâîþ òåõíè÷åñêóþ ðîëü è ïðèäåðæèâàòüñÿ åå 125
Êàê óðàçóìåòü ñâîþ òåõíè÷åñêóþ ðîëü
è ïðèäåðæèâàòüñÿ åå
Роль технического лидера заключается в том, чтобы координировать архитектур
ные и проектные решения. Архитектура и проектирование — это, как известно,
две разные вещи. Да, действительно, программисты иногда воспринимают их как
синонимы, но, я вас уверяю, это в корне неправильно. Практикуя техническое
лидерство в масштабе своего отдела, вы скоро убедитесь в том, что проектирова
ние компонентов приложений очень сильно отличается от разработки их общей
архитектуры. Архитектура направлена на многократное использование проект
ных решений. В идеале перед сборкой системы из составляющих ее компонентов
неплохо было бы макетировать архитектурное понятие. В этом контексте вспом
ните компонентное конструирование из области объектно ориентированной тех
нологии — своей основной целью оно провозглашает многократное использова
ние кода. Итак, мы имеем дело с двумя совершенно разными задачами, и по моему
скромному, но правильному мнению, многократное использование проектных
решений значительно важнее.
Àðõèòåêòóðà îðèåíòèðîâàíà íà ìíîãîêðàòíîå èñïîëüçîâàíèå ïðîåêòíûõ ðåøåíèé.
Сила объектно ориентированной технологии вне зависимости от языка, на ко
тором она реализуется, — это возможность создания объектов, связывающих при
кладные данные с вариантами пользовательского взаимодействия. Детали при
этом скрываются. Таким образом, избегая непосредственного соприкосновения
с уровнями данных и пользовательского интерфейса, объекты получают откры
тые интерфейсы, которые, в свою очередь, взаимодействуют со структурой про
граммы и процессами. Итак, мы получаем возможность собирать компоненты, со
гласующиеся со свойствами и методами, имена которых значимы в контексте
проблемной области (в противоположность области решений). К примеру, метод
под именем ShowAppointments, наполняя свойство Appointments графического поль
зовательского интерфейса, способен одновременно скрывать детали — такие как
Select * from Appointments where Date = Today. Таким образом, удобочитаемость про
грамм открывает возможности для решения конкретных задач.
Именно в этом высоком уровне понимания кроются огромные преимущества
объектно ориентированных методов, за счет которых последние выгодно отлича
ются от функциональной декомпозиции и структурных методик, доминировав
ших в более ранний период компьютерного программирования. В то же время
узкое место объектно ориентированной технологии приходится как раз на созда
ние общей архитектуры системы. С одной стороны, объектно ориентированные ме
тодики позволяют успешно проводить архитектурный анализ; с другой — навыки,
126 Ãëàâà 6 • Ôèëîñîôèÿ è ìåòîäû òåõíè÷åñêîãî ëèäåðà
полученные при создании компонента, не соответствуют напрямую тем навыкам,
которые требуются для организации целостной системы компонентов. Это белое
пятно в наборе средств объектно ориентированной технологии как раз закрыва
ется архитектурными методиками. Ваша задача как технического руководителя
состоит в том, чтобы обеспечить создание системной архитектуры до принятия
решений по технологии реализации и деталям компонентов, из которых данную
систему предполагается конструировать.
Обратимся к аналогии. Классическую архитектурную традицию западной ци
вилизации принято отсчитывать от древнегреческих и древнеримских строений.
Эти здания, простоявшие уже более двух тысяч лет, подобно литературным про
изведениям талантливых авторов, доносят до непосвященного наблюдателя про
стое и ясное послание. В то же время при более детальном анализе структуры
этих зданий выясняется, что в них скрыты многочисленные свидетельства дотош
ной творческой работы. Программная архитектура способна на такие же чудеса —
демонстрируя внешний блеск, она может заключать в себе невероятную слож
ность. Впрочем, поскольку наша дисциплина существует всего лишь полвека, до
того момента как ее лучшие достижения станут называть классическими, пройдет
еще много времени. Как технический лидер вы должны заложить те основы, на
которых сотрудникам вашей группы и, возможно, другим разработчикам пред
стоит заниматься непосредственно конструированием. Да, мы живем в то время,
когда популярное искусство необдуманно провозглашается непреходящей цен
ностью. При этом не следует забывать, что результаты наших трудов над клавиа
турой должны пройти проверку временем.
Êîíñòðóèðîâàòü èëè âûðàùèâàòü
Традиционной метафоре строительства в нашей профессии соответствует термин
«конструирование»1. Как часто мы им пользуемся для описания своих действий?
По моим наблюдениям, довольно часто. Все начинается с детства. Если вы из мо
его поколения, то ребенком, наверное, играли с конструкторами — ну а представи
тели поколения X, вероятно, помнят свои экзерсисы с Lego. Обиходное понятие
«конструирование программного обеспечения» вполне доходчиво обозначает повсед
невную деятельность программиста. Попробуем проанализировать эту метафору
в буквальном смысле и объяснить, что значит дополнять приложения новыми ха
рактеристиками. Можно ли надстроить небоскреб дополнительными десятью этажа
ми и при этом пребывать в уверенности, что фундамент их выдержит? Мне так не
кажется; надеюсь, что и вы придерживаетесь моего мнения. Придется обратиться
к еще одной метафоре — садоводству. Разбивая сад и выращивая его, вы, естествен
но, время от времени выкорчевываете одни растения и высаживаете другие. В сво
ей книге о прагматическом программировании Эндрю Хант (Andrew Hunt) и Дэ
вид Томас (David Thomas) высказываются об этой метафоре следующим образом:
«Растения в саду высаживаются, с одной стороны, в соответствии с исходным
замыслом, а с другой — согласно текущим обстоятельствам. Некоторые из них
1
И строительство, и конструирование выражаются в английском языке одним словом — construction.
Поэтому нам при переводе пришлось в меру сил лавировать между этими двумя значениями. Таким
вот печальным образом гипертрофированная метафоричность автора разбивается об языковой барь
ер. — Примеч. перев.
Ïðèìàò àðõèòåêòóðû 127
выживают, другим же суждено превратиться в компост. Растения можно пере
саживать, менять их расположение, играя, таким образом, со светом и тенью,
ветром и дождем. Переросшие растения подрезают или срезают, а если, к при
меру, какой нибудь цветок по своему цвету не соответствует окружению, его
пересаживают в более подходящее (с эстетической точки зрения) место. Зани
маясь садоводством, мы выдираем сорняки и удобряем растения, которым нуж
на дополнительная поддержка. Хороший садовод постоянно наблюдает за здо
ровьем растений на своем участке и при необходимости вносит разного рода
коррективы (удобряет почву, пересаживает растения, придумывает новый ва
риант разбивки)»1.
Надо сказать, что метафора садоводства значительно лучше соответствует раз
работке программных средств. Она делает очевидным преходящий характер про
граммных продуктов и акцентирует внимание на архитектуре, гибкость которой
подразумевает возможность реализации новых структур. В контексте архитекту
ры системы конструируются, а непосредственно программные продукты выра
щиваются. Чтобы соответствовать потребностям бизнеса XXI века, мы должны
построить органичную методику разработки программных продуктов.
×òîáû ñîîòâåòñòâîâàòü ïîòðåáíîñòÿì áèçíåñà XXI âåêà, ìû äîëæíû ïîñòðîèòü îðãàíè÷íóþ ìåòîäèêó ðàçðàáîòêè ïðîãðàììíûõ ïðîäóêòîâ.
Метафора садоводства, к тому же, выражает различие между органическим
и синтетическим. Все органическое выращивается; синтетические же объекты со
бираются из конструируемых компонентов. Действительно, конструируя компо
ненты, мы делаем их синтетическими по самой природе. Однако та среда, в которой
их предполагается выращивать, должна выводить целое за рамки суммы компо
нентов. Кроме того, она должна предусматривать возможность адаптации к изме
няющимся коммерческим требованиям и к технологической эволюции.
Итак, пытаясь усвоить материал, который я излагаю в дальнейшем, не забы
вайте о биологии и старайтесь не зацикливаться на аналогиях со строительной
индустрией. Функции метафор ограничены — они просто напросто помогают при
менить абстрактные понятия в условиях рутинной технической деятельности.
Нельзя писать код, исходя из метафоры. В этом процессе без деталей проектного
решения не обойтись. С другой стороны, все эти детали в совокупности формиру
ют образец. А вот образец уже можно рассматривать метафорически, анализируя
степень его применимости к решению бизнес задач. Вы ведь еще не забыли, как
важно для нас думать? Штудируя мою книгу, вы должны были уже уяснить, что
главное в нашей работе — мыслить. Мыслить широко и ни в коем случае не по
верхностно. Никогда не забывайте этот принцип — он вам пригодится.
Ïðèìàò àðõèòåêòóðû
За последнее десятилетие появилось множество работ — как фундаментальных,
так и прикладных, — доказывающих необходимость применения в процессе раз
1
Andrew Hunt and David Thomas, The Pragmatic Programmer (New York: Addison Wesley, 2000), p. 184.
128 Ãëàâà 6 • Ôèëîñîôèÿ è ìåòîäû òåõíè÷åñêîãî ëèäåðà
работки программных средств качественной архитектуры. Исследователи, специа
лизирующиеся в этой области, указывают на то, что огромное количество проек
тов приложений заканчиваются неудачей именно из за пренебрежения архитек
турными вопросами1. В результате выполнения таких проектов, как правило,
получаются «прямолинейные» системы. Их последующая адаптация к изменяю
щимся коммерческим требованиям осуществляется с большими трудностями,
поскольку предполагает выделение значительных временных, трудовых и интел
лектуальных ресурсов.
Занимаясь проектированием той или иной системы, вы должны уделять пер
воочередное внимание рискам. Каким видам рисков? Во первых, риску ухудше
ния позиций компании на рынке, возникающему, когда в существующий продукт
вследствие конкуренции приходится вносить новые непредусмотренные изна
чально черты; риску неумеренного усложнения процесса сопровождения продук
тов, возникающему вследствие жесткой взаимозависимости компонентов подсистем
или негибкости их конфигурации. Еще один вид рисков заключается в неоправ
данной сложности продукта на верхних уровнях архитектуры. Это обстоятель
ство чрезвычайно усложняет задачу кодировщиков, не принимавших участия
в процессе создания системы, но вынужденных выискивать способы исправле
ния базовых компонентов. Все перечисленные проблемы имеют непосредствен
ное отношение к временным и финансовым затратам, которые ваш начальник,
естественно, желает сократить.
Создание архитектуры — это активный творческий процесс, который отнюдь
не ограничивается сидением за клавиатурой, фиксацией коммерческих требо
ваний и реализацией компонентов, которые способны эти требования удов
летворить, в коде. В процессе работы над архитектурой вам придется абстраги
роваться от своих механистических обязанностей и максимально углубиться
в задачу, которую предстоит решить. Спору нет — во многих случаях решение ока
зывается вполне механистическим, то есть чисто программным. И тем не менее,
если вы не разберетесь в задачах, стоящих перед своей компанией, обеспечить
продуктам длительное и продуктивное существование вам, скорее всего, не удаст
ся. Марк и Лора Сьюелл (Marc & Laura Sewell) в своей работе о роли архитек
торов перечисляют ряд важнейших действий, которые должны предшествовать
составлению любого проектного плана2. С точки зрения этих авторов, любой ар
хитектор должен:
в совершенстве владеть искусством выслушивания, опрашивания и наблюде
ния;
1
2
хорошо разбираться в предметной области клиента — будь то банковское об
служивание, деятельность государственных органов, образование, здравоох
ранение, розничная торговля или скачки;
получить стратегическое представление о деятельности предприятия клиента,
не ограничиваясь тактическим или рабочим обзором его деятельности;
Рекомендую в этом контексте ознакомиться с работами апологетов позитивных и негативных этало
нов, например с трудами Брауна (Brown) и других исследователей, чьи публикации перечислены в биб
лиографии.
Marc T. Sewell and Laura M. Sewell, The Software Architect’s Profession (Upper Saddle River, NJ: Prentice
Hall, 2002), p. 68.
Ïðèìàò àðõèòåêòóðû 129
иметь комплексные познания в технологической области — для того чтобы
при разработке архитектурного плана суметь учесть все без исключения ва
рианты стратегических решений;
наладить конструктивное взаимодействие с клиентом и специалистом, ответ
ственным за конструирование;
уяснить видение вопроса клиентом и согласованное с ним проектное реше
ние, следить за их неукоснительным соблюдением.
Не кажется ли вам, что выполнение всех этих требований выходит за рамки
ваших скромных обязанностей? Если вы придерживаетесь такой точки зрения,
рекомендую вам расширить кругозор, предварительно попытавшись вспомнить
все разработанные с вашим участием продукты, которым так и не суждено было
продвинуться дальше первой версии. Все мы так или иначе имели дело с продук
тами однодневками. С моей точки зрения, недостаточно комплексное понимание
задачи приводит к созданию подобного рода тактических решений, которые на
первый взгляд удачны, однако не выдерживают проверки временем.
Архитектор должен уметь решать эту проблему, имея в виду два важных по
нятия: проектные ограничения (design forces), которые обусловливают все реше
ния, принимаемые относительно программных средств, и аналитические позиции
(analysis viewpoints), позволяющие принимать решения в соответствии с проект
ными ограничениями.
Ïðîåêòíûå îãðàíè÷åíèÿ â àðõèòåêòóðíîì ïëàíèðîâàíèè
Поскольку в формализованном виде дисциплина архитектурного планирования
появилась относительно недавно, в ее рамках существует несколько конкури
рующих концепций. Мальво (Malveau) и Маубрей (Mowbray)1 — два эксперта
в этой области — приводят список основных концепций. Это каркас Закмана
(Zachman), открытая распределенная обработка (Open Distributed Processing,
ODP), анализ предметной области, модель 4+1 представлений программной ар
хитектуры и, наконец, академическая программная архитектура. Это уже нема
ло. А знакомы ли вы с положениями каждой из них? Если нет, торопитесь —
принимайтесь за изучение перечисленных концепций, поскольку они предо
ставляют любому специалисту прекрасный инструментарий для создания мно
гократно используемых систем.
Разобравшись с положениями различных архитектурных концепций, вы пой
мете, что все они преследуют общую цель. Она заключается в контроле над проект
ными ограничениями, которые обуславловают все без исключения программные
решения, относящиеся к архитектуре. Проектные ограничения — это те факторы,
которые необходимо учитывать с самого начала процесса разработки программ
ного продукта. Они выражают ряд вопросов, на которые любая архитектура дол
жна отвечать. Частично эти вопросы перечислены ниже.
Сможет ли система предоставить пользователю комфортные условия работы
и функционировать согласно его ожиданиям?
1
Raphael C. Malveau and Thomas Mowbray, Software Architect Bootcamp (Upper Saddle River, NJ: Prentice
Hall, 2001).
130 Ãëàâà 6 • Ôèëîñîôèÿ è ìåòîäû òåõíè÷åñêîãî ëèäåðà
Может ли система функционировать в соответствии с проектным решением,
предусматривает ли она модификацию и сопровождение по мере изменения
коммерческих потребностей и технологии?
Минимизирована ли сложность высокоуровневых архитектурных характери
стик системы?
Какой бы продукт ни создавался, в течение нескольких последующих лет его
ожидают значительные изменения, причем предпосылки для осуществления
этих изменений должны закладываться в фундамент проекта.
В связи с тем, что ожидается реализация решений в аппаратной части, особое
внимание следует уделить созданию, конфигурированию и сопровождению
инфраструктуры.
Достаточна ли компетентность персонала для сопровождения систем, постро
енных на основе новых технологий? Если в конструировании1 применяются
старые технологии, насколько они перспективны с точки зрения продолжи
тельности использования системы?
Ни в коем случае не забывайте об этих вопросах и проблемах. Обязательно
сформулируйте их и донесите до группы разработчиков — ведь умение четко сфор
мулировать вопросы иногда важнее, чем даже знание правильных ответов на них.
Может быть, конечно, в этом я преувеличиваю, но, полагаю, мысль вам понятна.
Способов наделать глупостей всегда более чем достаточно, и первый вопрос, ко
торый вы должны себе задать, звучит так: «Что я должен делать? Какое решение
будет правильным?» Задавая адекватные вопросы, вы сможете организовать со
здание стройной, мощной и долговечной архитектуры.
Àíàëèòè÷åñêèå ïîçèöèè êàê ñðåäñòâî óïðàâëåíèÿ
ïðîåêòíûìè îãðàíè÷åíèÿìè
Чтобы решить проблемы, возникающие благодаря проектным ограничениям, не
обходимо иметь представление о позициях, с которых анализируются любые кор
поративные варианты архитектуры. Аналитическая позиция — это, по сути, точка
зрения на проектное решение, исходя из которой оно анализируется. Эта пози
ция, или точка зрения, изменяется по мере изучения системы с разных сторон,
исходя из степени серьезности различных проектных ограничений. Вне зависи
мости от конкретной концепции создания архитектуры все исследователи выде
ляют несколько общих аналитических позиций, формулируя их в виде вопросов.
Как будет проходить взаимодействие пользователей с системой? (Эту анали
тическую позицию часто называют вариантной.)
Какие компоненты требуется собрать для того, чтобы обеспечить функциони
рование системы?
Каков механизм взаимодействия компонентов, благодаря которому система
функционирует?
1
Как просто, оказывается, вернуться к привычной терминологии! Если бы я сказал «…в выращивании
применяются старые технологии…», смогли бы вы понять, о чем я говорю?
Ïðèìàò àðõèòåêòóðû 131
Какие технологии в наибольшей степени приспособлены для создания данно
го программного обеспечения?
Как предполагается поставить систему клиенту?
Задаетесь ли вы этими вопросами о предполагаемом продукте в ходе проект
ных совещаний (о них мы говорили в предыдущей главе)? Без них не обойтись —
в противном случае у вас получится случайная архитектура, а это крайне опас
ный негативный эталон. Не забывайте, что переработать архитектуру значитель
но сложнее и потенциально разрушительнее, чем реконструировать компоненты.
Этот фактор риска в процессе проектирования следует постоянно иметь в виду.
Ïåðåðàáîòàòü àðõèòåêòóðó çíà÷èòåëüíî ñëîæíåå è ïîòåíöèàëüíî ðàçðóøèòåëüíåå,
÷åì ðåêîíñòðóèðîâàòü êîìïîíåíòû.
Держу пари, что вы сомневаетесь: нужно ли вам все это знать? Полагаю, что
если вы действительно хотите стать эффективным техническим лидером, это зна
ние необходимо. Если вы пользуетесь языком программирования четвертого по
коления (4GL, например, Visual Basic), а не, скажем, C++, то больше внимания
следует уделять разработке архитектуры системы. Даже при условии примене
ния C++ создать плохую архитектуру не представляет труда — что уж говорить
о языках четвертого поколения! Да, действительно, они позволяют оперативно
выстроить механизм взаимодействия пользователя с системой, но это, как вы по
нимаете, лишь ее оболочка. Термин быстрая разработка приложений (Rapid Ap
plication Development, RAD), возникнув на заре создания программных продук
тов под Windows, первоначально отражал высокие темпы выхода продуктов на
рынок, достигавшиеся средствами языков четвертого поколения. В сегодняшних
условиях «быстрая» разработка в большинстве случаев приводит к появлению
некачественных программных продуктов. Мне даже кажется, что аббревиатуру
RAD сегодня более уместно расшифровывать как «разработка мерзких приложе
ний» (Rotten Application Development). Первоочередное внимание следует уде
лять, говоря анатомическим языком, скелету, нервной системе и внутренним орга
нам. В противном случае вы рискуете извергнуть очередную халтуру.
Некоторые компании настолько увлекаются скоростью разработки, что рано
или поздно им придется столкнуться с долгосрочными последствиями непроду
манности архитектуры. Кто знает, быть может, вы работаете в одной из таких ком
паний, трудитесь себе над продуктом, находящимся в конце цикла разработки,
и регулярно выслушиваете от сотрудников группы поддержки отчеты о найден
ных ошибках. Стремление ввести в продукт новые характеристики естественным
образом ограничивается необходимостью вернуться к исправлению найденных
ошибок, которые, вполне возможно, возникли именно из за того, что в процессе
разработки был взят слишком высокий темп. Если бы у вас нашлось время пораз
мыслить над этой проблемой, вы, скорее всего, пришли бы к выводу о том, что
быстрая работа существенно увеличивает риск в ближайшее же время столкнуться
с неприятностями, обусловленными непродуманностью архитектуры. Процесс кон
струирования программных продуктов, если обратиться на этот раз к спортивной
132 Ãëàâà 6 • Ôèëîñîôèÿ è ìåòîäû òåõíè÷åñêîãî ëèäåðà
терминологии, можно сравнить с марафоном, но уж никак не со спринтом. Темп,
предусматривающий долговечность конечного результата, есть необходимое ус
ловие достижения качества в производстве.
Ïðîöåññ êîíñòðóèðîâàíèÿ ïðîãðàììíûõ ïðîäóêòîâ ìîæíî ñðàâíèòü ñ ìàðàôîíîì, íî
óæ íèêàê íå ñî ñïðèíòîì. Òåìï, ïðåäóñìàòðèâàþùèé äîëãîâå÷íîñòü êîíå÷íîãî
ðåçóëüòàòà, åñòü íåîáõîäèìîå óñëîâèå äîñòèæåíèÿ êà÷åñòâà â ïðîèçâîäñòâå.
Как же, отказавшись от синтетического подхода в пользу органического и от
быстрой разработки с неудовлетворительным результатом, создать стройную ар
хитектуру? Мыслить органично вам поможет свежий взгляд на принципы проек
тирования и очередность этапов фазы разработки.
Ñâåæèé âçãëÿä íà ïðîåêòèðîâàíèå
Как отличить проектное решение от архитектуры? Представьте себя божком, со
бирающимся сотворить живое и разумное существо, обладающее, к тому же, спо
собностью к адаптации. Надеюсь, для вас это не проблема (кстати, если так, при
дется вам внимательно ознакомиться со следующей главой, посвященной темной
стороне лидерства). Как бы там ни было, трудно сотворить часть тела, не пони
мая, в каком окружении она будет существовать. К примеру, если бы легкие висе
ли на левой руке, вряд ли они смогли бы исполнять свою основную функцию, —
значит, лучше разместить их в груди. Полагаю, вы понимаете, к чему я клоню.
При создании проектного решения предполагается наличие архитектуры, кото
рая диктует расположение всех реализующих системные функции компонентов.
Таким образом, проектное решение становится «плотью»1 архитектуры; кроме
того, на этом этапе разработки производится выбор технологии реализации.
О чем вы говорите? Я предпочитаю VB и собираюсь писать на нем все про
граммы2. Вы так считаете? Подумайте еще раз. Задачи, которые вам предстоит
решать, — не гвозди; их нельзя вбивать одним молотком. Да, я опять обращаюсь
к метафоре строительства, но, по моему, в этом контексте она как нельзя более
кстати. Не забывайте, впрочем, что метафоры и аналогии выполняют исключи
тельно иллюстративную функцию — они как луч света в темной комнате, освеща
ющий очертания меблировки. Иначе говоря, иллюстрация и реальный объект не
идентичны; между иллюстрацией и проблемной областью нет точного соответ
ствия. Аналогичным образом проектные решения можно принимать только при
наличии утвержденной архитектуры.
В последующих разделах мы поговорим о том, как довести грамотно выращен
ный продукт до стадии сбора урожая. Вопрос заключается в следующем: являет
ся ли этот процесс многоступенчатым?
1
2
Ах, какой я молодец, что подобрал анатомическую метафору!
Лично я пользуюсь VB, начиная с версии 1.0, поэтому никаких предрассудков против этого языка не
питаю. Всем интересующимся проблемами создания архитектуры и проектирования средствами VB ре
комендую ознакомиться с работой Billy S. Hollis, Visual Basic 6 Design, Specification and Objects (Upper
Saddle River, NJ: Prentice Hall, 1999).
Ïðèìàò àðõèòåêòóðû 133
Íóëåâîé ýòàï ïðîåêòèðîâàíèÿ
Итак, имея на руках грандиозную архитектуру, вы готовы приступить к проекти
рованию компонентов. Прекрасно. Мобилизуйте все свои объектно ориентиро
ванные навыки. В первую очередь вам предстоит проверить архитектуру, имея
в виду подчеркнуть приоритет этого этапа (я называю его «нулевым») в контек
сте процесса проектирования. Другими словами, вы должны провести макетиро
вание архитектуры, но не совсем так, как это делается обычно. Вместо обширного
графического пользовательского интерфейса сконструируйте ряд низкоуровне
вых компонентов, снабдите их интерфейсами заглушками и возвращаемыми зна
чениями — это позволит убедиться в работоспособности системы в вертикальной
проекции. Конструируемые на этом этапе графические пользовательские интер
фейсы должны лишь подавать сигналы и запускать те или иные процессы — боль
ше от них ничего не требуется. Ведь ни один человек не выживет, если его мозг не
будет взаимодействовать с сердцем, так? Именно поэтому, кстати, косметические
операции проводятся исключительно по желанию пациента, а вот при проведе
нии операции на головном мозге его согласия не требуют. Я полностью убежден —
проверять архитектуру необходимо. На это, скорее всего, уйдет больше времени,
чем можно было бы ожидать, но не сомневайтесь — усилия стоят того. С соблаз
ном сразу перейти к разработке реальных компонентов системы нужно бороть
ся — будет очень неприятно, если, подключив все компоненты, вы обнаружите,
что они не стыкуются или не работают.
Ïåðâîå, ÷òî íóæíî ñäåëàòü â ïðîöåññå ïðîåêòèðîâàíèÿ, — ýòî ïðîâåðèòü àðõèòåêòóðó.
Подробности процесса «проверки концепции» я, пожалуй, опущу — благо ли
тературы, посвященной архитектуре и проектированию, предостаточно. Только
вот не стоит перекладывать обязанности по проверке архитектуры на кого то дру
гого — и не дай вам Боже отложить этот процесс до бета тестирования. Эта обя
занность ложится на вас и ваших подчиненных, а основная идея, которую я стрем
люсь до вас донести, ясна и понятна — нельзя уклоняться от выполнения своих
обязанностей. Ваша первоочередная задача в процессе проектирования заключа
ется как раз в том, чтобы проверить архитектуру на предмет ее применимости —
вот почему речь идет о «нулевом», то есть о приоритетном, этапе. Если на все
нижеследующие вопросы вам удастся ответить положительно, значит, вы навер&
няка на правильном пути.
Предполагает ли архитектура возможность идентификации подсистем функций
и предотвращает ли она их взаимозависимость с другими подсистемами? Уда
лось ли вам сконструировать объекты, способные функционировать сравни
тельно независимо при помощи ограниченного числа вспомогательных объек
тов?
Насколько доходчиво «перспективное представление» системы — сможет ли,
скажем, продавец, прослушав краткий инструктаж, объяснить потенциальным
134 Ãëàâà 6 • Ôèëîñîôèÿ è ìåòîäû òåõíè÷åñêîãî ëèäåðà
клиентам, как работает программный продукт, который они намереваются при
обрести?
Исключается ли жесткое кодирование параметров конфигурации системы?
К примеру, потребуется ли повторная компиляция программы при переиме
новании сервера или домена, или редактирования конфигурационного файла
будет достаточно?
Обратите внимание на слово «наверняка», выделенное курсивом в последнем
предложении абзаца, предшествующего списку. Почему я употребил именно это
слово? Дело в том, что вы должны учитывать все факторы воздействия на систему
на 1–2 года вперед. Невозможно выстроить надежный план действий, не зная ком
мерческой конъюнктуры. С другой стороны, разбираясь в тонкостях бизнеса, вы
имеете все шансы стать предсказателем будущего своих программных продуктов.
Почему я говорю «предсказатель», а не, скажем, «прогнозист»? Объясняется
это следующим образом. Термин «предсказатель» (prognosticator) образуется из
двух греческих корней: pro, что в переводе означает «до», и gnosis, то есть «зна
ние». Нельзя точно знать, что произойдет в будущем, однако, как и специалисты,
составляющие прогнозы погоды, чем больше мы практикуемся по части предска
заний, тем лучшие результаты получаем. Не стоит также забывать, что создание
программных продуктов — это искусство, которое постепенно приобретает очер
тания науки. Любая наука начинается с исследования явлений (феноменологии).
В контексте разработки программных средств эта деятельность сводится к доку
ментированию всех явлений, наблюдаемых в ходе процесса, и построению этало
нов. По мере исполнения этой миссии начинают выкристаллизовываться законо
мерности, согласно которым у нас что то получается или, наоборот, не получается.
В конце концов нам удается сформулировать принципы кодирования. Когда кому
нибудь это удается, он присваивает новому принципу свое имя, публикует книгу
и наслаждается признанием. Именно этим в последнее десятилетие занимались
разработчики концепции позитивных (pattern) и негативных (antipattern) этало
нов, в связи с чем ваши шансы на славу теперь минимальны.
На самом деле, если вам удастся найти в цепочке производства прибыльных
программных продуктов слабое звено, быть может, вы и не получите междуна
родного признания, но рост престижа среди сотрудников собственной компании
вам обеспечен. Не исключено также, что ваша компания не испытывает подоб
ных проблем. Что ж, тем больше перед вами открывается возможностей. Впро
чем, большинство представителей нашей профессии еще только на пути к про
граммной нирване и поэтому без посторонней помощи обойтись не могут. И у вас
как у технического лидера есть все возможности помогать окружающим.
Ýòàïû ïðîåêòèðîâàíèÿ 1, 2, 3, 2, 1, 4…
Итак, вы готовы запустить маховик проектирования. Теперь дела должны пойти
в гору. То есть, я имею в виду, с горы. Да, я полон противоречий. Но ведь и про
цесс проектирования, как и жизнь, похож на американские горки. Попытайтесь
получить удовольствие от поездки, смакуйте азарт и не забудьте вернуться живым.
Мне кажется, процесс проектирования в его лучшем понимании правомерно срав
нить с катанием на винтообразной (в противоположность круговой) трассе. В ней
есть начало и конец, но в то же время вашему взору регулярно открываются одни
и те же виды. А теперь сравните это удовольствие с падением с водопада, когда
Ïðèìàò àðõèòåêòóðû 135
вас несет вниз по реке, потом вы оказываетесь в свободном полете и, наконец,
шлепаетесь пятой точкой об воду, рассчитывая при этом остаться в живых. Такое
впечатление, что вы работаете в парке аттракционов, не так ли?
Нет, тут я неправ; слово «развлечение» (amusement), опять же, образуется из
двух греческих составляющих: а, что означает «нет», и muse в значении «думать».
Я, равно как и ваш начальник, все таки надеюсь, что в процессе проектирования
вы думаете. В данный момент я пытаюсь доходчиво объяснить различия между
устаревшим водопадным циклом разработки и разрекламированным в последнее
время итеративным циклом. Я убежденный сторонник последнего — несмотря
даже на то, что иногда он кажется бесконечным. Как бы там ни было, если вы
стремитесь к эффективному проектированию, необходимо неизменно придержи
ваться архитектурного плана. Существует множество книг, проводится множе
ство семинаров, на которых нас учат «правильным» методам проектирования. Не
которые из них действительно очень полезны. Лучшим же методом проектиро
вания мне представляется тот, которым вы и ваши подчиненные уже привыкли
пользоваться, и заключается он в решении корпоративных задач. Если вы еще не
достигли в этом отношении больших успехов, не стоит себя корить. Наша работа
не обходится без трудностей. Некоторые из нас совершенствуются, иные же через
пару лет просто исчезают из поля зрения. Это жестокий мир, так что крепитесь
и стремитесь к совершенствованию своих методов.
В предыдущем абзаце я обратился к метафоре из Дарвина по поводу того, что
выживает сильнейший. Родившийся в ХIX веке, этот замечательный принцип
и поныне применяется при оценке корпоративной культуры и деятельности со
трудников предприятий. Во многих случаях он вполне адекватен; не будем, впро
чем, забывать о других концепциях из области эволюционной биологии, в част
ности об адаптации. В настоящее время зарождается новый подход к адаптации.
Предлагают его те исследователи, которые занимаются вопросами поведения
сложных систем и принципами самоорганизации в таких системах. Стюарт Ка
уфман (Stuart Kauffman), один из ведущих специалистов в этой области, утверж
дает, что «…как биологическая, так и технологическая эволюция представляет
собой процессы, направленный на оптимизацию систем с конфликтующими огра
ничениями»1. Для более осмысленного освещения вопросов выживания организ
мов и их существования в хаосе сложных систем Кауфман предлагает выражение
«поступление сильнейших». Вооружившись его видением проблемы, исследова
тели привязали его выводы к процессы разработки программных продуктов.
Прекрасный образец применения теории сложных систем в области разработ
ки программного обеспечения являет собой книга Джеймса Хайсмита ( James
Highsmith) под названием «Адаптивная разработка программных средств». Хай
смит предлагает вниманию читателя итеративный цикл, который он называет
«жизненным циклом адаптивной разработки». В нем три основных компонента:
сотрудничество, размышление и обучение. С его точки зрения, у этого цикла есть
ряд преимуществ2:
реагируя на периодические отзывы, приложения эволюционируют, прибли
жаясь тем самым к предъявляемым заказчиками требованиям;
1
2
Stuart Kauffman, At Home in the Universe (New York: Oxford University Press, 1995), p. 179.
James A. Highsmith III, Adaptive Software Development (New York: Dorset House Publishing, 2000), p. 40.
136 Ãëàâà 6 • Ôèëîñîôèÿ è ìåòîäû òåõíè÷åñêîãî ëèäåðà
упрощается адаптация к изменяющимся бизнес требованиям;
процесс разработки подгоняется под заданный для данного продукта профиль
качества;
преимущества от применения продукта заказчик получает раньше, чем обыч
но, — хотя бы за счет того, что приложение поставляется ему быстрее, а значит,
он раньше начинает получать доход;
заказчики раньше, чем обычно, начинают испытывать доверие к проекту.
Какое отношение все это имеет к проектированию? В любом случае в вашей
компании применяется какой то метод проектирования — он либо адекватен, либо
требует усовершенствования, либо не годится для решения поставленных задач.
Возможно, требуется его немедленная замена. Решение за вами. Я считаю, вы дол
жны проявить инициативу, проанализировать применяемые в компании методы
проектирования и подогнать их под заведомо работоспособные образцы.
Теперь пора спуститься с теоретических высот (а теория эта весьма достойна)
и обратиться в следующем разделе к практическим методам разработки программ
ных продуктов, которые,по моему опыту, дают хороший результат. Мне кажется,
что они носят довольно общий характер и, следовательно, могут применяться лю
бой группой разработчиков вне зависимости от используемого ими языка про
граммирования.
Ïðèíöèïû ïðîåêòèðîâàíèÿ
Коль скоро мы придерживаемся принципа органической архитектуры, нам нуж
ны органические компоненты. Как появляется программный объект? Естествен
но, в результате написания кода — как это ни прискорбно, если мы нашепчем ком
пьютеру через микрофон идею объекта, он не появится. Собственно говоря, в такой
идее нет ничего плохого — в особенности если в ней заключены принципы коди
рования, подобные следующим.
Следование стандартам программирования, принятым для данного языка1. Это
обеспечивает единообразие методик конструирования объектов, применяе
мых разными программистами. (В этом контексте имеет полное право на су
ществование метафора строительства.)
Поощрение связности объектов. Не следует воспринимать объекты как кон
тейнеры для размещения совокупности процедур — скорее это органы, вы
полняющие конкретную функцию. Как известно, сердце не пытается дышать,
а легкие не качают кровь.
Ограничение взаимозависимости объектов. В отсутствие серьезных аргумен
тов в пользу иной точки зрения взаимозависимость приносит одни неприят
ности, превращая сопровождение в сплошной кошмар2. Чтобы однажды сде
1
2
«Стандарты программирования» — выражение многозначное. Диапазон его значений простирается от
инструкции по написанию качественной процедуры до утверждения единственной точки выхода из под
программы. Список этот можно продолжать бесконечно. Объединяющий принцип прост — заведите
стандарт и придерживайтесь его.
Что такое кошмар для программиста? Это когда он вынужден не спать всю ночь, исправляя код,
в котором, внеся одно исправление в одном объекте, получает изменение в трех местах другого объекта.
Ïðèìàò àðõèòåêòóðû 137
ланные взаимозависимыми объекты превратить в независимые, требуются
дополнительные временные и финансовые ресурсы.
Со временем, по мере того как вы будете нарабатывать опыт руководства про
ектами, приведенный список можно будет расширить. Наилучшие методики дея
тельности в области разработки программных средств обнаруживаются и утвер
ждаются постепенно. Не сомневаюсь в том, что у вас есть несколько любимых
авторов, чьи труды по мере обучения серьезно помогли. Если так, не изменяйте
им. На тот случай, если в вашей личной библиотеке не хватает полезных книг,
я составил библиографический список. Ведь учиться у предшественников и со
временников совершенно необходимо. Сегодня в качестве руководства вы выбра
ли мою книгу. Я стремлюсь к тому, чтобы поведать вам суть различных принци
пов разработки и объяснить причины, по которым вы как технический лидер
должны пропагандировать эти принципы среди своих подчиненных.
Ïðèíöèïû óñïåõà
Даже самая шикарная библиотека не гарантирует успешной деятельности в роли
технического лидера. Ее наличие — это лишь одно из многочисленных условий
достижения профессиональных высот. Ничто не мешает вам выстроить на пол
ках увесистые тома, пытаясь тем самым впечатлить себя и окружающих. Но от
этого вы не станете лучше как технический руководитель. Обширная библиотека
должна быть в ваших мозгах — лишь при таком условии вы сможете взвешенно
организовать процесс проектирования. Взвешенность приходит с опытом, явля
ясь следствием осмысления ошибок. Вот почему каждый раз, когда я совершал
какую нибудь ошибку, мой отец говорил «мотай на ус». Конечно, некоторые ошиб
ки не проходили бесследно, однако понимание того, что это в порядке вещей, меня
несколько успокаивало.
Îáøèðíàÿ áèáëèîòåêà äîëæíà áûòü â âàøèõ ìîçãàõ — ëèøü ïðè òàêîì óñëîâèè âû
ñìîæåòå âçâåøåííî îðãàíèçîâàòü ïðîöåññ ïðîåêòèðîâàíèÿ.
А вы боитесь совершать ошибки? Не стоит питать иллюзий — ошибок в суж
дениях в процессе руководства подчиненными вам не избежать. Ошибки допус
каются регулярно, и иногда за них приходится отвечать по полной программе —
в особенности когда вы не успеваете к контрольным срокам. Впрочем, с опытом
вы усовершенствуете свои навыки, и, будем надеяться, проблемы с соблюдением
сроков отпадут — ох, как же вас тогда зауважают сотрудники других отделов! На
входе в офис вас будут встречать восторженные поклонники и петь вам гимны.
Ну, может быть, я немножко преувеличиваю, но в одном нисколько не сомнева
юсь — если вам удастся повысить продуктивность сотрудников своей рабочей
группы, ваши уверенность в себе и преданность работе обязательно поднимутся
до заоблачных высот. Одержимость работой — вещь заразная, и вы должны всеми
силами стараться распространить ее на всех своих коллег.
Теперь вернемся к конкретике: есть ли у меня какое то универсальное реше
ние? Есть, и я о нем уже говорил: сосредоточьтесь и лидируйте. О том, как сосре
доточиться, мы рассуждаем в этой главе. Что же касается лидерства — думайте
138 Ãëàâà 6 • Ôèëîñîôèÿ è ìåòîäû òåõíè÷åñêîãî ëèäåðà
сами. В конце концов, роль лидера в вашей компании по праву принадлежит вам —
так что играйте ее убедительно. Как говорил Шекспир, «весь мир театр, и люди
в нем актеры».
Знание — это лишь исходное условие; по мере накопления опыта вы должны
стремиться к принятию взвешенных решений, последовательно культивировать
качества лидера.
ÊÎØÀ×ÜÈ ÐÀÇÁÎÐÊÈ — ÍÅ ÑÏÈ ÇÀ ÐÓËÅÌ!
Грег слыл отъявленным неряхой. И дело не в том, как он ел, хотя и эта его черта зачас
тую становилась предметом обсуждения окружающих. Его небрежность в кодировании
полностью соответствовала его наплевательскому отношению к своей внешности. По
его понятиям, быстрое исправление кода сводилось к созданию очередной глобальной
константы, передающей информацию между объектами, с попутным загаживанием сво
его рабочего места остатками тут же поедаемого хот дога. Впрочем, мы, его коллеги, по
нимали в плане кодирования не больше его — на протяжении десятилетия доминирова
ния DOS мы привыкли пользоваться любыми подручными средствами, лишь бы заставить
программу работать. Объектно ориентированная технология среди наших приоритетов
в то время не значилась.
Мы только что приступили к работе над новой программой последовательной связи,
и наш отдел продаж требовал поставить ее как можно быстрее. В те времена такого по
нятия, как отдел тестирования, еще не существовало — штат сотрудников проекта огра
ничивался кодировщиками, пытавшимися всеми силами успеть к срокам, установлен
ным отделом продаж. Грег в нашей компании трудился уже довольно долго и, надо
сказать, весьма успешно, поэтому к постоянному давлению привык. По крайней мере,
мне так казалось. У него даже была репутация ценного сотрудника — в основном пото
му, что он единственный из нас всех умудрялся сопровождать код старых приложений,
которые уже не продавались.
В отделе все стояли на ушах. Платформа Windows 3.0 только что появилась, и наши
старания по части разработки приложений сочетались с попытками постичь идиосин
кразическую природу интерфейса прикладного программирования Windows. И, между
прочим, у нас это неплохо получалось. В нашем отделе у каждого программиста было
собственное помещение, и в этих помещениях даже были двери, которые, как это ни
странно, закрывались. Это и погубило Грега.
Однажды, показывая заказчикам условия, в которых мы работали, директор с вице
президентом появились в отделе разработки. Познакомившись с парой инженеров, груп
па направилась в кабинет Грега. Что же они увидели, открыв дверь? Грег мирно спал за
столом, водрузив на него ноги. Повсюду были разбросаны пластиковые пакеты из под
еды, иногда с древними остатками самой еды, да и вообще комната представляла собой
весьма унылое зрелище и вряд ли могла кому то понравиться. Меня в тот момент там не
было, поэтому я говорю с чужих слов.
А рассказали мне много интересного. Вице президент по продажам настоял на том,
чтобы уволить Грега немедленно. Директор согласился. Выбора у меня не было. Вско
рости я сообщил Грегу неутешительные новости, после чего был вынужден наблюдать
жалкую сцену мольбы о пощаде и последнем шансе. Я ему сказал, что это не в моей
власти, что мне ужасно жаль, и еще до обеда его рабочее место очистили от мусора, а его
самого выставили за дверь.
Какова мораль? Очевидно, она в том, чтобы не спать на работе. Но это еще не все.
К сожалению, некоторые программисты не выдерживают нагрузки. Мы должны работать
в высоком темпе, а с теми, кто за ним не поспевает, приходится прощаться. Это жестокая
реальность. Надеюсь, у Грега все нормально, — ведь с тех пор я его ни разу не видел.
Êîäîâàÿ ïîëèöèÿ 139
Êîäîâàÿ ïîëèöèÿ
Переместимся из XVI в XX век — как говаривал Элиотт, «Это один из вариантов
конца света/Без треска, но с воем»1. Не стоит делать программы по этому прин
ципу. Для того чтобы избежать этого, вам придется играть роль кодового полицей
ского. Если выражаться более знакомыми терминами, вам предстоит проводить
регулярные критические обзоры кода, направленные на проверку соответствия
архитектурной базе и принципам проектирования. Вспомним принцип, который
я сформулировал в главе 2, — без регулярных проверок нельзя рассчитывать на
хорошие результаты. Именно поэтому критические обзоры кода так важны.
В ходе проведения обзора вам предстоит столкнуться с двумя трудностями.
С одной стороны, против вас работает время; с другой — программисты зачастую
слишком ревностно относятся к попыткам редактирования своего кода. В конце
концов, в сутках всего 24 часа. Пытаться изменить это обстоятельство бесполез
но, поэтому единственный выход — учиться использовать время рационально.
О том, как наиболее эффективно распоряжаться своим временем, говорится в гла
ве 4, посвященной организованности.
Что касается недовольства вторжением в результаты своей деятельности, про
граммистам придется смириться. Не стоит пугаться, что программисты отреаги
руют на такое вмешательство резко негативно. Это лишь признак сопричастно
сти, а она, как известно, является необходимым условием создания качественного
программного обеспечения. Хуже, если программист относится к вашей конструк
тивной критике индифферентно — из этого можно заключить, что конечный ре
зультат его не интересует. Толстокожесть техническому лидеру не повредит. Если
вы слишком стеснительны, чтобы исправлять чужие ошибки, вы рискуете набить
немало шишек — быть может, это вас образумит.
Ñëåäèòå çà çàêîííîñòüþ
Вы вместе с вашими подчиненными должны работать так, как будто повязаны
узами контракта. В качестве основных положений контракта при этом выступают
коммерческие спецификации и ваше видение архитектуры; условия же контрак
та сводятся к принципам и методикам проектирования. Будучи программным по
лицейским, вы должны следить за корректностью разрабатываемого программ
ного продукта, начиная от зародышевого состояния и вплоть до зрелости. Впрочем,
довести программный продукт до состояния зрелости пока что не удается — при се
годняшнем технологическом уровне приложения останавливаются в своем раз
витии в подростковом состоянии. Ну, может быть, мы приближаемся к юноше
ству. Каждая компания по своему уникальна, в каждой приняты собственные
стандарты оценки зрелости продуктов2. Принципам оценки в программной ин
женерии посвящены многочисленные издания. Кейперс Джонс (Capers Jones)
в своей книге «Applied Software Measurement»3 утверждает, что наиболее успеш
1
2
3
T.S. Elliot, Collected Poems 1909 1962 (New York: Harcourt Brace Jovanovich, 1971), p. 82.
См. Humphrey, op. cit., p. 5.
Capers Jones, Applied Software Measurement (New York: McGraw Hill, 1991), p. 1.
140 Ãëàâà 6 • Ôèëîñîôèÿ è ìåòîäû òåõíè÷åñêîãî ëèäåðà
ные компании, работающие в сфере разработки программного обеспечения, от
личаются шестью общими характеристиками.
1. Они проводят точные измерения продуктивности и качества программных
продуктов.
2. Они тщательно планируют и оценивают программные продукты.
3. У них работают квалифицированные менеджеры и технические специалисты.
4. У них адекватные организационные структуры.
5. Они пользуются наиболее эффективными методами и инструментами разра
ботки программного обеспечения.
6. Их сотрудники работают в достойных условиях.
Из всех этих характеристик наиболее важной Джонс считает первую. Именно
здесь в полную силу проявляются преимущества критических обзоров кода.
Правила вам известны. Если бы вы их не знали, объяснить ваше продвижение
по ступенькам административной лестницы было бы довольно трудно. Смысл кри
тических обзоров кода состоит в донесении вашего опыта до менее бывалых под
чиненных. Критические обзоры — это вам не контрольные работы в школе, за кото
рые в дневник ставят оценки, а потом напротив них свои подписи ставят родители.
Скорее их можно сравнить с университетскими семинарами, на которых прони
цательные студенты стремятся выявить наилучшие идеи и забраковать неудач
ные. Сотрудники, демонстрирующие неспособность учиться на критике, вряд ли
смогут долго оставаться в нашей профессии. Быть может, такой подход покажет
ся вам слишком жестким, но если не вывести теоретические основы разработки
на практический уровень, будет страдать качество конечного продукта.
Íàèáîëåå ðàñïðîñòðàíåííûå íàðóøåíèÿ
В своем кратком обзоре основных принципов проектирования я акцентирую ваше
внимание на трех аспектах: стандартах, связности и взаимозависимости. Рассмот
рим соответствующие нарушения.
Íàðóøåíèå ñòàíäàðòîâ
Везде ли проставлены комментарии? Сможет ли с их помощью новичок, не зна
комый со структурой данного модуля, в нем разобраться? Предположим, вы пы
таетесь проследить последовательность исправления ошибки, — можно ли это сде
лать по комментариям? Комментарии должны разъяснять, почему код написан
именно так и никак иначе, и как этого удалось достичь — причем основной упор
следует делать на раскрытии вопроса «почему?». О том как разработчик достиг
поставленной задачи, свидетельствует сам код; в то же время комментарии помо
гают проследить ход мыслей разработчика во время разработки модуля. Для того
чтобы продолжить чье то начинание, вы должны знать, почему ваш предшествен
ник пошел именно тем путем, которым пошел. В этом вам помогут комментарии.
Соглашение по именованию. Следуют ли ему ваши подчиненные? Возможно
ли, взглянув на имя переменной, с уверенностью судить о ее области действия?
Отлаживать код, в котором для определения области действия предположитель
но неверного параметра приходится тратить по полчаса, невероятно трудно. Бы
вает и так, что имена процедур настолько длинны, что наводят на мысль о беспо
Êîäîâàÿ ïîëèöèÿ 141
лезности или даже вредности введения длинных имен файлов в Windows. Быть
может, они, напротив, настолько коротки, что для расшифровки имен подпрограмм
приходится прибегать к словарю? Между этими крайностями нужно найти ба
ланс — кто знает, может быть, для этого вам придется провести урок грамматики
и объяснить своим подчиненным, чем глагол отличается от существительного.
Я понимаю, что префикс «get» в именах подпрограмм, извлекающих данные, утом
ляет; но его наличие безусловно свидетельствует о том, что они что то извлекают.
То же самое можно сказать о префиксе «set». Простота во многих случаях — си
ноним практичности.
Êîììåíòàðèè äîëæíû ðàçúÿñíÿòü, ïî÷åìó êîä íàïèñàí èìåííî òàê è íèêàê èíà÷å,
è êàê ýòîãî óäàëîñü äîñòè÷ü — ïðè÷åì îñíîâíîé óïîð ñëåäóåò äåëàòü íà ðàñêðûòèè
âîïðîñà «ïî÷åìó?». Î òîì êàê ðàçðàáîò÷èê äîñòèã ïîñòàâëåííîé çàäà÷è, ñâèäåòåëüñòâóåò
ñàì êîä; â òî æå âðåìÿ êîììåíòàðèè ïîìîãàþò ïðîñëåäèòü õîä ìûñëåé ðàçðàáîò÷èêà
âî âðåìÿ ðàçðàáîòêè ìîäóëÿ.
Соглашение по именованию и комментарии к коду предоставляют нам воз
можность употреблять в процессе написания кода единый язык. Не позволяйте
своим подчиненным прибегать к «технологии безмолвия». Заставьте их должным
образом расставлять комментарии и присваивать имена. Далеко не всегда разра
ботчики отказываются от комментариев из за спешки — иногда они сами плохо
понимают, что сделали (например, скопировав готовый код из библиотеки и по
надеявшись на авось). Бывает, они копируют комментарии, сделанные автором
библиотеки, к которой они обращаются. Это много о чем говорит. Конечно, в ос
новном про комментарии забывают из за неуверенности в результате или из за
элементарной лени. Несколькими пометками в коде ситуацию не исправить. Та
кие явления зачастую означают значительно более серьезную проблему, с кото
рой столкнулся кодировщик и решать которую нужно на более высоком админи
стративном уровне.
Среди прочих распространенных нарушений стандартов — применение под
программ с несколькими точками выхода, а также введение ненавистного опера
тора GoTo. (Программистам VB эту привычку можно простить — благо в .NET
операторы Try, Catch и Finally включены в библиотеку.) Еще один распространен
ный недочет — регулярное отсутствие обработки ошибок. Некоторые убежден
ные в своей непогрешимости кодировщики считают обработку ошибок пустой
тратой времени. Действительно, в некоторых случаях перехватить ошибку ввер
ху цепочки вызовов вполне достаточно; в то же время неумение выявлять потен
циальные источники ошибок свидетельствует об отсутствии у кодировщика на
выков стратегического мышления.
Возвращаясь к перечню отличительных черт различных пород программис
тов, приведенному в главе 1, замечу, что с его помощью удобно выявлять и другие
нарушения, допускаемые вашими подчиненными. Этот список можно продолжать
бесконечно в зависимости от конкретного кадрового обеспечения1. Я лишь хочу
1
Специалистам по VB я рекомендую труд James D. Foxall, Practical Standards for Microsoft Visual Basic
(Redmond, WA: Microsoft Press, 2000). Что касается других языков, выбор литературы обширен; взять
хотя бы классическое издание по C — Steve Maguire, Writing Solid Code (Redmond, WA: Microsoft
Press, 1993). Дополнительную литературу см. в библиографии.
142 Ãëàâà 6 • Ôèëîñîôèÿ è ìåòîäû òåõíè÷åñêîãî ëèäåðà
заметить, что, исполняя роль кодового полицейского, вы обязаны фиксировать
имена тех, кто нарушает правила.
Ñëàáàÿ ñâÿçíîñòü è ñèëüíàÿ âçàèìîçàâèñèìîñòü
Слабая связность и сильная взаимозависимость — две области нарушений, кото
рые допустимо рассматривать совместно, поскольку наличие одного предполага
ет наличие другого. Имеет ли в процедурах место обширное ветвление? Сильную
взаимозависимость между процедурами обычно называют ветвлением по входу
выходу. При высокой степени ветвления по выходу функционирование процеду
ры предполагает обращение к множеству других процедур, что, естественно, не
желательно. Ветвление по входу, напротив, оказывает положительное воздействие,
так как свидетельствует о строгой инкапсуляции. Общую оценку серьезности на
рушений по части связности и взаимозависимости можно дать исходя из степени
несоответствия основным объектно ориентированным принципам.
Есть ли возможность по результатам анализа кода составить диаграмму бло
ков, демонстрирующую иерархии объектов? Выглядят ли отношения на такой ди
аграмме логичными, или же стрелки, напротив, расставлены бессвязно? Можно
ли определить родословную объектов? При проведении критического обзора кода
без таких вопросов не обойтись. Ваша задача — выявить слабые места и добиться
их усиления. Не пытайтесь, впрочем, править код самостоятельно — ведь когда
сроки поджимают, появляется искушение сделать все самому. Не забывайте, что,
доверив исправление проблем сотрудникам группы, вы добьетесь гораздо более
серьезного результата. Этот процесс, конечно, может затянуться, но вы ведь по
нимаете: если нет времени решить задачу сразу и правильно, то времени на то,
чтобы переделать результат, тем более не останется.
Ñêîðûé ñóä è íåîòâðàòèìîñòü íàêàçàíèÿ
Заметив нарушения, вы должны приостановить процесс кодирования, пока нару
шители не исправят ситуацию. Чем дольше нарушения будут игнорироваться, тем
выше вероятность того, что код придется отправить прямиком на помойку1. Ког
да разработчики обнаруживают халтуру своих коллег, они невольно опускаются
до того же уровня — это человеческая природа, ничего не поделаешь. Если владе
ние оружием предполагает употребление обоих рук, то грамотное проведение кри
тических обзоров кода требует пресечения деятельности нарушителей за счет ав
торитета руководителя.
Писать и читать материалы о критических обзорах кода не составляет труда;
на практике же все оказывается значительно сложнее. Всем нам известны факто
ры, влияющие на качество кода и превращающие процесс сопровождения в хро
ническую головную боль. Новички в деле руководства и лидерства нередко ис
пытывают сложности, пытаясь перенести теоретические представления о своих
действиях в практическую плоскость. Сопротивление происходит от неуверен
ности в своих лидерских качествах, и технические навыки, какими бы впечатля
ющими они ни были, в данном случае отходят на второй план. Одно дело обсуж
1
См. Hunt and Thomas, op. cit. — авторы обозначают хаотичность в разработке программных продуктов
изысканной метафорой: «не надо жить с разбитыми окнами». Я более чем уверен, что эта книга обя
зательно должна занять достойное место в вашей библиотеке, — уж очень она хороша.
Ôèëîñîôèÿ â äåéñòâèè 143
дать проблемы кодирования в компании приятелей, и совсем другое — решать их
с позиции руководителя. Если все сотрудники осознают слабости кода, они ожи
дают проявления вашей инициативы. Попытайтесь предвидеть трудности и вну
шить себе необходимость адекватного реагирования на них. О том, что нужно де
лать при выявлении проблем, я рассказал предостаточно. Имейте в виду, что
прочтения этих строк совершенно недостаточно для превращения нужно в сде&
лаю. Чтобы это случилось, что то должно измениться в вашем характере. Именно
об этом я и намерен поговорить в оставшихся разделах главы.
Ôèëîñîôèÿ â äåéñòâèè
Философия без практики бесполезна. Видение и действие должны сочетаться гар
монично, как рука и перчатка. Иначе говоря, действуйте по своим убеждениям.
Многие люди, не исключая программистов и руководителей, знают, как нужно
делать, но тем не менее не делают этого. Существует ли верный метод экстрапо
ляции теоретических знаний на практику, способный предотвратить разрушитель
ные последствия бездействия? Никакого секрета здесь нет — скорее, возможен
некий диалог, способный убедить вас слезть с койки (то есть отказаться от празд
ности) и приступить к действию. Быть может, перечисление последствий бездей
ствия, исходя из сформулированных в этой главе принципов, вам поможет.
Äåëàéòå òî, ÷òî ñ÷èòàåòå íóæíûì.
Некачественная или случайная архитектура приводит к таким последствиям:
сверхтрудное сопровождение и низкая оперативность (а следовательно, фи
нансовые потери) при введении новых свойств;
нежелание программистов заниматься сопровождением кода вследствие чрез
мерной усложненности системы и неуверенности относительно первоочеред
ных действий при исправлении ошибок и введении новых свойств;
размывание кода из за лавинообразного роста числа объектов, за счет чего при
увеличении размера исполняемых файлов сокращается производительность.
Ниже перечислены последствия неадекватного проектирования:
из за несоблюдения стандартов создается впечатление, что все объекты созда
вались разными программистами;
модификация в одном месте приводит к нарушению в нескольких других;
вследствие многократного дублирования кода для изменения любой функции
требуется найти и также изменить все ее экземпляры.
Любой из этих списков можно было бы продолжить, но, держу пари, страху
я на вас нагнал уже предостаточно. Надеюсь, вы серьезно напуганы и готовы сде
лать все, чтобы перечисленные неприятности вас миновали.
Может, это и так, но вот я, например, предпочел бы еще пораскинуть мозгами.
В конце концов, в мире полно людей с благими намерениями, которые, тем не менее,
либо действуют строго противоположным образом, либо вообще ничего не делают.
144 Ãëàâà 6 • Ôèëîñîôèÿ è ìåòîäû òåõíè÷åñêîãî ëèäåðà
Êîíêðåòíûé ïðèìåð ôèëîñîôèè â äåéñòâèè —
Ëåîíàðäî äà Âèí÷è
Я не большой поклонник школы позитивного мышления и все таки несколько
лет назад меня заинтересовала книга о Леонардо да Винчи. Ее автор вознамерил
ся научить читателя мыслить как Леонардо. Поскольку Леонардо широко извес
тен, позволю себе называть его просто по имени. Билл Гейтс истратил кучу денег
(которые он предварительно выкачал из нас за свои программы) на оригиналы
дневников Леонардо. Этим все сказано. Леонардо был невероятно умен. Если вы
всерьез заинтересуетесь его биографией (а для этого мало прочитать единствен
ную книжку из серии «помоги себе сам»), то быстро поймете, что его творческий
гений направлялся жизненной философией. Эту самую философию Майкл Гелб
(Michael Gelb) вкратце сформулировал следующим образом1.
Неизменно любознательный взгляд на жизнь и сильнейшее стремление к по
стоянному обучению.
Привычка проверять знания через опыт, настойчивость и готовность учиться
на ошибках.
Последовательное совершенствование восприятия действительности органами
чувств (в особенности, зрением) как средство обогащения жизненной практики.
Готовность к восприятию неясностей, парадоксальных явлений и неопреде
ленности.
Уравновешивание науки и искусства, логики и воображения. Мышление «всем
интеллектом».
Воспитание изящества в движениях, «двуправорукости», физического здоро
вья и поведения.
Признание и понимание взаимосвязи между всеми вещами и явлениями. Сис
темное мышление.
Думаю, из Леонардо вышел бы добротный программный архитектор. То что
он был замечательным художником и инженером, не вызывает сомнений. Прин
ципы, которым он следовал, достойны всяческого уважения — они стимулируют
творческое мышление и являют собой прекрасный пример для подражания.
Влияние Леонардо на современную ему технологию впечатляет. Трудно себе
представить, как один человек смог выдумать все те изобретения, которые он на
бросал в своих дневниках, а частично и реализовал. Очевидно, в этом ему помог
ла его жизненная философия. Что делает ее такой действенной? Уверен, что ни
одна из ее составляющих не сыграла такой роли, как сбалансированное сочетание
различных векторов его мышления.
Взять, например, его тягу к знаниям в сочетании с терпимостью к неопреде
ленности. Убежденный в том, что опыт — лучший учитель, он постоянно совер
шенствовал свои воззрения с тем, чтобы улучшить наблюдательность. Леонардо
воспитал целую плеяду последователей, уделяя значительное время оценке их
достижений. Быть может, он был первым, кто пользовался принципом системно
1
Хотите верьте, хотите нет, но я эту книгу прочел. Michael J. Gelb, How to Think Like Leonardo da Vinci
(New York: Dell Publishing, 1998), p. 9.
Ïåðñïåêòèâû 145
го мышления — а ведь это именно то, к чему мы, специалисты по проектированию
программных продуктов, неизменно стремимся. Этот принцип предполагает сле
дование установленному плану вплоть до его окончательной реализации. Он имеет
непосредственное отношение к тому, о чем я уже говорил, — к комплексной про
верке архитектуры, предваряющей ее исполнение в виде подсистем компонентов.
Из иных творений Леонардо мы обнаруживаем, что он был человеком, чрез
вычайно крепким физически. Он не позволял телу тормозить работу ума. Быть
может, это слишком личное, но подумайте: готовы ли ваши чресла к решению за
дачи, поставленной интеллектом? Если нет, придется вам поработать над физи
ческой формой, совершенствуя попутно мозговые кондиции. Вы и только вы спо
собны понять, что в вашей рабочей деятельности препятствует следованию здоро
вой философии.
Крайне рекомендую на досуге почитать Леонардо — надеюсь, это поможет вам
на практике проводить в жизнь стройную систему деятельности. Вполне возможно,
побудить вас к действию смогут биографии современных лидеров нашей индуст
рии1. Полезно также ознакомиться с историями успеха деятелей других отраслей
экономики. Удивительно, но факт: они в своей деятельности сталкиваются с теми
же проблемами, что и мы. Короче говоря, биографическая литература — это не
плохой выбор для чтения перед сном. По крайней мере, она поможет вам отдох
нуть от повседневного чтения трудов по ADO 2.1, MTS MSMQ, VB, ASP, HTML
4.0 — видимо, их авторы считают, что заумная аббревиатура на корешке завлека
ет покупателя2. Кто знает, быть может, биография Джуди Гарланд ( Judy Garland)
напомнит вам, что как программист, руководящий другими программистами, вы
не в Канзас Сити.
Ëîæêà äåãòÿ
Умирая, Леонардо понимал, что труд его жизни остался незаконченным. Это же
стокая реальность. Тем не менее я призываю вас стремиться к самосовершенство
ванию и, руководствуясь полюбившимися философскими воззрениями, каждую
неделю делать немного больше полезных дел. Между знанием и действием в на
шей рабочей действительности огромная пропасть. Это своеобразное состязание
между эпистемологией и онтологией. Факт тот, что изначально мы предрасполо
жены к бездействию; однако, в конце концов, происходит что то, что заставляет
нас воскликнуть: «Хватит с меня этих проблем в коде!» — и наконец сделать что
нибудь стоящее.
Ïåðñïåêòèâû
Давайте абстрагируемся от подробностей и оценим результаты вашей деятельно
сти в роли технического лидера — довольны ли вы теми продуктами, которые по
явились на свет при вашем участии? Ниже я делаю краткий обзор вопросов, кото
рые мы затрагивали в этой главе. Надеюсь, этот перечень поможет вам адекватно
оценить степень своей полезности в области технического лидерства.
1
2
Есть одна восхваляющая амбициозность книга, которая мне очень нравится. James Champy and Nitin
Nohria, The Arc of Ambition (New York: Perseus Books, 2000).
Кстати, это неплохой маркетинговый прием — по крайней мере, я такие книги покупаю.
146 Ãëàâà 6 • Ôèëîñîôèÿ è ìåòîäû òåõíè÷åñêîãî ëèäåðà
Удается ли вам последовательно играть роль технического лидера? Я совер
шенно не хочу сказать, что ваши идеи всегда должны быть на порядок лучше
чужих, — просто ваши обязанности иные, к ним относятся отбор наиболее удач
ных идей и их практическая реализация.
Предполагают ли варианты архитектуры ваших продуктов расширяемость
и удобство сопровождения? Ответ на этот вопрос можно получить лишь тог
да, когда первая версия продукта уже выпущена на рынок, а вы принялись за
оценку ресурсов, требующихся для производства второй версии.
Смогли ли вы за счет своих проектных решений обеспечить возможность мно
гократного использования компонентов? Может ли любой сотрудник вашей
группы взять модуль, разработанный другим сотрудником, и успешно спра
виться с его сопровождением или расширением функциональности? Ответы
на эти вопросы свидетельствуют о ваших достижениях по части организации
и руководства проектной деятельностью.
Как вы обращаетесь с выявленными недостатками кода — устраняете их сразу
на стадии разработки или ведете журнал фрагментов кода, требующих перера
ботки?
Способствует ли здоровая критика действий ваших подчиненных повышению
их квалификации?
Что вы предпочитаете — умные разговоры или практические действия? По
мните ли вы, что нереализованные философствования бесполезны?
Руководствуясь принципами самоконтроля, вы должны регулярно задаваться
этими вопросами. И не забывайте на них отвечать. Техническое лидерство взра
щивается на почве знания и питается готовностью учиться на собственных ошиб
ках — в конечном итоге такая практика обязательно увенчается успехом.
×òî äàëüøå
Проводить философские воззрения в жизнь не так уж просто. В следующей гла
ве, в которой мы поговорим об обратной стороне лидерства, у вас еще будет воз
можность поразмышлять о последствиях неверной философии лидера. Даже уди
вительно, сколько неприятностей способны доставить люди, руководствующиеся
неподходящими философскими концепциями. Однако они, по крайней мере, уяс
нили, как превращать теорию в практику. Повторюсь — оценивать свои лидер
ские качества нужно по результатам каждодневной практической деятельности,
ведомой внутренними убеждениями.
Гл а в а
7
Çàêàò ëèäåðà
Йода говорил: «Остерегайтесь темной стороны». Это
предупреждение применимо и к нашей деятельности —
у лидерства тоже есть обратная сторона. Иначе говоря,
если отказаться от лексикона научной фантастики, ли
дерство бывает неэффективным и разрушительным.
Судя по моему опыту, темными (то есть не излучающи
ми свет, за которым могли бы следовать окружающие)
личностями люди становятся благодаря стилю руко
водства, который просто не создает почву для развития
лидерских качеств. Результатом неадекватных руково
дящих действий становится закат лидерства, который может повлиять как на вас,
так и (что хуже) на вашего шефа. Подобный стиль руководства, оказывая воздей
ствие на суждения, незаметно разъедает даже самых сильных лидеров. В резуль
тате эффективность лидерства сходит «на нет» из за неадекватного стиля руко
водства.
Во всех предыдущих главах я исходил из вашей способности отказаться от дей
ствий, приводящих к неэффективному руководству, и проводить в жизнь мето
дики, обеспечивающие истинное лидерство. Впрочем, некоторые люди неспособ
ны к изменениям, и воспринимать их следует как поддержанный автомобиль —
в состоянии «как есть», без гарантии и без возврата потраченных средств. Пола
гаю, что вы не относитесь к этой категории, — в противном случае, столкнувшись
с тем, что я ставлю под сомнение обыденные представления о руководстве и ли
дерстве, вы просто забросили бы чтение. В то же время в определенной степени
упрямство и нежелание меняться присутствует во всех людях — естественно, эти
качества мешают должному исполнению нами своих обязанностей. По мнению
Йоды, адептами «темной стороны» становятся те, кто пребывает во власти страха.
Может, он и прав. Мне действительно кажется, что страх совершить ошибку —
это одно из проявлений негатива, о котором пойдет речь в этой главе. Вы должны
уяснить для себя, что страх ошибиться можно преодолеть и маскировать его не
продуктивным стилем руководства совершенно не обязательно.
148 Ãëàâà 7 • Çàêàò ëèäåðà
Îáëè÷èå òüìû
Страх порождает самые что ни на есть темные явления. Примером тому — дья
вольский период правления Гитлера. Благородная сама по себе немецкая концеп
ция «лидера» (der Furer) превратилась в кошмар западной цивилизации. Эти зло
вещие страницы истории наталкивают меня на вывод: лидерство, если оно носит
разрушительный характер, чревато страшными последствиями для окружающих.
Аналогичным образом (хотя и в несколько более скромном масштабе), если груп
па разработчиков по вине своего лидера пойдет по неверному пути, следует ждать
снижения производительности, ухудшения качества выпускаемых данной ком
панией программных продуктов и неспособности сотрудников достигать наме
ченных целей. Есть одна древнееврейская пословица (может быть, вы ее слыша
ли), которая звучит примерно так: «недальновидность правителей губит людей».
Вот что случается с теми, кто теряет нить руководства. Среди подчиненных начи
нается анархия, но ведь, как я говорил в главе 1, руководитель должен стремиться
к тому, чтобы сотрудники его рабочей группы двигались в одном направлении.
Именно поэтому я считаю лидерство основной темой этой книги. Когда лидер
поддается дурным веяниям, он перестает быть таковым.
Получив представление об извращенных стратегиях лидерства, которые я опи
сываю в этой главе, вы должны сопоставить их с собственной административной
деятельностью и попытаться найти общие черты. За этим нужно следить — пере
нимая негативные элементы таких стилей, вы снижаете свой профессиональный
уровень. Как известно, сформулированная проблема наполовину решена. Вторая
половина требует больших усилий, но, надеюсь, осознание пагубности неверной
стратегии руководства и ее отрицательного влияния на подчиненных вас моби
лизует. В таком случае вы сможете с решимостью перейти к действиям по реше
нию проблемы, то есть скорректировать свои действия в роли руководителя. По
лагаю, на это у вас хватит сил — в противном случае вы вряд ли добрались бы до
этих строк. Прислушайтесь ко мне — в конце концов, мне самому каждый день
приходится бороться с обратной стороной лидерства.
Íåãàòèâíûå ýòàëîíû â ìåíåäæìåíòå
Полагаю, знакомясь с материалом главы 1, вы изрядно позабавились по поводу
описания различных типов программистов. В этой главе я обращаюсь к аналогич
ной схеме повествования, хотя на этот раз она вряд ли доставит вам соизмеримое
удовольствие. Итак, вам предстоит ознакомиться с негативными эталонами в пси
хологии — благо о том, что они собой представляют в области проектирования,
у вас уже есть некоторое представление. Назначение негативных эталонов — по
казать, как не стоит себя вести. Если среди перечисленных черт вы обнаружите
сходство с собственной моделью поведения, попытайтесь ее скорректировать. На
чальников следует остерегаться и быть осторожным в оценках. Быть может, это
слегка упрощенный совет, но пока что он вполне достаточен. В контексте про
блем, которые обсуждаются в этой главе, мы еще успеем поговорить о преодоле
нии трудностей и корректирующих стратегиях.
Многие руководители, которым, по идее, следует стремиться к приобретению
лидерских качеств, на деле демонстрируют в своем поведении смесь стилей. Об
Íåãàòèâíûå ýòàëîíû â ìåíåäæìåíòå 149
этих стилях, которые проявляются с той или иной силой, и пойдет речь. Анализи
руя порочные стили руководства, я не утверждаю, что они олицетворяют абсо
лютное зло, я вообще стараюсь воздерживаться от моральных оценок. Значитель
но важнее другое: по тем или иным причинам отдельные руководители перени
мают отрицательные качества деструктивных стилей руководства. Они со всей
очевидностью проявляются в рабочей среде и снижают качество лидера. Знание
перечисленных ниже негативных эталонов не означает, что вы должны настав
лять на путь истинный всех, кто им следует, — ваша цель в том, чтобы выявлять
соответствующие типы людей и уметь с ними общаться. С другой стороны, вы
должны подавлять эти качества в самом себе. Вся эта книга преследует одну цель —
направить вас на путь лидерства. Поймите, других людей вам не исправить. Это
очевидное, на первый взгляд, обстоятельство очень помогает в процессе взаимо
действия с окружающими.
Ïîéìèòå, äðóãèõ ëþäåé âàì íå èñïðàâèòü. Ýòî î÷åâèäíîå, íà ïåðâûé âçãëÿä, îáñòîÿòåëüñòâî î÷åíü ïîìîãàåò â ïðîöåññå âçàèìîäåéñòâèÿ ñ îêðóæàþùèìè.
Заимствовав некоторые идеи у апологетов применения негативных эталонов1,
я решил при описании порочных стилей руководства придерживаться следую
щей структуры.
Симптомы и последствия. С точки зрения феноменологии, понять истинные
намерения людей, следующих в своем поведении негативным эталонам, не
возможно — зато их поведение вполне идентифицируемо. Если вы сами подда
лись влиянию одного из негативных эталонов, не забывайте о своем преиму
ществе, которое выражается в том, что у вас есть все средства контролировать
собственную сознательную деятельность.
Вариации. Имеется в виду, что одна и та же проблема может выражаться по
разному. Тем не менее она неизбежно ведет к ухудшению лидерских качеств.
Исключения. Обо всех исключениях я буду говорить отдельно. Существуют
ли ситуации, в которых применение стиля руководства, не способствующего
развитию лидерства, допустимо? Да, существуют, но об этом позже.
Решения. Здесь я объясню, как скорректировать неверный стиль. Эти реко
мендации, естественно, применимы только к вам самому, поскольку, как я уже
говорил, заставить измениться окружающих невозможно. В то же время пони
мание способов корректировки стиля руководства поможет вам как можно
быстрее вернуть утраченные лидерские позиции. Решения наиболее общего
характера рассматриваются в заключительной части главы; впрочем, по мере
изложения материала я иногда буду акцентировать ваше внимание на методах
корректировки, применимых в контексте конкретного стиля.
Описание каждого негативного эталона начинается с заголовка, в котором я пы
таюсь в сжатой форме изложить его суть. Все негативные эталоны я развел по от
дельным разделам — они настолько серьезны, что их надо изучать по отдельности.
1
См. Brown et al, AntiPatterns in Project Management, op. cit.
150 Ãëàâà 7 • Çàêàò ëèäåðà
Ìåëî÷íàÿ îïåêà
Отдельные признаки мелочной опеки — в высшей степени порочного стиля руко
водства — демонстрирует великое множество руководителей. Упадочным этот
стиль считается по одной простой причине — он являет собой полную противо
положность качественному руководству, которое основывается на делегировании
и проверке. Деятели, увлекающиеся мелочной опекой, сводят с ума не только ок
ружающих, но и самих себя. Признаться, все мы в определенных условиях этим
грешим. Ну вот, к примеру, классическая ситуация — цикл разработки подходит
к концу, как вдруг выясняется, что один из ваших сотрудников забыл выполнить
данное ему задание. Если времени в обрез, а вокруг никого, кому это задание можно
было бы перепоручить, вы, скорее всего, не удержитесь и возьметесь за него сами.
Скажете, это простительное исключение? Может быть, но имейте в виду — дей
ствуя подобным образом, вы приучаете своих подчиненных к тому, что за невы
полненную работу никаких взысканий не последует — вы просто сами вседоде
лаете. Хорошо ли это? Думайте сами.
Как правило, мы, технические лидеры, приучены к активной и напряженной
работе, в связи с чем нам иногда кажется, что с поставленными задачами мы спра
вимся лучше, чем те, кому мы их делегировали. В конце концов, очень часто руко
водителями становятся именно те сотрудники компании, которые проявили себя
высокопрофессиональными инженерами. Не забывайте, впрочем, что кодирова
ние не относится к числу наших первоочередных обязанностей. Руководитель при
зван обеспечить решение задачи силами своих подчиненных. Первое, что должен
сделать лидер, — это создать условия для полноценного делегирования. Тот, кто
увлекается мелочной опекой, дискредитирует себя как лидера и как руководите
ля. Я даже не допускаю мысли о том, что руководитель, чья деятельность подчи
нена стилю мелочной опеки, может быть лидером — на это у него просто нет вре
мени. Все, что он делает, — это вмешивается в действия своих подчиненных. Если
вам так нравится, называйте их «мелочными лидерами». Свидетельства их ли
дерских качеств можно разглядеть разве что под микроскопом.
Ðóêîâîäèòåëü ïðèçâàí îáåñïå÷èòü ðåøåíèå çàäà÷è ñèëàìè ñâîèõ ïîä÷èíåííûõ.
Ïåðâîå, ÷òî äîëæåí ñäåëàòü ëèäåð, — ýòî ñîçäàòü óñëîâèÿ äëÿ ïîëíîöåííîãî
äåëåãèðîâàíèÿ.
Представители этого типа руководителей встречаются в нашей отрасли чаще
всего. Их можно разделить на несколько типов.
Всезнайка. Такой деятель искренне верит в то, что ему известно все о его ра
боте, о работе компании, о конкретных заданиях программистов. Он считает
себя эрудитом — несмотря даже на то, что этот термин, как мне кажется, ис
черпал себя в веке эдак семнадцатом. Я бы не отказался быть эрудитом, да и вы,
полагаю, тоже, но в сегодняшних условиях это просто невозможно — объем
накопленных со временем технических знаний слишком велик. Некоторые
считают, что навыки веб серфинга делают их умнее и информированнее. Ник
то не оспаривает роль Интернета как одного из инструментов познания, но
ведь на дворе нынче век информации, но никак не век знаний. Ни серьезная
Ìåëî÷íàÿ îïåêà 151
технологическая подготовка, ни невероятная сноровка в разгадывании крос
свордов не дают вам права претендовать на единоличное выполнение всего
комплекса заданий.
Диктатор. Девиз этих деятелей — «я прав, потому что я прав». Диктатор пыта
ется навязывать своим подчиненным конкретные методы решения поставлен
ных перед ними задач. На самом деле всем нам не мешает тщательно следить
за тем, чтобы не пойти по этому пути. Лидерство действительно предполагает
демонстрацию сотрудникам возможных способов работы, но в этом следует
соблюдать осторожность, поскольку лишать подчиненных чувства сопричаст
ности к созданию продукта недопустимо. Диктатор создает вокруг себя атмо
сферу животного ужаса, которая не позволяет сотрудникам в полной мере про
являть свои способности, — все с трепетом ожидают очередного указания сверху
и пытаются угадать последствия малейших проявлений независимости. Даже
в политике случаев, когда диктаторство можно было бы признать уместным,
ничтожно мало — что уж говорить о бизнесе! Настоящий лидер должен созда
вать условия, в которых разработчики могли бы гордиться результатами сво
их трудов, а для того чтобы их гордость воплощалась в хороших результатах,
им следует предоставлять определенную свободу выбора средств достижения
цели. Тем не менее хороший руководитель устанавливает некоторые пределы
свободы. Диктатор же ее просто напросто подавляет.
Генерал. Руководитель этого типа хорошо усвоил уроки школы «командова
ния и управления» в разработке программных средств. Генералы обнаружива
ют значительное сходство с диктаторами, проявляя в своей деятельности еще
большую жесткость. Было время, когда военная модель в бизнесе была рас
пространена довольно широко. В военных формированиях, где все носят уни
форму, которая подтверждает принадлежность людей к огромному механиз
му, управляемому командами, эта схема имеет полное право на существование.
Кстати сказать, такой стиль руководства характерен для многих крупных про
граммных проектов, разрабатываемых в гигантских корпорациях или в прави
тельственных структурах. Именно в этой среде зародилась методика программ
ной инженерии. По моему мнению, относительно сегодняшних программистов
этот метод себя не оправдывает — между выпасом котов и командованием вой
сками наблюдается существенная разница. Программисты не носят униформу
(если, конечно, не считать таковой их дурацкие футболки) и обожают брави
ровать своей независимостью. Если вы вообразили себя генералом, а своих
подчиненных считаете солдатами, имейте в виду: битвы с противником вам
придется вести одному. Солдаты, скорее всего, будут отсиживаться где нибудь
в углу, спокойно попивая кофе. Противостоит такому подходу стиль сотруд
ничества — и, вы знаете, он имеет широкое употребление, просто потому, что
он правильный. Во время войны сотрудничество редко имеет место. В области
разработки программного обеспечения, напротив, трудно себе представить
ситуацию, в которой установлению отношений на основе сотрудничества что
либо воспрепятствовало бы.
Первопричина мелочной опеки кроется в убежденности руководителя в том,
что никто не может выполнить работу лучше него. Прибавьте к этому страх допу
стить ошибку, и вы поймете, почему так много руководителей попадаются в эту
152 Ãëàâà 7 • Çàêàò ëèäåðà
ловушку. Я не сомневаюсь, что вы хотите преуспеть в своей деятельности, но по
думайте, какую цену вы готовы за это заплатить. Какой смысл было нанимать
сотрудников, если вы намерены взять на себя все их обязанности? Если практи
ковать мелочную опеку достаточно долго, вы рано или поздно достигнете предела
продуктивности. Этот предел определяется, с одной стороны, вашей способно
стью делать работу за других, с другой — терпением ваших сотрудников, осознаю
щих невостребованность своих талантов.
В табл. 7.1 сравниваются характеристики руководителя, практикующего ме
лочную опеку, и полноценного лидера.
Òàáëèöà 7.1. Ìåëî÷íàÿ îïåêà è ëèäåðñòâî
Ðóêîâîäèòåëü, ïðàêòèêóþùèé
ìåëî÷íóþ îïåêó
Вероятно, анализируя собственный стиль руководства, вы сможете выявить
и другие черты, отличающие лидерство от мелочной опеки. Все мы время от време
ни впадаем в эту крайность. Обратите внимание на то, где в табл. 7.1 встречаются
местоимения «я», «меня», «моим». Увлекаясь мелочной опекой, мы неизбежно
замыкаемся на себе; полноценный лидер, напротив, стремится к конструктивно
му сотрудничеству с окружающими. Освободиться от оков мелочной опеки по
могает осознание ценности ваших сотрудников и пользы от взаимодействия с ни
ми. Не слишком затягивайте узду. Не забывайте, что у вас есть персонал — дайте
ему спокойно работать.
ÊÎØÀ×ÜÈ ÐÀÇÁÎÐÊÈ — ÑÀÌÎÄÓÐ
Эта история произошла в одной небольшой программно консалтинговой компании лет
десять назад. Работала фирма стабильно, принося владельцу солидный доход. Ее не
многочисленные, но преданные сотрудники были довольны объемом работы, заключав
шейся в решении проблем всего нескольких заказчиков. Но хозяину этого показалось
мало. В конце концов, это вполне объяснимое желание — увеличить масштаб деятель
ности компании и, соответственно, расширить клиентскую базу. «Либо вырастем, либо —
гори все синим пламенем» — вот принцип, которым он руководствовался. Итак, он на
чал привлекать к деятельности компании консультантов, с тем чтобы они помогли рас
ширить бизнес. Поскольку к своим сотрудникам он предъявлял довольно высокие тре
бования, подобрать нужного человека было непросто. Но наконец подходящая кандида
тура нашлась — новый консультант согласился взять на себя обязанности оперативного
управления, подчиняясь при этом воле владельца. В теории план казался безусловно
выигрышным.
Новоиспеченный менеджер с удовольствием взялся за исполнение новых обязанно
стей — он приступил к комплексному изучению деятельности компании, познакомился
с сотрудниками и проектами, которые они вели. Хозяин, строя радужные планы по рас
ширению бизнеса, принялся, в свою очередь, искать новых клиентов. Несколько меся
цев дела выглядели как нельзя лучше и позволяли надеяться на блестящий результат.
Ìåëî÷íàÿ îïåêà 153
Через некоторое время новый менеджер по развитию ввел в рабочее расписание со
трудников еженедельные совещания. Кроме того, он разработал для внутреннего пользо
вания программу, позволявшую отслеживать текущие задания программистов и конеч
ные сроки проектов. Сотрудники отнеслись к этим инициативам с пониманием и стре
мились придерживаться новых процедур. Раньше хозяин руководил процессом с помо
щью распоряжений, формировавшихся по большей части интуитивно. Теперь же, по мере
роста, появилась необходимость в введении более формализованного подхода. Есте
ственно, хозяин присутствовал на всех еженедельных совещаниях. И вот здесь начались
трудности.
Многие решения и процессы, проводившиеся новым менеджером, владелец публич
но подвергал сомнению на совещаниях, вследствие чего они нередко задним числом «за
двигались». Через несколько месяцев, когда совещания доказали полную нежизнеспо
собность, менеджер окончательно понял, что он здесь лишний. Сроки сдачи проектов
по прежнему не соблюдались, а программисты не могли понять, кто же, наконец, ими
руководит.
В период реформирования штат пополнился несколькими новыми сотрудниками.
При этом процесс подбора персонала превратился в сущий кошмар. Стоило менедже
ру найти достойного претендента, как владелец его с завидной настойчивостью забра
ковывал. Из за самодурства хозяина немногочисленные новички вскоре покинули ком
панию. Единственной областью, в которой хозяин предоставил менеджеру полную
самостоятельность, было увольнение. И на том спасибо — по крайней мере, в этих во
просах менеджер мог быть уверен в том, что его решения не будут ставиться под со
мнение.
Вскоре менеджера увлекли новые перспективы. После непродолжительных разду
мий он решил сменить работу — благо на новом месте ему была предоставлена возмож
ность полностью раскрыть свои способности.
Эта история — классический пример мелочной опеки, которой в данном случае ув
лекался владелец компании. История демонстрирует губительное воздействие на под
чиненных политики руководителя, опасающегося «ослабить вожжи». Ощущение невос
требованности и сознание невозможности в полной мере реализовывать свои навыки
и высказывать мнения побуждает людей менять работу.
Ñîâåòû òåì, êòî óâëåêàåòñÿ ìåëî÷íîé îïåêîé
Существуют ли обстоятельства, в которых мелочная опека допустима? Вероятно,
да — в ночь перед сдачей проекта при условии, что вы в силах быстро внести ис
правления. Во всех прочих случаях этот стиль ограничивает деятельность лиде
ра. Лидерство ориентировано на привитие подчиненным собственной мотивации.
В частности, лидер должен культивировать в сотрудниках чувство сопричастно
сти (как успехам, так и неудачам) и предоставлять им возможность творческих
начинаний. Мелочная опека исключает такие перспективы.
Предположим, вы поймали себя на следовании этой схеме. Как исправиться?
Во первых, попробуйте понять, откуда берется побуждение к мелочной опеке.
Быть может, ваши сотрудники действительно так бездарны, что не справляются
со своими обязанностями? Если это так, наберите новый штат. Если же к тоталь
ному контролю над действиями подчиненных вас побуждает страх не достичь
цели, придется вам провести серьезный анализ своих ожиданий. Никто не любит
ошибаться, но, тем не менее, иногда это случается со всеми. Это реальность — вос
приятие ее в таком качестве помогает сбалансировать стиль рабочей деятельности.
154 Ãëàâà 7 • Çàêàò ëèäåðà
Как скорректировать собственные ожидания, чтобы вероятность неудачи не
казалась такой обескураживающей? Полагаю, для этого вы должны приучить себя
анализировать действия, направленные на достижение успеха, не менее тщатель
но, чем собственные результаты. Люди всегда ошибаются; хороший лидер же оши
бается только тогда, когда приложенные им усилия оказываются недостаточными.
Неудачный результат простителен, а вот недостаточные усилия — это смертный
грех. Приложите все усилия к тому, чтобы настроить сотрудников на продуктив
ную деятельность, — не распространяйте на них свои опасения о возможности
неудачного исхода. Акцентируйте их внимание на сладости успеха, а не на горечи
поражения. На самом деле, напоминать людям о незавидных последствиях не
удач не стоит. Они это и так понимают. Сконцентрируйтесь на позитивной цели,
и пусть ваши подчиненные спокойно работают в этом направлении.
Íåóäà÷íûé ðåçóëüòàò ïðîñòèòåëåí, à âîò íåäîñòàòî÷íûå óñèëèÿ — ýòî ñìåðòíûé
ãðåõ.
Доверие, на первый взгляд, плохо укладывается в контекст ограниченного по
времени процесса разработки программных средств — деятельности, в которой
зачастую даже малейшая оплошность способна привести к катастрофе. Ответ на
вопрос: «Доверяете ли вы своим сотрудникам?» — неоднозначен. У вас в отделе
могут работать самые компетентные программисты, однако отношения доверия
можно построить только по прошествии длительного времени. Доверие предпо
лагает риски: риск неудачи, риск разочарования и прочие не слишком приятные
эмоции. Построить доверительные отношения, разумеется, непросто, — но, с дру
гой стороны, они устраняют основную предпосылку мелочной опеки. На это ухо
дит время, которого у вас не так много. В то же время отказ от мелочной опеки
увеличит ваши временные резервы.
Построение доверительных отношений между руководителем и подчиненны
ми проходит в двух направлениях. Проявляя надежность, поддержку и готовность
решать их проблемы, вы заставляете подчиненных доверять вам. Выстраивание
вашего доверия к ним проходит несколько этапов. Сформулируйте план мини
мум — дайте каждому небольшое, не слишком важное задание и предоставьте воз
можность справиться с ним самостоятельно. Чем большую независимость в рабо
те они будут проявлять, чем меньше им будет требоваться ваше непосредственное
наблюдение, тем сильнее вы будете им доверять и тем более востребованными
они себя почувствуют. Повторюсь — на выстраивание доверительных отношений
уходит время, но, поверьте мне, результаты того стоят.
В компании Radio Shack практикуется замечательный принцип обучения пер
сонала. Его можно сформулировать так: «делайте то, что нужно делать, даже если
никто не смотрит». Именно к этому вы должны стремиться. Ваши подчиненные
должны работать как следует просто потому, что они ответственны и мотивиро
ваны. По мере развития доверительных отношений между вами и вашей коман
дой вы приучите сотрудников к мысли, что правильные действия приводят к наи
лучшим результатам — как для них самих, так и для компании в целом. Лидер
должен постоянно стремиться к созданию такого рода условий; те же руководите
Íåîðãàíèçîâàííûå ðóêîâîäèòåëè 155
ли, которые увлекаются мелочной опекой, напротив, препятствуют их формиро
ванию.
Что делать, если признаки мелочной опеки демонстрирует ваш собственный
начальник? У вас два варианта действий: либо позволить ему взвалить на соб
ственные плечи весь груз работ, либо доказать, что вы и сами можете справиться
с задачами. Вполне может быть, что у вас так и не появится шанса проявить себя,
но такая ситуация встречается довольно редко. Если уж вас наняли для исполне
ния конкретных функций, то, по крайней мере, одну возможность показать свою
дееспособность вы получите. Если ваш начальник, отличающийся склонностью
к мелочной опеке, ставит перед вами какую то задачу, приложите все усилия к то
му, чтобы решить ее лучше, чем он ожидает. Большинство руководителей, прак
тикующих мелочную опеку, все таки обращают внимание на выдающиеся уси
лия и соответствующие результаты. Они порабощены страхом неудачи, но если
вам удастся приучить их к успеху, опасения, скорее всего, развеются. Если вы
сможете наладить с начальником доверительный диалог, дайте ему знать, что вы
постараетесь приложить к решению максимум усилий и ему совсем не обязатель
но постоянно стоять у вас за плечом. Доказывая начальнику свою компетентность
и способность работать на его благо, вы, вероятно, сможете освободиться от оков
его мелочной опеки.
Íåîðãàíèçîâàííûå ðóêîâîäèòåëè
Неорганизованный руководитель обнаруживает недостаток организационных
навыков, которые иногда, к тому же, сочетаются с нехваткой практического мыш
ления.
Таких менеджеров иной раз называют выразительно пустоголовыми, раздол
баями, без царя в голове и т. д. Неорганизованные руководители в рабочее время
думают о чем угодно, но не о работе. Иногда, впрочем, неспособность сосредото
читься объясняется недостатком опыта. Такие деятели часто кажутся забавными,
но стоит только возложить на них ответственность за что либо, как они сразу ста
раются от нее избавиться — а ведь это явление в процессе разработки программ
ных средств представляет собой серьезную опасность.
Мне доводилось наблюдать за действиями персонажей, которых можно отнес
ти к нескольким подтипам рассматриваемого стиля. В реальности их, конечно,
больше, но я описываю только те, которые приходят на ум.
Скарлетт О’Хара. Главная героиня классической киноленты 1939 года «Уне
сенные ветром», сталкиваясь с проблемой, требующей незамедлительного ре
шения, любила говорить: «Я подумаю об этом завтра». Сразу уточню: со
вершенно не считаю, что рассматриваемый негативный эталон представлен
исключительно женщинами. На самом деле мне доводилось работать только
с руководителями мужчинами, обнаруживавшими черты этого стиля, и, чест
но говоря, я не знаю в нашей области ни одной женщины менеджера, которая
грешила бы тем же. Деятели, работающие по данной схеме, либо не могут, либо
не хотят концентрироваться на текущих задачах и решениях. Иногда им ка
жется, что задачи слишком сложны; в иных случаях они не принимают ника
ких решений по той лишь причине, что боятся совершить ошибку. Как вы уже,
156 Ãëàâà 7 • Çàêàò ëèäåðà
несомненно, знаете, отказ от принятия решения зачастую равноценен санкции
на его принятие другими людьми; иногда, что еще хуже, дальнейший ход дей
ствий обусловливается последствиями непринятых решений.
Временщик. Имеется в виду человек, нацеленный в первую очередь на про
движение вверх по карьерной лестнице. Такие деятели, думающие исключи
тельно о высоком, считают занятия менеджментом среднего звена не более чем
времяпрепровождением. Большую часть своего времени они предпочитают
тратить не на работу над проектом, а на демонстрацию окружающим своих
амбиций. Сталкиваясь с необходимостью принятия решения, они обычно начи
нают активно интересоваться чужим мнением. Спору нет, лидер может ин
тересоваться позицией окружающих, но в то же время у него должно быть
собственное четкое мнение — прежде всего потому, что он совмещает анализ
текущих задач с долгосрочным планированием. Временщики крайне редко уде
ляют достаточное внимание сотрудникам и проектам. В этом состоит основное
противоречие, характерное для данного типажа. С одной стороны, эти люди
хотят преуспеть и обеспечить тем самым профессиональный рост; с другой же —
они обнаруживают неспособность к концентрации внимания, что не позволяет
им достигать первой цели. Одними лишь мечтами о блестящем будущем его
наступления не приблизишь. Лишь понимание того, что каждодневная работа
есть дело вашей жизни, помогает сделать прожекты реальностью.
Новичок. Это совсем неопытный руководитель, который вовсе не знает, с чего
начать. Такие деятели и не помышляют о лидерстве; свою цель они видят в том,
чтобы обуздать все административные тонкости своей деятельности. Некото
рые из них даже считают, что лидерство определяется не достижениями, а од
ной лишь должностью. Руководители такого типа испытывают серьезные про
блемы по части расстановки приоритетов, поскольку все задачи кажутся им
в равной степени сложными. Иногда они приходят к тому же результату, что
и двигатели самолета, пытающегося набрать высоту без достаточного ускоре
ния, — то есть просто глохнут.
Последствия деятельности неорганизованных руководителей весьма разнооб
разны — в частности, они срывают сроки сдачи проектов и вносят в души подчи
ненных полный разброд относительно конкретных задач. Многие неорганизован
ные руководители имеют обыкновение в огромных количествах генерировать
новые идеи, в связи с чем выполненный наполовину проект быстро оказывается
устаревшим. Иногда неорганизованные руководители относятся к своим обязан
ностям совершенно несерьезно. Мне доводилось сталкиваться с руководителями,
которые постоянно что то увлеченно обсуждают (как правило, это «что то» не
имеет никакого отношения к их повседневной деятельности) — и, несмотря на их
очевидное обаяние, после беседы задаешься вопросом: «К чему это все?»
Никто не спорит — хохмить можно и в рабочее время, однако если это подме
няет деятельность по организации работы сотрудников, в конце концов будет не
до шуток.
В выдающейся работе под названием «AntiPatterns in Project Management»
высказывается следующая мысль:
«…многие руководители проектов, не имеющие достаточного опыта лидерства,
полагают, что руководство — это деятельность чисто формального характера.
Íåîðãàíèçîâàííûå ðóêîâîäèòåëè 157
Причины внезапной деградации проекта крайне разнообразны. Это может быть
неадекватное управление критическим событием, неопытность или неумелость
руководителя проекта, а также проведение в жизнь высших руководящих ре
шений человеком, который, во первых, не имеет достаточного представления
о проекте, во вторых, не уполномочен принимать сколько нибудь значимых
решений. Планы и процессы разработки программных средств не могут пре
дусмотреть все возможные варианты развития событий; соответственно, в не
стандартных ситуациях от них допустимо отступать. Руководитель проекта,
равно как и другие руководители, должен демонстрировать изрядную гиб
кость — с тем, чтобы в случае выявления рисков справляться с ними практич
но и эффективно. Хаос, когда он уже начался, очень трудно остановить»1.
Принимая необдуманные решения (а взвешенность решений характерна толь
ко для опытных лидеров), неорганизованные руководители способствуют обра
зованию тупиковых ситуаций, допуская промедление, следствием которого ока
зывается хаос.
Íåîðãàíèçîâàííûå ìåíåäæåðû ÷àñòî äîïóñêàþò ïðîìåäëåíèå, ñëåäñòâèåì êîòîðîãî
îêàçûâàåòñÿ õàîñ.
Что, вы тоже неорганизованны? Отчего? Оттого ли, что вы боитесь принимать
решения, или же вы просто путаетесь в тонкостях своей работы? Обе проблемы
весьма распространены, а решаются они за счет повышенного внимания к орга
низационным аспектам своей административной деятельности. Рекомендую вам
в этом контексте еще раз обратиться к материалу предшествующих глав. В них я
разъясняю основы выстраивания стратегии лидерства. Со временем, если вы бу
дете упорно совершенствовать свои навыки, вы обязательно преуспеете.
Если вы намерены продолжить свой путь к вершинам менеджмента, имейте
в виду: для этого успех должен войти в привычку, что невозможно без должного
внимания к текущим задачам. Ни умозрительные схемы, ни прожекты не приве
дут вас к повышению. Этого результата можно достичь только за счет успешной
деятельности; при этом чем дальше вы будете совершенствоваться в исполнении
своих рабочих функций, тем более взвешенными станут ваши амбиции. Крайне
трудно найти компанию, в которой повышения происходят только лишь по жела
нию претендента.
Никаких оправданий неорганизованному стилю руководства мне в голову не
приходит. Причин, по которым формируется такая модель поведения, предоста
точно, и, поверьте мне, время от времени любые руководители теряют концентра
цию, однако настоящие лидеры умеют ее восстанавливать. Впрочем, восстановить
ся не так уж просто; иногда для этого требуется, скажем так, «перезарядить ак
кумуляторы». Разумно в такой ситуации взять отпуск или выделить выходной
день на «восстановление умственных способностей». Для того чтобы вернуть спо
собность контролировать тонкости процесса, любые средства хороши.
Что делать, если неорганизованного стиля придерживается ваш собственный
руководитель? Попробуйте обратиться к технике «мелочной опеки наоборот».
1
Brown et al, AntiPatterns in Project Management, op. cit., p. 39, 40.
158 Ãëàâà 7 • Çàêàò ëèäåðà
Предлагайте разумные решения задач. Делайте то, что считаете нужным, — в осо
бенности если задачи распределены недостаточно четко. Если ваш руководитель
дистанцируется от проблемы, у вас будет больше времени. Пользуйтесь этим вре
менем с умом. Кто знает — может быть, вас повысят. Впрочем, это не есть ваша
основная задача; главное — должным образом справиться с решением проблем,
стоящих перед вашим отделом. Если начальник не хочет работать, инициатива
переходит к его подчиненным — при условии, конечно, что им не все равно, как
идут дела в компании.
Ãåíèé íå íà ìåñòå
Довольно часто в нашей индустрии в менеджеры производят блестящих програм
мистов, неспособных к руководящей деятельности и уж, тем более, неспособных
к лидерству. Такой программист может весь день сидеть за клавиатурой и «стро
гать» прекрасный код, но в том, что касается передачи знаний окружающим, он
полный ноль. Проводя проектное совещание, гений демонстрирует чудеса на элек
тронном табло, но объяснить слушателям суть понятий, которые он на нем с та
кой легкостью иллюстрирует, у него не получается. Консенсус он понимает как
единодушное согласие со своими предложениями.
Гении бывают самые разные. Я не намерен воспроизводить характеристики
всех подтипов (слишком их много); скажу лишь, что всем гениям свойственно
одно и то же качество — исключительная способность к концентрации. Основной
акцент они обычно делают на технологии, отодвигая кадры на второй план. Имен
но это обстоятельство мешает им стать полноценными лидерами. Спору нет, ру
ководитель обязан обращать внимание на вопросы технологии, но основным при
оритетом в его деятельности должны быть люди, которые работают с технологией.
Код не возникает сам по себе. Его создание есть результат умственной работы
программистов, стимулируемых интеллектуальной тиранией руководителей.
Гении в ранге руководителей имеют обыкновение разрабатывать для приме
нения подчиненными целые программные шаблоны, которые, по их мнению, не
обходимо задействовать во всех без исключения продуктах. Зачастую такие шаб
лоны оказываются слишком сложными для применения в небольших проектах,
однако гении, несмотря ни на что, настаивают на их применении, объясняя это
необходимостью «поддерживать единую кодовую базу». Гении создают собствен
ные шаблоны даже в тех случаях, когда продукты, способные выполнять те же
функции и снабженные толковой документацией, присутствуют на рынке в боль
шом количестве. За многие годы моей профессиональной деятельности мне не
раз приходилось сталкиваться с гениями, и, надо заметить, я научился у них са
мым разным техническим приемам. Но вот по поводу менеджмента ничего путного
они мне сообщить не смогли, за исключением, пожалуй, фактических сведений
для введения данного негативного эталона, выражающего неверное приложение
исключительных умственных способностей.
Один из гениев, с которым я столкнулся на своей предыдущей должности,
умудрился разработать такой шаблон, в котором для выгрузки пользовательско
го интерфейса требовалась цепочка вызовов из пятнадцати процедур. Шаблон этот
создавался в расчете на один из предшествующих продуктов, но мой гений, тем не
Ãåíèé íå íà ìåñòå 159
менее, настаивал на том, чтобы использовать его и в весьма скромном проекте,
хотя последний, откровенно говоря, совершенно не соответствовал выбранному
решению. На изучение принципов функционирования шаблона и способов взаи
модействия с ним у меня ушло больше времени, чем на написание нового кода
и доведение продукта до стадии альфа тестирования. Надо сказать, остальные чле
ны команды испытывали те же проблемы. Мы все были поражены блестящим
интеллектом нашего руководителя и не могли устоять под прессом его методоло
гических предложений. При этом большинство наших продуктов так и не добра
лось до стадии бета тестирования, поскольку на их разработку уходило слишком
много времени и к моменту завершающего этапа коммерческая потребность в про
дуктах исчезала. Он был действительно очень умен, но как организатор челове
ческих ресурсов и процессов никуда не годился.
Такого рода менеджеры, как правило, разрушают те административные про
цессы, с помощью которых их подчиненные ранее достигали успехов. Гении рас
сматривают администрирование как работу «для других», недостойную их вни
мания. Руководители высшего уровня, как правило, считают гениев прекрасными
лидерами, объясняя свою точку зрения их выдающимися способностями. Чем
больше наблюдатель удален от повседневных процессов, тем выше он склонен
оценивать достижения гениев, не замечая их откровенных недоработок, происхо
дящих от неэффективного распоряжения человеческими ресурсами и пренебре
жения к административным процедурам.
Ãåíèè ðàññìàòðèâàþò àäìèíèñòðèðîâàíèå êàê ðàáîòó «äëÿ äðóãèõ», íåäîñòîéíóþ
èõ âíèìàíèÿ.
Что, усматриваете в этом описании свои черты? Если так, поймите, наконец,
что ваши знания не находят себе нужного применения. Постарайтесь, не отказы
ваясь от акцента на технологии, обращать больше внимания на кадры, без кото
рых никак не обойтись. Для сравнения рассмотрим табл. 7.2.
Òàáëèöà 7.2. Ãåíèé è ëèäåð
Êàê ìûñëèò ãåíèé
Ñëîæíîñòü îïðàâäûâàåòñÿ ëèøü â òîì ñëó÷àå, åñëè
âñå ó÷àñòíèêè ïðîåêòà â äîñòàòî÷íîé ìåðå ðàçáèðàþòñÿ â âîïðîñå è âíåñëè ñâîþ ëåïòó â ñîçäàíèå
ñèñòåìû
В ваших силах расширить ваши горизонты и поставить вопросы кадрового
обеспечения на центральное место в процессе решения бизнес задач. Ваши под
чиненные в любом случае обращаются к технологиям, и здесь вы сможете им
160 Ãëàâà 7 • Çàêàò ëèäåðà
серьезно помочь; не стоит в то же время забывать, что, пренебрегая человеческим
фактором, вы теряете лидерство.
Что если вам приходится работать под началом типичного гения? Судя по мо
ему опыту, единственный способ выжить в такой обстановке — повышать уро
вень своих знаний и не давать гению забыть, что окружающие его люди тоже иног
да генерируют неплохие идеи. Да, это трудно, но, в конце концов, начальник есть
начальник, тут никуда не денешься. Я не призываю вас начинать полномасштаб
ную интеллектуальную войну, но отвечать на любые замечания менеджеров по
добного рода чем нибудь в духе «Да, сэр!», поверьте мне, не стоит. Допустимый
ответ на их предложения мог бы звучать так (в уважительном тоне): «Да, хорошо,
но не думали ли вы о… [далее следует стройная аргументация]?» Не пытайтесь
препираться с гением, если по своим познаниям в предмете спора вы ему заметно
уступаете, — уважения к вам от этого очевидно не прибавится.
Помнится, мне встречались своеобразные тандемы, состоящие из гения и его
помощника по административным вопросам, которому удавалось компенсировать
управленческие недостатки шефа. Сочетание это весьма рискованное, но иногда
оно срабатывает. Действительно, интеллектуалы на лидерских позициях в нашей
индустрии нужны; при этом не менее важно, чтобы их умственные способности
не ограничивались технологическими проблемами и распространялись также на
пользователей и исполнителей.
Ñòðîèòåëè èìïåðèé òüìû
Лидеров, относящихся к типу строителей империй, можно с равным успехом на
зывать политиканами. Интриги в отношениях между сотрудниками корпораций
наблюдаются сплошь и рядом, и если дело касается создания качественных про
граммных продуктов, ни к чему хорошему они не приводят. Строители империй
руководствуются в основном одной единственной целью — подбором преданных
исполнителей их воли; при этом очень часто они забывают о необходимости пре
творять в жизнь цели компании. Поначалу они осыпают подчиненных разного
рода поблажками и подарками, но цели построения сплоченной команды перед
ними не стоит; они озабочены только одним — превращением своих сотрудников
в роботов, беспрекословно исполняющих их предписания. Руководители, не уме
ющие воспринимать несогласных, не имеют ничего общего с лидерами, — скорее
их можно охарактеризовать как коллекционеров чинов и подчиненных. Прислу
живание они ценят значительно выше, чем производительность.
Ñòðîèòåëè èìïåðèé ðóêîâîäñòâóþòñÿ â îñíîâíîì îäíîé-åäèíñòâåííîé öåëüþ —
ïîäáîðîì ïðåäàííûõ èñïîëíèòåëåé èõ âîëè; ïðè ýòîì î÷åíü ÷àñòî îíè çàáûâàþò
î íåîáõîäèìîñòè ïðåòâîðÿòü â æèçíü öåëè êîìïàíèè.
Как то мне довелось работать в компании, у которой было две группы разра
ботчиков, дислоцированные в разных городах. После нескольких успехов и пора
жений, случившихся в обеих группах, одна из них стала обнаруживать явные при
знаки доминирования в деятельности корпорации. Ее руководитель, заручившись
Ñòðîèòåëè èìïåðèé òüìû 161
поддержкой других ответственных лиц, сумел обеспечить для своих подчинен
ных наилучшие условия труда. Все они работали за 21 дюймовыми мониторами,
пользовались современными ноутбуками и новейшими моделями карманных ком
пьютеров, имели возможность посещать любые курсы. Помимо прочего, им пла
тили лучше, чем остальным. При любой попытке объединить усилия двух групп
между ними неизменно возникали разногласия, что немало расстраивало менед
жера, отвечавшего за координацию всех процессов разработки в компании. Все
эти годы на разработку любого мало мальски качественного продукта затрачива
лись неимоверные усилия — и все из за распрей между двумя группами.
Империи играют положительную роль только при определенных условиях: во
первых, если в них создаются качественные продукты, во вторых, если они не за
мыкаются на решении своих узкокорыстных задач. По моему мнению, компании
Microsoft удалось привнести в нашу индустрию чувство единения. Быть может,
относительно Microsoft (если хотите, пишите это название по другому: «Micro
$oft») у вас другие соображения, но, как мне кажется, эта корпорация пришла
к доминирующему положению на рынке продуктов для персональных компьюте
ров и сделала из своих продуктов стандарт «де факто» исключительно собственны
ми усилиями. Империи тьмы, напротив, лишь удовлетворяют личные амбиции
своих руководителей, а клиентов воспринимают как одно из средств достижения
целей; основная цель же, как правило, заключается в расширении влияния любы
ми средствами. Даже если вы категорически не согласны с моим мнением относи
тельно Microsoft, нельзя не выделить в личностях строителей империй тьмы сле
дующих качеств.
Все крутится вокруг лидера. Для него крайне важна личная власть и престиж.
Если вы — среди фаворитов лидера, права на ошибку у вас нет.
Лояльность ценится выше, чем производительность.
Вознаграждения (деньги, инструментарий и т. д.) не всегда выдаются исходя
из заслуг и часто служат средством воздействия.
Лидер мыслит в категориях «мы — они», наделяя эту дихотомию враждебным
оттенком; все, что так или иначе ставит под угрозу власть лидера, подвергает
ся яростным гонениям.
Какую империю строите вы? Она удовлетворяет потребности клиентов или
ваши собственные амбиции? Поймите меня правильно: амбиции — вещь хорошая,
и личные устремления руководителей ни в коем случае нельзя сбрасывать со сче
тов. Более того, амбиции часто стимулируют деятельность руководителя и его под
чиненных. В то же время в рамках империи следует избегать тенденции, согласно
которой группа разработчиков преследует своекорыстные интересы и пытается
наращивать свое влияние за счет стратегических интересов компании в целом.
Если вам довелось работать под началом строителя империи, средств смягчить
последствия издержек этого положения (на случай, если они себя проявят) у вас
не так уж много. Лучшее, что вы можете сделать, — работать честно. Это качество
способно уберечь вас в ситуации, когда над вами начнут сгущаться тучи. Вы
сказывая такое мнение, я, естественно, исхожу из того, что представители верхних
эшелонов руководства неусыпно следят за соблюдением интересов компании
162 Ãëàâà 7 • Çàêàò ëèäåðà
и не готовы слишком долго терпеть действия мелких «божков». В то же время
следует иметь в виду, что если строитель империи на практике демонстрирует
положительные результаты, значит, скорее всего, он устраивает высшее руковод
ство. Да, наш мир несовершенен; в истории много прецедентов длительного су
ществования империй тьмы. Если такая структура выполняет полезную функ
цию и приносит прибыль, то и в корпоративном мире она имеет право на суще
ствование.
Деятельность по строительству империй идет вразрез с курсом на выработку
консенсуса в технических вопросах. Лидер, излишне обеспокоенный своим поло
жением, вряд ли потерпит ситуацию плюрализма мнений. Как известно, консен
сус вырабатывается в результате конкуренции идей; с этой точки зрения мы мо
жем сделать вывод о том, что технологическая база империй зачастую страдает.
В процессе формирования лидерского стиля вы должны иметь это в виду. Вы ведь
хотите стать сильным лидером, не так ли? Сила предполагает способность выдер
живать стрессовые ситуации и не сдаваться под грузом обстоятельств. С давлени
ем, которое оказывает на нас быстрая смена технологий и бизнес требований,
сложно справиться без такого качества, как гибкость. Но гибкость и строитель
ство империй — вещи не слишком сочетаемые. Стараясь наращивать производи
тельность своих подчиненных (как в количественном, так и в качественном отно
шениях), не забывайте об этом.
Äåÿòåëüíîñòü ïî ñòðîèòåëüñòâó èìïåðèé èäåò âðàçðåç ñ êóðñîì íà âûðàáîòêó êîíñåíñóñà
â òåõíè÷åñêèõ âîïðîñàõ. Ëèäåð, èçëèøíå îáåñïîêîåííûé ñâîèì ïîëîæåíèåì, âðÿä
ëè ïîòåðïèò ñèòóàöèþ ïëþðàëèçìà ìíåíèé.
Çàèãðûâàíèå ñ äüÿâîëîì
Уверяю вас: если не обращать внимания на определенные признаки, свернуть
на порочный путь очень просто. Проработав над проектом шесть недель без пере
рыва и выходных, удерживая в голове все его детали, немудрено в какой то мо
мент послать всех подальше. Такая реакция вполне объяснима — ведь вы же че
ловек, а не робот, в конце концов! Тем не менее на такие вещи нужно обращать
внимание. В современных условиях сочетать рабочие обязанности со всеми ос
тальными составляющими повседневной жизни становится все сложнее. Посто
янно сталкиваясь с разного рода соблазнами, трудно им не поддаться. Не стоит
играть с огнем. Я перечислю ряд признаков, при появлении которых стоит насто
рожиться.
Âû äîñòèãëè ñâîåãî ïðåäåëà
Вы работаете все больше, но эффективность продолжает падать. Отношения с под
чиненными стремительно ухудшаются; у вас регулярно случаются приступы яро
сти, и вы все чаще прибегаете к необоснованной критике. Обзоры кода проводят
ся все реже, а недостаток концентрации не позволяет вам вырабатывать конструк
Êàê âûæèòü â ïåðèîä óïàäêà è âîññòàòü èç ïåïëà 163
тивные и полезные предложения. Ваше ощущение подавленности передается ок
ружающим, продуктивность сотрудников падает.
Пора остановиться и дать знать всем остальным участникам проекта, что вы
выжимаете из себя максимум возможного и срыва сроков сдачи не избежать. Это
сложная задача, но по достижении предела продуктивности у вас просто не оста
ется другого выхода. Попытки превзойти свои физические возможности приве
дут лишь к более плачевным последствиям.
Âû ïðûãíóëè âûøå ãîëîâû
Работа вас достала. Вы обнаруживаете неспособность разбираться в сложных во
просах с необходимой оперативностью и теряете контроль над персоналом. Вы
с неохотой ездите на работу, ищете любую возможность остаться дома, мечтаете о
том, чтобы сменить сферу деятельности. Избегая принятия решений, вы надее
тесь, что ситуация разрешится сама собой.
Посоветуйтесь с другими руководителями. Обратитесь за поддержкой к на
чальнику — в конце концов, он для этого и существует. Если возможно, сбавьте
темп работы и обсудите сложившуюся ситуацию с подчиненными — возможно,
они подскажут какие то стратегии и тактики, которые позволят вам вернуть себе
контроль над процессом разработки. Свои недочеты лучше признавать как мож
но раньше — в противном случае ближе к завершению проекта ваши ошибки все
равно станут для всех очевидными. Если вернуть себе контроль не удастся, воз
можно, пора уходить. Только вы сами можете определить, насколько вы подходи
те для выполнения лидерских функций. В таких вещах лучше признаваться само
му себе, пока за вас это решение не приняли окружающие.
Âàñ áåñèò êðèòèêà
Приступы ярости, как правило, свидетельствуют об игнорировании двух преды
дущих признаков. Ярость, по сути, — это неосознаннаяреакция на чувство бесси
лия или на неудачу. На этот признак следует обращать особое внимание: ярость
может подорвать ваш авторитет и восстановить его впоследствии будет очень
сложно. Критика, в лучшем смысле этого слова, помогает повысить производи
тельность. Раздражает она в том случае, если вы убеждены, что сделали все воз
можное.
Если вы работаете с полной самоотдачей на протяжении многих недель или
месяцев, достигать высот продуктивности становится все сложнее. Прибавьте
к этому недостаток опыта и несоответствие личностных характеристик занимае
мой должности, и вы превратитесь в бомбу замедленного действия. Собрать все
кусочки после взрыва очень трудно, так же как, например, переделать все экзем
пляры скомпилированного и распространенного исполняемого файла.
Êàê âûæèòü â ïåðèîä óïàäêà è âîññòàòü èç ïåïëà
У этой книги практическая направленность. В теории, если следовать разумным
советам (а лучшие советы, несомненно, мои), можно избежать опасностей,
164 Ãëàâà 7 • Çàêàò ëèäåðà
способных подорвать ваше лидерство. В то же время реальность сильно отлича
ется от теории. Каждый лидер может указать на огрехи в своей деятельности,
многие из которых я упомянул в этой главе. Таким образом, навыки преодоле
ния трудностей и возобновления успешной деятельности совершенно необхо
димы.
Какие отношения нарушились за время ваших трудностей? Можно ли попра
вить дело? Что делать с неудачными проектами и пропущенными сроками сдачи?
Как компенсировать ущерб? Если вам предстоит восстановить свои пошатнув
шиеся лидерские позиции, вы должны обязательно задать эти вопросы.
Начните с людей. Найдите тех, кто пострадал из за допущенных вами ошибок,
и извинитесь перед ними. Не ищите себе оправданий — признайте свою неправо
ту. Не вдавайтесь в сентиментальность или драматизм — просто дайте знать, что
вы сожалеете о том, что случилось, и двигайтесь дальше. Незаслуженно постра
давшие ждут, когда перед ними извинятся, и если вы признаете свои ошибки, вас
будут уважать за честность. Дело не том, чтобы установить теплые отношения,
а в том, чтобы восстановить фундамент лидерства. Необходимость ставить точки
над «i» в ваших отношениях с персоналом не слишком приятна, но без этого не
обойтись. Если вы ранее успели проявить лидерские качества, сотрудники вас
простят. Не обманывайте их ожидания — не извиняйтесь по электронной почте.
Если обида носит личный характер, то и извиняться надо без посредников — в кон
це концов, никто не заставляет вас документировать свои огрехи.
Ущерб, нанесенный процессам, не носит столь личный характер, но компенси
ровать его не проще, чем испорченные человеческие отношения. Если допущен
ные вами ошибки явили собой прямое нарушение правил компании, принятых
принципов работы или методологии разработки, лучше всего постараться обес
печить соответствие им. Составьте для себя план повторного изучения всех зна
чимых правил компании, имеющих отношение к вашей деятельности. Правила
имеют одну четкую функцию — они обеспечивают единообразие в работе и в дос
тижении качественных результатов. Мы, разработчики, очень ревностно относим
ся к своей независимости, в связи с чем часто легкомысленно воспринимаем пра
вила. Вы — руководитель и лидер, — демонстрируя пример несерьезного отноше
ния к правилам, можете ожидать того же от своих подчиненных.
Êàê èçáåæàòü çàêàòà
В идеале лидер вообще не должен попадать в ситуации заката. Чтобы восстано
вить лидерские позиции, вы должны придерживаться фундаментальных прин
ципов лидерства — о них, кстати, речь пойдет в следующей главе. Обзор нега
тивных аспектов деятельности руководителя, приведенный в этой главе, был
призван помочь вам разобраться в некоторых стереотипных стилях руководства,
которые за незнанием лучшего мы иногда принимаем или имитируем. Приходя
на руководящие посты из рядов программистов, мы, как правило, лишены фор
мального образования в области менеджмента и лидерства, а потому имеем обык
новение переносить все наработанные нами в качестве программистов админи
Êàê èçáåæàòü çàêàòà 165
стративные навыки на свою новую роль. Некоторые из навыков действительно
применимы к руководящей деятельности, но далеко не все.
Резюмирует все вышесказанное табл. 7.3 — надеюсь, она поможет вам избе
жать негативных аспектов лидерства.
Òàáëèöà 7.3. Ïîðî÷íûå ñòèëè ðóêîâîäñòâà
Ñòèëü
Îáåñïå÷åíèå äëÿ ñîòðóäíèêîâ âîçìîæíîñòè ïðîÿâèòü ñåáÿ
è îòêàç îò ïîëèòèêàíñòâà
Как видно из табл. 7.3, употребление порочных стилей руководства приво
дит к определенным последствиям и для самого менеджера, и для его подчинен
ных, и для продукта. Представители этих стилей не уделяют внимание вопро
сам лидерства — они либо ведут своих сотрудников в неверном направлении,
либо вообще их никуда не ведут. Знание последствий применения упомянутых
166 Ãëàâà 7 • Çàêàò ëèäåðà
стилей руководства поможет вам побороть их симптомы. Впрочем, в каждом кон
кретном случае вы должны проанализировать личные причины появления при
знаков того или иного стиля — ведь если лечение не затрагивает первопричины
болезни, уничтожить ее оно не сможет.
×òî äàëüøå
В следующей главе мы рассмотрим фундаментальные качества лидера. Получить
адекватное представление о полноценном лидерстве можно, сравнив стили, опи
санные в этой и следующей главах. Быть может, знание отрицательных аспектов
лидерства при одновременном рассмотрении его положительных качеств приве
дет вас к прозрению. Всем нам время от времени нужны источники вдохновения,
и, я надеюсь, материал следующей главы поможет вам обрести уверенность в сво
их силах и дополнительные навыки лидерства.
Гл а в а
8
Âîñõîä ëèäåðà
Учитывая, что в предыдущей главе мы рассмотрели не
гативные аспекты лидерства, полагаю, оно заслуживает
реабилитации. Знание всех проблем, с которыми время
от времени сталкиваются лидеры, заставляет усомнить
ся в том, можно ли вообще преуспеть в этом качестве, —
уверяю вас, можно. Хороший лидер — это гораздо боль
ше чем блестящий руководитель. Лидерство, хотя оно
и строится на основе различных стилей руководства,
подразумевает приложение значительных усилий, ко
торые отнюдь не ограничиваются координацией людей
и процессов. Лидеры должны быть на передовой — они призваны разрабатывать
новые пути развития компании, привлекая для этой цели надлежащие техноло
гии. Не всегда лидеру удается с первой попытки заставить окружающих двигать
ся в выбранном направлении. Мобилизовать сотрудников на решение определен
ных задач помогает харизма — одна из черт лидера, которую, по моему мнению,
практически невозможно привить. Харизматический лидер тем более должен по
нимать, в каком направлении двигаться.
Подобно программному обеспечению, лидерство выстраивается на определен
ном фундаменте. Для программных продуктов в этой роли выступает архитекту
ра, а для лидерства — ваш характер. Характер, который должен отвечать четким
требованиям. Характер, предполагающий ответственность за подготовку техни
ческих достижений компании и за их реализацию силами ее сотрудников. Под
робнее об этих фундаментальных принципах мы и будем говорить в настоящей
главе — культивируя и дополняя их, вы сможете добиться в своей деятельности
грандиозных успехов.
Ïîäîáíî ïðîãðàììíîìó îáåñïå÷åíèþ, ëèäåðñòâî âûñòðàèâàåòñÿ íà îïðåäåëåííîì
ôóíäàìåíòå. Äëÿ ïðîãðàììíûõ ïðîäóêòîâ â ýòîé ðîëè âûñòóïàåò àðõèòåêòóðà, äëÿ
ëèäåðñòâà — âàø õàðàêòåð.
168 Ãëàâà 8 • Âîñõîä ëèäåðà
Ôóíäàìåíòàëüíûå ïðèíöèïû ëèäåðñòâà
Начну с вопроса, который, по моему, ничем не хуже дилеммы курицы и яйца: кто
появился раньше — лидер или его последователи? Не знаете? То то — это вопрос
с подвохом (это я так подготавливаю вас к более глубокому анализу фундамен
тальных принципов). Я думаю так: чтобы лидера можно было назвать лидером,
ему нужны последователи; в то же время хороший лидер сам формирует для себя
группу последователей. Процесс подготовки последователей прекрасно иллюст
рируют пять основных принципов, которые, как мне кажется, определяют суть
характера любого лидера. На рис. 8.1 эти принципы приводятся в двух вариантах
группировки. Первый вариант иллюстрирует очередность применения принци
пов, второй — их цикличность.
Ðèñ. 8.1. Îñíîâíûå ïðèíöèïû ëèäåðñòâà
Каждый из принципов важен как по своей сути, так и с точки зрения взаимо
действия с остальными. Упомянутые принципы лидерства вы должны усвоить
полностью — ведь они подобны фундаменту здания, который по определению дол
жен быть его самым надежным элементом.
Ïîíèìàíèå
Прежде чем приступать к обязанностям лидера, вы должны четко уяснить, в ка
ком направлении поведете своих подчиненных. Для того чтобы забраться на вер
шину Эвереста, одной лишь карты недостаточно. Для этого нужно изучить дей
ствия тех, кому удалось это сделать до вас и кто после этого умудрился вернуться
живым. Вы должны знать условия восхождения, связанные с ним риски, препят
Ôóíäàìåíòàëüíûå ïðèíöèïû ëèäåðñòâà 169
ствия, встречающиеся на пути, правила применения соответствующего оборудо
вания, цель путешествия. Правда, нередко энтузиасты совершают восхождение
на гору только лишь «потому, что она есть». Полагаю, впрочем, что на самом деле
цель заключается в другом — люди стремятся покорить то, что считают могуще
ственнее себя; аналогичным образом для создания конкурентных преимуществ
и завоевания доли рынка коммерческие предприятия производят товары и услу
ги. Быть может, такая аналогия слишком груба, но рынок, по моему мнению, пред
ставляет собой арену жесткой конкуренции и битв не на жизнь, а на смерть; и на
ша конечная цель как разработчиков программных средств заключается в том,
чтобы выпустить продукт (или услугу), который может помочь нашей компании
выиграть несколько таких битв. Битвы на рынке способны выигрывать только
лидеры, понимающие характер, методы и цели военных действий в области про
граммного обеспечения.
Áèòâû íà ðûíêå ñïîñîáíû âûèãðûâàòü òîëüêî ëèäåðû, ïîíèìàþùèå õàðàêòåð, ìåòîäû
è öåëè âîåííûõ äåéñòâèé â îáëàñòè ïðîãðàììíîãî îáåñïå÷åíèÿ.
Вы должны полностью уяснить для себя цели компании — лишь в этом случае
вы сможете донести их до своих подчиненных. Естественно, процесс изучения
начинается с перспективного представления, хотя им одним задача не исчер
пывается — специалистам в области разработки программных средств приходит
ся копать довольно глубоко. Одно из обязательных качеств лидера — умение от
личать лес от деревьев. Мы, программисты, нередко блуждаем среди деревьев, не
понимая топологии леса. Лидер программистов не может себе позволить заблу
диться — слишком серьезными могут быть последствия и для подчиненных, и для
продукта.
Пока вы не обдумаете, не взвесите и не обоснуете каждое коммерческое требо
вание, добравшись, наконец, до «эврики»1, на комплексное понимание проблемы
не рассчитывайте. Наивно надеяться на то, что сотрудники, прочитав специфика
цию продукта, все сразу поймут и создадут реализацию именно такой, как требу
ется. Только выстроив для себя подробный план реализации от начала до конца,
вы сможете руководить процессом и отслеживать его. Здесь опять же необходимы
время и настойчивость. Первого никогда не бывает в достатке (за это я ручаюсь!),
а второе условие напрямую зависит от того, насколько серьезно вы относитесь
к своим лидерским обязанностям. Что касается времени, то у всех нас его поров
ну — просто некоторые им пользуются рациональнее, чем другие. Относительно
того, как опасно пренебрегать личной ответственностью за деятельность подчи
ненных и судьбу продукта, лучшие рекомендации дает опыт.
Требования кто то формулирует — значит, очевидно, они поддаются понима
нию. Это своеобразная трактовка известного высказывания о том, что если есть
воля, значит, есть и выход — правда, «волю» здесь следует понимать как исследо
вание вопроса вплоть до его полного понимания. План анализа проблемы можно
изложить следующим образом.
1
Именно так (в переводе с греческого: «нашел!») выразился Архимед, открыв основанный на принципе
плавучести метод проверки чистоты золота.
170 Ãëàâà 8 • Âîñõîä ëèäåðà
1. Прочтите требования дважды: один раз, чтобы понять широту замысла, вто
рой — чтобы постичь его глубину.
2. Сопоставьте требования с известными методиками реализации и выявите те
части функциональности, для реализации которых потребуются новые разра
ботки.
3. Набросайте предварительный план макетирования проектов — он поможет
выявить среди требуемых свойств неизвестные.
4. Составьте на основе документации с требованиями контрольный список, ко
торый, в свою очередь, послужит исходной точкой для формулирования задач.
Так вы сможете привязать каждое требование к набору задач и тем самым га
рантировать реализацию свойства.
Понимание рождает решения. Соответственно переходим к следующей роли
лидера — передаче знаний коллегам.
Ïåðåäà÷à çíàíèé
Слово «благовещение» я первый раз услышал в церкви еще ребенком. В религи
озном контексте оно употребляется в совершенно четком смысле и обозначает
распространение хорошей новости. Много позже я услышал этот термин в светс
кой интерпретации от Microsoft — словосочетание «благовестник продукта»1 по
казалось мне чрезвычайно точной характеристикой для восторженного молодень
кого преподавателя, к которому я ходил на курсы программирования. Способность
передавать знания есть второй необходимый признак лидера. Иногда говорят:
«тот, кто умеет, делает; тот, кто не умеет, преподает». Это изречение я считаю не
верным и предлагаю встречную мысль: у того, кто не может адекватно изложить
свои мысли, их слишком мало. Полагаю, что именно эта проблема обусловливает
плохую передачу информации в бизнесе: недостаточное понимание проблемы по
рождает комплекс, в результате чего субъект, который, по смыслу, должен эту про
блему доходчиво изложить, начинает надеяться на то, что окружающие смогут
интуитивно разобраться в ней и уяснить свои задачи. Наитие выходит на первый
план, если документацию с бизнес требованиями по ночам не читать, а использо
вать по естественному назначению — в качестве подушки; впрочем, и наитие ни
когда не сможет заменить четкое изложение мысли.
Цель передачи знаний — обеспечить понимание персоналом предъявленных
к продукту требований на том же уровне, на котором их понимает лидер. Итак,
каким образом вам самому удалось понять проблему в комплексе? Восстановите
последовательность действий, направленных на изучение требований, и перене
сите ее на процесс обучения сотрудников. Тот, кто способен четко доносить свои
знания до окружающих, сможет преуспеть в педагогике. Да, действительно, даже
самый лучший учитель не может обойтись без заинтересованных учеников, но
как лидер программистов вы располагаете в этом отношении существенным преи
муществом — ваши «студенты» работают под вашим же началом, и никуда им от
1
В оригинале — «product evangelist». Если бы не параллель с евангелистской терминологией, которую
приводит автор, мы, несомненно, предпочли бы перевести это словосочетание как «проповедник про
дукта». — Примеч. перев.
Ôóíäàìåíòàëüíûå ïðèíöèïû ëèäåðñòâà 171
вас не деться. Может быть, они не всегда вас слушают, но ведь вы — шеф и поэто
му располагаете методами принуждения к обучению. Поощрение, несомненно, вы
игрывает в сравнении с принуждением, но бывают ситуации, когда выбирать не
приходится. Вернемся к основной мысли: если передача знаний равнозначна пе
дагогической деятельности, то как лучше составить «план урока»? Элементы, при
веденные в табл. 8.1, являются минимально необходимыми для адекватной пере
дачи знаний.
Òîò, êòî ñïîñîáåí ÷åòêî äîíîñèòü ñâîè çíàíèÿ äî îêðóæàþùèõ, ñìîæåò ïðåóñïåòü
â ïåäàãîãèêå.
Èëëþñòðàöèè. Àíàëîãèè è ìåòàôîðû, ïîìîãàþùèå ïîêàçàòü
àëüòåðíàòèâíûå àñïåêòû ïðîáëåìû è òåì ñàìûì óãëóáèòü
åå óñâîåíèå
Многие лидеры излишне увлекаются стилем — в основном по той простой при
чине, что у них не все в порядке с содержанием. Основное внимание нужно все
таки уделять содержанию, ну а тонкости изложения можно будет наработать
с опытом. Перечисленные в табл. 8.1 элементы передачи знаний следует задей
ствовать как при устном, так и при письменном общении.
Необходимо различать запланированный процесс передачи знаний и случайные
разговоры на ту или иную тему. Поскольку вы — лидер, ваши замечания, пусть да
же высказанные по случаю, зачастую воспринимаются сотрудниками как официаль
ные распоряжения. Большую часть жизни мы доносим до окружающих информацию
172 Ãëàâà 8 • Âîñõîä ëèäåðà
интуитивно, не пользуясь заготовками и отталкиваясь исключительно от текущего
контекста. Различия между бессистемным и формальным мышлением следует обя
зательно иметь в виду; бывают ситуации, когда случайно высказанная мысль при
водит к непредусмотренным разрушительным последствиям для бизнеса. Спо
собность контролировать поле боя общения помогает выиграть битву понимания.
Ñïîñîáíîñòü êîíòðîëèðîâàòü ïîëå áîÿ îáùåíèÿ ïîìîãàåò âûèãðàòü áèòâó ïîíèìàíèÿ.
Как лучше всего донести до программиста суть требований? Показать ему ча
стично функционирующий макет. Даже одни пользовательские интерфейсы спо
собны помочь программисту составить представление о задаче. Впрочем, не сто
ит сбрасывать со счетов архитектуру. Как я говорил в главе 6, прежде чем собирать
урожай программных объектов, необходимо разбить сад, в котором вы намерены
их выращивать.
Испытанный способ улучшить передачу знаний — обратиться к помощи UML,
PowerPoint или Visio. Возможно, в вашей организации применяется оригиналь
ный процесс документирования требований и составления проектных докумен
тов. Если это так, придерживайтесь его, а при необходимости адаптируйте к кон
кретному проекту. Впрочем, имейте в виду, что строить разработку программных
средств исключительно на основе документов не стоит. Нередко такие важные
элементы процесса передачи знаний, как макетирование и критический обзор
предварительных аспектов реализации, просто напросто игнорируются. Полагаю,
что, став руководителем и лидером, вы начали испытывать ностальгию по коди
рованию. Если так, то, обратив внимание на два упомянутых элемента, вы сможете
освежить навыки программирования и одновременно решить свою непосредствен
ную задачу. Утверждения о «самодокументированности кода» слышны повсюду,
но на самом деле они редко соответствуют действительности. Конструирование
макетов как средств передачи знаний приносит пользу в двух отношениях: во
первых, удовлетворяет привычку к кодированию, во вторых, помогает донести
до окружающих ваше понимание решения поставленной задачи.
Äåëåãèðîâàíèå
Объяснив подчиненным, какая задача перед ними стоит, заставьте их ее решить.
Делегирование — это тоже искусство, а о том, почему оно является вашей глав
ной обязанностью, я уже неоднократно говорил. Способность к делегированию —
это одно из тех качеств, которое вы, лидер, должны постоянно совершенствовать.
Косвенно этой темы я касался в главе 1. Сопоставив перечисленные в ней типы
программистов с личностными качествами ваших сотрудников, вы сможете при
нять правильное решение относительно распределения задач между ними.
В идеале проект нужно разбить на рабочие единицы, которые впоследствии
можно будет распределить между всеми разработчиками. Впрочем, на практике
этот подход не всегда себя оправдывает. Может статься, что для решения отдель
ных задач по проекту или даже для комплексной его реализации лучше всего под
ходит ограниченная группа сотрудников. Иногда, в тех ситуациях, когда две го
Ôóíäàìåíòàëüíûå ïðèíöèïû ëèäåðñòâà 173
ловы лучше, чем одна, программистов имеет смысл разбивать по парам. Этот при
ем описан в методике разработки программных средств под названием экстре
мального программирования1. В рамках этой методики также культивируется
другой тип делегирования — он предусматривает создание команды из двух про
граммистов, в которой один пишет код, а другой ежедневно тестирует его и про
водит критические обзоры. Если подобрать подходящих кандидатов (лучше все
го — опытного программиста и новичка), эта схема делегирования оказывается
очень эффективной — сам видел. Однако если подобрать партнеров неверно, при
сущая программистам независимость сведет эффективность этой замечательной
идеи нулю. Помимо прочих навыков делегирования, вы должны понимать, какие
из ваших сотрудников могут работать вместе, а какие — нет.
Не забывайте и о хрестоматийном правиле, согласно которому введение в про
ект новых сотрудников на завершающих стадиях разработки только оттягивает
срок его сдачи. Делегировать можно задачи, но не темпы их решения. Если вы
обнаруживаете, что разбить проект на отдельные задания трудно, значит, возмож
но, проблема кроется в проектном решении. Вероятно, плану конструирования
недостает модульности. Иногда в самом начале работы над проектом кажется, что
никаких проблем с делегированием не возникнет. Впоследствии, однако, выясняет
ся, что одни группы уже решили поставленные перед ними задачи, а другие запаз
дывают. Подобные ситуации возникают из за неверного представления о продол
жительности выполнения тех или иных заданий. Эта проблема опять же связана
с проектированием. Качественное проектное решение (при наличии достойной
архитектуры) обеспечивает удобство делегирования по модулям.
Íå çàáûâàéòå è î õðåñòîìàòèéíîì ïðàâèëå, ñîãëàñíî êîòîðîìó ââåäåíèå â ïðîåêò
íîâûõ ñîòðóäíèêîâ íà çàâåðøàþùèõ ñòàäèÿõ ðàçðàáîòêè òîëüêî îòòÿãèâàåò ñðîê åãî
ñäà÷è. Äåëåãèðîâàòü ìîæíî çàäà÷è, íî íå òåìïû èõ ðåøåíèÿ.
Нужно уметь корректировать план делегирования на ходу. К необходимости его
корректировки нужно быть готовым с самого начала — она не должна стать для вас
сюрпризом. В ходе выполнения проекта от начальных стадий к завершающим у ли
дера нередко появляется ощущение стрельбы по движущейся мишени — вот поче
му для него так важен опыт. Если бы лидеры разработки программных продуктов
могли тренироваться в стрельбе по движущимся мишеням на стрельбище, было бы
просто здорово. К сожалению, практиковаться нам приходится в реальных услови
ях — иначе вряд ли мы срывали бы сроки. Чем больше вы будете тренироваться,
тем совершеннее станут ваши навыки. Делегирование — это лучший помощник в де
ле стрельбы по мишеням. Стоит вам попытаться сбить их все самостоятельно (то
есть поддаться соблазну мелочной опеки), патроны кончатся раньше времени.
Ïðîâåðêà
В этом контексте на авансцену выходит знакомый принцип «ожидай, но проверяй».
Естественная задача, возникающая после делегирования, заключается в контроле
1
Среди изданий, перечисленных в библиографии, присутствует книга «Extreme Programming Explained»
Кента Бека (Kent Beck).
174 Ãëàâà 8 • Âîñõîä ëèäåðà
за ходом выполнения заданий. Это не мелочная опека — это именно проверка.
Лучший способ приблизить перспективу завершения проекта в срок — проводить
регулярные сборки компонентов вплоть до полной готовности кода. Такие дей
ствия, помимо прочего, помогают избежать попадания в проектный тупик. Слиш
ком много времени теряется, если на подходе к завершению цикла разработки
приходится начинать все сначала — по той лишь причине, что проектное решение
себя не оправдало. Одним из элементов вашей повседневной деятельности долж
на стать ежедневная проверка результатов работы сотрудников; при приближе
нии сроков сдачи такие проверки нужно проводить еще чаще.
Эффективный мониторинг подобен непрекращающемуся критическому обзору
кода — он также предполагает контроль за соответствием проектному решению и стан
дартам кодирования. Чем дольше вы будете затягивать проведение обзора, тем
больше задач вам придется решать, — а если откладывать процесс слишком долго,
у вас просто не останется времени на то, чтобы разобраться в запутанном коде.
Перечислю некоторые методики проверки.
Ежедневно наведывайтесь к своим подчиненным и интересуйтесь, как у них
идут дела. Если личный контакт не представляется возможным, воспользуй
тесь телефоном или, на крайний случай, электронной почтой.
С регулярностью в несколько дней тестируйте готовые модули кода. Эта дея
тельность роднит вас с тестерами, но вы должны воспринимать ее как свою
первоочередную обязанность.
Регулярно пробуйте интегрировать компоненты в целостную систему и про
веряйте архитектуру на стройность. Здесь придется «поиграть» с кодом. Так
вы сможете выявлять ошибки, допущенные при конструировании, и держать
ся в курсе методов, которыми ваши программисты решают поставленные пе
ред ними задачи.
Проводя еженедельные совещания сотрудников (о них мы говорили в главе 5),
не забывайте отслеживать состояние проекта и вырабатывать вместе с подчи
ненными новые идеи. Эта деятельность дополняет ежедневные визиты к со
трудникам и позволяет привлечь к решению проблем общего характера кол
лективный разум.
Тех участников группы разработчиков, которым удалось быстро расправиться
со своими задачами, следует привлекать к тестированию результатов труда
остальных. Делать это нужно с осторожностью, допускать высказывания типа
«тестирование — это не мое дело» нельзя. Программирование не ограничива
ется написанием кода, оно также предполагает обеспечение его реального функ
ционирования.
Требуйте от программистов документировать все новые модули кода и состав
ляйте из этих отчетов сопроводительную документацию для отдела тестиро
вания. Тем самым вы дадите возможность себе и своим подчиненным оцени
вать ход процесса и соответствие заданным требованиям.
Äîïóñêàòü âûñêàçûâàíèÿ òèïà «òåñòèðîâàíèå — ýòî íå ìîå äåëî» íåëüçÿ. Ïðîãðàììèðîâàíèå íå îãðàíè÷èâàåòñÿ íàïèñàíèåì êîäà, îíî òàêæå ïðåäïîëàãàåò îáåñïå÷åíèå åãî ðåàëüíîãî ôóíêöèîíèðîâàíèÿ.
Ôóíäàìåíòàëüíûå ïðèíöèïû ëèäåðñòâà 175
Вышеупомянутые методики (впрочем, их список можно расширять) помогают
превратить процесс мониторинга в продуктивную и конструктивную деятель
ность, не ограничивающуюся оголтелой критикой. Если лидер не будет прове
рять своих подчиненных, кто нибудь из них может выпасть из общего темпа раз
работки, вследствие чего продукт не будет сдан вовремя. Достичь сопоставимых
успехов в разработке должны все участники группы — в противном случае толку
от такой деятельности будет очень мало.
Ó÷àñòèå
Несмотря на свое положение лидера, вам нередко придется участвовать в процес
се кодирования. Если сочетать эту деятельность с делегированием и проверкой,
ничего страшного не произойдет. Участие в «грязной работе» поможет вам утвер
диться в роли лидера, хотя здесь нужно стараться воздерживаться от мелочной
опеки. Разделяя обязанности по кодированию со своими подчиненными, вы не
раз получите от них одобрение; впрочем, имейте в виду, что увлекаться кодирова
нием для менеджера опасно. С учетом численности персонала отдела эта деятель
ность может стать необходимостью, однако за написание кода, с одной стороны,
и организацию этого процесса, с другой, отвечают разные участки мозга. Пере
ключаться с одного вида деятельности на другой довольно сложно. Для ведения
административных дел далеко не всегда требуется такая же концентрация, как
для программирования; таким образом, исполняя обязанности руководителя, мож
но позволить себе отвлечься на телефонный звонок или письмо, пришедшее по
электронной почте. Что же касается кодирования, полагаю, мне не нужно вам
объяснять, насколько губительными оказываются разного рода раздражители.
Если бы у нас вместо мозгов были микропроцессоры, в которых при «преры
вании» предусматривается сохранение состояния системы, параллельное испол
нение многочисленных заданий не составляло бы для нас такой проблемы. Мы
можем сколь угодно хвастаться способностью делать несколько дел одновремен
но, однако, как правило, качество исполнения каждого из них оставляет желать
лучшего. В нашей работе необходима концентрация — любой специалист в обла
сти разработки программных средств должен стремиться в каждый конкретный
момент заниматься чем то одним.
Как я уже говорил в разделе «Проверка», ваше участие в кодировании зачас
тую сводится к тестированию. Это жизненный пример участия лидера в процес
се. Трудно найти компанию, в которой обязанности по интеграции и тестирова
нию (до наступления этапа альфа тестирования) мог бы взять на себя кто то
помимо лидера группы разработчиков. Готовьтесь к нетривиальным испытаниям
ваших технических навыков и учитесь рационально использовать время. Спра
вившись с этими трудностями, вы сможете укрепиться в положении лидера. Если
вы будете активно участвовать в разработке, вам вряд ли хватит стандартных со
рока часов в неделю. Правда, здесь вас подстерегают опасности — вспомните ощу
щения, которые, как я говорил в предыдущей главе, можно охарактеризовать од
ной фразой: «Мне уже все равно». Если человек доходит до такого состояния, то,
наверное, менять что либо уже поздно. Вы должны постоянно следить за уровнем
своей загруженности — с тем, чтобы не выпасть из процесса в самый неподходя
щий момент. Как помните, разработка программных продуктов — это не спринт,
а марафон; в этом контексте умение взять правильный темп есть необходимое
176 Ãëàâà 8 • Âîñõîä ëèäåðà
условие стабильной работы всей команды. Чтобы выиграть марафон, нужно под
держивать взятый темп, прилагать усилия к тому, чтобы переставлять ноги, сле
дить за рельефом и не забывать, как это здорово — пересечь финишную линию
с достойным временем.
В школе и колледже я занимался бегом по пересеченной местности. Через не
сколько лет, за которые я успел жениться, отслужить в армии, завести детей и ус
тремиться к достижению американской мечты, тренировки ушли на второй план.
Много позже, пропустив несколько десятилетий, я начал тренироваться заново
и попытался войти в форму. Конечно, сейчас я уже не могу пробежать пять миль
за тридцать минут. Пару лет назад у меня это получалось за сорок минут, но, надо
сказать, не так легко, как в молодости. Каждый раз, когда я пытаюсь побить соб
ственный рекорд, мне приходится постоянно поддерживать концентрацию. Я об
наружил, что если во время пробежки вслух произносить «сконцентрируйся!»,
становится легче. Этот режим я стараюсь переносить в свою профессиональную
деятельность. Участие — это способность пробежать всю дистанцию, ни разу не
теряя внимания. Иногда, поскольку вы лидер, придется исполнять роль тренера,
стоящего у трассы, но не стоит забывать — лучшие лидеры сами умеют бегать.
Èíîãäà, ïîñêîëüêó âû ëèäåð, ïðèäåòñÿ èñïîëíÿòü ðîëü òðåíåðà, ñòîÿùåãî ó òðàññû,
íî íå ñòîèò çàáûâàòü — ëó÷øèå ëèäåðû ñàìè óìåþò áåãàòü.
В общем, участие предполагает переживание трудностей и побед вместе с под
чиненными. Для этого нужно быть всегда готовым помочь окружающим, уметь
прогнозировать возникновение проблем и решать их прежде, чем они окажут воз
действие на сотрудников. Другой гранью участия является проявление здорового
интереса к личной жизни подчиненных. Не нужно ни к кому навязываться в дру
зья — просто проявите понимаете того факта, что исполнением рабочих функций
их жизнь не ограничивается.
Возвращусь ненадолго к примеру с моими юношескими беговыми упражнени
ями. Однажды, помнится, наш тренер сказал нам, потным и запыхавшимся, при
мерно следующее: «Придет время, ребята, и вы будете рассказывать своим детям,
как быстро когда то бегали!» Тогда я не понял, к чему это он сказал. Тридцать во
семь лет спустя я уверен: он имел в виду, что участие в команде придает дополни
тельный смысл индивидуальным стараниям. Вы должны учитывать это обстоя
тельство в процессе взаимодействия со своими подчиненными — не пренебрегая
тренерскими обязанностями, как можно активнее участвуйте в их деятельности.
Íàäñòðîéêà
Разобравшись с фундаментальными принципами, пора переходить к более оче
видным вещам. Речь идет о некоторых наиболее значимых видах деятельности,
которые естественным образом вытекают из вашего лидерского положения. Если
вам они не покажутся столь очевидными, значит, необходимо проверить, насколь
ко полно реализованы основные принципы лидерства. В процессе формирования
команды лидер испытывает немало приятных минут — вы же не хотите их упус
Íàäñòðîéêà 177
тить, не правда ли? Ей богу, головной боли в ходе руководства процессом разра
ботки и так хватает. Так не будем пренебрегать возможностью разбавить ее более
приятными ощущениями!
Íàñòàâíè÷åñòâî
Обучая других обучать, мы приумножаем свои усилия и повышаем эффектив
ность. Пусть это будет рабочим определением наставничества. Наставничество
помогает решить множество различных задач, и чем больше внимания вы ему уде
ляете, тем серьезнее отдача. Вы уяснили смысл этого хитрого выражения: «обу
чать других обучать»? Наставничество — это больше, чем преподавание, посколь
ку оно предполагает передачу педагогических навыков. Как сказал мне мой отец,
в колледже я должен прежде всего научиться находить источники нужной мне
информации и правильно с ними обращаться. Он был прав. Наставничество под
разумевает обучение самообразованию при одновременной передаче знаний.
Îáó÷àÿ äðóãèõ îáó÷àòü, ìû ïðèóìíîæàåì ñâîè óñèëèÿ è ïîâûøàåì ýôôåêòèâíîñòü.
В академической науке педагогике основную роль играют проблемы эвристики.
Как наставник вы должны поощрять стремление своих сотрудников к получению
дополнительных знаний и экспериментированию, совершенствуя тем самым спо
собности своих подчиненных к самостоятельному решению задач. Последнее ка
чество в контексте разработки программного обеспечения совершенно необходи
мо. Охотно верю, что, изучая в школе математику, вы ненавидели слово «задача»,
но ведь, по существу, вся наша жизнь — эта одна большая задача. Вы должны пре
образовать требование в работающий программный продукт, а для этого необ
ходимо установить соответствие между данными в области требований и машин
ной реализацией, воплотив в нее свой богатый опыт пользователя.
Цель наставничества — воспитать лидеров не хуже самого наставника, а мо
жет быть, даже лучше него. Чем больше ответственности за процесс разработки
вы сможете привить своим подчиненным, тем серьезней будет та помощь, на ко
торую вы сможете рассчитывать при приближении сроков сдачи. Если это воз
можно, выделите на наставническую деятельность один из дней рабочей недели.
Придерживаться такого графика иногда будет сложно; однако ориентируясь на
обучение сотрудников, вы помогаете не только им, но и себе. Подготовка к на
ставнической деятельности укрепляет ваши собственные знания, формирует бо
лее ясное представление о рабочих обязанностях, помогает уточнять задания, ко
торые вы намереваетесь распределить между персоналом.
Характерным примером наставничества может стать построение в реальном
времени макета, иллюстрирующего тот или иной метод конструирования про
граммных средств. Быть может, имеет смысл на несколько часов присоединиться
к сотруднику, которому попалось особо трудное задание. Это отнюдь не мелоч
ная опека — скорее удачный пример сотрудничества. Наставничество — это соче
тание участия и понимания (двух фундаментальных принципов лидерства), на
правленное на повышение квалификации сотрудников.
178 Ãëàâà 8 • Âîñõîä ëèäåðà
Наставник — это не обязательно «старый хрыч». Возраст в данном случае не
имеет значения; куда важнее готовность делиться знаниями. Для того чтобы груп
па смогла добиться выдающихся успехов в разработке программных продуктов,
ее сотрудники должны друг другу помогать. Инициатором таких отношений дол
жны выступить вы, главный наставник; надо надеяться, на вашем примере этому
научатся остальные.
В зависимости от ситуации вы должны демонстрировать владение двумя вида
ми наставничества: целевым и комплексным. Целевое наставничество (targeted
mentoring) предполагает оказание сотрудникам вполне конкретной помощи, напри
мер в написании процедуры вызова интерфейса прикладного программирования
или подпрограммы сортировки — в зависимости от потребности. Такого рода на
ставничество востребовано всегда. Для комплексного наставничества (complete
mentoring) нужно нечто большее. Оно требует установления с сотрудниками тес
ных отношений, построенных на искренности и взаимопонимании (в то же время
необходимо отдавать себе отчет, что не со всеми сотрудниками это возможно).
Выберите из числа подчиненных самых многообещающих — тех, кого вы хотели
бы видеть своими последователями, — и уделите их воспитанию максимум вни
мания. Делясь своими знаниями, старайтесь укреплять отношения с избранника
ми. Взять хотя бы художника — он может научить студентов, как работать над
эскизами, выстраивать тень и перспективу. Уроки художника посещают многие
студенты, и, конечно, они перенимают у него часть знаний. Но лишь немногие,
лучшие ученики сознательно подготавливаются художником для того, чтобы впос
ледствии занять его место. Я говорю о роли ученика, подмастерья, адепта. Если
вы незаменимы, вас никогда не заменят. Учитывая планы карьерного роста, ниче
го хорошего в такой незаменимости нет.
Âîçíàãðàæäåíèå
Выдающиеся успехи нужно поощрять. Вы как лидер должны принимать решения
о том, когда и в каком виде выдавать призы. Выбор широк: от повышения зара
ботной платы до похода с отличившимся сотрудником в хороший ресторан или
на какое нибудь спортивное зрелище. Награда должна соответствовать достиже
ниям и основываться исключительно на заслугах. За то чтобы сотрудники выкла
дывались на все сто, им платят: дополнительные поощрения должны распростра
няться лишь на тех, кто, превысив ожидания, прыгнул выше головы.
Принципы вознаграждения сотрудников обычно регулируются корпоратив
ной политикой, что, однако, не исключает творческого подхода к этой задаче. Мож
но, например, провести в период бета тестирования конкурс, в котором сотруд
ники будут соревноваться в количестве устраненных ошибок; победителю в таком
соревновании, естественно, полагается денежный приз. Оценивать результаты вы
должны исходя из характера ошибок и информации о лицах, их допустивших.
Ниже я привожу пример схемы подобного рода оценки.
1. Количество исправленных ошибок.
2. Сложность каждой ошибки.
3. Время, потраченное на исправление каждойошибки.
4. Успешность предложенного решения (зависит от результатов повторного тес
тирования).
Íàäñòðîéêà 179
5. Усилия по взаимодействию с другими сотрудниками, направленному на по
иск решения (в случае, если такое взаимодействие необходимо).
6. Степень компетенции в области, к которой относится исправляемая ошибка.
7. Ваши собственные усилия по содействию сотрудникам, которые испытывают
затруднения при исправлении ошибки.
8. Дополнительные усилия, выходящие за рамки рабочей необходимости.
9. Своевременность решения задач, не относящихся к текущему выпуску про
дукта.
0. Желание приобретать дополнительные сведения о продукте, преодолевая при
этом трудности понимания и усваивая особо сложные моменты.
1. Настойчивость в решении задач, кажущихся невыполнимыми.
Естественно, отслеживать все эти моменты для каждой ошибки и каждого чле
на группы довольно сложно, однако рассматриваемый метод мониторинга — од
ного из фундаментальных принципов лидерства — конструктивен, а кроме того,
придает деятельности по организации процесса развлекательный характер. Сто
ит также обратить внимание на то, как в вышеприведенном списке находит свое
отражение концепция наставничества. Обычно, будучи лидером, вы стремитесь
не допускать между разработчиками соперничества, способного усложнить дос
тижение результата группой в целом. Именно поэтому при распределении воз
награждений так важно вести подсчет достигнутых сотрудниками успехов. Если
бы я лучше разбирался в спорте, то, наверное, не удержался бы от какой нибудь
аналогии, например с количеством подстраховок (кажется, есть что то такое
в бейсболе или в баскетболе? или в обоих видах? не знаю).
Вне зависимости от того, какой метод поощрения сотрудников вы выберете,
будьте справедливыми и не опаздывайте с вознаграждением. Когда какого то бо
гатого человека спросили о том, сколько денег ему нужно для счастья, он ответил:
«Всегда немножко больше». Не забывайте, что вознаграждать нужно только тех,
кто показал исключительные достижения, превысив все ожидания.
Íå çàáûâàéòå, ÷òî âîçíàãðàæäàòü íóæíî òîëüêî òåõ, êòî ïîêàçàë èñêëþ÷èòåëüíûå
äîñòèæåíèÿ, ïðåâûñèâ âñå îæèäàíèÿ.
Èñïðàâëåíèÿ
Необходимым условием профессионального роста любого программиста должна
быть перепроверка результатов его деятельности. Исправляя ошибки, вы не дол
жны действовать как университетский профессор и ставить жирный крест поверх
неправильно решенной задачи. Настоящий лидер программистов старается сде
лать так, чтобы его подчиненные сами находили свои ошибки и учились на них.
Конечно, при этом он должен советовать наиболее разумные способы решения
проблем. Это очень тонкая задача, к решению которой лидер должен подходить
со всей осторожностью, не впадая при этом в занудство. Недопустимо закрывать
глаза на неаккуратный код и нерациональные действия сотрудников.
180 Ãëàâà 8 • Âîñõîä ëèäåðà
В главе 6, посвященной техническому лидерству, мы обсуждали метод крити
ческого обзора кода, а также последствия пренебрежения этой крайне важной обя
занностью лидера. Вообще говоря, ваши корректирующие усилия должны быть
в основном направлены на обеспечение максимальной отдачи всех сотрудников.
Если кто то работает одной левой, попытайтесь понять, почему. Не думаю, что
ваш отдел так богат, что в нем можно держать сотрудника, который ограничива
ется исполнением своих минимальных обязанностей. Как я говорил в главе 3,
иногда проблемы с сотрудниками решаются только путем увольнения. Если же
проблема решаема, то доводить ее до необходимости увольнения неразумно. Зна
чительно лучше попытаться регулярно оказывать сотруднику помощь, которая
может привести к его реабилитации.
Пытаясь помочь программисту исправить ошибки или обрести мотивацию к ак
тивной деятельности, не забывайте, что процесс этот двунаправленный. Если вы
не проверяете собственные ошибки, вряд ли к вашей правке будут относиться серьез
но. Быть может, в человеческих отношениях действительно слишком много лице
мерия, но лидеру программистов это качество противопоказано. В главе 2, говоря
о борьбе с собственными слабостями, я упоминал о том, какое сильное влияние на
сотрудников способен оказывать ваш стиль кодирования, — вопрос в том, какой
характер носит это влияние: положительный или отрицательный? Ваши подчи
ненные прекрасно видят, насколько увлеченно вы относитесь к своим обязаннос
тям, — укоряя кого нибудь за недостаточное усердие, имейте это в виду.
Áûòü ìîæåò, â ÷åëîâå÷åñêèõ îòíîøåíèÿõ äåéñòâèòåëüíî ñëèøêîì ìíîãî ëèöåìåðèÿ,
íî ëèäåðó ïðîãðàììèñòîâ ýòî êà÷åñòâî ïðîòèâîïîêàçàíî.
Ïðåäâèäåíèå
Способность предугадывать будущее развитие событий привлекает к вам после
дователей. Некоторые даже считают, что это — основное качество лидера. И дей
ствительно, оно играет очень важную роль — даже если ваших способностей про
видца не хватает для создания очередной убойной программы. И самые скромные
прогнозы чрезвычайно вдохновляют сотрудников. Представление о том, как со
кратить усилия по сопровождению в очередной версии флагмана вашей компа
нии, может сыграть для нее не меньшую роль, чем изобретение Интернета.
Можно ли сформулировать метод предвидения? Быть может, настоящий про
видец действительно общается с музами и сообщает людям услышанное? Навер
ное, при создании образцов высокой литературы и музыки без муз не обошлось,
но вообще во всех творческих начинаниях очень важно мыслить нестандартно.
Когда во время Второй мировой войны Алан Тьюринг (Alan Turing), работая на
британскую разведку, расшифровывал немецкие сообщения, он попутно сформу
лировал новый способ осмысления вычислительных методов. В краткой биогра
фии Тьюринга имеется следующий фрагмент:
«Тьюринг изначально представлял себе, что его машина должна будет выполнять
те же функции, что и человеческий мозг. [Тьюринг] предложил и проанализиро
вал понятие «разумной машины»… Он обращался к аналогии с учителем и учени
Íàäñòðîéêà 181
ком. Ученик может превзойти учителя, выйдя на более высокий интеллектуаль
ный уровень, — для этого вполне достаточно информации, переданной ему учи
телем. По Тьюрингу, появление подобной машины вполне возможно — достаточ
но правил, введенных в машину. Впрочем, «играя против такой машины, чув
ствуешь, будто разум уничтожает что то живое». Поскольку компьютер может
учиться, его поведение выходит за рамки механистического детерминизма и
демонстрирует свободу, создающую ощущение живого разума… Тьюринг мыс
лил на уровень выше математики, вычислимых чисел и даже компьютеров»1.
К какому продолжению привели идеи, высказанные Тьюрингом, нам извест
но. Результатом стало признание исключительной важности алгоритмов в архи
тектуре программного обеспечения. Калькуляторы переросли в более мощные
машины, способные побить чемпиона мира по шахматам. Благодаря нестандарт
ности мышления Тьюринга его метод стал адекватным задачам современности.
Роль лидера прогнозиста как раз и предполагает такого рода широкое мышление;
ваше положение в компании создает прекрасные условия для его воспитания.
Сочетание «глобального» осмысления деятельности вашей компании с техни
ческими навыками и административной проницательностью позволяет вырабо
тать новые методы повышения продуктивности сотрудников. Такого рода прак
тичное предвидение в нашей деятельности крайне приветствуется. Реализация
навыков, которые вы почерпнули из этой главы, способна превратить прогнозы
в реальность — передавайте свои знания, делегируйте полномочия, проверяйте ход
выполнения проекта, участвуйте во взращивании и сборе урожая.
Ðåàëèçàöèÿ íàâûêîâ, êîòîðûå âû ïî÷åðïíóëè èç ýòîé ãëàâû, ñïîñîáíà ïðåâðàòèòü
ïðîãíîçû â ðåàëüíîñòü — ïåðåäàâàéòå ñâîè çíàíèÿ, äåëåãèðóéòå ïîëíîìî÷èÿ, ïðîâåðÿéòå õîä âûïîëíåíèÿ ïðîåêòà, ó÷àñòâóéòå âî âçðàùèâàíèè è ñáîðå óðîæàÿ.
Àäàïòàöèÿ
В первой главе, как вы помните, я сделал акцент на адаптации к обязанностям ли
дера. Потребность в адаптации тем выше, чем дольше вы пребываете в роли лидера.
Корректировка своих действий в соответствии с текущими условиями — это необ
ходимость и одно из основных требований к хорошему лидеру. Люди, к сожале
нию, не могут предсказывать будущее в стратегической перспективе; будь у нас та
кая возможность, и планировать стало бы гораздо легче. В то же время люди как
представители биологического вида привыкли адаптироваться к изменяющемся ус
ловиям среды. Не стоит ждать биологических изменений — лучше разделить свою
лидерскую деятельность на ряд областей компетенции и оценить динамику разви
тия своих навыков. Новые проблемы, встречающиеся в вашей работе, помогают
тренировать способности к адаптации и приобретать новые знания. Любую трудную
задачу следует рассматривать как возможность для дальнейшего развития, а от
нюдь не как очередной повод «сжать кулаки». Эти мои размышления сильно на
поминают концепцию позитивного мышления, о которой я мельком упоминал
в предыдущей главе, но они разумны, а значит, заслуживают внимания.
1
Paul Strathern, Turing and the Computer (New York: Doubleday, 1997), pp. 75–78.
Пожалуй, я слишком увлекся разного рода клише. Среди практических вопро
сов адаптации, которыми вам стоит задаться, можно привести следующие.
Каким образом нужно скорректировать мой стиль руководства, чтобы лучше
решать текущие задачи?
Какие новые технологии стоит изучить моим сотрудникам, чтобы наши про
дукты сохранили конкурентоспособность?
Каких новых сотрудников мне стоит нанять, чтобы повысить компетентность
персонала, а соответственно, и качество исполнения новых проектов?
Можно ли изменить структуру отдела так, чтобы повысить качество, не сры
вая при этом сроков выхода продуктов на рынок?
Все эти вопросы (а может быть, и какие то другие, которые придут вам в голо
ву) нужно задавать себе (а желательно — и сотрудникам) ежедневно. Естественно,
ответы на них должны быть выверенными, но не забывайте, что умение задавать
нужные вопросы — это тоже элемент адаптации. Станьте экспертом по формули
рованию вопросов и поощряйте диалог с сотрудниками по поводу наиболее труд
ных текущих проблем.
Процесс адаптации идет строго по науке: сначала ставятся эксперименты, а за
тем их результаты оцениваются на предмет успешности. Неудачные методы за
меняются новыми. Постепенно вырабатывается «идеальная» методология, кото
рая в итоге переходит в ранг закона. Поощряя адаптационные процессы в самом
себе и в своих сотрудниках, вы обрекаете себя на роль подопытных кроликов. Не
стоит, впрочем, беспокоиться на этот счет — это не смертельно. При условии ре
гулярной оценки результатов применения новых методов и их корректировки
согласно текущей конъюнктуре вы сможете застраховать себя от фатальных по
следствий.
Ïîéäóò ëè çà âàìè?
В чем заключается политическая опора вашей лидерской деятельности? Я не имею
в виду выстраивание империй, но ведь должны быть у вас средства принуждения
подчиненных к труду! Как я уже говорил, лидеры сами создают себе последовате
лей, обращаясь при этом к своим наиболее притягательным качествам. В этом
разделе мы поговорим о тех факторах общего характера, которые заставляют лю
дей идти в заданном лидером направлении. Некоторые из представленных здесь
методов очевидно выигрывают на фоне других, но, в принципе, все они имеют
право на существование. Время от времени их приходится задействовать все сра
зу, и ничего страшного в этом нет. Попробуйте проанализировать, насколько они
применимы в конкретных условиях, выберите для себя наиболее удачные — и впе
ред к победам!
Ïîéäóò ëè çà âàìè? 183
Ïðèíóæäåíèå
Набирая в команду сотрудников, вы ставите перед ними ясное условие: чтобы
получать зарплату, они должны трудиться. Это очевидное обстоятельство неред
ко воспринимается как данность. Действительно, современная система коммер
ческих отношений предполагает обмен мастерства на наличность. Но достаточно
ли этого, чтобы заставить людей делать свою работу качественно? Как правило,
нет, хотя с этого можно начинать — по крайней мере, в отсутствие более удачных
средств мотивирования сотрудников.
Прибегать к силе принуждения нужно в последнюю очередь. Впрочем, рыноч
ные условия иногда заставляют нас действовать подобным образом. Если компа
ния сильно отстает в техническом отношении, для того чтобы отвоевать утерян
ные позиции, приходится предпринимать определенные усилия. Подобного рода
внешние факторы, если донести их правильно, оказывают на людей должное воз
действие. Не надо пугаться фраз типа «требования рынка» и «наши конкуренты
располагают…» и соответствующих средств мотивирования — они работают!
Íå íàäî ïóãàòüñÿ ôðàç òèïà «òðåáîâàíèÿ ðûíêà» è «íàøè êîíêóðåíòû ðàñïîëàãàþò…»
è ñîîòâåòñòâóþùèõ ñðåäñòâ ìîòèâèðîâàíèÿ — îíè ðàáîòàþò!
Не стоит прибегать к аргументам типа «потому что я так сказал» — если,
конечно, вы не хотите, чтобы вас воспринимали как ментора с ограниченными
умственными способностями. Не спорю, вы — начальник, и задания, которые вы
распределяете между подчиненными, должны выполняться, но не забывайте —
я пытаюсь научить вас пасти котов, а они, как известно, пугаются громких звуков.
Äîëã
Некоторые подчиненные следуют указаниям начальника просто потому, что
не понимают, как можно этого не делать, — преданность у них в подкорке. Заме
чательно — вы должны поощрять такое отношение. С другой стороны, право на
зываться боссом нужно заслужить, и одним лишь наличием должности здесь не
обойтись. Повторюсь: высказывания о том, что сотрудники «обязаны следовать
вашим указаниям», ни к чему не приводят. Это не более чем демонстрация грубой
силы. Чувство долга формируется в человеке под воздействием личных и душев
ных факторов. Ему нельзя научить. Требовать его проявления в военных услови
ях допустимо, но в группе программистов подобное отношение практиковать
не следует.
Как лучше всего воспитать чувство долга в своих сотрудниках? Нужно куль
тивировать в них ощущение гордости за свои коллективные достижения. Все хо
тят быть причастными к победам. Взгляните на фанатов команды победителя. Они
ведь не принимают участия в состязании, но результат переполняет их эмоция
ми. Ваша задача в роли лидера — сделать так, чтобы сотрудники воспринимали
долг перед командой, состоящей сплошь из выдающихся личностей, как высшую
честь.
184 Ãëàâà 8 • Âîñõîä ëèäåðà
Êàê ëó÷øå âñåãî âîñïèòàòü ÷óâñòâî äîëãà â ñâîèõ ñîòðóäíèêàõ? Íóæíî êóëüòèâèðîâàòü
â íèõ îùóùåíèå ãîðäîñòè çà ñâîè êîëëåêòèâíûå äîñòèæåíèÿ. Âñå õîòÿò áûòü ïðè÷àñòíûìè ê ïîáåäàì.
Âîñõèùåíèå
Я восхищаюсь Альбертом Эйнштейном и поэтому, будь у меня такая возможность,
пошел бы работать в любую лабораторию, если бы ей руководил он. Правда, свою
лабораторию он держал в уме, так что это не самое удачное сравнение. Но вы меня
поняли. Очень часто люди идут за лидером лишь потому, что восхищаются его
личными качествами. Все это, конечно, замечательно, но вот незадача — большин
ство из нас не вызывают особого восхищения.
Способны ли вы работать так, чтобы подчиненные вами восхищались? Пола
гаю, да. Поможет ли это? Ну, с некоторой натяжкой тоже да. Правда, почитатели
непостоянны — спросите у любого поклонника какой нибудь закатившейся ки
нозвезды. Для того чтобы люди восхищались вами постоянно, да еще и получали
от этого ощущения силы для своей деятельности, нужно не отступать от своего
стиля руководства, неизменно демонстрировать эффективность лидерской дея
тельности и поддерживать стабильные отношения с персоналом; иными слова
ми — проявлять последовательность. Это трудно, но необходимо. Последователь
ность — замечательное качество: она создает в подчиненных чувство защищен
ности и здорово помогает в самые трудные моменты, когда всей группе приходит
ся биться над тем, чтобы закончить разработку проекта и сдать его в срок. Идти
к такого рода последовательности нужно долго и упорно — не месяц и, вероятно,
даже не год. Но, с другой стороны, ваши ежедневные усилия в достижении после
довательности не пройдут незамеченными, а значит, вас будут больше уважать
и стремиться работать прилежнее.
Äëÿ òîãî ÷òîáû ëþäè âîñõèùàëèñü âàìè ïîñòîÿííî äà åùå è ïîëó÷àëè îò ýòîãî îùóùåíèÿ
ñèëû äëÿ ñâîåé äåÿòåëüíîñòè, íóæíî íå îòñòóïàòü îò ñâîåãî ñòèëÿ ðóêîâîäñòâà,
íåèçìåííî äåìîíñòðèðîâàòü ýôôåêòèâíîñòü ëèäåðñêîé äåÿòåëüíîñòè è ïîääåðæèâàòü
ñòàáèëüíûå îòíîøåíèÿ ñ ïåðñîíàëîì; èíûìè ñëîâàìè — ïðîÿâëÿòü ïîñëåäîâàòåëüíîñòü.
Âîçíàãðàæäåíèå
Многие считают, что вознаграждение — это один из лучших способов принужде
ния. В разделе, посвященном фундаментальным принципам лидерства, я уже го
ворил о премиях. Не стоит забывать, что вознаграждение — это краткосрочное
решение, оно может мотивировать только на первых порах. Увлекаясь раздачей
наград, мы начинаем регулярно задаваться неблагодарным вопросом: «А что ты
для себя сегодня сделал?» Лично я терпеть не могу так мыслить. Итак, ценность
тех видов вознаграждения, к которым руководители прибегают чаще всего (день
ги, выходные и т. п.), ограничена во времени.
Нужно сделать так, чтобы сотрудники извлекали из работы над проектами,
которыми вы руководите, особые, неосязаемые виды вознаграждения — ведь они
самые эффективные! Бытует мнение о том, что программирование как область
Âîçðàñòíûå àñïåêòû ëèäåðñòâà 185
человеческой деятельности дарит своим приверженцам наслаждение — но этого
мало. За счет своих навыков руководителя и лидера вы должны стремиться со
здать в своем отделе такую атмосферу, в которой сотрудники, просыпаясь утром,
могли бы благодарить судьбу за то, какая у них прекрасная работа. Не слишком
ли высокую планку я перед вами ставлю? Ну, возможно, для некоторых она и ока
жется недостижимой, но, в принципе, стремиться к этой цели стоит — результаты
оправдывают все усилия.
Как этого достичь? Ответ вам известен, но я повторюсь, ибо повторение, как
известно, — мать учения: концентрируйтесь и становитесь лидером. О том, как
концентрироваться, мы уже говорили в предыдущих главах — с тем, что касается
принципов лидерства, мы бьемся уже здесь. Испытывайте на практике теорети
ческий материал, который я здесь излагаю, и ищите наиболее подходящие в ва
шей ситуации методы. Воистину практика — это путь к совершенству, и вашим
сотрудникам она приносит серьезные дивиденды.
Çíàíèå
Про нашу индустрию можно с уверенностью сказать: «Знание — сила!» Програм
мисты любят работать под началом компетентных лидеров, поскольку те помогают
им решать их собственные задачи. Действительно, знание — это хорошее средство
создать последователей. Станьте экспертом в своей области, и программисты, гото
вые идти по заданному вами пути, не заставят себя ждать. Не слишком ли многого
я требую от вас, учитывая необходимость ежедневно выполнять множество адми
нистративных функций? Да, это трудно, но если вы остановитесь в своем про
фессиональном развитии, то не сможете должным образом руководить своими
подчиненными.
В предыдущей главе я упоминал о программистах, которые, обладая блестя
щей квалификацией, тем не менее не приспособлены к выполнению организаци
онных задач. Если вы — гений (и при этом чувствуете себя на своем месте), мои
вам поздравления. В таком случае у вас, скорее всего, уже есть последователи. Но
ведь их еще нужно удержать — для этого старайтесь передавать им свои знания,
которые позволили бы им дорасти до вашего уровня. Я это серьезно. В нашей ин
дустрии много блестящих программистов и лидеров, но нужно еще больше. Об
ращайте особое внимание на свои наставнические функции, и вам удастся воспи
тать достойных последователей.
Âîçðàñòíûå àñïåêòû ëèäåðñòâà
Хочется надеяться, что эту книгу читают люди самых разных возрастов. Сам
я пребываю в среднем возрасте; вы же, быть может, лишь недавно вышли из юно
шеского состояния. Биологический возраст оказывает довольно серьезное воз
действие на осмысление лидерской роли и подход к решению задач в области раз
работки программных средств. Не так уж часто встречаются опытные лидеры, не
успевшие еще разменять четвертый десяток, хотя есть и такие. Старость — от
нюдь не гарантия мудрости. У нас, «стариков», часто встречаются не слишком
приятные привычки, от которых нужно избавляться, и в этом нам совсем не поме
шают рекомендации молодых людей.
186 Ãëàâà 8 • Âîñõîä ëèäåðà
Какие черты характерны для молодых?
Они быстро усваивают новую информацию.
Они на равных с новыми технологиями.
Для них нет невыполнимых задач.
Они ощущают себя бессмертными, что позволяет им добиваться великих до
стижений.
Впрочем, кто сказал, что все эти качества не могут относиться к более взрос
лым людям? Взрослея, вы должны обращать внимание на поведение молодых,
поскольку нам есть чему у них поучиться.
Теперь перечислю качества, которыми обычно наделяют людей в возрасте (я не
имею в виду какой то конкретный возраст).
Они мудры, потому что прожили долго и всю жизнь учились.
У них есть многолетний опыт общения с изменяющейся технологией, а следо
вательно, они умеют к ней адаптироваться.
Они более терпеливы, поскольку научены на собственных ошибках.
Они все больше ощущают свою смертность и пытаются выжать максимум из
каждого прожитого дня.
Опять же нельзя утверждать, что молодые люди лишены этих качеств. Мы все
можем учиться на чужом опыте. Будь вы самым молодым или, наоборот, самым
старшим из всей команды — в любом случае у окружающих есть чему поучиться.
Способность к обучению не имеет возрастных рамок. Отказ от повышения уров
ня знаний в нашей отрасли чреват закатом карьеры.
Есть и другие, более серьезные возрастные различия. В современной психоло
гии, которая являет собой науку о поведении, проведено несколько исследований
жизненного цикла человека. Согласно этим исследованиям, возраст действитель
но обусловливает определенный подход к рабочей деятельности, и в особенности
это касается лидерства. Следующий пассаж, в котором жизнь, подобно солнечно
му году, трактуется как последовательность сезонов, доказывает различия в мен
тальности в зависимости от возраста.
«Если проводить аналогии с временами года, нетрудно заметить, что жизнь
обладает определенными очертаниями и проходит через ряд четких форм. Се
зон — это относительно стабильная часть общего цикла. Лето существенно от
личается от зимы, равно как и сумерки не похожи на зарю. Утверждение об
относительной стабильности сезона, впрочем, еще не означает, что он неизме
нен или статичен. Каждому сезону — свое время; каждый из них важен не мень
ше, чем другие, и требует осмысления с привлечением индивидуального по
нятийного аппарата. Нет сезона, который можно было бы признать менее
значимым, чем любой другой. Каждый из них занимает особое и необходимое
Êàê ëèäåðó ñî÷åòàòü ôîðìó è ñîäåðæàíèå 187
положение в рамках целого и придает ему собственный оттенок. Любой сезон
представляется органичным элементом общего цикла — соединяя прошлое с на
стоящим, он одновременно заключает в себе то и другое»1.
В зависимости от того, какой сезон мы переживаем в данный момент, наши
воззрения на лидерство меняются. Вместе с ними меняется восприятие важности
успехов и неудач. Кроме вас, никто не может сказать, каким конкретно образом
возраст влияет на ваше представление о лидерской роли. Не существует такой
закономерности, на основании которой мы могли бы утверждать, что один воз
раст лучше другого.
Я тоже не избежал влияния возрастных факторов. Свой путь в индустрии я на
чал с кодирования на Фортране, используя перфокарты для IBM; я передавал ко
лоды карт через конторку в своем компьютерном центре, а чтобы узнать, работает
ли программа, приходилось ждать несколько дней. Мне довелось работать с пер
вой предтечей Интернета — сетью, которая в те дни называлась ARPANET2, —
она работала жутко медленно и понимала только символы. Поэтому я причисляю
себя к первому поколению «ботаников» — тех, кто в колледже не мог обходиться
без логарифмической линейки за поясом и запасных предохранителей в кармане.
Сегодняшнего лидера программистов порой невозможно отличить от какого ни
будь магистра. Он сам зачастую носит гордое имя магистра экономики и управле
ния (MBA) и, конечно, имеет за плечами серьезное образование в области ком
пьютерных наук. Представителям моего поколения приходилось получать все эти
знания на ходу. Подобного рода различия, разумеется, оказывают влияние на наши
взгляды и на решения, которые мы принимаем в роли лидеров. С другой стороны,
к какому бы поколению мы ни принадлежали, мы можем учиться на своих разли
чиях. Именно в этом взаимодействии рождаются самые удачные воззрения и идеи.
Êàê ëèäåðó ñî÷åòàòü ôîðìó è ñîäåðæàíèå
Форма — это выраженные в поведении личностные характеристики, которые в на
шем случае переплетаются с реализацией принципов лидерства. Форму, которая
безусловно важна, нужно удачно сочетать с содержанием, которое отражает ваши
представления о важнейших лидерских принципах. Форма без содержания — это
не более чем голая методика, лишенная стратегической ценности. Тем не менее
мы зачастую раньше замечаем в окружающих форму, чем начинаем разбираться в
ее наполнении. Слава богу, не существуют двух лидеров, имеющих одну и ту же
форму. Многообразие для технарей чрезвычайно полезно, и будучи лидерами, мы
не менее разнообразны, чем программисты, которыми руководим.
Все мы учимся походить на лидеров, которым следуем и которыми восхища
емся. Хорошо бы еще учиться на собственных достижениях и ошибках в роли лиде
ров. Литература по коммерческому менеджменту изобилует биографиями людей,
1
2
Daniel J. Levinson, The Seasons of a Man’s Life (New York: Ballantine Books, 1978), p. 7.
ARPA — это сокращение от Advanced Research Projects Agency (Управление перспективных исследо
вательских программ) — ведомства, которое в 1970 х годах было переименовано в DARPA. Первая бук
вы D в этой новой аббревиатуре обозначала принадлежность к министерству обороны США (defense —
оборона), заведовавшего ракетами, бомбами с лазерным наведением, технологией «Стелс» и всеми прочи
ми прелестями времен холодной войны.
188 Ãëàâà 8 • Âîñõîä ëèäåðà
примерами которых можно восхищаться. В главе 2 я уже ссылался на Джека Уэл
ча ( Jack Welch) — бывшего главу General Electric и одного из тех людей, которым
не стыдно подражать. Есть в нашей индустрии еще два хрестоматийных лидера:
Энди Гроув (Andy Grove) и Билл Гейтс (Bill Gates).
Ýíäè Ãðîóâ — àãðåññèâíûé ïàðàíîèê
Под руководством Гроува компания Intel превратилась в крупнейшего в мире про
изводителя полупроводников и одну из самых уважаемых организаций. Гроуву
удалось привести Intel к такому статусу вопреки постоянным переменам и жест
кой конкуренции, наблюдавшимися в нашей индустрии на протяжении послед
них десятилетий. Как это у него получилось? В первой главе своей книги о ли
дерстве Гроув пишет:
«Мне часто приписывают крылатую фразу ”выживают только параноики“. Хоть
убейте, не вспомню, когда я ее первый раз произнес, но, действительно, в том, что
касается бизнеса, я верю в силу паранойи. Успех коммерческого предприятия
одновременно создает предпосылки для его разрушения. Чем успешнее ты ста
новишься, тем больше людей пытаются урвать кусочек твоего дела, потом дру
гой — и в конечном итоге оставить тебя без гроша в кармане. Я убежден, что
руководитель должен в первую очередь постоянно отбиваться от нападок за
вистников и прививать аналогичные настроения своим подчиненным»1.
Паранойя — в том качестве, в котором ее определяет Гроув, — действительно де
монстрирует в бизнесе чрезвычайную эффективность. Вести себя подобным образом
с женой, конечно, не стоит, но вот в Intel под руководством Гроува эта стратегия сра
ботала. Познакомившись с тем, как Гроув управлял Intel, вы обязательно придете
к выводу, что основным фактором успеха компании стал стиль реагирования на
перемены, практикуемый ее руководителем. Управлять переменами очень слож
но, а в роли лидера вам предстоит сталкиваться с этой проблемой ежедневно.
Гроув умел предвидеть перемены и атаковал их. Даже несмотря на неудачи
(вспомните, например, историю с плавающей точкой в процессорах Pentium), он
осознавал основополагающие цели своей индустрии и творчески реагировал на
самые неожиданные явления. Итак, учитесь: не ставьте себя в изолированное по
ложение — постоянно следите за факторами, которые оказывают влияние на ин
дустрию в целом и на ваших сотрудников в частности. Если для этого придется
стать параноиком — станьте им! Лучше ожидать неожиданное, чем удивляться,
когда оно предстанет перед вами в полный рост.
Íå ñòàâüòå ñåáÿ â èçîëèðîâàííîå ïîëîæåíèå — ïîñòîÿííî ñëåäèòå çà ôàêòîðàìè,
êîòîðûå îêàçûâàþò âëèÿíèå íà èíäóñòðèþ â öåëîì è íà âàøèõ ñîòðóäíèêîâ â ÷àñòíîñòè.
Åñëè äëÿ ýòîãî ïðèäåòñÿ ñòàòü ïàðàíîèêîì — ñòàíüòå èì! Ëó÷øå îæèäàòü íåîæèäàííîå, ÷åì óäèâëÿòüñÿ, êîãäà îíî ïðåäñòàíåò ïåðåä âàìè â ïîëíûé ðîñò.
Áèëë Ãåéòñ — îäåðæèìîñòü è ðàñ÷åòëèâîñòü
Трудно не восхищаться Биллом Гейтсом. Сравните выгнанного из колледжа юно
шу с неадекватным выражением лица, запечатленного на фотографии 1978 года,
1
Andrew S. Grove, Only the Paranoid Survive (New York: Random House, 1996), p. 3.
Êàê ëèäåðó ñî÷åòàòü ôîðìó è ñîäåðæàíèå 189
с тем человечищем, которым он стал через несколько лет, и восторга не избежать.
Корни империи Microsoft — в одержимости, предвидении, предпринимательских
способностях и расчетливости одного из ее основателей. О нем ходят легенды.
Один из соседей Гейтса по общежитию в колледже рассказывает, как тот играл
в покер, буквально следующее:
«У Билла было одно совершенно маньяческое качество… За все, что его интере
совало, он брался мертвой хваткой и не отрывался. У него была цель — разоб
раться в предмете любой ценой. Наверное, глупо сравнивать покер и Microsoft,
но в обоих случаях Билл направлял всю свою энергию на решение одной зада
чи, и ему было все равно, что об этом думают окружающие»1.
Остальное — история. Впрочем, если вы не понимаете, что одержимость успе
хом в конечном итоге приводит к успеху, значит, вы недооцениваете один из
важнейших аспектов лидерства. Как вы уже знаете, важнейшим принципом дея
тельности лидера я считаю умение концентрироваться. Этим искусством в совер
шенстве владеют одержимые. Возможно, мотивация лидера вызывает вопросы,
но успеху, от которого выигрывают очень многие, трудно что то противопоста
вить.
К стилю лидерства, который практикует Гейтс, я также отношу расчетливость.
Как и Гроув, он умеет предсказывать перемены и к моменту их наступления уже
имеет четкий план действий. Вот, например, вы замечали, что в большинстве вер
сий Windows период действия авторских прав указывается с 1981 года2? Это, по
моему, прекрасное свидетельство планирования, которое этот чрезвычайно рас
четливый человек совершенствовал в течение многих лет. Да, Гейтс не всегда
лидировал в индустрии, но в любом случае на нашу повседневную деятельность
в роли программистов и их лидеров он оказал наибольшее влияние. Вот где фор
мальная расчетливость в сочетании с содержательной стороной дела приводит
к формированию лидерского ресурса. Любые инструменты и инфраструктура, со
зданные вне Microsoft, все равно оцениваются в свете достижений этой компании
(или вопреки им).
Âû — ________________ (ââåäèòå íåäîñòàþùåå ñëîâî)
Исходя из двух вышеприведенных примеров лидерства, как бы вы охарактеризова
ли свой лидерский стиль? Впрочем, лучше мотайте на ус следующую мысль: буду
чи лидером, вы можете подбирать подчиненных, исходя из своих знаний и интуитив
ной оценки кандидатов. А что если перевернуть ситуацию вверх дном и предоставить
вашим подчиненным возможность выбирать тип лидера? Предположим, что со
трудники могли бы интервьюировать нескольких лидеров и брать на работу того,
который им понравится. Ситуация, конечно, довольно сложная и странная, но за
дать себе такой вопрос необходимо — он имеет непосредственное отношение к ана
лизу лидером своей деятельности (см. главу 2) и отрицательным чертам пороч
ных стилей лидерства, которые мы обсуждали в предыдущей главе (см. главу 7).
Только вы и никто иной можете заполнить оставленное в заголовке пустое про
странство. Вводимый текст зависит от вашего представления о собственном стиле
1
2
See James Wallace and Jim Erickson, Hard Drive: Bill Gates and the Making of the Microsoft Empire (New
York: John Wiley & Sons, 1992).
Ibid., p. 61.
190 Ãëàâà 8 • Âîñõîä ëèäåðà
лидерства. Я также не могу говорить от лица ваших подчиненных и утверждать,
что из нескольких кандидатур они выбрали бы именно вас. Это вопросы личного
характера, на которые вы должны отвечать только сами. Впрочем, приведу одну
цитату, которая в данном контексте, полагаю, весьма полезна:
«Качества лидера нельзя почерпнуть из выступлений на семинаре или с полки
вашего любимого книжного магазина; лидерство неизмеримо в долларах и цен
тах. Лидерство происходит из деятельности в интересах команды — деятель
ности разумной и направленной на достижение стратегических коммерческих
целей. Поймите, что люди — это, по существу, средства производства, и ваш
успех зависит от уважения к вам со стороны подчиненных, которых вы при
званы защищать от происков внешних сил»1.
Предвижу иронию в связи с этой цитатой — ведь и мою книгу вы, наверное,
купили в местном магазине. Если это приобретение помогло вам осознать смысл
сочетания формы и содержания, значит, оно не было напрасным. «Происки» упо
минаются здесь не совсем в том смысле, в котором о них рассуждал Макиавелли;
тем не менее в духе здоровой паранойи вы должны готовиться к грядущим пере
менам и не позволять им застать вас врасплох.
Ðåçþìå
Не удивляет ли вас, что в книге, в которой всего десять глав, я подобрался к сути
лидерства лишь к концу восьмой? Дело в том, что продавая вам свое представле
ние о лидерстве, я совершаю своего рода пакетную сделку. Чтобы добраться до
подарка, нужно снять несколько слоев обертки. Кроме того, если уж мы заговори
ли об обертках, замечу, что я, не отставая от других авторов, попытался изложить
материал четко и понятно. Известно, что ясность изложения — один из определя
ющих факторов успеха книги. Впрочем, проницательный ум всегда сможет отли
чить форму от содержания. Вот почему многие считают, что телевизионные про
граммы, основанные на реальных событиях, выигрывают в сравнении с тради
ционными драматическими формами. По моему, такие программы — это не со
всем удачная попытка показать реальную жизнь, которая страдает из за своей зам
кнутости. Как говорится, недокументированная жизнь не стоит того, чтобы ее про
живать. (Это, типа, шутка.)
Ëèäåðñòâî ôîðìèðóåòñÿ â ïðàêòè÷åñêîé äåÿòåëüíîñòè
Основная мысль, которую я хотел донести в этой главе, сводится к тому, что путь
к лидерству индивидуален для каждого человека и зависит от конкретных условий:
компании, в которой вы работаете, сотрудников, которыми руководите, времени,
в котором живете. Без теории не обойтись, но лишь практика вдыхает в нее жизнь.
1
Don S. Olson and Carol L. Stimmel, The Manager Pool: Patterns for Radical Leadership (New York: Addi
son Wesley, 2002), p. 9.
Ðåçþìå 191
Через несколько лет вы, возможно, напишете собственную книгу или статью о ли
дерстве — это полезно хотя бы потому, что дает возможность упорядочить свой
опыт. И в этом контексте очень важно обращаться к практике документирования.
Если вы положительно относитесь к этому занятию, заведите дневник и фиксируй
те в нем свою деятельность. Если вам понравилась моя книга, можете рассказать
о ней знакомым. Тогда она станет бестселлером, и у меня появится возможность
больше публиковаться1. Я мог бы собрать присланные вами материалы в сборник
статей о лидерстве. Не подумайте, что я пекусь лишь о собственных интересах, —
я действую в соответствии с изложенной выше стратегией наставничества. В ны
нешней поре моей жизни она прочно вошла в мои лидерские будни.
Îòòàëêèâàéòåñü îò îñíîâíûõ ïðèíöèïîâ ëèäåðñòâà
Переходя к реальной практике лидерства, не забывайте фундаментальные прин
ципы, которыми я с вами поделился. Ими пользуются многие мои коллеги и учи
теля. Не жадничайте и делитесь с окружающими знаниями, которые, по вашему
мнению, правдивы. Рассказывая правдивые истории, вы сможете зафиксировать
накопленный опыт и утвердить его в своем характере.
Во всем, что вы делаете, необходимо соблюдать пять основных принципов ли
дерства.
Понимание. Определитесь с тем, куда вы идете.
Передача знаний. Делитесь своими знаниями — так, чтобы подчиненные все
поняли.
Делегирование. Общие задачи нужно решать общими усилиями.
Проверка. Проверяйте свои действия и то, что делают ваши подчиненные в кон
тексте достижения поставленных целей.
Участие. Погружайтесь в работу с головой — будьте примером для остальных.
Не забывайте о надстройке. Свое развитие основные принципы лидерства по
лучают в следующих областях деятельности.
Наставничество. Учите окружающих учить.
Вознаграждение. Награждая сотрудников за выдающиеся результаты, вы смо
жете создать ситуацию, в которой одни успехи естественным образом вылива
ются в другие.
Исправление. Помогая сотрудникам учиться на собственных ошибках, повы
шайте их квалификацию.
Предвидение. Предугадывайте проблемы, пока они не ударили по вашей ко
манде, — это станет хорошим стимулом для окружающих.
Адаптация. Совершенствуйтесь, извлекая уроки из собственных ошибок.
1
Я серьезно! Присылайте рассказы о своем пути на лидерском поприще по адресу HerdingCats@mind
spring.com.
192 Ãëàâà 8 • Âîñõîä ëèäåðà
×òî äàëüøå
В следующей главе мы поговорим об отношениях с начальством. Попутно вы
сможете оценить свои лидерские способности. Одно дело вести подчиненных
в заданном направлении, и совсем другое — самому следовать за боссом. Чтобы
изучить проблему лидерства в комплексе, нужно иметь опыт следования за лиде
ром. Знакомясь с материалом следующей главы, не забывайте принципы, изло
женные в главе текущей, и оценивайте, в какой степени их воплощает ваш на
чальник. Вероятно, из этих наблюдений вы сможете почерпнуть много полезного —
ведь, скорее всего, ваш шеф уже прошел через все трудности и радости, о которых
я вещал в этой главе, и неоднократно имел возможность пересмотреть и усовер
шенствовать свои лидерские навыки.
Г л а в а
9
Êàê óæèòüñÿ ñ íà÷àëüñòâîì
 ýòîé ãëàâå, ÷òîáû âûäåðæàòü ÷åòêóþ ïîâåñòâîâàòåëüíóþ ëèíèþ,
ÿ áóäó ãîâîðèòü íå î íà÷àëüíèêàõ, à î íà÷àëüíèöàõ. Åñòü ó ìåíÿ
è äðóãîå ñîîáðàæåíèå. Òðàäèöèîííî â íàøåé èíäóñòðèè äîìèíèðóþò
ìóæ÷èíû, à æåíùèíû ðàññìàòðèâàþòñÿ â ïðîöåññå ðàçðàáîòêè ïðîãðàììíûõ ñðåäñòâ íåñêîëüêî â äðóãîì ðàêóðñå. Âîçìîæíî, åñëè áû
â ïåðèîä ôîðìèðîâàíèÿ íàøåé îáëàñòè çíàíèé æåíùèíû áûëè â íåé
ïðåäñòàâëåíû áîëåå øèðîêî, íàì óäàëîñü áû èçáåæàòü íåêîòîðûõ
î÷åâèäíûõ îãðåõîâ, êîòîðûå âðåìÿ îò âðåìåíè ìû äîïóñêàåì.
Не пугайтесь названия этой главы, даже если ваши
отношения с вышестоящей инстанцией строятся не слиш
ком удачно. Осознав, какое давление испытывает на
чальница, вы сможете сделать свои отношения с ней
более конструктивными, извлечь из них пользу для са
мосовершенствования в роли лидера и развития способностей собственных под
чиненных. Не забывайте, что у нее, по видимому, тоже есть начальник и она не
раз ощущала себя в вашей шкуре.
Если отношения с начальницей у вас стабильно ровные, надеюсь, что идеи,
которые я намерен изложить в этой главе, окажут на вас сильное эмоциональное
влияние. Вы с вашей начальницей должны составить прекрасный альянс. Проч
ность и гибкость рабочих отношений с начальницей — это один из тех факторов,
которые способны ускорить движение к лидерству. Лидер тоже должен уметь сле
довать в четко заданном направлении; эти навыки помогут вам выстроить план
действий относительно собственных подчиненных в контексте решения установ
ленных вами и вашей начальницей приоритетных задач.
Êàê ïîíÿòü, ÷åì æèâåò âàøà íà÷àëüíèöà
Как легче всего сбалансировать отношения с начальницей? Все очень просто: пред
ставьте, что вы сами продвинулись вверх по карьерной лестнице. Возможно, вы
совершенно не собираетесь этого делать — в конце концов, если вы пришли в ру
ководящее звено из числа программистов, как это обычно и случается, вряд ли вы
194 Ãëàâà 9 • Êàê óæèòüñÿ ñ íà÷àëüñòâîì
испытываете неудовлетворенность своим положением. И тем не менее вообрази
те себе, что вы продвинулись до должности, в данный момент занимаемой вашей
нынешней начальницей. Попробуйте представить ожидания, которые в этом случае
вы предъявляли бы своим подчиненным. Если уж вы вынуждены выстраивать
совместную деятельность вместе с начальницей, этот и подобные ему вопросы
задавать себе совершенно необходимо.
Поймите меня правильно — воображать, как бы вы командовали своей началь
ницей, не стоит; просто представьте, что она управляет вами точно так же внима
тельно, как вы управляете сотрудниками своего отдела. Желание порадовать на
чальницу естественно. Впрочем, будьте осторожны: если не отдавать себе полный
отчет в своих мотивах, есть опасность в порыве служебного рвения забыть о необ
ходимости быть честным. Что заставляет начальников радоваться? Выполнение
выданных ими заданий в срок, без жалоб и нытья. Именнорезультаты должны
стать мерой оценки вашей деятельности, а отнюдь не успокаивающие речи, на
правленные лишь на то, чтобы просто слегка отсрочить приговор.
Принципы, которые я здесь излагаю, допускают незначительную корректиров
ку в зависимости от структуры конкретной компании. Впрочем, вы должны усвоить
основную мысль: чем выше положение в управленческой иерархии, тем больше
ответственность и тем шире область деятельности, на которую она распространя
ется. Вместе с ответственностью повышается потребность в делегировании, кото
рое в таком случае проходит уже несколько уровней бюрократии. Действительно,
цепочка делегирования, в которой вы исполняете роль одного из звеньев, крайне
трудно поддается организации и проверке.
×åì âûøå ïîëîæåíèå â óïðàâëåí÷åñêîé èåðàðõèè, òåì áîëüøå îòâåòñòâåííîñòü è òåì
øèðå îáëàñòü äåÿòåëüíîñòè, íà êîòîðóþ îíà ðàñïðîñòðàíÿåòñÿ.
Авторы книги «The Centerless Corporation»1 высказывают следующее наблю
дение: «В то время как размеры современных корпораций стремительно растут,
их управляемость в плане достижения заданных целей неуклонно падает». Имей
те в виду: ваша начальница пытается бороться с этой тенденцией. «Заданными
целями» должны проникнуться все сотрудники компании. Чем вы можете помочь,
чтобы достичь такого результата?
Несмотря на все разговоры о «децентрализованных» корпорациях и необхо
димости модернизации структуры корпораций, большинство из нас продолжает
работать в рамках иерархических структур, в которых один отчитывается перед
другим, другой — перед третьим и т. д. Субординация — это отнюдь не пустое сло
во. Сколько отчетов вынуждена подавать ваша начальница, а сколько — вы? По
пробуйте посчитать. Это — лишь один из тех факторов, которые формируют пред
ставление о роли начальницы в вашей рабочей деятельности. Вы ведь прекрасно
знаете по собственному опыту, что управлять людьми не так уж просто; то обсто
ятельство, что у нее значительно больше подчиненных, уже о чем то говорит.
1
Bruce A. Pasternack and Albert J. Viscio, The Centerless Corporation (New York: Simon & Shuster,
1998), p. 15.
×åñòíîñòü è ïðèíöèïèàëüíîñòü ïðîòèâ ïîäòàñîâîê è ëæè 195
И здесь математические расчеты не всегда приводят к верным выводам. Руково
дители, которые стоят в иерархии выше вас, ответственны за всех нижестоящих.
При общении с начальницей вы должны иметь это в виду. Ее уровень ответствен
ности значительно выше вашего.
×åñòíîñòü è ïðèíöèïèàëüíîñòü ïðîòèâ
ïîäòàñîâîê è ëæè
В предыдущем разделе я мельком упоминал о честности — не хотелось бы про
должать эту тему, но придется. При любой попытке утверждения реалистичных
сроков сдачи проекта честность вступает в противоборство с прожектерством.
Большинство компаний бредят маркетингом; срок выхода на рынок — их основ
ной приоритет. Для того чтобы сохранить положение на рынке, необходимо в про
цессе усовершенствования программных продуктов исходить именно из бизнес
требований. Такая ситуация накладывает на ваших сотрудников дополнительные
обязательства, которые, естественно, передаются и вам. Напряжение, испытывае
мое вашей начальницей, еще серьезнее — ведь, скорее всего, она тоже кому то под
отчетна. Эта цепочка подчинения — очень серьезный фактор; и будьте уверены,
утверждения о важности требований рынка совсем не преувеличены. Взять хотя
бы мощнейшую маркетинговую машину Microsoft — эту компанию можно не лю
бить, но с ее успехом не поспоришь1. Спросите директора любой компании или
группу заинтересованных лиц: хотят ли они такого же успеха, как Microsoft? Вряд
ли ответ будет отрицательным.
Находясь под влиянием рыночной конъюнктуры, компании нередко устанав
ливают сроки сдачи продуктов, не советуясь с руководителями вашего уровня.
Ситуации, когда утверждение бизнес плана предшествует окончательной форму
лировке коммерческих требований, случаются сплошь и рядом. В главе 3 я уже
говорил о различиях между реалистичными и нереалистичными планами проек
тов. Полагаю, соответствующие принципы следует воспроизвести и здесь. В иде
але планирование должно осуществляться в такой последовательности:
1. Утверждение коммерческих требований.
2. Создание проектного решения, допускающего успешную реализацию в про
дукте всех требований.
3. Макетирование проектного решения с целью выявления его недостатков и по
следующей корректировки проектного решения или требований.
4. Планирование проекта с учетом сроков разработки и тестирования.
Разработанный план позволяет с определенной уверенностью говорить о вре
менных рамках выпуска; исключительно на их основе можно давать какие либо
обещания представителям отдела продаж. Естественно, как и во всех проектах,
временные рамки выпуска должны быть обусловлены успешным бета тестирова
нием.
1
Ну то есть поспорить можно, но какой в этом смысл? Я много лет пользуюсь продуктами Microsoft
и не испытываю особых затруднений — полагаю, у вас та же ситуация.
196 Ãëàâà 9 • Êàê óæèòüñÿ ñ íà÷àëüñòâîì
Как известно, мир, в котором мы живем, несовершенен; иначе вряд ли было бы
столько разговоров о программистах, у которых под столами спальные мешки.
У вас, таким образом, есть единственный выход — научиться выживать в реаль
ных условиях1. При чем тут честность, спросите вы? При том, что вы должны осоз
навать нереалистичность поставленных перед вами задач в свете реальных усло
вий, примеры которых перечислены ниже:
несмотря на то что коммерческие требования сформулированы еще не полно
стью, в погоне за соблюдением неизвестно кем установленной даты выпуска
вы вынуждены приступать к проектированию немедленно;
из за неразберихи с требованиями вам приходится постоянно корректировать
проектное решение;
у вас не остается времени на макетирование, или, что еще хуже, недоработан
ный макет превращается в код;
единственный план, которым вы располагаете, заключается в том, чтобы, от
талкиваясь от установленной специалистами по продажам даты выпуска, пы
таться получить представление о реальных сроках разработки.
В любом случае вопреки объективной реальности вы должны всеми силами
стремиться к тому, чтобы закончить работу в срок. Юность нашей индустрии и дав
ление рыночных факторов заставляет нас совершать героические поступки. Та
ким образом, честностью я называю способность признаться самому себе в труд
ности задачи, но все таки попытаться ее решить. Вы со мной согласны? Если
согласны, присылайте резюме на мой адрес — такие, как вы, мне необходимы.
Еще пара слов насчет геройства2. В начале карьеры идея стать героем воодушев
ляет, однако реализуют ее немногие. На самом деле стремиться нужно к балансу
между ожиданиями и реальными действиями, исходя при этом из соображений
честности. Иначе говоря, если вы пару раз сорвете сроки, никто не удивится. Это
исправимые вещи. Значительно труднее справиться с привычкой давать невы
полнимые обещания. Если вы уж обещаете что то, не забывайте в полной мере
доносить до сведения начальства все те факторы, которые могут воспрепятство
вать реализации плана. Любые обязательства должны быть подтверждены в проек
те с некоторой долей уверенности, которая варьируется в зависимости от ситуа
ции. Восстановить репутацию значительно сложнее, чем исправить ошибки в вы
пущенном продукте.
Íà ñàìîì äåëå ñòðåìèòüñÿ íóæíî ê áàëàíñó ìåæäó îæèäàíèÿìè è ðåàëüíûìè äåéñòâèÿìè, èñõîäÿ ïðè ýòîì èç ñîîáðàæåíèé ÷åñòíîñòè. Âîññòàíîâèòü ðåïóòàöèþ çíà÷èòåëüíî ñëîæíåå, ÷åì èñïðàâèòü îøèáêè â âûïóùåííîì ïðîäóêòå.
Обратной стороной геройства является фатализм. Фаталист — это человек,
который неудачно пытался стать героем, а потом в ситуации, которую он создал
1
2
Рекомендую в этом контексте ознакомиться с предложениями Йордона (Yourdon) по вытягиванию про
ектов, изложенными в книге «Death march» (cм. библиографию).
Лишь те, кто живет в обществе, подобном нашему, могут претендовать на звание героев. Впрочем,счи
тайте, что вам повезло получить хорошую работу, и старайтесь выкладываться на все сто. Настоящие
герои умерли одиннадцатого сентября в попытках спасти невинных жертв.
сам, начинал винить судьбу. Если вам приходится иметь дело с нереальным про
ектом, необходимо отдавать себе отчет в том, что фактически вы и ваша команда
попадаете в условия, приближенные к боевым. Регулярная работа по ночам изма
тывает разработчиков, в результате страдает код. Не стоит вводить в проект новых
программистов — если это случится на поздней стадии разработки, вы рискуете
в очередной раз подтвердить закон Брукса1. Именно по этой причине на началь
ных этапах планирования проекта так важна честность (если, конечно, у вас есть
план).
Честность зависит от тщеславия и чувства собственного достоинства. Я уже
в том возрасте, когда каждое утро для удовлетворения тщеславия мне нужны лак
для волос, зеркало и время. Признаться, я лысею, и это — горькая правда. Я могу
пытаться это скрывать, но ведь все равно окружающие узнают!2 Аналогичным об
разом лучше высказать голую правду о сроках, чем сочинять сказки.
Êàê ïîìî÷ü íà÷àëüíèöå óäà÷íî
ñïëàíèðîâàòü ïðîöåññ
Начальница знает, что и когда нужно делать; вы специализируетесь на том, как
этого достичь. Так… кажется, я выразился не слишком ясно. Попробуем еще раз.
Как правило, планирование в масштабах предприятия проводится начальством;
вы же призваны заменить общие наметки детальным планом. Час от часу не лег
че, так? То то же. Планирование подчиняется формуле: два шага вперед, один
шаг назад. Процесс этот напоминает рекурсивную процедуру: нужно постоянно
«копать» стратегический план, наполняя его деталями, которые, кстати, вам же
и предстоит реализовывать. В этом отношении вы можете оказать начальнице цен
ную услугу — высказать свое экспертное мнение по поводу ее глобальных заду
мок. В планировании кропотливая работа оттесняет вдохновенные прозрения.
В некоторых компаниях отдел разработки рассматривается как производствен
ный цех, который, принимая на входе спецификации, в конечном счете выпуска
ет готовый продукт. Будь это правдой, я, наверное, предпочел бы сменить про
фессию и из наемного рабочего превратиться во владельца такой фабрики. Во
многих консалтинговых компаниях на полном серьезе рассуждают о «фабриках
программных продуктов». Большинство таких компаний базируются за океаном,
а выводы свои строят исходя из высокой стоимости и низкой окупаемости инвес
тиций — действительно, многие отделы разработки программного обеспечения
в американских компаниях демонстрируют такую динамику. В двух книгах Эд
варда Йордона (Edward Yourdon) — «Decline & Fall of the American Programmer»
(Yourdon Press, 1993) и «Rise & Resurrection of the American Programmer» (Yourdon
Press, 1996) — раскрываются причины, по которым в кругах разработчиков про
граммного обеспечения планирование зачастую проводится недостаточно тща
тельно или вообще игнорируется. Возможно, связано это с тем, что мы упорствуем
1
2
«Введение в запаздывающий проект новых сотрудников увеличивает время разработки» — см. Brooks,
op. cit., p. 25.
Если вы женщина, стали бы вы встречаться с типом, который, стараясь скрыть правду, обматывает го
лову последним оставшимся волосом, как тюрбаном? Не думаю. Хотя если вы знаете даму, которая на это
пойдет, дайте телефончик.
198 Ãëàâà 9 • Êàê óæèòüñÿ ñ íà÷àëüñòâîì
в восприятии программирования как одного из видов искусства1. Если бы мы под
готавливали запуск ракеты на Луну, уверяю вас — обойтись без планирования
было бы невозможно.
Кстати, скажу несколько слов об американской космонавтике. Как могло про
изойти, что в 1960 е годы, когда существующие программные средства уступали
уровню типичного современного карманного компьютера, нам удалось высадить
человека на Луну? Секрет в том, что причастные к этому проекту специалисты,
исходя из имеющихся инструментальных средств, планировали свою деятельность
с расчетом на успешный финал. В своих мемуарах, рассказывая о Центре управ
ления полетами, Джин Кранц2 (Gene Kranz) раскрывает принципы, которые, по
его мнению, определили заметные успехи подведомственной ему структуры.
Дисциплина. Способность лидировать, с одной стороны, и идти в заданном на
правлении, с другой. Понимание того, что для решения задачи необходимо,
прежде всего, совладать с собой.
Компетентность. Космические проекты не терпят небрежности и безразли
чия — требуется полная готовность к выполнению задания и тотальная уст
ремленность на успех.
Уверенность. Вера в себя и окружающих; сознание необходимости задушить
страх и неуверенность.
Ответственность. Понимание того, что поставленную задачу нельзя никому
передоверить; есть всего две альтернативы: либо сделать то, что требуется, либо
потерпеть фиаско.
Упорство. Нацеленность на преодоление возможных трудностей; последова
тельность в достижении цели, даже если для этого необходимо пройти по слож
ному пути.
Командные усилия. Уважение к способностям друг друга и их разумная эк
сплуатация; ощущение работы над общей целью и коллективной ответствен
ности за результат.
Далее Кранц утверждает, что «лучше попробовать и потерпеть неудачу, чем
приложить недостаточно усилий». Придерживаясь этих принципов, он разраба
тывал прекрасные планы — иногда слишком поспешно, но тем не менее ему это
удавалось. Он не мог действовать без планирования — в конце концов, на него
ложилась ответственность за человеческие жизни. Программные продукты, ко
нечно, никого не убивают, но неудачный результат разработки способен сломать
вашу карьеру вместе с карьерой начальницы3.
1
2
3
Каюсь, в этой книге я слишком вольно обращался с терминами «мастерство» и «искусство» и недостаточно
акцентировал ваше внимание на том, что разработка программных средств — это, как никак, инженерная
дисциплина. Но такой выбор был осознанным — посвятив долгие годы разработке аппаратных средств,
я на короткой ноге с прикладными научными дисциплинами. Я все же предпочитаю рассматривать нашу
отрасль как жанр искусства, хотя, конечно, признаю, что в определенных случаях без строгих научных
изысканий не обойтись. Более подробно об этом я поговорю в следующей главе.
Gene Kranz, Failure is Not an Option (New York: Simon & Schuster, 2000), p. 393.
Естественно, при разработке критически важных приложений ставки повышаются. Я до сих пор не
доверяю финансовым операциям через Интернет. Знаете, почему? Потому что я знаю тех ребят, кото
рые писали программы для этих операций.
Çíàéòå ñâîé ïîòîëîê 199
Применимы ли принципы Кранца в нашей области? Думаю, вполне, и мне
к ним даже нечего добавить. Это четкие, справедливые принципы, которые не
плохо бы записать на бумажке, приклеив ее к монитору. Как я уже неоднократно
говорил, совершенствование лидерских качеств повышает шансы на достижение
успеха, а в части планирования без лидерства не обойтись. Не стоит сваливать
эти обязанности на начальницу — не забывайте, что помимо вашего отдела ей,
скорее всего, подчинены несколько других. Представьте себя локомотивом ком
мерческих достижений компании. Если следовать этой аналогии, получается, что
вам, с одной стороны, требуются топливо и грамотная эксплуатация, с другой —
кто то должен жать на газ. Может быть, вы — свеча зажигания? Насколько резво
вы искрите? Хватает ли вашей увлеченности, чтобы зажечь искру энтузиазма сре
ди подчиненных?
Çíàéòå ñâîé ïîòîëîê
Вероятно, в планировании ваша начальница достигла больших успехов, чем вы.
В конце концов, почему она оказалась в своей должности? Скорее всего потому,
что за ней закрепилась репутация человека, который сочетает в себе навыки пла
нирования и исполнения. Кроме того, вполне возможно, что и во всем остальном
она более квалифицирована. В то же время одного она не может знать лучше, чем
вы, — вашей верхней планки. Если вы следите за моей мыслью с самого начала
книги (надеюсь, что это так), вспомните: в главе 2 мы говорили о том, как преодо
левать собственные слабости.
Рассмотрим аналогию из одной программы.
Обычно мы считаем, что в области технологии, инженерии, науки, програм
мирования — да чего бы то ни было! — достигли неплохих успехов. Люди с таким
самомнением зачастую ставят перед собой сложные задачи, испытывая тем самым
свой интеллектуальный уровень. Я давно играю в шахматы — мне это нравится,
хотя свои успехи я оцениваю сдержанно. Мои программные шахматы позволяют
устанавливать уровень квалификации противника, роль которого, естественно,
исполняет компьютер, — с тем, чтобы любой игрок мог играть в свое удовольствие.
Таким образом, если «человеческий» игрок хочет выиграть, он должен заменить
максимальный уровень квалификации более низким. Обращаясь к терминоло
гии этой игры1, назову восемь уровней квалификации:
1. Новичок.
2. Начинающий.
3. Простой.
4. Упрощенный.
5. Средний.
6. Сложный.
1
Chess Master 5000. Не думаю, что производитель будет сильно против, если я позаимствую из его иг
ры структуру меню — в конце концов, это устаревшая версия. Кстати, более свежую и, соответствен
но, более мощную версию мне одолеть пока что не удалось!
200 Ãëàâà 9 • Êàê óæèòüñÿ ñ íà÷àëüñòâîì
7. Специалист.
8. Чемпион.
Вашу квалификацию по части выполнения рабочих функций, очевидно, тоже
можно оценить в границах этого спектра. Квалификация начальницы, скорее все
го, выше. Одновременно на рынке идет борьба за звание чемпиона. При общении
с начальством вы не должны заблуждаться относительно уровня собственных зна
ний. Начальница выше оценит честное «не знаю», чем убедительное, на первый
взгляд, мнение, которое высказывается по незнанию проблемы.
Ïðè îáùåíèè ñ íà÷àëüñòâîì âû íå äîëæíû çàáëóæäàòüñÿ îòíîñèòåëüíî óðîâíÿ
ñîáñòâåííûõ çíàíèé. Íà÷àëüíèöà âûøå îöåíèò ÷åñòíîå «íå çíàþ», ÷åì óáåäèòåëüíîå,
íà ïåðâûé âçãëÿä, ìíåíèå, êîòîðîå âûñêàçûâàåòñÿ ïî íåçíàíèþ ïðîáëåìû.
Раз уж я упомянул шахматы, обратимся к стратегическому и тактическому
мышлению — очередным ориентирам, помогающим оценивать квалификацию.
В шахматах необходимы навыки стратегического планирования; тактики, как пра
вило, в них не выигрывают — за исключением, конечно, ситуаций, когда оба игро
ка торопятся закончить игру. В отношениях с начальницей всегда имейте в виду
эти два способа решения задач: стратегию и тактику. Скорее всего, в стратегиче
ском отношении она вас превосходит. Если это не так, постарайтесь ей помочь;
если же я прав, учитесь! Вероятно, она сможет лучше решать свои задачи, если
сконцентрируется на стратегии, а решение тактических вопросов поручит вам.
Ваше сотрудничество выгодно обеим сторонам.
Êàê îæèäàòü íåîæèäàííîñòü
Полагаю, ваше положение в компании таково, что стратегические решения прини
маются кем то сверху, а вам остается лишь проводить их в жизнь. В такой ситуации
трудно удержаться от ощущения бессилия. И действительно, кому понравится,
когда начальство ставит перед фактом очередных решений, которые невозможно
было предугадать? По выражению изобретателя современных вакцин Луи Пас
тер (Louis Pasteur), «шанс приходит только к тем, кто к нему готов». Напишите
эти слова на руке или приклейте бумажку с ними на монитор. Наша динамичная
индустрия регулярно подбрасывает своим деятелям разного рода сюрпризы. Точ
но так же любит поступать наше начальство — имейте это в виду и готовьтесь.
Как «подготовиться» к непредсказуемому? Хороший вопрос, на который нет
очевидного ответа. С одной стороны, вы должны постоянно пополнять свои зна
ния о технологических возможностях с учетом имеющихся и обещающих вскоре
появиться инструментальных средств. Для этого нужно держать в голове техно
логические новинки в самых разных областях. Эрудитами нам в сегодняшних ус
ловиях стать нереально, однако если много читать, разумно пользоваться Интер
нетом и обращать внимание на конъюнктуру рынка, справиться с поставленной
задачей можно. Выделяйте время на ознакомление с информацией, которая мо
жет потребоваться в будущем. Не увлекайтесь технологическими игрушками; на
блюдайте за новейшими течениями, которым следуют наиболее прогрессивные
компании, — если уж ваша организация не относится к их числу, это минимум
Êàê ïðåîäîëåòü áåçûíèöèàòèâíîñòü êîìïàíèè 201
того, что вы можете сделать. Обязательно следите за последними бета версиями
широко применяемых в вашей рабочей деятельности инструментальных средств.
В идеале, если ваша компания сможет нанять специалиста по исследованию рын
ка (а возможно, даже создать соответствующий отдел), ваши шансы на адекват
ную подготовку к будущим изменениям серьезно повысятся. Не стесняйтесь об
ращаться к помощи начальницы — скорее всего, она готова к изменениям лучше,
чем вы. (В разделе «Контролируйте свои слабости» главы 2, в частности, говорит
ся о чтении профессиональной литературы.)
Êàê ïðåîäîëåòü áåçûíèöèàòèâíîñòü êîìïàíèè
Более чем уверен, что ваша должность относится к среднему звену руководства,
а ваша начальница, соответственно, находится в иерархической системе чуть вы
ше. И знаете что? У вас есть преимущество, о котором вы, возможно, даже не по
дозреваете: вы более восприимчивы к тенденциям в мире разработки программных
продуктов за пределами конкретного предприятия. Благодаря своему высокому
посту ваша начальница, скорее всего, хуже ориентируется в этих вопросах. Такая
ситуация, к сожалению, складывается во многих компаниях, и справиться с ней
зачастую нет никакой возможности. Происходит она от чрезмерного внимания,
которое менеджеры высшего звена уделяют существующей иерархии. Они тратят
массу усилий, чтобы контролировать деятельность нижестоящих сотрудников,
упуская при этом ситуацию в индустрии в целом.
Посмотрим, что думает о том, как работают представители менеджмента сред
него звена, Энди Гроув:
«Старшие менеджеры стали таковыми за счет своих профессиональных до
стижений. Со временем такие люди осознают свои достоинства и, исходя из
этого, берут на себя лидерские функции. Таким образом, нет ничего удиви
тельного в том, что и на руководящих постах они продолжают эксплуатиро
вать стратегические и тактические приемы, наработанные в течение карьеры, —
в особенности в ”чемпионский сезон“»1.
Гроув называет такое состояние «инерцией успеха»; оно представляет серьез
ную опасность. Вы, кстати, тоже не застрахованы от этой болезни, так что вещи,
которые я рассказываю о вашей начальнице, можете экстраполировать на себя.
Ñëåäèòå çà òåíäåíöèÿìè â îòðàñëè
Регулярно оценивайте состояние дел вашей компании в контексте рыночной кон
куренции. Замечайте действия конкурентов и сравнивайте их с позицией соб
ственной компании. Возможно, ваша начальница настолько погружена в свою
текущую деятельность, что даже не допускает мысли о возможности ухудшения
положения на рынке. В комплекс обязанностей технического лидера входит, в част
ности, отслеживание новейших тенденций в индустрии и анализ их влияния на
процесс разработки. Если начальница довольна положением дел, это совершенно
не значит, что вы должны с ней соглашаться. Если вы видите, что какой то аспект
деятельности компании можно улучшить, подумайте, как это сделать, и донесите
1
Grove, op. cit., p. 127.
202 Ãëàâà 9 • Êàê óæèòüñÿ ñ íà÷àëüñòâîì
ваши соображения до начальства. Для обоснования своих взглядов можете при
вести ряд примеров из опыта изучения новых методик разработки и анализа ве
роятности грядущих революций.
Помимо прочего, необходимо следить за признаками пренебрежения со сторо
ны начальства проблемами, с которыми вы сталкиваетесь, — это особенно важно,
если компания находится в стадии кризиса. Кризис приходит в высокотехноло
гичные компании в том случае, если они сначала отказываются повиноваться ве
яниям времени, а затем внезапно сталкиваются с необходимостью всеобщей мо
дернизации. Выйти из кризиса компания, конечно, должна достойно — это важно
и для нее, и для вас. Вы находитесь в уникальном положении — более адекватно
воспринимая изменения окружающего мира, вы можете раскрыть глаза началь
нице на то, чего она, ослепленная своими былыми успехами, не видит. Естествен
но, доносить свое мнение нужно осторожно и вежливо, но в то же время уверенно.
Вы стоите чуть ли не ближе всех к линии фронта; вовремя сообщать другим пред
ставителям компании о допущенных ошибках необходимо — ведь от этого зави
сят и ваши дальнейшие успехи.
Âû ñòîèòå ÷óòü ëè íå áëèæå âñåõ ê ëèíèè ôðîíòà; âîâðåìÿ ñîîáùàòü äðóãèì ïðåäñòàâèòåëÿì êîìïàíèè î äîïóùåííûõ îøèáêàõ íåîáõîäèìî — âåäü îò ýòîãî çàâèñÿò
è âàøè äàëüíåéøèå óñïåõè.
Ýêñïåðèìåíòèðóéòå ñ íîâûìè ìåòîäàìè è ïðèåìàìè
Технический лидер должен апробировать новые методы реализации коммерче
ских задач. Цель такого рода действий — не в том, чтобы выбрать из нескольких
альтернатив. Главное — найти способ снизить издержки разработки и/или повы
сить ценность предлагаемых компанией продуктов и услуг. Иногда начальство
ставит перед нами задачу, детали которой еще только предстоит утрясти. Чув
ствуете, что инерция берет верх? Попробуйте что нибудь новое — просто чтобы
встряхнуться. Не забывая об осторожности, все же проявляйте лидерские каче
ства: если вы понимаете, что та или иная новация способна улучшить результаты,
смело обращайтесь к ней.
Возможно, вашему начальству интересен только конечный результат. Вам, оче
видно, тоже, но ведь им проблема не ограничивается! Если за счет внедрения новых
методов или инструментов можно сократить срок разработки на 10 %, а издерж
ки — на 20 %, значит, имеет смысл пойти на риск. Если попытка окажется удачной,
не забудьте объяснить начальнице, каким образом вы добились успеха. Она оценит
старания, ваш статус в ее глазах повысится, и последствия могут быть самыми что
ни на есть радужными — как для компании в целом, так и для вас в частности. Это
лучший способ стать героем — значительно лучше тех, о которых я говорил ранее.
Ó÷èòåñü ÷óâñòâîâàòü âðåìÿ
Корпоративная инерция приводит к тому, что когда экономические или техноло
гические условия диктуют потребность в переменах, сотрудники компании их
попросту не замечают. Если ваша начальница знает, что такое успех, вполне веро
ятно, она чувствует себя неуязвимой и считает, что приспособиться к изменениям
Êàê ïðåîäîëåòü áåçûíèöèàòèâíîñòü êîìïàíèè 203
очень просто. Может, она и права, но, в конце концов, это не так уж сложно —
следить за признаками перемен.
Íå çàáûâàéòå, ÷òî èíòåðåñû êëèåíòà íà ïåðâîì ìåñòå
Есть и другой вид инерции, который в технологичных компаниях происходит от
чрезмерного внимания к методам реализации в ущерб результату. В конце кон
цов, вы призваны создавать продукты и услуги, которые удовлетворяют потреб
ностям клиентов. Посмотрим, что думает по поводу поддержки клиентов один из
лидеров нашей индустрии.
«Лучшая поддержка клиентов — это отсутствие поддержки клиентов. Да да,
все правильно, потребности в хорошей поддержке клиентов просто не должно
возникать. Цель должна быть такой: шаг за шагом совершенствовать продук
ты и услуги, чтобы клиент без посторонней помощи легко мог их использовать
и в них разобраться. Ориентированные на клиента фирмы, если они хотят до
биться успеха, должны реализовывать такие технологии, которые позволяют
глубже понять потребности клиентов. В результате такой практики компания
получает возможность выпускать продукты и услуги, действительно необхо
димые клиентам. Сообщаю всем зацикленным на окупаемости инвестиций: на
чальные капиталовложения в поддержку клиентов позволяют впоследствии
существенно снизить издержки на поддержку продуктов (чему способствуют
сбор и анализ информации о клиентах)»1.
Если упустить из виду признаки технологической инерции, вы рискуете на
рваться на ситуацию, когда из за пренебрежения к потребностям пользователей
после выхода на рынок последнего «чудесного» продукта на корпоративную служ
бу поддержки клиентов обрушится шквал звонков. Чрезмерное увлечение инстру
ментарием чревато потерей внимания к конечным пользователям. Современные
технологии крайне сложны, но в то же время они призваны избавить пользовате
лей от лицезрения деталей реализации.
В период планирования следующего продукта попросите начальницу предо
ставить вам более свободный доступ к маркетинговым данным. Если она отнесется
к вашему предложению легкомысленно, обратите ее внимание на необходимость
анализа рыночной конъюнктуры — в конце концов, именно для этого существуют
отделы продаж. Я уже говорил о том, что сроки сдачи продуктов нередко обуслов
ливаются маркетинговыми соображениями — но, с другой стороны, этот фактор
носит прогрессивный характер. Анализ рыночной ситуации существенно рас
ширяет охват аудитории, на который в качестве коммерческого решения может
претендовать тот или иной продукт (или услуга). Прошлогодние соображения по
поводу требований рынка бесполезны. Сведения о потребностях, которые пользо
ватели испытывают сегодня и будут испытывать завтра, должны быть такими же
свежими, как и технологии, позволяющие их реализовать.
1
См. статью Челлис Ходж (Challis Hodge) «Smoothing the Path» по адресу http://www.webtechniques.com/
archives/2001/11/hodge/. Ходж — основатель и генеральный директор HannaHodge, — чикагскойком
пании, занимающейся изучением взаимодействия пользователей с системами. Кроме того, он разра
ботал план преподавания дисциплины «проектирование интерфейсов» для Висконсинского универ
ситета и возглавил разработку пользовательских интерфейсов для корпоративных веб решений ком
пании IBM.
204 Ãëàâà 9 • Êàê óæèòüñÿ ñ íà÷àëüñòâîì
Ðåçþìå
Итак, я упомянул о некоторых областях взаимоотношений с начальством, на ко
торые вам надлежит обратить особое внимание. Основная ваша цель, по моему,
должна состоять в том, чтобы наладить с боссом конструктивное взаимодействие,
от которого выиграют обе стороны. Ниже я привожу краткий перечень наиболее
важных моментов этой стороны вашей деятельности.
Войдите в положение начальницы — она в своей работе подвергается серьез
ному давлению. Первой реакцией на ее замечания должно быть согласие, од
нако если у вас есть разумные и обоснованные предложения, выскажите их.
Честность в суждениях в любом случае предпочтительнее нереалистичных обе
щаний — пусть даже она иногда приводит к не слишком приятным последствиям.
Помогайте начальнице в вопросах планирования. Настаивайте на необходи
мости разработки реалистичных планов и прилагайте максимум усилий к их
реализации.
Если вам нечего противопоставить замечаниям начальницы, признайте пора
жение. Не стоит вешать ей лапшу на уши в попытках замаскировать собствен
ные огрехи.
Будьте готовы к непредвиденным изменениям — чем лучше вы будете осве
домлены, тем проще будет с ними столкнуться. Иногда неожиданные решения
исходят от начальства, в иных случаях — обусловливаются внешними факто
рами. Тщательная подготовка есть залог ваших успехов1.
Следите за признаками инерции в самом себе и в начальнице. Если она отри
цает очевидную потребность в изменениях, старайтесь спасти положение, пока
не поздно.
Чтобы окончательно закрыть тему взаимоотношений с начальницей, скажу еще
одну вещь. Обращайтесь с ней так, как хотели бы, чтобы обращались с вами. Это
золотое правило, которое, хоть и ассоциируется с воскресной школой, работает
во всех сферах человеческой деятельности.
Êîíåö óæå áëèçêî
Не карьеры, а книги. Следующая глава будет последней. В ней рассматриваются
самые разные вопросы, которым в предыдущих главах было уделено недостаточ
но внимания или которые вообще не упоминались. Материал книги я решил струк
турировать по тематическому принципу — в соответствии с различными облас
тями деятельности, с которыми менеджеру приходится сталкиваться каждый
божий день. Следующая же глава, по большому счету, бессистемна. В ней вы,
в частности, познакомитесь с необычными для руководителя программистов про
блемами, выходящими за рамки повседневной деятельности.
1
Это «переработка» известного высказывания Пастера (Pasteur): «шанс приходит только к тем, кто
к нему готов». Авторство парафраза принадлежит не мне — впервые я его услышал в детстве из уст
отца.
Г л а в а
10
Ñëîâà áåç ïåñíè
В целом разработка программных продуктов носит ли
нейный характер. Это проявляется даже тогда, когда
применяется итерационный процесс. В любом случае
переход от одного этапа к другому логичен. Руковод
ство процессом разработки, напротив, представляет со
бой нелинейную область деятельности. Вы постоянно
вынуждены переходить от одной проблемной области
к другой, причем решения, имеющие ценность в одной
из таких областей, могут не иметь никакого смысла в
любой другой. Таким образом, лучшее, что вы може
те сделать, — это привлечь весь свой интеллектуальный
ресурс к решению текущих проблем, не забывая при этом про конечную цель: вы
вести подчиненных из состояния хаоса и заставить их двигаться в одном направ
лении. Такую стратегию, наверное, можно обозначить как «жизнь над краем про
пасти» — думаю, именно в таком состоянии вы проводите многие дни на работе.
Название данной главы выражает вот это самое состояние. Отчасти это пере
кличка с традицией композиторов эпохи романтизма, которые широко эксплуа
тировали жанр песни без слов (к таковым, в частности, относится Мендельсон).
Мне кажется, из всего классического репертуара эти композиции — чуть ли не
самые мелодичные. Смысл этой главы, по большому счету, в обратном: общая тема
отсутствует, а отдельные партии довольно сложно назвать гармоничными. Мо
жет показаться, что в этой главе я собрал все темы, которые по тем или иным
причинам не нашли отражения в предыдущих главах, — и это ощущение правиль
но. Впрочем, такую бессистемность можно обосновать и по другому, более хит
ро — дело в том, что иногда наша работа производит впечатление совокупности
ничем не связанных действий. Бывает, нам даже приходится разбираться с про
блемами, способы решения которых в предыдущем опыте отсутствуют. Вот в этом
направлении я и выстроил главу1. Надеюсь, вопросы, которые в ней поднимают
ся, внесут некоторую ясность в ваши обязанности.
1
Помимо всего прочего, я опасался, что глава под названием «Разное» не вызовет должного читательского
интереса.
206 Ãëàâà 10 • Ñëîâà áåç ïåñíè
Ðàñïðåäåëåííàÿ ðàáî÷àÿ ñèëà
Современная корпоративная культура зачастую не оставляет места для геогра
фической централизации групп разработчиков. Финансовые соображения, нали
чие выдающихся особо талантливых специалистов, равно как и традиции кон
кретной компании, — все это иногда приводит к тому, что ваши подчиненные, хотя
и образуют единую группу, фактически работают в разных местах. Если сотруд
ники находятся в разных зданиях или даже в разных часовых поясах, обеспечить
гармоничное сочетание сотрудничества с уединением, что является основным фак
тором продуктивной деятельности группы, не так то просто1. Если среди ваших
подчиненных есть такие, которые один или два раза в неделю общаются с осталь
ными на телеконференциях, вам не обойтись без специальных методов, позволя
ющих контролировать их продуктивность.
Åñëè ñîòðóäíèêè íàõîäÿòñÿ â ðàçíûõ çäàíèÿõ èëè äàæå â ðàçíûõ ÷àñîâûõ ïîÿñàõ,
îáåñïå÷èòü ãàðìîíè÷íîå ñî÷åòàíèå ñîòðóäíè÷åñòâà ñ óåäèíåíèåì, ÷òî ÿâëÿåòñÿ
îñíîâíûì ôàêòîðîì ïðîäóêòèâíîé äåÿòåëüíîñòè ãðóïïû, íå òàê-òî ïðîñòî.
Ñóòü ïðîáëåìû
Если вам удается успешно сочетать сотрудничество с уединением, процесс разра
ботки существенно упрощается.
Уединение. Способность работать, не отвлекаясь на внешние раздражители,
в условиях, допускающих абстрактное мышление.
Сотрудничество. Обмен предложениями на очной встрече вплоть до выработ
ки консенсуса во мнениях всей группы или нескольких программистов, рабо
тающих над решением одной задачи.
Группа, в которой удовлетворяются две вышеупомянутые потребности, спо
собна работать крайне продуктивно. Для написания качественного кода необхо
дим баланс между этими условиями.
В контексте распределенных групп, в которых одни сотрудники работают дома,
другие трудятся в офисе вместе с остальными не связанными с ними функцио
нальными обязанностями специалистами, третьи образуют более мелкие группы,
также работающие удаленно, обеспечить сотрудничество и уединение довольно
трудно. Одни специалисты, не испытывающие недостатка в уединении, будут ли
шены средств продуктивного сотрудничества. Другие могут, с одной стороны, ис
пытывать нехватку уединения, а с другой — активно общаться с чужими с точки
зрения выполняемых обязанностей людьми. Проблемы, которые возникают в по
добных ситуациях, можно обобщенно сформулировать следующим образом.
Решения, которые при условии географической централизации принимаются
за считанные минуты, растягиваются на многие часы и даже дни.
1
Непосредственная проверка деятельности и продуктивности персонала заме
няется взаимодействием с сотрудниками по телефону и электронной почте.
О сотрудничестве и уединении мы говорили в главе 4.
Ðàñïðåäåëåííàÿ ðàáî÷àÿ ñèëà 207
Таким образом, хрестоматийный принцип руководства «доверяй, но проверяй»
не соблюдается.
Техническое проектирование осуществляется в основном не в интерактивном
режиме, а посредством документов. Документы же должны быть не средством,
а результатом сотрудничества. Из за ограничений по времени этап проекти
рования растягивается или вообще пропускается.
Сотрудники группы лишены чувства работы в единой атмосфере. Возможно
сти для выстраивания дружеских отношений отсутствуют.
Виртуальное рабочее пространство формируется средствами электронной по
чты и службы мгновенной передачи сообщений. При всей своей полезности
они не заменяют очного взаимодействия.
Большую часть времени вы, руководитель, проводите с телефонной трубкой
в руках.
Некоторые из вышеупомянутых проблем проявляют себя даже при условии
географической централизации, однако руководитель, вынужденный координи
ровать действия сотрудников, работающих в разных местах, сталкивается с ними
в наихудших проявлениях.
Ðåøåíèå
Если провести централизацию нет никакой возможности, значит, придется адап
тировать ваш стиль руководства к создавшимся условиям. Как я говорил в гла
ве 1, адаптация — это тот навык, без которого руководителю программистов не
обойтись. Рассмотрим, как он проявляется в некоторых аспектах деятельности
руководителя в условиях распределенной группы.
Ïëàíèðîâàíèå
Во первых, вы должны тщательно продумать вопрос распределения задач. Это
невозможно без предварительного планирования проекта, позволяющего выде
лить в его рамках отдельные блоки, которые можно распределить между подчинен
ными с поправкой на недостаток сотрудничества. Конечно, лучше всего детально
планировать все проекты, но в случае с распределенной группой эта проблема
приобретает особую актуальность.
Ýòî íåâîçìîæíî áåç ïðåäâàðèòåëüíîãî ïëàíèðîâàíèÿ ïðîåêòà, ïîçâîëÿþùåãî âûäåëèòü
â åãî ðàìêàõ îòäåëüíûå áëîêè, êîòîðûå ìîæíî ðàñïðåäåëèòü ìåæäó ïîä÷èíåííûìè
ñ ïîïðàâêîé íà íåäîñòàòîê ñîòðóäíè÷åñòâà.
Если вам не удастся четко сформулировать отдельные задания, на их уточне
ние уйдет гораздо больше времени, чем обычно, — просто в силу удаленности от
сотрудников. Кроме того, вы должны спланировать деятельность персонала та
ким образом, чтобы результаты его работы легко стыковались. В таких условиях
предпочтение нужно отдавать компонентной архитектуре — если, конечно, она
вписывается в корпоративную стратегию. Конструирование программных продук
тов, таким образом, должно походить на сборочный конвейер, на котором каждая
деталь идеально стыкуется со всеми остальными. Хороший принцип, который
208 Ãëàâà 10 • Ñëîâà áåç ïåñíè
неплохо было бы реализовать. Это вполне возможно, хотя и требует значитель
ных усилий по части планирования и проектирования.
Вообще то планирование, проводящееся на ранних этапах разработки любого
проекта, предполагает очное взаимодействие. Иначе говоря, чтобы приступить
к созданию проектного решения, по крайней мере один раз вам придется собрать
всех сотрудников в одном месте. Это недешево, но временные затраты на проек
тирование по электронной почте или по телефону оказываются значительно се
рьезнее. Постарайтесь во время этого сеанса планирования решить две задачи:
утвердить основы проектного решения и сделать первые шаги в направлении фор
мирования команды. Полезно в этом смысле где то раз в год выезжать вместе с со
трудниками на отдых в экзотические страны. Впрочем, вполне возможно, что, уз
нав цены на авиабилеты «туда и обратно», вы решите, что куда мудрее будет
развернуть за те же деньги каналы для проведения видеоконференций или, на
пример, заказать какую нибудь хитрую систему, которая могла бы отображать
электронное табло на одном мониторе и картинку нескольких групп на другом.
Конечно, все подобные экономические вопросы нужно решать исходя из бюдже
та. В любом случае, пользуясь имеющимися у компании средствами, вы должны
поощрять взаимодействие участников группы.
Âçàèìîäåéñòâèå
Большое человеческое спасибо Александру Грэму Беллу (Alexander Graham Bell)!
Телефон значительно облегчил для нас двустороннюю связь в реальном времени.
Правда, полагаю, что Белл воскликнул «Поди ка сюда, Ватсон!», просто утомив
шись от своего аппарата и решив, что лучше переговорить с помощником с глазу
на глаз. Если бы все ваши подчиненные находились в одно время в одном месте,
планировать распорядок дня было бы гораздо проще. Тем не менее, если, конеч
но, вы не сводите все взаимодействие к общению по электронной почте, имейте
в виду, что в условиях децентрализации группытелефон представляет собой за
метную ценность. Если вы можете себе позволить организацию регулярных ви
деоконференций, качество взаимодействия, несомненно, повысится. Впрочем,
далеко не все компании на это способны. При наличии канала с достаточной про
пускной способностью можно разориться на веб камеры и соответствующее про
граммное обеспечение. Замечу, что с этими средствами мне не удалось добиться
сколько нибудь заметных успехов.
Естественно, в большинстве географически рассредоточенных групп электрон
ная почта выступает в роли основного средства взаимодействия. Для менеджера
в практическом смысле это означает, что на проверку новых писем приходится
тратить значительную часть рабочего дня. Но ведь у вас много других админи
стративных обязанностей, а значит, нужно учиться отвечать на письма как можно
быстрее. Попытайтесь ограничить переписку по электронной почте темами, кото
рые можно адекватно выразить в письменной речи или на схемах. Все дискуссии
следует проводить по телефону, а для решений, требующих документирования,
вполне подойдет электронная почта.
Невзирая на все недостатки документно ориентированного процесса проек
тирования, скорее всего, именно на нем вы остановите свой выбор. Кроме того,
полезен в данном контексте метод проектирования по контракту, подразумеваю
Ðàñïðåäåëåííàÿ ðàáî÷àÿ ñèëà 209
щий первоочередное (в самом начале периода проектирования) создание откры
тых интерфейсов объектов, с тем чтобы впоследствии их можно было без труда
разработать. Этот метод полезен даже в условиях централизации группы, а уж
если один разработчик трудится в Калифорнии, а другой — где нибудь в Новой
Англии, соглашение по части взаимодействия компонентов и их способности
к взаимодействию выходит на первый план. Купите качественное программное
обеспечение для совместной работы и задействуйте его в роли библиотеки доку
ментов. За рыночную нишу программных продуктов для совместной работы со
ревнуются несколько производителей, и это вам на руку — следите за их послед
ними разработками1.
Ïðîâåðêà
В том что касается проверки результатов сотрудников децентрализованной груп
пы, ваши обязанности весьма осложняются. Из за разницы временных поясов вам,
вероятнее всего, придется удлинить свой рабочий день. Такое решение — факти
чески единственный способ эффективной организации в данных условиях — тре
бует от вас выносливости. Если вам приходится ежедневно проводить на работе
по 12 часов, не забывайте о том, что вы живой человек, и кроме профессии в жиз
ни есть еще кое что. Рекомендую взять за правило при первой возможности де
лать перерывы и посвящать их личным делам — в противном случае вы вряд ли
долго протянете.
Удаленный мониторинг персонала — дело ненадежное. Бывает, проходишь за
спиной сотрудника, который вместо работы шатается по Сети, и спрашиваешь:
«А почему не работаешь?!» Ну, он, конечно, отвечает: «Знал бы, что вы рядом, при
нялся бы за работу!» Ситуация, на первый взгляд, забавная, удачно характеризу
ет особенности роли «виртуального шефа». В отсутствие начальника люди начи
нают валять дурака — это в природе человека. Как с этим бороться? Сравнительно
эффективный мониторинг возможен только при наличии формального плана сда
чи сотрудниками результатов и при условии тщательной проверки его выполне
ния. Структура распределения работ в данном случае должна быть мельче, чем
обычно, — так вы сможете с большей уверенностью предотвращать отклонения от
графика разработки проекта. Для выполнения контрольной функции вам опять
же понадобятся телефон и электронная почта. Заставьте сотрудников присылать
еженедельные отчеты (а в исключительных случаях — даже ежедневные).
Можно также обратиться к решению в духе Оруэлла — оснастить рабочие стан
ции разработчиков программами дистанционного мониторинга, позволяющими
в любой момент видеть их экран. Сами сотрудники, естественно, должны знать,
что их компьютеры «прослушиваются», и если уж необходимость плотного сле
жения за каким то деятелем назрела, это решение себя оправдывает. Правда, надо
сказать, оно совсем не способствует укреплению доверительных отношений — ско
рее, напротив, вызывает негодование. Поэтому прежде чем прибегать к подобным
мерам, хорошо подумайте — стоит ли.
1
См. http://www.eroom.com, http://www.fox.se/english/starteam/starteam_version_control.htm и другие
предложения от IBM и Symantec.
Ëè÷íûå êîíòàêòû
Чем чаще вы будете посещать своих сотрудников в их привычных рабочих усло
виях, тем выше шансы на построение полноценной команды. Обозначая свое при
сутствие на рабочем месте, вы способствуете развитию у сотрудника чувства уча
стия в коллективной деятельности и придаете вес своему лидерству в остальное
время. На подобные визиты уходит много времени, да и не бесплатно это, однако
таким способом вы сможете смягчить некоторые недостатки децентрализации.
Êóëüòóðíûé ôàêòîð â ìåíåäæìåíòå
Америка — настоящий плавильный котел народов мира; нет — точнее, наверное,
будет сказать «культурный винегрет». И, надо заметить, программировать умеют
не только американцы. Научиться руководить сотрудниками, относящими себя к
разным национальностям и культурам, не так уж просто. Имея дело с неоднород
ным в культурном отношении персоналом, вы должны в первую очередь видоиз
менить привычные методы взаимодействия и мотивирования. Стремитесь к нео
фициальному общению с представителями иных народов — интересуйтесь их
семейными обычаями и культурными традициями. Так вы сможете добиться от
них большего рвения; кроме того, видя, что вы пытаетесь вникнуть в их особое
миропонимание, программист, скажем, из России [где это?] сможет почувство
вать свою ценность в команде.
ßçûê è êóëüòóðà
Работая с представителями разных культур, вы должны привести свою речь к оп
ределенному стандарту. С чужаками нельзя общаться так же, как с корешами из
соседнего двора, — не выйдет! Структуры речи, общераспространенные разговор
ные стили и даже язык тела — во всех этих отношениях между разными культура
ми наблюдаются серьезные различия. Заставьте себя говорить медленнее — пой
мите, что факт употребления английского как второго языка еще не означает
знания американского сленга, адекватного восприятия привычки к небрежному
построению предложений и следования вашему ходу мысли, выраженному в сло
вах. Даже британский английский в некоторых моментах существенно (и ради
кально!) отличается от американского1.
Íåëüçÿ îáùàòüñÿ ñ ÷óæàêàìè òàê æå, êàê ñ êîðåøàìè èç ñîñåäíåãî äâîðà, — íå âûéäåò!
1
Не говорите англичанину про богатый (rich) пользовательский интерфейс. Он обязательно подумает,
что интерфейс слишком дорогостоящий.
Êóëüòóðíûé ôàêòîð â ìåíåäæìåíòå 211
Есть и другие культурные различия, которые иногда удивляют, а иногда ка
жутся достойными включения в стандартную корпоративную практику. Знаете
ли вы, например, что среди филиппинцев публичное рукопожатие служит при
знаком дружбы? Когда индиец первый раз приходит в гости, он обязательно при
носит подарок. Австралийская культура, на первый взгляд, во многом пересека
ется с американской, но знаете ли вы, в каких количествах австралийцы поедают
овощную пасту?2 А как насчет традиционных американских праздников? Уверяю
вас: человек, родившийся в Бангалоре, в День благодарения будет, как обычно,
работать. Вы должны выяснить все существующие различия и стать гражданином
мира — усваивайте лучшие черты всех культур и включайте их в свой «джентль
менский набор» лидера.
Ìîòèâàöèÿ ÷óæàêîâ è êîíòðîëü íàä íèìè
Мотивация программистов деньгами среди стандартного набора американс
ких приемов менеджмента является «наименьшим общим кратным». С другой
стороны, имейте в виду, что деньги — это наименее эффективный способ
построения командной атмосферы в многокультурной среде. Что же делать?
Проанализировать все факторы, способные стимулировать к работе существу
ющую команду или новых сотрудников, которых вы только собираетесь
привлечь. По результатам недавнего опроса 100 наемных работников, не яв
ляющихся гражданами США, Дин Бетменг (Dene Bettmeng) делает следую
щие выводы.
«Многие сотрудники рассматривают в качестве основных преимуществ рабо
ты в американских компаниях корпоративную культуру и корпоративные пра
вила, а также технологическую оснащенность. В частности, их привлекают пер
спективы карьерного роста, заработная плата и льготы, равно как и возможность
изучать и применять новые технологии. Все эти люди считают, что работать
в компании, расположенной в США, в целом предпочтительнее, чем в какой
бы то ни было другой стране. Помимо вышеперечисленных преимуществ, они
ценят политическую стабильность, напряженный ритм деятельности и команд
ный дух»2.
Как и в любой команде, руководителю необходимо составить представление
о своих разношерстных подчиненных — иначе он не сможет преуспеть в каче
стве лидера. Наличие в подведомственной группе представителей различных
культур усложняет познание, но в то же время дает неоценимый (в зависимо
сти от ситуации, положительный или отрицательный) личный опыт. Сталкива
ясь с трудностями в поисках свежих американских талантов, мы обращаем вни
мание на заморских консультантов. Иной раз ставка на них себя оправдывает, но
бывает и по другому. В некоторых культурах споры с начальником (или даже
уточнение его позиции) не поощряются. В результате начальник утверждается во
мнении, что подчиненный понял, чего от него хотят, а в том, как жестоко ошибся,
убеждается, когда уже слишком поздно. В этой области нужно соблюдать осто
рожность.
1
2
Хотя она чем то напоминает арахисовое масло, уверяю вас, совсем не так вкусна!
Из отчета на конференции Network World Fusion (http://www.nwfusion.com/careers/2001/0402man.html).
212 Ãëàâà 10 • Ñëîâà áåç ïåñíè
ÊÎØÀ×ÜÈ ÐÀÇÁÎÐÊÈ — ÈÍÎÑÒÐÀÍÍÛÉ ËÅÃÈÎÍ
Мы решили как можно быстрее заполнить вакансии в трех проектах за счет привлече
ния 12 иностранных консультантов. Кандидаты ниже экспертного уровня нас не инте
ресовали — по крайней мере, именно таким образом мы сформулировали свои требова
ния. Как выяснилось, все специалисты, которых нам подобрали, приехали из Индии —
страны, стремительно укрепляющей свои позиции по части квалификации программи
стов. Мне предстояло составить из них группы в соответствии со специальностями
и приступить к работе над проектами. Я участвовал во всех интервью, отбирая кандида
тов по специальности. К сожалению, все интервью проводились по телефону — тут то я
и получил первый урок. Естественно, осознать, какую головную боль я себе организо
вал, мне удалось лишь тогда, когда сформированные группы принялись за работу.
Урок 1. Впоследствии выяснилось, что для телефонных интервью консультантам пре
доставили длиннющие шпаргалки с ответами на все мыслимые и немыслимые вопросы.
Стоило мне спросить: «Какое средство моделирования данных вы предпочитаете?» —
как абонент, выдержав паузу, переспрашивал: «Повторите, пожалуйста, вопрос — я не
совсем понял, о чем речь». В это время он листал шпаргалки в поисках правильного
ответа. Отыскав его, он отвечал: «Больше всего мне нравится ERStudio, но у него есть
такие то недостатки. ERWin — тоже ничего, он выгодно отличается тем то и тем то».
Понимаете, дословно повторяя содержимое шпаргалок, они говорили все то, что я хотел
услышать. Мне уже стало казаться, что группа будет состоять исключительно из гениев.
Вскоре после начала работы над проектом я понял, как сильно ошибался.
Собственно, по мере продвижения проектов я получил еще несколько печальных уро
ков. Все мои неудачи происходили от того, что я совершенно не учитывал культурные
факторы — я даже не предполагал, что в деле управления группами, состоящими из за
рубежных специалистов, культурные факторы имеют какое то значение.
Урок 2. Когда индиец кивает головой, он имеет в виду «нет», а не «да». Вы можете
себе представить, как это сбивает с толку?! Ведь мы принимаем за аксиому, что кивок
выражает согласие!
Урок 3. В большинстве случаев специалисты из Индии не препираются, не пытаются
вас поправить и не подвергают сомнению авторитет начальства — по крайней мере пуб
лично. Таким образом, они согласятся со всем, что вы скажете, — пусть даже вы будете
нести полную чушь. Некоторые из них после совещаний продолжают решать задачу по
своему, вне зависимости от того, что им сказали. Работая с индийцами, я возомнил себя
великолепным лидером — ведь американские программисты ни за что не позволят до
стичь консенсуса так быстро и легко!
Урок 4. Как правило, если консультанты не понимали, что я им говорил, они даже не
пытались дать об этом знать. Они несколько раз повторяли, что все мои предложения
в высшей степени разумны, после чего продолжали кодировать так, как считали нужным.
Урок 5. Последняя индийская перепись населения зафиксировала в стране более 200
языков и диалектов. Поскольку все мои сотрудники приехали из разных регионов Ин
дии (кстати сказать, друг друга они недолюбливали), между собой они общались ис
ключительно на ломаном английском. Многочисленные улыбки и жесты отнюдь не спо
собствовали преодолению взаимного непонимания.
Урок 6. Несмотря на то что всех новоиспеченных сотрудников нам привело одно и то
же агентство, все они работали на разные консалтинговые компании. Я платил за их
услуги по 125 долларов в час, из которых самим исполнителям доставалось только от
15 до 55.
Но… все эти уроки я выучил слишком поздно. Лишь один из трех проектов был ус
пешно завершен; остальные два постигла печальная судьба — немалые деньги оказались
выброшенными. Ни за что больше не буду ввязываться в подобные авантюры.
Îöåíêà ìåòîäîëîãèé ðàçðàáîòêè
ïðîãðàììíûõ ñðåäñòâ
Раньше программирование считалось уделом инженеров и ученых, весьма дале
ких от суеты бизнес центров. Нынче компьютерами пользуются все подряд, а упо
требление технологических достижений в коммерческих целях обязывает созда
вать качественные программные продукты вовремя и в рамках установленного
бюджета. К последнему утверждению можно, конечно, относиться с иронией, но
факт остается фактом: эпоха программ, разрабатывавшихся энтузиастами по соб
ственным правилам, ушла в историю. Бизнес требует тщательности в разработке
и внимания к практическому результату деятельности персонала. Здесь то и на
чинается самое интересное. Практически все представители нашей индустрии, по
лучившие какое никакое признание, считают себя экспертами и норовят продать
«уникальные» методологии разработки.
Со мной другая ситуация — я пытаюсь продать принцип эклектичности в ме
тодиках разработки. Задействуйте и совершенствуйте те методы, которые доказа
ли свою практичность для вас лично, для группы и для компании. Создавайте
собственные методы и приспосабливайте их для нужд своей организации — вне
зависимости от того, что они собой представляют, суть должна быть одна: опера
тивная разработка качественного программного обеспечения. В следующих раз
делах я привожу обзор заметных школ разработки программных средств, причем
основной акцент делаю на их концептуальной основе. Школы проектирования
я обсуждать не собираюсь. Структурное программирование, объектно ориенти
рованное проектирование, эталоны проектирования — все эти течения в основ
ном сфокусированы на деталях конструкции и значительно меньше внимания
уделяют общей методологии разработки. Архитектурные проблемы (рассматри
ваемые в главе 6) также не получают в них достаточно глубокого развития. Итак,
отступив от деталей, я собираюсь представить на ваш суд наиболее общий анализ
ситуации.
Ñîçäàâàéòå ñîáñòâåííûå ìåòîäû è ïðèñïîñàáëèâàéòå èõ äëÿ íóæä ñâîåé îðãàíèçàöèè — âíå çàâèñèìîñòè îò òîãî, ÷òî îíè ñîáîé ïðåäñòàâëÿþò, ñóòü äîëæíà áûòü
îäíà: îïåðàòèâíàÿ ðàçðàáîòêà êà÷åñòâåííîãî ïðîãðàììíîãî îáåñïå÷åíèÿ.
Ïðîãðàììíàÿ èíæåíåðèÿ
В конце 1960 х годов, когда тогдашним инженерным гениям удалось высадить
человека на Луну, располагая при этом меньшими вычислительными мощностя
ми, чем любой современный калькулятор1, в обиход вошел термин «программная
инженерия». Эта концепция зиждется на представлении, согласно которому про
граммное обеспечение можно разрабатывать средствами традиционных инженер
ных дисциплин. Применительно к сверхкрупным программным проектам, которые,
1
Первый функционирующий микропроцессор появился в 1971 году.
214 Ãëàâà 10 • Ñëîâà áåç ïåñíè
как правило, заказывались правительством или крупными подрядчиками мини
стерства обороны, эта методика несколько раз показала достойные результаты,
но в остальных случаях потерпела фиаско1. Метод программной инженерии зача
стую применялся в условиях одновременной разработки программного и аппа
ратного обеспечения. Кроме того, с его помощью удалось создать несколько ком
мерческих продуктов. IEEE определяет этот метод следующим образом:
«Программная инженерия — это систематический, структурированный, коли
чественный подход к разработке, функционированию и сопровождению про
граммных средств; иначе говоря, способ применения инженерных методов
в разработке программных продуктов»2.
Полагаю, вы, как и я, в замешательстве. Основное внимание в этом методе уде
ляется сокращению количества дефектов в коде — о соблюдении бюджетных ра
мок ни слова.
Это не в меру сжатое определение, по моему, можно расширить.
Систематически — все аспекты разработки можно контролировать в едином
процессе.
Структурно — последовательное употребление должных методов с целью
производства качественного программного продукта.
Количественно — все требования известны и допускают отображение на ме
тоды реализации.
Прежде чем чесать затылок, глядя на мою интерпретацию трех основных кон
цепций программной инженерии, согласитесь: всем нам хотелось бы достичь оп
ределенности, точности и завершенности, которые декларируются. Посмотрим,
как относится к мифу о суперпрограммистах один из наиболее последовательных
поборников программной инженерии:
«Существует распространенное мнение, согласно которому несколько высо
коклассных специалистов, собранных вместе, способны сделать больше, чем
стандартная группа разработчиков. Имеется в виду, что их знания о способах
достижения высоких результатов интуитивны, а значит, потребность в систе
матизации процесса отпадает. Будь это действительно так, можно было бы пред
положить, что компании, у которых в штате числятся наиболее квалифициро
ванные специалисты, не должны испытывать типичных проблем с качеством
разрабатываемых программных средств и продуктивностью. Опыт же подска
зывает нам, что это совершенно не так»3.
Видите, какой получается конфликт. «Человек» противопоставляется «маши
не» — в контексте программной инженерии «машиной» можно назвать дисципли
нированную группу разработчиков, работающую на основе общей методологии.
«Человеком» же обозначается программист светило, который как по волшебству
мастерит продукты, руководствуясь исключительно своими познаниями. В дис
куссию по этому поводу (по моему, она немного искусственна) вступать не стоит.
Хорошие специалисты и надежный процесс в равной степени необходимы — не
1
2
3
См. Glass, Software Runaways, op. cit.
См. IEEE Standard Computer Dictionary (Institute of Electrical and Electronics Engineers, Институт ин
женеров по электротехнике и электронике, 1990).
Humphrey, op. cit., p. ix.
будь одного из этих компонентов, создавать качественные программные продук
ты было бы крайне сложно. Вопрос лишь в том, является ли надежным процессом
программная инженерия.
Мнения на этот счет расходятся. Предположим, перед вами стоит задача кон
струирования системы управления воздушным движением. На первый взгляд,
программная инженерия прекрасно подходит для ее решения. Но… стоит поду
мать еще раз. К провалу проекта комплексной системы автоматизации (Advanced
Automation System, AAS) Федерального управления гражданской авиации США
(Federal Aviation Administration, FAA), с помощью которого в 1980 х годах пред
полагалось модернизировать систему управления воздушным движением, мето
дика программной инженерии имеет непосредственное отношение. Несмотря на
миллионные затраты, проект так и не оправдал ожиданий1.
Кое кто до сих пор убеждает общественность в том, что программная инжене
рия — это именно то, что нужно; их оппоненты не соглашаются — по их мнению,
эта методология оторвана от реальности и с наступлением эпохи Интернета не
применима к рутинным проектам. Я предлагаю вам самостоятельно изучить со
ответствующую литературу, опробовать на практике декларируемые в ней идеи и
лишь после этого делать выводы. В рамках школы программной инженерии ис
следователям удалось выработать ряд весьма удачных идей, и если они вам под
ходят — действуйте! С моей точки зрения, программная инженерия — это скорее
идеальная конструкция, чем реальная методология; по этой причине методы для
внедрения в повседневную деятельность своей команды я предпочитаю искать
в других концепциях.
MSF
Хотите — возмущайтесь, но в одном вы меня не переубедите: компании Microsoft
удалось разработать крайне продуманный метод и успешно его разрекламировать.
Несколько компаний2 даже решили в приказном порядке отправить своих сотруд
ников на недельные курсы обучения предлагаемому Microsoft методу. Не сомне
ваюсь, что компании уровня Microsoft, специализирующейся на разработке ком
мерческих программных продуктов, есть что сказать на заданную тему.
Концептуальная основа метода MSF (Microsoft Solutions Framework — каркас ре
шений Microsoft) предполагает координацию групп, тем или иным способом ответ
ственных за процесс разработки. Вместо того чтобы воспроизводить яркие реклам
ные лозунги, я сосредоточу ваше внимание на отдельных деталях метода — по мо
ему, они лучше любых сообщений информационных служб и даже лучше научно
го изложения концепции отражают позицию Microsoft. Согласно выпущенному
компанией руководству3, предлагаемая методика основывается на «трех китах».
1. Прикладная модель строится на основе предоставляемых услуг, побуждая раз
работчиков рассматривать любое приложение как сеть услуг, в которой ха
рактеристики и функциональность можно пакетировать вне зависимости от
функциональных границ и в расчете на многократное использование.
1
2
3
См. Glass, Software Runaways, op. cit., p. 56.
В том числе и моя, естественно.
Solutions Development Discipline Workbook (Redmond, WA: Microsoft Corporation, 1996), pp. 1–17.
216 Ãëàâà 10 • Ñëîâà áåç ïåñíè
2. Итерационная модель процесса жизненного цикла разработки ориентирована
на поставки, отталкивается от рисков и включает четыре основных этапа.
3. Используется модель масштабируемой группы разработчиков, состоящей из
шести равнозначных ролей.
Не сомневаюсь, что вы с нетерпением ожидаете изложения упомянутых «че
тырех этапов» и «шести ролей». Сходите на курсы Microsoft — я не хочу реклами
ровать специалистов Microsoft больше, чем они того заслуживают. Они высказали
ряд замечательных идей, которые мне удалось приспособить к своей методоло
гии разработки. Ну ладно — полагаю, у вас не так много времени, чтобы прово
дить собственные исследования, так что, коль скоро вы купили мою книгу, пого
ворим о деталях.
Что касается этапов MSF, то здесь группа разработчиков должна принять на
вооружение ряд принципов.
1. Видение/рамки. Основное внимание уделяется не требованиям, а рамкам работ.
2. План проекта. Заказчики и участники группы должны договориться о постав
ках, приоритетах и ожиданиях.
3. Закрытые рамки/Первое применение. Первая бета версия готового продукта.
4. Выпуск. Продукт или услуга предоставляется рабочей группе и группе под
держки.
Роли в MSF распределяются следующим образом.
1. Руководство продуктом. Особое внимание уделяется оценке продукта с ком
мерческой точки зрения.
2. Управление программой. Разработка функциональных спецификаций, утверж
дение и корректировка графика.
3. Разработка. Конструирование продукта (или услуги), соответствующего спе
цификации и ожиданиям заказчиков.
4. Тестирование. Выявление всех проблем перед выпуском программы.
5. Обучение пользователей. Каждый пользователь должен получать от продукта
максимум возможностей.
6. Логистика. Обеспечение беспрепятственных выпуска, установки и миграции.
Все очень складно, не правда ли? На самом деле максимальной продуктивнос
ти, вооружившись методикой MSF, можно достичь лишь при наличии достаточно
многочисленного персонала, который позволит сформировать группы и испол
нять процессы согласно рекомендациям. Преподаватели на курсах утверждают,
что метод MSF применяется в самой компании Microsoft. Учитывая характер ли
тературы, выпущенной Microsoft Press за последние 10 лет, полагаю, что это дей
ствительно так1.
Вам лишь остается выяснить, насколько успешно методология MSF может про
явить себя в условиях конкретной группы и компании. Она ведь не ограничива
1
В первую очередь, я имею в виду работу Jim McCarthy. Dynamics of Software Development (Microsoft
Press, 1995). Вероятно, именно в ней впервые сформулированы некоторые основополагающие прин
ципы MSF.
ется одной разработкой. В ней предпринимается попытка направить усилия все
го предприятия на достижение одной цели — поставки достойного по качеству
программного обеспечения. Лично я положительно оцениваю свой опыт приме
нения MSF — правда, этот метод требует адаптации к реалиям корпоративной
культуры и корректировки отдельных характеристик рекомендованных групп.
Ýêñòðåìàëüíîå ïðîãðàììèðîâàíèå
С одной стороны, экстремальное программирование (Extreme Programming, XP)
позиционируется как новаторская методика; с другой — эта методика существует,
пожалуй, с тех давних пор, когда в реле находили тараканов1. Позвольте пояс
нить. Основное внимание в XP уделяется командному программированию с ак
центом на код сам по себе. Последний понимается как средство передачи требова
ний и изменений, а также ключ к пониманию задачи программного продукта. Один
из ведущих проповедников XP Кент Бек (Kent Beck) утверждает, что XP обещает
радужные перспективы двум группам заинтересованных лиц:
«Программистам XP предоставляет возможность каждый день сосредоточи
ваться только на тех вопросах, которые действительно важны. Им больше не
придется сталкиваться с устрашающими ситуациями один на один. Они смо
гут проявить свои способности на все сто, направить их всецело на обеспече
ние качества системы. Им не придется принимать решения в тех областях, в ко
торых они не слишком много понимают, — они могут сосредоточиться на своих
прямых обязанностях».
«При помощи XP заказчики и руководители смогут каждую неделю разработ
ки получать максимальный результат. С регулярностью в несколько недель
они будут оценивать конкретный результат работы над решением задач, кото
рые для них наиболее важны. Корректировать направление разработки проек
та можно будет в самый разгар трудовой деятельности программистов, причем
никаких сверхъестественных затрат на это не потребуется»2.
Каким образом метод XP реализует эти перспективы? Путем введения ряда
принципов программирования, которым группы должны следовать неукоснитель
но. Вместо того чтобы перекладывать отдельные аспекты разработки на руково
дящее звено, метод XP концентрируется на функциях собственно программистов,
то есть на конструировании программных продуктов.
В центре процесса разработки по версии XP стоит принцип ежедневного тес
тирования, которое должно проводиться командой из двух программистов. Та
ким образом, ситуация, при которой каждый разработчик изолируется в своей
кубышке, а создаваемый им впервые код тестируется специализированной группой
лишь через месяц, решительно исключается. Интеграция модулей кода произво
дится сразу после разработки, а тестирование — незамедлительно после интегра
ции. Практика запуска всех существующих контрольных сценариев на каждом
этапе интеграции кода позволяет убедиться в том, что изменение любого отдельно
взятого модуля не приводит к деградации остальных. Таким образом, метод XP
1
2
Термин «жучок» (bug), очевидно, появился еще в эпоху наиболее древних (до 1950 х годов) компью
теров, в которых реле выходили из строя вследствие попадания в них всякого рода насекомых.
Kent Beck, Extreme Programming Explained (Reading, MA: Addison Wesley, 2000), p. xvi.
218 Ãëàâà 10 • Ñëîâà áåç ïåñíè
выделяется сжатыми циклами выпуска и еще более быстротечными итерациями
проектирования.
Метод экстремального программирования ориентирован на проекты, допус
кающие конструирование силами компактных групп (численностью от двух до
десяти разработчиков), участники которых напрямую получают информацию от
заказчиков. Процесс XP, таким образом, управляется самой группой разработчи
ков, а центральное место в методологии занимает программист. Коммерческие
специалисты фактически отстраняются от руководства, ограничиваясь «поощри
тельными» функциями. Управленческая инициатива в группе принадлежит ин
структору — программисту, ответственному за процесс разработки в целом.
Буква «X» в аббревиатуре XP означает «экстремальный». Эту характеристику
многие деятели нашей индустрии признали вполне удачной. Впрочем, есть и такие,
которые, уважая суть концепции, с некоторым презрением относятся к ее назва
нию1. По моему, в публикациях, посвященных этой «новой» методологии, равно
как и в практической деятельности по реализации ее принципов, очень много по
лезного. Полагаю также, что материалы сайта http://www.extremeprogramming.org
помогут вам сориентироваться в том, какие методы этого заметного (пожалуй,
даже крикливого) течения стоит принять на вооружение. Хотя, если уж следо
вать духу XP, получается, что вычленять из этой методологии отдельные элемен
ты или смешивать ее с другими стилями нельзя — либо вы «экстремал», либо нет.
Меня на это не купишь, хотя мотивация мне вполне понятна. Поборники экстре
мального программирования пытаются сказать примерно следующее: «Либо дис
циплинируйтесь, либо убирайтесь из профессии — вам в ней нечего делать!» Вот
это мне по душе — надеюсь, и вам тоже.
Ãèáêàÿ ðàçðàáîòêà
В поисках новых методов для себя и своей команды вам еще не раз предстоит
столкнуться с термином «гибкий» (agile). Любой эффективный метод разработ
ки программного обеспечения является таким по свой природе. Гибкость означа
ет способность к адаптации, к изменяющимся требованиям и развивающейся тех
нологии, в том числе на этапе конструирования проекта. Мнения большинства
специалистов в области разработки программных средств сходятся в одном: гиб
кость — это священный Грааль всех методик разработки. Существует даже обще
ственная организация, состоящая из ведущих специалистов по разработке про
граммных продуктов и ставящая своей целью пропаганду концепции гибкости2.
Эти деятели даже опубликовали манифест, в котором обозначены четыре основ
ные проблемы, свидетельствующие, в зависимости от решения, о гибкости тех или
иных методов3.
1. Отдельные лица и взаимодействие или процесс и инструментальные средства.
2. Функционирующее программное обеспечение или комплексная документация.
1
2
3
См. колонку «Feedback» в журнале «Software Development» за ноябрь 2001 года.
См. http://www.AgileAlliance.org.
См. Alistair Cockburn, Agile Software Development (New York: Addison Wesley, 2002), Appendix A.
3. Сотрудничество заказчиков или переговоры по контракту.
4. Реакция на изменения или следование плану.
Признавая определенную ценность положений, расположенных в правой час
ти списка, авторы придают большую значимость его левой части.
Между так называемой «гибкой» школой и экстремальным программирова
нием много параллелей. Действительно, в совещании, на котором был принят ма
нифест гибкости, участвовали, помимо прочих, основатели концепции XP. На
самом деле методология гибкости — это, скорее, совокупность принципов, при
менимая к любым процессам и мероприятиям в области планирования, направ
ленным на конструирование программных средств. В главе 6, рассуждая о мето
дах технического проектирования, я упомянул термин1 «адаптивная разработка
программных средств», имея в виду деятельность, обусловливающую ваш успех
в роли технического лидера. Так вот, адаптивная разработка тоже происходит от
гибкости.
Ìíåíèÿ áîëüøèíñòâà ñïåöèàëèñòîâ â îáëàñòè ðàçðàáîòêè ïðîãðàììíûõ ñðåäñòâ
ñõîäÿòñÿ â îäíîì: ãèáêîñòü — ýòî ñâÿùåííûé Ãðààëü âñåõ ìåòîäèê ðàçðàáîòêè.
В отличие от других методов, рассматривающих предвидение изменений как
малозначащий фактор, на который не следует обращать внимания, или как тен
денцию в процессе разработки, которой нужно сопротивляться, концепция гиб
кости призывает к конструктивному и адаптивному реагированию на изменения.
В этом свете XP трактуется как подготовительная стадия к внедрению филосо
фии гибкости. Любой метод, предусматривающий фиксацию требований и сле
дование предопределенному процессу, приводит к созданию не вполне адекват
ного программного продукта. Приведу цитату из Кокберна (Cockburn).
«Некоторые считают, что необходимым условием успешности проекта является
следование заданному процессу. Те, кто придерживается такого мнения, тра
тят уйму энергии на проверку его соблюдения. Человек, твердо убежденный
в том, что именно в процессе вся суть, может очень долго не обращать вни
мания на несоответствие между практикой следования процессу и его исхо
дом»2.
Иначе говоря, методология гибкости снимает с нас шоры и открывает глаза на
те вещи, которые рабы процесса не замечают.
Перечисление этапов процесса разработки, основывающегося на методологии
гибкости, противоречит самому ее духу. Методология гибкости рассматривает
процесс разработки как опыт сотрудничества и взаимодействия между програм
мистом и заказчиком. Эта позиция, иногда трактуемая исключительно как мето
дологическая тенденция, как мне кажется, являет собой единственный способ
обуздать трудный процесс создания качественных программных средств.
1
2
Этот термин взят из одноименной книги Джима Хайсмита (Jim Highsmith). См. библиографию.
Cockburn, op. cit., p. 5.
220 Ãëàâà 10 • Ñëîâà áåç ïåñíè
Я крайне рекомендую вам порыться в литературе, посвященной гибким мето
дам. Ресурсов по этому вопросу великое множество1. Не менее важно оценивать
по стандарту гибкости те методы, которыми вы пользуетесь в данный момент.
Представьте себе ситуацию, в которой плохо сформулированное коммерческое
требование уточняется ближе к сроку завершения кодирования. Сможет ли ваша
группа отреагировать на такое изменение без недопустимых задержек? Когда тре
бования меняются во время цикла разработки, большинство из нас проклинают
все вокруг. Тем самым мы пытаемся дистанцироваться от реального положения
вещей — ведь чем глубже мы разрабатываем проблему реализации требования,
тем больше двусмысленности обнаруживаем, а значит, возвращаемся к этапу оп
ределения продукта. Гибкие методы культивируют определенное восприятие не
определенности.
Ìàñòåðñòâî — ÿäðî ëþáîãî óñïåõà
Приведенный обзор методологий разработки приводит, как мне кажется, к един
ственному выводу — разрабатывать программы должны не инженеры, а мастера.
Понятие мастерства не всегда легко поддается осмыслению. Я пришел из акаде
мической науки и на раннем этапе своей деятельности занимался инженерией; по
этой причине я сперва отказывался признавать приоритет искусства перед нау
кой в процессе создания программных средств. Впрочем, вскоре я понял, что «со
противление бессмысленно»2. Посмотрим, под каким заголовком вышел один из
ведущих технических журналов в 1990 году3:
«Производители программных средств страдают от недостаточного контроля
за качеством. По мере того как программные продукты становятся все более
сложными, компаниям становится все сложнее контролировать миллионы
строк кода сложных пакетов»4.
В статье под этим заголовком речь идет о зрелости программных продуктов
(см. главу 6, в которой упоминается модель оценки зрелости продуктов) и коли
честве ошибок в расчете на строку кода. Там обсуждаются методы измерения
количества ошибок, но совершенно не уделяется внимание наиболее важной про
блеме: программные продукты создают люди, а отнюдь не процессы, исполняе
мые автоматами.
Ïðîãðàììíûå ïðîäóêòû ñîçäàþò ëþäè, à îòíþäü íå ïðîöåññû, èñïîëíÿåìûå àâòîìàòàìè.
Кто создает программные продукты? Мастера. Осознав, что мастера совершен
но не пренебрегают наукой и инженерией, вам будет легче признать, что искус
ство (мастерство) главенствует над научным подходом. Рекомендую поразмыс
1
2
3
4
Примеры приводятся в работе Cockburn, op. cit. Обзор имеющихся ресурсов имеется также на сайте
http://www.adaptivesd.com.
Похоже на «Звездные войны», правда?
Как вы помните, тогда не было ни Windows, ни графических пользовательских интерфейсов.
Electronic Business, October 15, 1990, p. 147.
Òåõíîëîãè÷åñêèå ðåâîëþöèè 221
лить над тем, как нам всем прийти к достойному балансу искусства и науки/ин
женерии в себе, чтобы обеспечить превращения кода в полезные и качественные
программные продукты. Я абсолютно согласен с Питом Макбрином (Pete
McBreen) в том, что он пишет в предисловии к своей книге по мастерству разра
ботки программных продуктов:
«Мастерство знаменует собой возвращение к корням разработки программных
средств. Хорошие разработчики понимают (и всегда понимали), что программи
рование — это деятельность из области искусства. Какими бы потаенными и по
дробными техническими знаниями ни обладал разработчик, в конечном итоге
процесс разработки приложений сводится к ощущению и опыту. Можно знать
самые изощренные детали языка программирования Java, но при этом, не чув
ствуя эстетической стороны программ, так и не стать достойным разработчиком.
Если же человек чувствует процесс разработки программных средств, знание
конкретных технических деталей уходит далеко на второй план. Лучшие разра
ботчики постоянно учатся новым технологиям и методологиям; постижение
очередной технологии для разработчика должно стать обыденным занятием»1.
Следуя духу мастерства, создайте собственную методологию разработки. Учи
тесь у коллег, сумевших документировать изобретенные ими процессы, и пусть
опыт станет самым верным средством проверки методов2. В конце концов, суть
науки сводится к постижению истины путем экспериментов. Таким образом, при
нимаясь за работу с позиции мастера — с тем, чтобы создать достойное программ
ное обеспечение, — вы действуете в полном соответствии с научным и инженер
ным принципом.
Ñëåäóÿ äóõó ìàñòåðñòâà, ñîçäàéòå ñâîþ ñîáñòâåííóþ ìåòîäîëîãèþ ðàçðàáîòêè. Ó÷èòåñü
ó êîëëåã, ñóìåâøèõ äîêóìåíòèðîâàòü èçîáðåòåííûå èìè ïðîöåññû, è ïóñòü îïûò
ñòàíåò ñàìûì âåðíûì ñðåäñòâîì ïðîâåðêè ìåòîäîâ.
Òåõíîëîãè÷åñêèå ðåâîëþöèè
«Мыльные пузыри» в рядах программных продуктов регулярно создают излиш
ний шум. Это явление я бы назвал «интеллектуальным зомбированием». Проек
ты, о которых шли беспрерывные разговоры, не приведшие, однако, к фактиче
ской реализации, весьма многочисленны. Упомяну лишь некоторые несбывшиеся
обещания и беспочвенные заявления3.
Подключенный к сети компьютер за 500 долларов избавит мир от Windows.
MSN уничтожит AOL (не так быстро — AOL нынче владеет Time Warner).
Intuit, несмотря на противостояние с Microsoft, удалось создать более удач
ный продукт — Quicken.
1
2
3
McBreen, op. cit., p. xv.
Такой подход рекомендовал сам Леонардо (см. главу 6).
Этот список я по большей части позаимствовал у Дэвида Корси (David Coursey) — редактора рубрики
AnchorDesk на портале http://www.zdnet.com (конкретнее — из статьи, опубликованной им 12 октяб
ря 2001 года).
222 Ãëàâà 10 • Ñëîâà áåç ïåñíè
OS/2 — это DOS лучше «настоящей» DOS и Windows лучше «настоящей»
Windows.
Разработчики настольных прикладных систем дружно перейдут на Java. (Ну
это мы еще посмотрим!)
Прецедентов великое множество, и, конечно, здесь они отражены далеко не
полностью. Этим своим списком я лишь хочу напомнить о том, что, сталкиваясь
с очередным Сенсационным Откровением компьютерной индустрии, стоит быть
осторожным. «Технологии нового поколения» — выражение, употребляемое во
многих рекламных кампаниях — как правило, действительно дорабатываются
лишь с приходом очередного поколения.
Революции в нашей отрасли, бесспорно, случаются. Впрочем, симптомы гря
дущих изменений, как правило, прослеживаются задолго до окончательного ут
верждения новых идей и их воздействия на процесс разработки. Вы должны на
учиться предсказывать тенденции, обещающие заявить о себе через некоторое
время. В «Искусстве войны» Сун Цзу (Sun Tzu) писал:
«Не разбивайте лагерь на сложной местности. Объединяйтесь с союзниками
на пересечении крупных путей. Не задерживайтесь на изолированных пози
циях. Находясь в окружении противников, старайтесь обмануть их. Деритесь
только при крайней необходимости»1.
Следуя этим мудрым советам, с тем чтобы избежать «крайней необходимос
ти», разрабатывайте техническую стратегию революции задолго до наступления
самой революции. Сун Цзу говорит о «сложной местности» — полагаю, эта ситу
ация применима и в разработке программных средств. Домысливая китайского
философа, я рекомендую вам в ходе долгосрочного планирования учитывать сле
дующие стратегические проблемы.
Не разбивайте лагерь. Знания ваших подчиненных программистов не должны
ограничиваться единственным языком и одной инфраструктурной реализацией
архитектурных решений коммерческихзадач.
Объединяйте усилия. См. предыдущий пункт. Обращайтесь к зарекомендовав
шим себя решениям от разных поставщиков — чем больше их будет, тем луч
ше. Время от времени привлекайте консультантов — пусть делятся с сотруд
никами новыми знаниями. Стимулируйте процесс обучения за счет построения
силами сотрудников компактных макетов, нацеленных на проверку примени
мости новых методик к разработке более крупных проектов.
Не задерживайтесь. Успехи компании иногда порождают в ее сотрудниках
инертность, которая не позволяет им внимательно отслеживать новые ходы
конкурентов и находить возможности для дальнейшего роста. Вы должны ста
раться сохранять гибкость по части применения новых методов и инструмен
тов. Не отвыкайте от неудобств — даже в том случае, если в данный момент вы
их не ощущаете.
Как отслеживать новейшие тенденции? Для этого существует литература, ко
торую нужно читать в больших количествах, и Интернет, пользоваться которым
нужно с умом. Выберите несколько надежных источников информации и обра
1
Цитирую по: Sun Tzu, The Art of War. Ed. James Clavell (New York: Dell Publishing, 1983), p. 37.
Ýêîíîìè÷åñêèå íåñ÷àñòüÿ 223
щайтесь к ним, как только вам потребуется что то узнать1. А самое главное — пу
тем плотного взаимодействия с начальником и подчиненными выработайте ком
плексную стратегическую программу, то есть руководство к действию в постоян
но меняющемся мире, в котором мы, разработчики, все пребываем.
Ýêîíîìè÷åñêèå íåñ÷àñòüÿ
Слова «экономические» и «несчастья» часто употребляются вместе. Не так уж
часто можно услышать об экономических радостях, так? Из последних событий
в контексте экономических несчастий в памяти всплывают лопнувшие пузыри
интернет компаний. Как бы там ни было, риск — это неотъемлемый элемент буд
ничной деятельности специалистов в области разработки программных средств,
и учиться на неудачах мы должны не менее тщательно, чем мы учимся на успеш
ных прецедентах. Крах интернет компаний, конечно, можно свалить на инвестици
онных банкиров, но, пожалуй, для нас как для профессиональных разработчиков
такая позиция представляется не слишком продуктивной. Спору нет — жадность,
алчность и все прочие присущие капитализму пороки сыграли в крушении этих
компаний не последнюю роль. Тем не менее на первый план во время экономи
ческого несчастья выходят люди, такие как вы и я, которые теряют работу, испы
тывая попутно эмоциональные и интеллектуальные страдания. В этом разделе
я постараюсь объяснить, какие конструктивные действия вы можете предпринять,
чтобы предотвратить наступление кризиса.
Пожалуй, самый важный урок, которому нас учат многочисленные кризисы, со
стоит в следующем: если компания перестает приносить доход, значит, вероятно,
конец близок2. Таким образом, лучший способ предотвратить наступление кризиса
в компании — это следить за издержками разработки и стремиться к рентабель
ности. Признаю: совет не слишком оригинален — это все равно что сказать: «Если
хотите заработать на Уолл стрит, покупайте задешево, а продавайте втридорога».
Совет на самом деле правильный, но лишь при условии верно выбранного време
ни. Таким образом, очевидно, что во главе угла находится именно время.
И вот это самое обстоятельство подводит меня к основной мысли в экономиче
ском контексте. Если правильный выбор времени играет такую важную роль, значит,
синхронизировать экономические часы вашей компании с реальной ситуацией
можно лишь за счет последовательности. Что я имею в виду? Занимая лидирующую
позицию в своей команде, вы должны придерживаться нижеследующих правил.
Вы — не только технарь, но и бизнесмен. О стоимости, таким образом, нужно
думать не меньше, чем о коде.
Составьте представление о реальных затратах на содержание вашего отдела.
Ежемесячно собирайте данные о стоимости технических средств, оборудова
ния, услуг, инструментов и заработной плате персонала.
1
2
Как мне кажется, для начала подойдет сайт TechRepublic (http://www.techrepublic.com). На нем
публикуются вполне добротные тематические обзоры.
Интернет компании славились (и славятся до сих пор) бездоходностью. Amazon.com вот уже несколь
ко лет приносит прибыль, и, вероятно, эта компания — скорее исключение из общего правила; впрочем,
время покажет. Лично мне будет жаль, если они обанкротятся. В конце концов, неужели многих со
тен долларов, которые я перечислил им за годы нашего знакомства, недостаточно для выживания?!
224 Ãëàâà 10 • Ñëîâà áåç ïåñíè
Сравнивайте окончательную фактическую стоимость проекта с предварительны
ми расчетами. Оценивайте расхождения между сметой и расходами и на осно
ве этого опыта учитесь подходить к составлению смет с более реалистических
позиций. Не забывайте поговорку: «День профилактики стоит года лечения».
Держите зарплаты сотрудников под контролем. Платите им столько, сколько
они заслуживают, сверяясь при этом с рыночной конъюнктурой1.
Увольняя сотрудника, позаботьтесь о его дальнейшем трудоустройстве — пи
шите рекомендательные письма2 и звоните работодателям. Почувствовав, что ско
ро могут уволить вас самого, немедля приступайте к поиску нового места работы
(если, конечно, это возможно) — не ждите, пока извещение об увольнении придет
по факсу. Перейти с одной работы на другую значительно проще, чем выбраться
наверх из армии безработных.
Îäèíî÷åñòâî ðóêîâîäèòåëåé
Лидеры, осваивающие во главе своих групп новые территории, часто ощущают
свое одиночество. Это — цена лидерства. Переход из программистов в разряд ру
ководителей и соответствующее изменение обязанностей не всегда проходят бес
следно, и далеко не всем удается избежать депрессии. Как я уже говорил, ждать,
что кто то похлопает вас по плечу и скажет, что вы все правильно делаете, не сто
ит — этого может и не случиться. Если процесс адаптации к административным
функциям еще не закончен, вполне возможно, вы чувствуете себя не слишком
комфортно — в эмоциональном плане.
Все, что я скажу по этому поводу, можно, конечно, воспринимать как опыт
психологического анализа, но ведь я сам прошел через этот этап — так что, скорее,
это воспоминания. Чувство пребывания не в своей тарелке пройдет, поверьте,
и есть средства, с помощью которых процесс психологического восстановления
можно ускорить.
Óäåëÿéòå âðåìÿ èññëåäîâàòåëüñêîé ðàáîòå
Как смягчить последствия отхода от привычной деятельности — кодирования?
Рекомендую как можно больше времени уделять исследованию новых техноло
гий, написанию кода с помощью не испробованных ранее инструментов и мето
дик. Не стоит, впрочем, заниматься кодированием в рамках текущих проектов —
если, конечно, вы не испытываете недостатка в персонале. Ответственность за
процесс разработки в целом усложняет наблюдение за промежуточными резуль
татами сотрудников. Поэтому если за счет руководящих обязанностей вы окаже
тесь единственным разработчиком, не успевшим доделать свою часть кода, ситу
ация лишь усложнится. Я понимаю, что вы готовы взяться за любую возможность
1
2
Я уже высказывался на эту тему в главах 1 (см. подраздел «Мотивирование деньгами» в разделе «Сла
ва, почет и деньги») и 3 (см. подраздел «Денежное поощрение и продвижение сотрудников по служ
бе» в разделе «Как сформировать команду и как ее поддерживать»), но здесь имеет смысл повториться.
В некоторых случаях от такой помощи приходится отказываться по правовым причинам. По вопро
сам корпоративной политики в этой области вам стоит проконсультироваться у начальника.
Îäèíî÷åñòâî ðóêîâîäèòåëåé 225
поработать с кодом, и эта деятельность тоже входит в обязанности лидера, но про
шу вас: будьте в этом отношении благоразумны.
Одна из наиболее существенных технических задач лидера сводится к оценке
применимости для внедрения в проект новых программных средств, методик и ва
риантов архитектуры. Вы — лидер и наставник — не сможете обучать сотрудни
ков, не зная реального положения вещей в тех или иных областях. Подобного рода
анализ — занятие трудоемкое и требующее серьезной технической подготовки,
а это значит, что ваш опыт в роли высококвалифицированного программиста бу
дет весьма кстати.
Êàê ïðåâðàòèòü àäìèíèñòðàòèâíûå ôóíêöèè
â èíæåíåðíûå
Как вы знаете, в оценке программной инженерии как методологии разработки я не
слишком оптимистичен; тем не менее мне кажется, что инженерные методы впол
не применимы к административной деятельности. Автоматизируйте процесс пла
нирования проекта и еженедельного распределения рабочих заданий. В гла
ве 4 я уже касался этой темы, но, по моему, она заслуживает повторного обзора.
Администрирование отнимает много времени, и для всех сфер деятельности ру
ководителя этого времени не хватает; упорядочить поток информации помогут
ваши навыки программирования.
Изучите биографии и принципы деятельности руководителей, которым уда
лось выстроить свои административные обязанности и реализовать амбиции.
Помимо составления памяток, телефонных звонков и прочих будничных адми
нистративных операций, они приложили усилия к процветанию своих компаний,
самосовершенствованию и повышению квалификации персонала. Если вы поста
вите своей целью административную деятельность и не будете всеми силами ста
раться избегать ее, то сможете достичь сопоставимых высот.
Ñòðàòåãè÷åñêîå ïëàíèðîâàíèå êàê íàóêà
В предыдущей главе (см. главу 9) я рассказывал о том, как помочь начальству до
стичь успеха. Может статься, что вашей основной обязанностью окажется страте
гическое планирование развития компании в техническом аспекте. Таким обра
зом, вы должны уделить особое внимание совершенствованию навыков создания
стратегических планов, в которых должны не просто прогнозироваться возмож
ные векторы развития, а буквально строиться будущее. Это не так то просто.
Многие так называемые «белые книги» — программные документы корпораций —
зачастую несут единственную функцию: развеять опасения о непродуманности
будущего развития. Впрочем, думать о будущем и планировать его — это несколь
ко разные вещи.
Разрабатывая стратегию на будущее, необходимо изучать прошлое. Проана
лизируйте старые планы, подумайте, почему некоторые из них увенчались успе
хом, в то время как другие провалились. Таким образом, вам предстоит стать ис
ториком применявшихся в компании технологий и предсказателем тенденций на
многие годы вперед. Говорят, «те, кто отказываются учить уроки истории, обре
чены на ее повторение», — быть может, это и банально, но смысл очевиден.
226 Ãëàâà 10 • Ñëîâà áåç ïåñíè
Планы нужно строить исходя из зарекомендовавших себя моделей — об
ращать излишнее внимание на «мыльные пузыри» не стоит. Лишь при этом
условии стратегическое планирование сможет претендовать на научное напол
нение. Кто сказал, что стратегические документы не нужно подкреплять приме
рами кода? Жизнеспособность новых идей и методик в исследованиях надо на
глядно иллюстрировать разделами, посвященными их практической проверке.
Конечно, блок схемы с прототипами архитектурных реализаций очень важны,
но, подтвержденные примерами из «текущей деятельности», они приобретают
еще больший вес.
Ó÷èòåñü öåíèòü ÷åëîâå÷åñêèå îòíîøåíèÿ
Не сомневаюсь в том, что значительную часть межличностных отношений вы оце
ниваете вполне адекватно. Но, черт побери, мы же технари, а значит, наша спо
собность к контактам довольно ограничена. Если это не про вас, примите мои
извинения. И все же — существует ли «предельная ценность» применительно
к межличностным отношениям на работе? С «параноидальной» точки зрения, на
верное, да. Впрочем, это совсем не та паранойя, к которой нужно стремиться1.
Я совсем не имею в виду «слезливую плаксивость» — может статься, вы и в этом
меня заподозрили. На самом деле речь о личностной ценности каждого конкрет
ного сотрудника группы, на которого вы затрачиваете время и энергию, пытаясь
стимулировать его рост как программиста и потенциального лидера. Жалко, что
в Вооруженных силах нынче не в ходу лозунг «будь тем, кем ты способен быть», —
ведь лидеры иногда ощущают себя сержантами, муштрующими своих солдат.
Æàëêî, ÷òî â Âîîðóæåííûõ ñèëàõ íûí÷å íå â õîäó ëîçóíã «áóäü òåì, êåì òû ñïîñîáåí
áûòü», — âåäü ëèäåðû èíîãäà îùóùàþò ñåáÿ ñåðæàíòàìè, ìóøòðóþùèìè ñâîèõ
ñîëäàò.
Никогда не забывайте о том, что настоящий лидер пытается подвигнуть своих
подчиненных на максимально продуктивную деятельность. Чем больше вы в них
вкладываете, тем лучше результат. Следовательно, все случаи формального и не
формального общения с сотрудниками, по большому счету, воспринимаются как
рабочие. Вы — начальник, и именно в этой роли вас видят и оценивают подчинен
ные. «Своим парнем», как когда то в бытность программирования в команде, вам
уже не быть. Таким образом, любые отношения с сотрудниками следует выстраи
вать с учетом вашего положения в компании.
Ôèíàë
Глава эта, как известно, называется «Слова без песни». Вот и здорово, что заключи
тельный ее раздел тематически совпадает с названием. Гоняя вас по темам самого
разного содержания, я преследовал единственную цель — показать, что в процес
1
См. главу 8 — в ней упоминается конструктивная трактовка слова «паранойя», приписываемая Энди
Гроуву.
Ôèíàë 227
се выпаса котов побеждать хаос можно по разному. Итак, мы пришли к следую
щим умозаключениям.
В контексте распределенных рабочих групп усиливается значимость плани
рования и проверки проекта.
Для того чтобы управлять сотрудниками, относящимися к разным культурам,
вы должны стать гражданином мира и подавить те национальные характерис
тики, которые могли бы стать препятствием к взаимопониманию и снизить
мотивацию вашего многонационального персонала к успешному ведению дея
тельности.
Вам предстоит постоянно совершенствовать применяемые методологии раз
работки. Одним из необходимых условий успеха является стремление к гиб
кости всех процессов.
Технологические революции поддаются прогнозированию, а значит, к ним
можно подготовиться. Стратегическое планирование на основе понимания
предстоящих перемен — вот средство, позволяющее предотвратить излишнюю
суету в случае их наступления.
Экономические кризисы случаются регулярно, и ничего с этим не поделаешь.
Стремлением к прибыльности своей компании вы должны стараться свести
к минимуму последствия неблагоприятной экономической ситуации. Для на
чала научитесь руководить отделом не только как технарь, но и как бизнесмен.
Лидерство иногда приводит к ощущению одиночества. Существуют, впрочем,
средства, позволяющие безболезненно выйти из этого состояния. Откажитесь
от самоизоляции. Культивируйте в себе активный творческий подход к иссле
довательской деятельности, администрированию, планированию и общению
с людьми.
Лидерство — это увлекательное приключение. Я уверен, возможностями для
исследования и творчества наша индустрия изобилует. Мы, люди технической
направленности, работая в ней, имеем все шансы расширить свой кругозор и стать
пионерами кадрового и программного обеспечения. Итак, цените каждый миг ра
бочего дня и извлекайте из него пользу — как для себя, так и для подчиненных.
П о с л е с л о в и е
Ñíîâà â ïëàâàíèå…
Так, ладно — пора вам закругляться и возвращаться к повседневным обязанно
стям. Послесловие, как видите, тоже метафорично — действительно, я хочу, что
бы вы трактовали свои поступки на руководящем посту как плавание корабля
в неспокойном море. Морем считайте индустрию разработки программных про
дуктов в том виде, в котором она существует сейчас — полагаю, в XXI веке она
покажет себя не менее динамичной, чем в веке XX. Чтобы без особых трудностей
проплыть через это море, вам потребуются надежный руль для поддержания кур
са, большой и прочный парус, чтобы ловить ветер, и якорь для устойчивости. На
деюсь, моя книга поможет удержать вашу шлюпку на плаву.
Ðóëü
Кораблем управляют с помощью руля. Чем управляется ваша профессиональная
деятельность? В идеале она должна основываться на двух важнейших императи
вах: «сконцентрируйся и лидируй!» По мере совершенствования лидерских качеств
и преследуя цель производства отличных программных продуктов, не забывайте
о том, что повышать концентрацию нужно постоянно. Ищите любую возможность
попрактиковаться в деле лидерства — если не закрывать глаза на окружающий
мир, такие случаи будут подворачиваться на каждом шагу. Все принципы и мето
дики, рассмотренные на предшествующих страницах, направлены на достижение
одной единственной цели: помочь вам стать лидером и совершенствоваться в этом
качестве. Чтобы выделить время на лидерскую деятельность, нужно предвари
тельно достичь определенных высот на ниве руководства — таким образом, скон
центрировавшись на неотложных и наиболее значительных приоритетах, вы дол
жны проявить себя хорошим организатором. Именно в этом заключается смысл
«концентрации» — умение не отвлекаться на внешние раздражители помогает
уделять максимум внимания решению самых важных задач.
Сфера вашей деятельности весьма обширна — вам предстоит заниматься раз
ными делами, причем некоторые из них очень интересны. Раздражители, помимо
прочего, появляются из за неверного выбора технологий для решения коммер
ческих задач. Вы должны научиться отметать не подходящие для достижения ва
Ïàðóñ 229
шей компанией успеха решения (пусть даже они, по идее, очень хороши) в пользу
действительно необходимых вариантов. Подобная систематизация достигается
путем планирования и реализации плана. Устранению раздражителей помогает
также правильная организация административной деятельности. Внешне при
бранный рабочий стол свидетельствует о структурированности мысли, а беспо
рядок, напротив, выражает неопределенность по поводу приоритетов. Обратите
внимание: я сказал «внешне». На самом деле, важнее всего ваше внутреннее от
ношение к рабочим вопросам.
Вступив в бой с процессом разработки, вы будете вынуждены пересмотреть
свою систему приоритетов. Стоят ли люди на первом плане в вашей иерархии
ценностей? Они должны быть именно там — в конце концов, никто кроме лю
дей не напишет для вас код. Чем внимательнее вы будете относиться к своим
сотрудникам, тем больше вероятность, что они станут воспринимать ваши зада
чи как свои и делать все для их решения. Многие считают так: «я работаю на
компанию такую то». Этого мало — нужно, чтобы они говорили: «я работаю
на _________________ (впишите сюда ваше имя)». Преданными люди стано
вятся не сразу — для того чтобы сформировать в них это качество, необходимо
постоянно терпеливо принимать участие в их рабочей жизни.
Ïàðóñ
Ветер надувает паруса, заставляя корабль двигаться. Атмосфера в индустрии раз
работки программных средств отличается динамичностью, поэтому «ветров» в ней
бушует предостаточно. Способность идти (в зависимости от ситуации) по ветру
или против ветра есть необходимое условие продвижения в верном (в контексте
целей вашей компании) направлении. От того, к какому «лагерю» вы принадле
жали в бытность занятий программированием, ничего не зависит — имейте в виду,
в последние десять лет бури дули часто и сильно.
Если вы привыкли ориентироваться на продукцию Microsoft, значит, ветры
больше всего дули с северо запада. Направление ветров за последние несколько
лет можно определить — все они явились результатом тщательного (и не очень)
планирования. В чем, по вашему, смысл Windows 98 Second Edition? А как на
счет бесчисленных служебных пакетов для Visual Studio? Сможете ли вы навскид
ку припомнить все номера вышедших в свет версий ADO? Пробовали ли вы за
пускать утилиту от Microsoft, определяющую наиболее подходящую для конкретной
машины версию ADO1? Не успели вы привыкнуть к Windows 2000, как на рынке
появляется Windows XP (более дорогая) — так ведь? Каждая последующая вер
сия Visual Studio знаменует для программистов VB смещение парадигмы и обе
щает кардинальным образом изменить методы написания кода.
Изменения не обошли стороной сообщества Java и C++, и, скорее всего, ими
дело не ограничится. Компания Sun несколько лет держала название своего нового
языка в секрете — собственно, оно шло вразрез с традицией именования языков.
Первоначально язык предполагали назвать «Oak», но, как оказалось, это имя уже
1
Я имею в виду программу ComCheck, которая распространяется Microsoft бесплатно и призвана по
мочь разобраться в создаваемом ADO библиотечном кошмаре.
230 Ïîñëåñëîâèå • Ñíîâà â ïëàâàíèå...
занято. Судя по всему, имя «Java» придумали с расчетом на то, чтобы «встрях
нуть» быстро развивающийся рынок разработки интернет проектов. И, действи
тельно, все мы почувствовали встряску. Кроме того, есть пространство CORBA
и COM. Или, возможно, CORBA и COM+? Или CORBA и SOAP? Кто знает —
может, сформировавшуюся брешь закроет XML? Ну, в общем, вы меня поняли…
В условиях постоянного ужесточения бизнес требований и развития техноло
гий изменения неминуемы. Пользователи едва успевают за этой динамикой, не
говоря уже о программистах (ваших, моих, пашущих на Microsoft и проч.), кото
рые часто повторяют собственные ошибки. Все эти условия благоприятствуют
сильным ветрам.
Для того чтобы устоять в бурю, нужно постоянно стремиться к созданию каче
ственных программных продуктов и регулярно повышать планку этого самого
«качества». Вам придется утрясать сроки с начальством, препираться со специа
листами по анализу рынка насчет задач, на решение которых способен тот или
иной продукт, как то разбираться с недостатками сетевой инфраструктуры… Этот
список можно продолжать бесконечно. Ничего удивительного в том, что продук
ты нашей деятельности зачастую несут оттенок незаконченности. Дело даже не
во впечатлении — они действительно являются таковыми. Вероятно, лишь в иде
альном мире можно было бы создать условия для производства абсолютно безо
шибочного продукта. Впрочем, на пути к идеалу мы движемся слишком мед
ленно — непозволительно медленно. Сосредоточьтесь на качестве, и вы сможете
завоевать уважение коллег и успех на рынке.
Для того чтобы постоянно поднимать планку «качества», нужно быть увле
ченным своей работой — только при этом условии, кстати говоря, ваши лидер
ские начинания имеют шанс на развитие. Именно увлеченность позволяет удер
живаться на плаву в шторм. Увлеченность формируется за счет баланса рабочей
деятельности, с одной стороны, и приятных для вас мелочей жизни, с другой.
Невоздержанность в той или иной сфере жизни приводит к потере увлеченности,
а следовательно, к усталости и краху. Старайтесь удержать увлеченность работой
и любовь к жизни — превращайте все свои начинания в увлекательные приклю
чения.
Еще один момент касательно «баланса». В современных рабочих условиях ба
ланс предстает в виде «смешения». Это утверждение особенно справедливо по
отношению к удаленным сотрудникам — вне зависимости от того, работают они
полный рабочий день или садятся за кодирование вечерами. При наличии кар
манных компьютеров, ноутбуков, постоянных интернет соединений через вирту
альные частные сети и прочих инструментов нашей деятельности появляется
возможность не покидать рабочее место. «Балансирование» в таких условиях
предполагает проведение 15 часов кряду в одном и том же месте — там, где можно
заниматься и работой, и личными делами. Как организовать для себя отдых —
необходимое условие «подзарядки» мозгов? Ничего определенного на этот счет я
сказать не могу, но отдыхать необходимо — иначе вы рискуете потерять увлечен
ность и, в конечном итоге, «сгореть». Если топлива не осталось, зажечь огонь за
ново не так то просто.
ßêîðü 231
ßêîðü
Якорь придает нам устойчивость, и время от времени мы к нему прибегаем. Одно
лишь наличие якоря на борту позволяет чувствовать себя спокойно даже в штор
мовую погоду. Роль якоря в нашей профессии исполняют лидерские навыки.
Выпас котов — деятельность, которой я с помощью этой книги пытаюсь вас на
учить, — предполагает проявление лидерских качеств на уровне «выше среднего
программиста». Программист в силу особенностей своей профессии сориентиро
ван на объекты, которыми можно управлять. Создавая объект с определенным
количеством открытых интерфейсов, мы ожидаем, что при обращении из другого
объекта проявят себя только они. Люди устроены немного по другому. За неко
торый период времени они могут несколько раз сменить маску, а в экстренных
ситуациях — измениться до неузнаваемости. Ваша задача — научиться работать
с людьми в их самых необычных обличьях, с тем чтобы выстроить их однона
правленную деятельность. Относительно направления, в котором всем предстоит
двигаться, вы не должны испытывать никаких сомнений. Кроме того, вам нужны
факторы притяжения (attractors). Я в данном случае не имею в виду хитрые кон
структивы из теории хаоса. Я о более простых вещах — необходимо научиться
привлекать к себе людей за счет уверенного лидерства. Даже самый талантливый
руководитель на это не способен. Творческому и продуктивному программисту
это тоже не под силу. Но, сосредоточившись на развитии в своем характере лидер
ских качеств, вы сможете добиться в этой области нужного результата. Дело не
в методиках. Совершенствовать методики позитивного мышления можно сколь
ко угодно — привлекательными для сотрудников они все равно не станут. Неза
менимым в этом отношении оказывается великолепие последовательного и про
думанного лидерства.
Вам предстоит проводить регулярный анализ эффективности своего лидер
ского поведения. Рассмотрим аналогию. Как известно, программные продукты
иногда перестают работать из за конфликта версий библиотек DLL. Это явление,
которое время от времени ставит под угрозу результаты труда разработчиков, на
зывают «библиотечным кошмаром» (DLL Hell). Правда, к счастью, все подобные
проблемы можно решить разом — просто переустановив операционную систему.
Примерно этим вам предстоит время от времени заниматься в контексте своих
лидерских качеств. Нельзя беспрерывно накапливать руководящие методики и на
деяться, что таким образом все проблемы решатся сами собой. Иногда полезно
начинать отсчет «с нуля» — каждый божий день стараться мыслить вне сложивших
ся стереотипов. «Стереотипом» в данном случае представляется существующий
метод ведения дел в отделе. Переосмысливать фундаментальные принципы лидер
ства нужно по мере необходимости. Что сделать из того, до чего вы еще не доду
мались? Какие практики следует прекратить? Трудно надеяться на то, что стать
лидером программистов вам удастся лишь по той причине, что вы занимаете пост
менеджера, руководителя группы разработчиков, начальника отдела разработки —
да хоть менеджера по информации! Право на лидерство нужно еще заслужить —
для этого необходимо осознать свои слабые места и стремиться к их устранению.
232 Ïîñëåñëîâèå • Ñíîâà â ïëàâàíèå...
Надеяться на то, что за ваши достоинства вас будут превозносить до небес, не
стоит — но, по крайней мере, они (достоинства) возымеют действие на сотрудни
ков компании. Ваши недостатки, наоборот, не пройдут незамеченными — о них
будут говорить, в том числе и вам самим; да, так устроен мир, ничего не подела
ешь. В общем, налегайте на свои достоинства.
Кое какой материал в этой своей книге я представил в форме наставлений. На
самом деле их было предостаточно. Может быть, именно по этой причине вы до
читали книгу до конца — вам нужна была проповедь. Надеюсь, она прошла небез
результатно и поможет вам в последующей деятельности.
Дж. Хэнк Рейнуотер
Январь 2002
П р и л о ж е н и е
А
Êàê óõàæèâàòü çà
æèâíîñòüþ — ýëåêòðîííûé
àäìèíèñòðàòîð
У программ с открытым исходным кодом есть много достоинств и совсем немно
го недостатков. Как известно, главное для нас — стандарты. В то же время при
наличии исходного кода у нас появляется возможность вводить собственные стан
дарты. Я решил предоставить в ваше распоряжение исходный текст электронного
администратора — быть может, с ним вы сможете добиться успеха чуть быстрее,
чем без него. Должен предупредить, что эта программа предназначена исключи
тельно для личного пользования — соответственно ее нельзя перепродавать, а так
же сначала переделывать, а потом перепродавать. Для ее загрузки зайдите на сайт
http://www.piter.com.
Электронный администратор (подробнее см. главу 4) написан в среде Visual
Basic 6.0 с установленным служебным пакетом 5. В качестве базы данных приме
няется Access 2000. Помимо стандартных элементов VB, я обращался к следую
щим средствам:
интерфейсы источников данных от Microsoft;
библиотека Microsoft ActiveX Data Objects 2.6;
Crystal Reports версии 8.5 (отдельные компоненты)1;
Microsoft Direct Speech Synthesis;
Microsoft Agent Control 2.0;
Microsoft Scripting Runtime;
Microsoft Direct Speech Recognition.
1
В Crystal Reports 8.5 какое то невероятное количество библиотек DLL. У меня установлена полная
версия этого пакета для разработчиков, и для того чтобы с отчетами можно было хоть что то делать,тре
буется великое множество файлов. При этом ни сам пакет, ни мастер развертывания (Deployment Wizard)
в VB 6.0 не справляется с идентификацией этих файлов.
234 Ïðèëîæåíèå À • Êàê óõàæèâàòü çà æèâíîñòüþ — ýëåêòðîííûé àäìèíèñòðàòîð
Помимо стандартных компонентов, в этом проекте я обратился к довольно
древнему элементу управления календарем, созданным MSCAL.OCX1 из поставки
Access 97, и специальным элементом управления датами под названием MyData.
OCX, который вы можете скопировать с сайта вместе с исходным кодом.
Можете заменять ссылки и компоненты как вам заблагорассудится. Только не
забудьте соответствующим образом скорректировать код.
INI файл регулирует конфигурацию программы и жестко задает структуру ка
талогов. Каждому «ресурсу», определенному в таблице базы данных с аналогич
ным именем, должен соответствовать каталог для экспорта отчетов. В каталоге
с шаблонами содержатся задействованные в программе файлы Crystal Reports.
Стоит только открыть самораспаковывающийся файл с кодом, и он автоматичес
ки создаст нужную структуру каталогов. В тот же момент база данных наполнит
ся шаблонными данными.
В базе данных есть ряд таблиц соответствия, которые вы можете заполнить
так, как сочтете нужным. На то, чтобы сделать еще несколько таблиц, мне элемен
тарно не хватило времени — в частности, я не добрался до таблицы проектов, ко
торую можно было бы соединить с таблицей заданий. Это решение, надо сказать,
упростило процесс генерации отчетов средствами программы Crystal Reports, а по
тому имейте в виду: любое изменение скажется на шаблоне отчетов. Если хотите,
можете изменить мой код — мне, конечно, будет интересно увидеть результат. Воз
никнут вопросы — пишите на адрес herdingcats@mindspring.com. Постараюсь на все
отвечать.
А теперь — несколько слов о дополнительных экранах программы, которые спо
собны оказать существенную помощь в деле организации личных информацион
ных потоков. На рис. А.1 изображено родительское окно.
Экран Today, показанный на рис. 4.3 в главе 4, несомненно, важен для система
тизации административных функций, однако им одним программа не исчерпыва
ется. Согласно моей теории планирования руководящей деятельности, любое за
дание нужно рассматривать в трех основных измерениях: Project (Проект), Source
(Источник) и Assigned (Назначенные задания). Представление Project (рис. А.2) по
могает отслеживать ход выполнения всех заданий в рамках проекта. Представле
ние Assigned (рис. А.3) демонстрирует распределение заданий между сотрудника
ми. Наконец, представление Source (рис. А.4) напоминает о том, кто (например,
какой процесс или комитет) требует результата от вас. Все это дочерние окна ин
терфейса MDI с изменяемым размером, поэтому открывайте их столько, сколько
хотите.
По информации с каждого из этих экранов генерируются отчеты, которые мож
но отправить по почте сотрудникам, принести на собрание, предоставить началь
нику, просмотреть на предмет согласования ваших планов с деятельностью дру
гих подразделений компании. До тех пор пока приложения для коллективной
работы не достигнут определенного уровня зрелости, несогласованность в дей
1
Этот элемент OCX вызывает у меня некоторые подозрения. Он вроде как не обнаруживает зависимо
стей от других файлов (помимо стандартных файлов Windows API), однако заставить его работать
без Access 97 мне не удалось. Я соорудил собственную версию этой программки на основе элемента
управления календарем из поставки VB 6.0, так что если при загрузке кода вы наткнетесь на нерабо
тающую ссылку, милости прошу!
ствиях между отделами при отслеживании разных типов заданий будет оставать
ся обычной практикой — при этом каждый из отделов будет навязывать собствен
ный стиль руководства. Поэтому для управления списками заданий часто при
влекается метод «вырезания и вставки», а управленческие реалии, которые больше
напоминают страшный сон, некоторые именуют не иначе как «казнь через разре
зание на тысячу кусочков».
Три окна со списками, расположенные по периметру родительского окна (см.
рис. А.1), предназначены для быстрого доступа к трем основным представлени
ям. В этих окнах содержатся списки имен проектов, ресурсов, которыми можно
назначить новые задания (в основном это имена людей), и источников заданий,
над которыми вы работаете или которые отслеживаете. По двойному щелчку на
любом пункте списка на экране появляется новое представление, в котором зада
ния рассортированы в соответствии с назначением представления.
Я предпочитаю выделять отдельный элемент Source для отслеживания тех за
даний, которые передо мной ставит моя многоуважаемая руководительница. За
быть предписание начальницы — это же так глупо (не говоря уже о том, что этот
опрометчивый поступок ставит под угрозу карьерные перспективы)!
Выполнение функций, представленных в открываемых щелчком правой кноп
кой мыши контекстных меню, обеспечивается несколькими объектами контей
нерами. Испробуйте их или хотя бы взгляните на соответствующий код обработ
ки событий.
Ну и все на этом. Хотите узнать больше — поройтесь в исходном тексте. Забав
ляйтесь с живностью, но не обижайте ее!
П р и л о ж е н и е
Б
Êàê äàòü ñêîòèíå â ãëàç —
êðèòè÷åñêèé îáçîð
êîäà ýëåêòðîííîãî
àäìèíèñòðàòîðà
В главе 6, в разделе «Кодовая полиция», я объяснял, как стать кодовым полицей
ским. Сохранять объективность при чистке собственного кода очень сложно, но
я постараюсь. Связав в названии этого приложения свой код со скотным двором,
я надеялся подсказать вам, что я собираюсь делать. Все, что я хочу, — это чтобы
вы разобрались в процессе критического обзора кода и обратили внимание на не
которые моменты, которые играют существенную роль в процессе проверки кода,
написанного подотчетной вам группой.
Имея перед глазами исходный код, вам будет легче читать это приложение.
Как я уже говорил в приложении А, скачать код можно c сайта http://www.piter.com.
Êîíòåêñò è ïðîèñõîæäåíèå
ïðîãðàììíîãî ïðîäóêòà
Код электронного администратора я написал вскоре после прекращения работы
над неким веб проектом, призванным облегчить административную волокиту,
сопровождающую любой процесс разработки программного обеспечения. По
скольку времени на написание кода, который мне позже предстояло самому же
раскритиковать, категорически не хватало, для иллюстрации нескольких архи
тектурных принципов я привлек материалы упомянутого проекта. Эксперимент
этот, принесший мне немало забавных впечатлений, кажется, удался.
Не скажу, что код, о котором идет речь, может по своему качеству соревно
ваться с коробочными продуктами, но, в общем, он не так уж плох и с моими ад
министративными функциями справляется успешно.
Ïðàâèëà èãðû
Анализировать код я намерен по методике, изложенной в главе 6. Итак, как я уже
говорил, хороший код отличается следующими особенностями.
238 Ïðèëîæåíèå Á • Êàê äàòü ñêîòèíå â ãëàç
Он пишется в соответствии со стандартами программирования, принятыми
для конкретного языка. В таком случае применяемые разными программиста
ми методики конструирования объектов, обусловленные архитектурой, не бу
дут слишком разниться.
Внутри объектов соблюдается строгая связность. Объект — это несколько
больше, чем просто группа процедур; он должен выполнять конкретную функ
цию. Как известно, сердце не дышит, а легкие не качают кровь.
Взаимозависимость между объектами по возможности минимизируется. В боль
шинстве случаев (в отсутствие существенных доводов в его пользу) взаимоза
висимость не приводит ни к чему хорошему — она лишь усложняет сопровож
дение. На последующую изоляцию взаимозависимых объектов затрачиваются
серьезные финансовые и временные ресурсы.
Я обращу ваше внимание на ряд слабых сторон кода. По большей части они
обусловливаются сжатыми временными рамками и тем обстоятельством, что ин
струмент, к которому этот код относится, я проектировал исключительно под себя.
Пока что я ни разу не утверждал, что безгрешен, поэтому мои самоистязания вряд
ли кого нибудь удивят.
Ñëåäîâàë ëè ÿ ñòàíäàðòàì?
В основном я следовал стандартам — по крайней мере, мне так кажется. VB я поль
зуюсь, начиная с версии 1.0, и с годами отношения с кодом складывались у меня
(наверное, так же как и у вас) по разному — был и удачный, и провальный опыт.
С моей точки зрения, следование стандартам VB выражается в попытках привес
ти объектно ориентированные понятия в соответствие с этим языком, который,
по правде говоря, отнюдь не полностью поддерживает объектно ориентирован
ную парадигму.
В главе 4 я изложил понятие задачи, или задания, — основного организующе
го принципа программного обеспечения. Просмотрев мой код, вы найдете в нем
объект под именем clsTasks и вспомогательный объект clsTask. В этих двух модулях
классов инкапсулированы пользовательское взаимодействие и все данные, обра
батываемые программой в связи с заданиями. Формы frmTask и frmTasks, ответствен
ные за обработку заданий на стороне графического пользовательского интерфей
са, являются дочерними объектами объекта clsTasks. Все прочие объекты, например
clsToday, при обработке заданий обращаются к локальным экземплярам clsTasks.
Эта схема довольно удачно, как мне кажется, иллюстрирует методику многократ
ного использования объектов.
Модульные объявления объекта clsTasks выглядят так:
'---Çàêðûòûå îáúåêòû è ñîáûòèÿ
Private mo_DataService As clsDataService '---äàííûå îáúåêòà
Private mo_PickList As clsPickList
'---ñïèñîê îòáîðà äëÿ ôîðì
Private WithEvents mf_Tasks As frmTasks '---âñå çàäàíèÿ, ñâÿçàííûå ñ frmTasks
Private WithEvents mf_Task As frmTask
'---îòäåëüíîå çàäàíèå, ñâÿçàííîå ñ frmTask
Private mo_DataGrid As DataGrid
Private WithEvents mo_DataProvider As clsDataProvider '---îñíîâíûå äàííûå
Private ml_CurTaskID As Long
'---âûáðàííûé èäåíòèôèêàòîð çàäàíèÿ
Private ms_Project As String
'---ïðèìåíÿåòñÿ ñ frmProject
Private mo_ProgConfig As clsProgConfig
Private ms_TaskFilter As String
Ïðàâèëà èãðû 239
Private mo_Task As clsTask
Private mb_NeedRefresh As Boolean
Private ms_Resource As String
Private ms_Source As String
'---îòêðûòûå îáúåêòû è ñîáûòèÿ
Public Event TaskUpdated()
И что мы имеем? Много комментариев, среди которых нет ни одного, который
описывал бы назначение центрального объекта. Плохой код и бездарный кот! И ка
ким же образом человек со стороны сможет понять, зачем этот объект нужен, если
нет никаких описаний?! Для этого придется основательно изучать код. Я то его
знаю вдоль и поперек, а вот свежий взгляд наткнется на труднопреодолимое пре
пятствие.
Будь вы менеджером, вы бы, конечно, настояли на введении заголовка модуля
с указанием его автора и даты создания. Кроме того, вы, вероятно, потребовали
бы от программиста составить обзор модуля, обозначив в нем имена открытых
процедур и механизм «жизнеобеспечения» ими объекта.
Нельзя, однако же, не признать некоторые достоинства вышеприведенного
фрагмента кода. Обратите внимание на имена переменных — m в них идентифи
цирует область действия (модуль), а следующий символ обозначает тип перемен
ной (l соответствует длинной переменной, s — строковой, b — логической, и т. д.).
Теперь рассмотрим конкретную процедуру, инициирующую процесс отобра
жения формы задания:
Public Sub Show(Optional sResource As String = "")
If (mf_Tasks Is Nothing) Then
SetHourglass
Set mf_Tasks = New frmTasks
Load mf_Tasks
Set mo_DataGrid = mf_Tasks.grdTasks
'---load tasks
LoadTaskGrid
'---Load resource combo
mo_PickList.LoadPickList mf_Tasks.cboResource, PIC_RESOURCE
'---configure task list
ms_Resource = sResource
mf_Tasks.Configure ms_Resource
If sResource "" Then '---óñòàíîâêà èñòî÷íèêà äàííûõ
äëÿ îòîáðàæåíèÿ îòäåëüíîãî çàäàíèÿ
ms_TaskFilter = "Assigned =" & Chr$(39) & sResource & Chr$(39)
mo_DataProvider.Filter ms_TaskFilter
mo_DataProvider.Sort "Status"
End If
SetReady
End If
With mf_Tasks
.WindowState = 0
.Show
.ZOrder 0
End With
End Sub
Здесь, несмотря на немногочисленность комментариев по именам вызываемых
процедур, можно определить их назначение — таким образом, в некотором отно
шении этот код можно признать самодокументированным. С другой стороны, ком
ментарии модульного уровня опять же отсутствуют — о том, что это ключевая
подпрограмма с открытой областью действия, код ничего не говорит.
240 Ïðèëîæåíèå Á • Êàê äàòü ñêîòèíå â ãëàç
Êàê íàñ÷åò ñâÿçíîñòè è âçàèìîçàâèñèìîñòè?
Что касается связности, то здесь вам придется поверить мне на слово, поскольку,
как мы выяснили в предыдущем разделе, комментариев в коде не хватает и разо
браться в общем процессе исполнения и структуре кода довольно сложно. Но,
вставив комментарий насчет связности и взаимозависимости, я исправился. Вам
же полагается знать следующее.
Программа управляется объектом clsApplication с глобальной областью дей
ствия. Из него создаются и управляются на высоком уровне все остальные объек
ты. К примеру, в процедуре с понятным именемclsApplication.StartApplication со
здана родительская форма MDI и ряд других вспомогательных объектов. С точки
зрения процесса исполнения программы это сугубо положительный момент.
Объявления модулей в clsApplication выглядят так:
Private
Private
Private
Private
Private
Private
Private
Private
Private
Private
Private
Private
Private
Private
Private
Private
WithEvents mf_Parent As mdiManager
WithEvents mo_Projects As clsProjects
WithEvents mo_Tasks As clsTasks
WithEvents mo_Today As clsToday
WithEvents mo_Archive As clsArchive
mo_Contacts As clsContacts
mo_DataService As clsDataService
mo_Reports As clsReports
mo_ProgConfig As clsProgConfig
mo_PickList As clsPickList
mc_Tasks As New Collection
'---êîëëåêöèÿ îáúåêòîâ clsTasks
mc_Projects As New Collection '---êîëëåêöèÿ îáúåêòîâ clsProjects
mc_Sources As New Collection '---êîëëåêöèÿ îáúåêòîâ clsSource
mo_User As clsUser
mo_Source As clsSource
ms_DSN As String 'ïðèìåíÿåòñÿ ïðè ïîäêëþ÷åíèè
Здесь, если не считать нехватки комментариев уровня модуля, присутствуют
все дочерние объекты clsApplication. Из этого фрагмента кода в принципе можно
вывести всю объектную иерархию программы.
Реализация в программе многочисленных событий заметно «стройнит» код
форм. В большинстве случаев родителями форм выступают модули классов, при
чем имена форм явственно свидетельствуют об этих отношениях. К примеру,
clsProjects запускает frmProjects; впоследствии, если в форме происходит какое то
событие, его аналог сразу запускается в родительском элементе управления. Таким
образом, код по большей части локализуется, что, в свою очередь, способствует
инкапсуляции.
Все содержащиеся в программе основные объекты (clsTasks, clsProjects и clsToday)
обращаются к локальной копии объекта источника данных под именем clsData
Provider. Это модуль класса VB, в котором поведение источника данных прирав
нено к значению vbDataSource. Объект clsDataProvider пользуется услугами посред
ника clsDataService, причем посреднические обязанности осуществляются через
функцию под именем GetDataProviderRS, которая одним своим именем демонстри
рует факт извлечения набора записей источника данных. Здесь же расположено
большинство управляющих программой SQL операторов. Наконец, приставка
«Get» указывает на действие и в некоторой степени объясняет назначение проце
дуры. По моему, я уже достаточно пожурил свою живность насчет нехватки ком
ментариев, так что об этом недостатке я больше говорить не буду.
Ïðàâèëà èãðû 241
С точки зрения доступа к данным объект clsDataService является открытым ин
терфейсом логического звена данных. Объект clsDataProvider, описанный в преды
дущем абзаце, обеспечивает взаимодействие между данными и уровнем графи
ческого пользовательского интерфейса. В составе clsDataService есть дочерний
объект под именем clsDataAccess, который фактически осуществляет подключе
ние к базе данных и исполняет передаваемые родительским объектом SQL опе
раторы. Подобного рода разделение обслуживания сводит взаимозависимость
к минимуму и, по моему мнению, существенно облегчает сопровождение и мо
дернизацию электронного администратора.
Äðóãèå äîñòîèíñòâà è íåäîñòàòêè
По существу, я лишь мельком коснулся некоторых аспектов, которые можно было
бы проверить на этом примере. Далее я затрону еще пару вопросов, которые мо
гут вам пригодиться при проверке собственного кода.
Êàê ïðîâîäèòñÿ ïîäêëþ÷åíèå ê áàçå äàííûõ?
Соединение с базой данных устанавливается в начале исполнения, поддержива
ется в активном состоянии и по мере необходимости передается нуждающимся
в данных объектам. Эта схема вполне приемлема для двухзвенной программы с од
ним пользователем. В то же время, если мы попытаемся масштабировать мою про
грамму для нескольких пользователей, окажется, что обозначенное проектное
решение не слишком удачно. Причина, по которой я к нему обратился, заключа
ется в том, что его можно было удобно и быстро реализовать. Оправдывают ли
эти преимущества принятые решения? В принципе, мне этого хватает, поскольку
расширять свою программу я не собираюсь. С другой стороны, это наглядный
пример принятия под давлением временных ограничений простейшего решения,
о котором впоследствии можно сильно пожалеть.
Êàêóþ ðîëü â ìîåé ïðîãðàììå èñïîëíÿþò íàáîðû çàïèñåé?
Динамические наборы записей открываются в каждом объекте по отдельности
и, подобно соединению с базой данных, поддерживаются в активном состоянии.
Такое решение повышает реактивность программы, если с ней на одной физиче
ской машине работает один пользователь, но сильно ухудшает шансы на масшта
бирование. Бессвязные наборы записей в данном случае могли бы существенно
улучшить возможности масштабирования программы.
Нехватка связей между таблицами — это еще один очевидный недостаток кода,
связанный с наборами записей. Иначе говоря, вместо того чтобы задать ссылку
внешним ключом на таблицу проектов, я сохраняю имя проекта в таблице заданий.
Таким образом, я полностью исключаю возможность переименования проектов.
Плохой код и безмозглый кот! И, опять же, пожертвовав здесь значительно более
оптимальным решением, я предпочел завершить кодирование побыстрее. Впро
чем, в защиту выбранного решения выступает и то обстоятельство, что процесс
генерации отчетов с помощью программы Crystal Reports при передаче в файл
шаблон ненормализированного набора записей значительно упростился. Кроме
того, так мне стало удобнее разрабатывать сам шаблон — ведь, работая в програм
ме Crystal Designer, я просто открывал базу данных и копировал в шаблон ее поля.
242 Ïðèëîæåíèå Á • Êàê äàòü ñêîòèíå â ãëàç
Конечно, можно было бы подумать и над другими решениями, но то, на котором
я остановился, по крайней мере, позволило оперативно генерировать для подве
домственной мне группы еженедельные отчеты.
Åñòü ëè â êîäå âîëøåáíûå ÷èñëà1?
Нет. Поскольку мне хотелось сделать программу удобочитаемой, я в основном
отдавал предпочтение закрытым и открытым перечислимым типам (перечисли
мые типы с глобальной областью действия присутствуют в basMain). Есть все же
несколько массивов элементов управления, на которых вместо перечислимого
типа установлена числовая ссылка. Но в основном, чтобы понять назначение па
раметра, достаточно взглянуть на его определение.
Çàêëþ÷åíèå
Как вы заметили, большинство недостатков кода я пытаюсь оправдать нехваткой
времени. На самом деле это много о чем говорит — думаю, что когда вы будете
проводить критические обзоры кода, проблема времени окажется одной из самых
существенных. Но ведь это вы руководитель, и поэтому темп разработки, при ко
тором можно достичь приемлемого качества, всецело зависит от вашей воли. По
скольку в данном проекте я выступал сразу в двух ролях — руководителя и коди
ровщика, — можете считать, что я завалил проект во всех отношениях. Если у вас
есть желание озадачить меня какими то соображениями, связанными с моим ко
дом, отправляйте вопросы и претензии по адресу herdingcats@mindspring.com.
Я вам советую иногда перечитывать главу 6 — так вы хотя бы не забудете ос
новные принципы технического руководства. Написание этой главы, честно го
воря, побудило меня сознаться в собственных неудачах в роли руководителя, и я
в очередной раз осознал опасность неумения применять на практике полученные
знания.
1
Волшебными я называю числа, которые внезапно начинают играть серьезную роль, — по той лишь
причине, что найти определение их значений мне не удается.
Б и б л и о г р а ф и я
Ðåñóðñû äëÿ ñïåöèàëèñòîâ
ïî âûïàñó êîòîâ
В библиографию я поместил все работы, упоминаемые в сносках, и ряд других
трудов по теме книги — в основном те, которые недавно опубликованы.
Книги в категории «Разработка программного обеспечения» снабжены крат
кими аннотациями — надеюсь, так вам будет легче определиться с тем, стоит ли
читать каждое конкретное издание. По моему, если книги читаются, их не может
быть слишком много. Естественно, у каждого должны быть свои критерии отбора,
и хочется верить, что с моей скромной помощью вы сможете выбрать самые полез
ные и приятные для чтения источники.
Ðàçðàáîòêà ïðîãðàììíîãî îáåñïå÷åíèÿ
Книги в этом разделе расположены согласно моему субъективному мнению о том,
насколько они значимы для специалистов нашей области. Впрочем, они все в рав
ной степени заслуживают вашего внимания.
Êëàññè÷åñêèå òðóäû
Brooks, Frederick P. The Mythical Man)Month: Essays on Software Engineering,
Anniversary Edition. New York: Addison)Wesley, 1995.
Основываясь на собственном опыте деятельности в качестве руководителя про
екта IBM 360, Брукс излагает принципы разработки, казавшиеся в его время
новаторскими и полностью доказавшие со временем свою состоятельность. Его
хрестоматийный принцип — «стоит ввести в запаздывающий проект новых
людей, как он начнет запаздывать еще больше» — подтвержден многократно.
Обязательное чтение для всех руководителей. С точки зрения технологии дан
ные Брукса устарели, но проведенный им анализ задач персонала для групп
разработчиков полностью актуален.
Weinberg, Gerald M. The Psychology of Computer Programming, Silver Anniver)
sary Edition. New York: Dorset House Publishing, 1998.
Еще одна классическая работа в нашей области. Вейнберг, до сих пор продол
жающий активные исследования, этой своей книгой 1971 года перевернул
244 Áèáëèîãðàôèÿ • Ðåñóðñû äëÿ ñïåöèàëèñòîâ ïî âûïàñó êîòîâ
представления о разработке программных средств. Он одним из первых провел
углубленный анализ человеческого фактора и руководства в программирова
нии, объединив тем самым технические аспекты процесса разработки с психо
логией. Многие принципы, изложенные в этом издании, на сегодняшний день
не менее актуальны, чем тридцать лет назад.
Âûäàþùèåñÿ ðàáîòû
Beck, Kent. Extreme Programming Explained: Embrace Change. Reading, MA:
Addison)Wesley, 2000.
Бек часто обращается к школе программной инженерии, но при этом предлага
ет новые методы и практические рекомендации для тех, кто окончательно по
гряз в процессе кодирования. С точки зрения руководителя его методология
кажется несколько диковатой, однако нельзя не признать, что она способствует
интеграции небольших групп разработчиков. Тем кто предпочитает писать код
в одиночку, работа не понравится.
Cockburn, Alistair. Agile Software Development. New York: Addison)Wesley, 2002.
Термин «гибкая разработка» появился не так уж давно, но описанные в этой
замечательной работе методы в полной мере адаптированы к реальным повсе
дневным попыткам перенести бизнес требования на реализацию программных
продуктов. Если в ходе разработки область действия разрастается (а разве бы
вает по другому?), прочтите эту книгу — она научит адекватно реагировать на
такого рода изменения.
DeMarco, Tom, and Timothy Lister. Peopleware: Productive Projects and Teams,
Second Edition. New York: Dorset House Publishing, 1999.
Переиздание любой книги по компьютерной тематике неизменно свидетель
ствует о ее качестве. Этот труд, написанный двумя профессиональными руко
водителями программных проектов, — лишнее тому подтверждение. В работе
рассматриваются вопросы пространственного планирования, формирования ра
бочих групп, руководства специалистами и многие другие вопросы, способству
ющие упорядочиванию деятельности ведущих программистов.
Highsmith, James A., III. Adaptive Software Development. New York: Dorset
House Publishing, 2000.
Будьте уверены — этой книге уготована долгая жизнь. Воспринимать изложен
ный в ней материал временами трудновато, но лишь потому, что Хайсмит за
ставляет читателя глубже анализировать характер процессов разработки про
граммных средств. Подзаголовок книги гласит: «Сотрудничество в руководстве
сложными системами». Автор логично доказывает сложность повседневной де
ятельности руководителей проектов и программистов. Из за одних лишь его
пассажей о сотрудничестве издание стоит приобрести. Работа замечательно
дополняет труд Кокберна по той же теме.
Hunt, Andrew, and David Thomas. The Pragmatic Programmer. New York: Ad)
dison)Wesley, 2000.
Прекрасная книга! Заставьте прочесть ее всех программистов в своей группе.
Справедливость советов, которые дают ее авторы, подтверждается годами опы
Ðàçðàáîòêà ïðîãðàììíîãî îáåñïå÷åíèÿ 245
та; не сомневаюсь, что по мере ознакомления с ней вы устанете кивать в знак
согласия. Предложенная авторами практическая методика управления осно
вывается на предотвращении хаотичности в разработке программных средств.
McBreen, Pete. Software Craftsmanship. New York: Addison)Wesley, 2002.
Смелыми и аргументированными рассуждениями Макбрин обеспечил своей
книге устойчивые позиции среди литературы по программной инженерии. Не
смотря на подзаголовок «Новые веяния», автор утверждает, что мастерство ко
дирования знаменует собой возврат к истокам разработки программных средств.
Если вы согласны с тем, что кодирование есть не что иное, как искусство, эта
книга для вас. Если вы не согласны, все равно прочтите эту книгу — возможно,
она вас переубедит.
McCarthy, Jim. Dynamics of Software Development. Redmond, WA: Microsoft
Press, 1995.
Написанная хорошим языком и далекая от поверхностного взгляда книга,
в которой рассказывается о том, на какие ухищрения идут группы разработчи
ков, лишь бы поставить программный продукт вовремя. Здесь отражены мно
гие проблемы, которые компании Microsoft в разное время пришлось разре
шать самостоятельно. Автор пишет с увлечением, глубоким пониманием про
блемы и прицелом на практическую деятельность. Кроме того, Маккарти из
лагает материал в категориях гибкости, и здесь нужно иметь в виду, что когда
эта книга появилась, термин «гибкость» еще не был так распространен, как се
годня. Можете рассказать об этой книге на следующем производственном со
вещании.
Ïðèìå÷àòåëüíûå ðàáîòû
Brown, William H., et al. AntiPatterns: Refactoring Software, Architectures,
and Projects in Crisis. New York: John Wiley & Sons, 1998.
Эта и следующая книги доходчиво доказывают педагогические преимущества
ложных приемов. В книге анализируются проблемы, с которыми вы наверняка
уже сталкивались. Кроме того, в ней изложены многочисленные полезные ме
тодики разрешения трудностей в кодировании.
Brown, William H., et al. AntiPatterns in Project Management. New York: John
Wiley & Sons, 2000.
Эта книга, ориентированная на анализ методик управления с позиций негатив
ных эталонов, органично дополняет мои соображения относительно «обратной
стороны» деятельности руководителей (см. главу 7). Серьезно помогает в оценке
собственного стиля руководства.
Constantine, Larry L. Beyond Chaos: The Expert Edge in Managing Software
Development. New York: Addison)Wesley, 2001.
Сборник статей, написанных разными авторами, но, тем не менее, вышедших
под именем Ларри Константайна. Тематический диапазон — от вопросов, свя
занных с персоналом, до процессов и соблюдения сроков. Менеджменту и кол
лективной работе посвящен целый раздел.
Constantine, Larry L. The Peopleware Papers. Upper Saddle River, NJ:Yourdon
Press, 2001.
Концептуально Константайн относится к тому же лагерю, что и Демарко с Лис
тером (см. раздел «Выдающиеся работы»). Работа представляет собой сборники
статей, опубликованных за несколько лет в ведущих журналах, посвященных раз
работке программных продуктов. Книгу можно начинать читать с любой стра
ницы. Особо занимательны взгляды автора на руководство специалистами.
Glass, Robert L. ComputingFailure.com. Upper Saddle River, NJ: Prentice Hall, 2001.
Подборка рассказов Гласса о несостоятельных проектах. Акцент сделан на бан
кротствах в период бума интернет компаний. Прекрасное изложение материа
ла и дельные прогнозы по поводу связи незавершенки с объемом инвестиций.
Glass, Robert L. Software Runaways. Upper Saddle River, NJ: Prentice Hall, 1998.
Уже много лет Гласс информирует общественность о несостоятельных про
граммных проектах и весьма в этом преуспел. Анализ он проводит с точки зре
ния программной инженерии, а о последних «достижениях» пишет увлекательно
и осведомленно.
Maguire, Steve. Writing Solid Code. Redmond, WA: Microsoft Press, 1993.
Акцент в этой книге делается на достижение безошибочности кода C, однако
изложенные в ней принципы применимы к любому языку. Работа сопоставима
с упомянутым в этом разделе изданием Макконнелла. Они обе написаны при
мерно в одно время и прекрасно дополняют друг друга.
Malveau, Raphael, and Thomas J. Mowbray. Software Architect Bootcamp.
Upper Saddle River, NJ: Prentice Hall, 2001.
Книга эта входит в серию Всемирного института программных архитекторов
(Worldwide Institute of Software Architects, WWISA). Прекрасно разъясняет
существо программной архитектуры для тех, кто не отличает ее от проектного
решения.
McConnell, Steve. Code Complete. Redmond,WA: Microsoft Press, 1993.
Хрестоматийный труд о программировании на C. Практические рекомендации
сохраняют справедливость и сейчас, в контексте современных проблем коди
рования — взять хотя бы раздел о соглашениях по именованию. Все, что сооб
щает Макконнелл, помогает писать самодокументированный код.
Olson, Don S., and Carol L. Stimmel. The Manager Pool: Patterns for Radical
Leadership. New York: Addison)Wesley, 2002.
Если вам интересно сравнить собственные навыки руководства программистами
с опытом других специалистов, эта книга — для вас. Различные модели руко
водства разбираются с психологической точки зрения. Особой похвалы авторы
заслуживают за классификацию универсальных поведенческих моделей, кото
рых придерживается большинство руководителей программных продуктов.
Sewell, Marc T., and Laura M. Sewell. The Software Architect’s Profession: An
Introduction. Upper Saddle River, NJ: Prentice Hall, 2002.
Еще одно наименование из серии WWISA. Авторами выступили президент это
го института вместе со своей женой — специалистом в области клинической
Ðàçðàáîòêà ïðîãðàììíîãî îáåñïå÷åíèÿ 247
психологии. Весьма занимательный труд, читается на одном дыхании. Роль про
граммного архитектора сравнивается с профессией «настоящего» архитектора.
Yourdon, Edward. Death March. Upper Saddle River, NJ: Yourdon Press, 1999.
Еще один классический труд. Всем нам приходилось участвовать в «умерших»
проектах, и всякий раз мы не понимали, почему они такими становятся. Йор
дон объясняет не только причины этого явления, но и способы реанимации
проекта (правда, дело это довольно сложное). Подзаголовок «Универсальное
руководство разработчика программного обеспечения по реанимации «умер
ших» проектов» говорит сам за себя.
Yourdon, Edward. Decline & Fall of the American Programmer. Englewood Cliffs,
NJ: Yourdon Press, 1993.
Первое издание этой книги, написанной одним из ведущих специалистов в на
шей области, оказало эффект разорвавшейся бомбы. С тех пор многие рассмат
риваемые в этом труде Йордона темы получили продолжение в работах других
авторов. Заголовок немного обескураживает, но содержание актуально по сей
день. Во многих университетах эта книга даже введена в учебный план.
Yourdon, Edward. Rise & Resurrection of the American Programmer. Upper
Saddle River, NJ: Yourdon Press, 1996.
Продолжение предыдущей работы Йордона, причем не менее значимое, чем
первая часть. Обширный опыт Йордона позволяет ему с легкостью анализиро
вать различные тенденции. Прекрасно дополняет более пессимистичный труд,
изданный несколькими годами ранее.
Ïîëåçíûå ðàáîòû
Bullock, James, Gerald M. Weinberg, and Marie Benesh, eds. Roundtable on
Project Management. New York: Dorset House Publishing, 2001.
Сборник дискуссий о руководстве проектами, проходивших на разных веб сай
тах. Весьма занимательные свидетельства о том, как выявить трудности в вы
полнении проекта с точки зрения персонала и процесса. Помогает избежать
подобных ситуаций в собственных проектах.
DeMarco, Tom. The Deadline. New York: Dorset House Publishing, 1997.
Димарко — один из лучших специалистов, исследующих проблемы кадрового обес
печения программных проектов. Конкретно эта книга написана в жанре рома
на. Об управлении проектами говорится таким языком, что оторваться трудно.
Freedman, Daniel P., and Gerald M. Weinberg. Handbook of Walkthroughs,
Inspections, and Technical Reviews. New York: Dorset House Publishing, 1990.
Книга в значительной степени устарела, но, с другой стороны, проблема, кото
рой она посвящена, очень мало исследована. В частности, здесь изложен под
робный план проведения технических обзоров.
Humphrey, Watts S. Managing the Software Process. New York: Addison)Wes)
ley, 1989.
Классический труд. Прочитать его стоит всем — даже тем, чьи взгляды не со
впадают с позицией Хэмфри, который исходит из принципов школы программ
248 Áèáëèîãðàôèÿ • Ðåñóðñû äëÿ ñïåöèàëèñòîâ ïî âûïàñó êîòîâ
ной инженерии. Несмотря на то что с момента выхода книги прошло 15 лет,
многие изложенные в ней универсальные принципы до сих пор актуальны; кро
ме того, любопытно сравнить предлагаемые в ней принципы с принципами дру
гих методологий разработки.
Jones, Capers. Applied Software Measurement. New York: McGraw)Hill, 1991.
Книга из серии Института программной инженерии (Software Engineering Insti
tute, SEI). (Кстати, в той же серии вышла предыдущая книга Уотса Хэмфри.)
Ее предмет — контроль качества программных средств — не так очевиден, как
кажется на самом деле. Вместо того чтобы мыслить по стереотипу «если оно
работает, значит, можно выпускать», советую ознакомиться с изложенными
в этой книге принципами и впредь перед компиляцией уделять больше внима
ния вопросам тестирования.
Kerth, Norman L. Project Retrospectives. New York: Dorset House Publishing,
2001.
Если вам нужен современный справочник по критическому обзору проектов,
считайте, что вы его уже нашли. Автор — ведущий специалист в рассматривае
мой области, хотя публикуется довольно редко. На мой взгляд, в книге много
дельных и обдуманных предложений.
Whitehead, Richard. Leading a Software Development Team: A Developer’s
Guide to Successfully Leading People & Projects. New York: Addison)Wesley,
2001.
Уайтхеду удалось написать доступную по стилю изложения книгу, ориентиро
ванную на начинающих руководителей программных проектов. Составленная
по модели «вопрос ответ», она очень удачно раскрывает многие из тех проблем,
с которыми все мы сталкиваемся в деле выпаса котов.
Îáùèå ðàáîòû ïî ìåíåäæìåíòó
Carlson, Richard. Don’t Sweat the Small Stuff at Work. New York: Hyperion, 1998.
Champy, James, and Nitin Nohria. The Arc of Ambition. New York: Perseus Books,
2000.
Covey, Stephen R. Principle Centered Leadership. New York: Simon & Schuster,
1992.
Covey, Stephen R. The 7 Habits of Highly Effective People. New York: Simon &
Schuster, 1989.
Grove, Andrew S. Only the Paranoid Survive. New York: Random House, 1996.
Katzenbach, Jon R., and Douglas K. Smith. The Wisdom of Teams. New York:
HarperCollins, 1999.
Pasternack, Bruce A., and Albert J. Viscio. The Centerless Corporation. New York:
Simon & Shuster, 1998.
Welch, Jack. Straight from the Gut. New York: Warner Business Books, 2001.
Ðàçíûå ðàáîòû 249
Ðàáîòû ïî ÿçûêàì ïðîãðàììèðîâàíèÿ
Appleman, Dan. Moving to VB .NET: Strategies, Concepts, and Code. Berkeley,
CA: Apress, 2001.
Foxall, James D. Practical Standards for Microsoft Visual Basic. Redmond, WA:
Microsoft Press, 2000.
Hollis, Billy S. Visual Basic 6 Design, Specification, and Objects. Upper Saddle River,
NJ: Prentice Hall, 1999.
Ðàçíûå ðàáîòû
Blake, William. The Complete Poetry and Prose of William Blake. Edited by David
V. Erdman. Berkeley, CA: University of California Press, 1982.
Elliot, T. S. Collected Poems 1909 1962. New York: Harcourt Brace Jovanovich,
1971.
Kauffman, Stuart. At Home in the Universe. New York: Oxford University Press,
1995.
Kranz, Gene. Failure Is Not an Option. New York: Simon & Schuster, 2000.
Levinson, Daniel J. The Seasons of a Man’s Life. New York: Ballantine Books, 1978.
Merton, Thomas. No Man Is an Island. New York: Harcourt Brace Jovanovich, 1955.
Raymond, Eric S., ed. The New Hacker’s Dictionary, Third Edition. Cambridge, MA:
The MIT Press, 1998.
Rich, Adrienne. The Dream of a Common Language. New York: W. W. Norton &
Company, 1978.
Shenk, David. The End of Patience: Cautionary Notes on the Information Revo
lution. Bloomington, IN: Indiana University Press, 1999.
Strathern, Paul. Turing and the Computer. New York: Doubleday, 1997.
Tzu, Sun. The Art of War. New York: Dell Publishing, 1983.
Wallace, James, and Jim Erickson. Hard Drive: Bill Gates and the Making of the
Microsoft Empire. New York: John Wiley & Sons, 1992.
Ullman, Ellen. Close to the Machine. San Francisco: City Lights Books, 1997.
Yeats, William Butler. Selected Poems and Three Plays of William Butler Yeats.
Edited by M. L. Rosenthal. New York: Collier Books, 1986.
Àëôàâèòíûé óêàçàòåëü
Ñèìâîëû
.NET, среда разработки 141
4+1, модель представления архитектуры 129
4GL, языки программирования четвертого
поколения 131
A
Access 2000, система управления
базами данных 233
ACT!, приложение 85
ADO, технология 229
Amazon.com, компания 223
ARPANET, сеть передачи данных 187
B
Bell Labs, компания 77
C
C++, язык программирования 131, 229
Chess Master 5000, компьютерная игра 199
COBOL, язык программирования 73
COM, модель 230
COM+, модель 230
ComCheck, программа 229
CORBA, архитектура 230
Crystal Reports, система генерации отчетов 234
G
General Electric, компания 188
I
Intel, компания 188
J
Java, язык программирования 103, 229
L
Lotus Notes, приложение 85
M
Microsoft Outlook, приложение 85
Microsoft Press, издательство 216
Microsoft Project, приложение 85
Microsoft Team Manager, приложение 85
Microsoft, компания 161, 170, 189, 195, 215,
216, 230
MSDN, библиотека документов 85
P
Pentium, семейство процессоров 188
R
Radio Shack, компания 154
V
Visual Basic 6.0, среда программирования 233
Visual Basic, язык программирования 131,
132, 141
Visual Studio, среда разработки 229
W
Windows 3.0, операционная система 138
Windows, семейство операционных
систем 189, 229
X
XML, язык разметки 230
À
агрессивный параноик 188
Адамс, Скотт (Scott Adams) 117
адаптация к роли руководителя 26, 44, 45
подбор персонала 37
поощрение и вознаграждение 40, 41
породы программистов 31
стереотипы
программиста 29
руководителя 27, 29
умение
думать 42
слушать 42, 44
слышать 42, 44
адаптивная разработка приложений 135
адекватность руководства 99
административные функции
руководителя 63, 80
административный фильтр 64
денежное поощрение сотрудников 77
задания программистов 67
Àëôàâèòíûé óêàçàòåëü
административные функции
руководителя (продолжение)
координация программистов 72, 76
наем сотрудников 74
планирование 70
повышение квалификации 74
подготовка преемника 79
продвижение сотрудников по службе 77
раздражители 66
просьбы подчиненных 65
служба мгновенных сообщений 67
электронная почта 66
разрастание проекта 68, 70
увольнение сотрудников 76
фокусировка 65, 66
формирование команды 74
административный фильтр 64
администрирование
и лидерство 91
индивидуальные навыки 90
неподконтрольные области деятельности 92
подконтрольные области деятельности 92
Алман, Элен (Ellen Ullman) 30
анализ предметной области 129
аналитические позиции 129, 130
архитектура 52, 128
концепции 129
требования 129
Á
Бек, Кент (Kent Beck) 217
Белл, Александр Грэм (Alexander
Graham Bell) 208
беседа один на один 116
Бетменг, Дин (Dene Bettmeng) 211
библиотечный кошмар 231
бизнес требования 53
Блейк, Уильям (William Blake) 48
Брукс, Фредерик (Frederick Brooks) 38
Брукса закон 197
бумажные носители
недостатки 83
преимущества 83
прогноз развития 84
быстрая разработка приложений (RAD) 131
Бэкон, Френсис (Francis Bacon) 50
Â
ведение совещаний 107, 123
Вейнберг, Джеральд (Gerald Weinberg) 73
взаимозависимость 142
взаимоотношения с окружающими 97
влияние внешних раздражителей 104
вознаграждение отличившихся 178
временщик 156
всезнайка 150
выделение структурных подразделений 98
выращивание программных продуктов 126
251
Ã
Гарланд, Джуди (Judy Garland) 145
Гейтс, Билл (Bill Gates) 188, 189
Гелб, Майкл (Michael Gelb) 144
генерал 151
гений 158
гибкая разработка программных продуктов 218
Гласс, Роберт (Robert Glass) 71
Гроув, Энди (Andy Grove) 188, 189, 201, 226
Ä
да Винчи, Леонардо (Leonardo da Vinci) 144
делегирование 172
денежное поощрение сотрудников 77
Джонс, Кейперс (Capers Jones) 139
диктатор 151
Демарко, Том (Tom DeMarco) 68
дисциплина 198
документирование 53
достижение успеха 81, 106
адекватность руководства 99
баланс между руководством
и лидерством 81
безбумажное делопроизводство 85, 86,
88, 90
взаимоотношения с окружающими 97
выделение структурных
подразделений 98
документооборот 83, 84
информационный поток 92
контроль 91
навыки администрирования 90
назначение заданий 93
ожидания 96
определение проекта 101
повышение организованности в масштабах
компании 98
превращение информации в знания
и действия 82, 84, 85, 90
принципы 105
рабочие часы 95
рабочий стол 82
разработка архитектуры 94
руководство
инфраструктурой 103
продуктами 99
процессами 101, 103
тестирование 103
техническое обеспечение
программистов 105
Å
еженедельные совещания 107
естественный отбор 50
лидерство 228
адаптация 181, 191
вознаграждение отличившихся 178, 191
возрастные аспекты 185
и администрирование 91
и руководство 81, 231
исправление кода 179, 191
исследования 224
мотивирование сотрудников 182
вознаграждение 184
восхищение 184
долг 183
знание 185
принуждение 183
наставничество 177, 191
негативный эталон 148
вариации 149
исключения 149
последствия 149
решения 149
симптомы 149
основные принципы 168, 192
делегирование 172, 191
передача знаний 170, 191
понимание 168, 191
проверка 174, 191
участие 175, 191
отношения с начальством 193, 204
геройство 196
готовность к неожиданностям 200
опасность инерции 201
разумная оценка своих способностей
199
субординация 194
точка зрения начальника 193
участие в планировании 197
честность и принципиальность 195
ощущение одиночества 224
порочный стиль 147, 148, 165, 166
гениальность не к месту 158
заигрывание с дьяволом 162
мелочная опека 150, 152
неорганизованность 155
строительство империи тьмы 160
предвидение 180, 191
преодоление трудностей 164
реакция на критику 163
систематизация административных
функций 225
стратегическое планирование 225
теория и практика 190
увлеченность 230
факторы притяжения 231
È
информационный поток 92
исправление кода 179
É
Йордон, Эдвард (Edward Yourdon) 197
Ê
Кави, Стивен (Stephen Covey) 44
каркас решений Microsoft (MSF) 215
Карлсон, Ричард (Richard Carlson) 96
Кауфман, Стюарт (Stuart Kauffman) 135
Кит, Норман (Norman Keith) 119
код
практичность 53
чистота 53
чтение 73
кодовая полиция 139
законность 139
нарушения 140, 142
неотвратимость наказания 142
скорый суд 142
Кокберн, Алистер (Alistair Cockburn) 219
командные усилия 198
компетентность 198
комплексная система автоматизации (AAS) 215
комплексное наставничество 178
консенсус 122
Константайн, Ларри (Larry Constantine) 97
конструирование программных продуктов 126
контроль 51
концепция разумной машины 180
координация программистов 72
Корси, Дэвид (David Coursey) 221
Кранц, Джин (Gene Kranz) 198
критерии успеха 140
критика 163
критический обзор кода 139
минимизация взаимозависимости между
объектами 238, 240
соблюдение стандартов
программирования 238
строгая связность внутри объектов
238, 240
культурное разнообразие 212
культурный фактор в руководстве 210
мотивация сотрудников 211
язык 210
Àëôàâèòíûé óêàçàòåëü
лидерство (продолжение)
форма и содержание 187
человеческие отношения 226
Листер, Тимоти (Timothy Lister) 68
личные контакты 210
личный информационный секретарь (PIM) 85
Ì
Макбрин, Пит (Pete McBreen) 78, 221
Маккарти, Джим (Jim McCarthy) 42
Мальво, Рафаэль (Raphael Malveau) 129
Маубрей, Томас (Thomas J. Mowbray) 129
машинный разум 180
мелочная опека 150, 165
Мертон, Томас (Thomas Merton) 102
методология разработки программ 213
гибкая разработка 218
метод MSF 215
программная инженерия 213
экстремальное программирование 217
мониторинг 174, 209
мотивирование сотрудников
вознаграждение 184
восхищение 184
долг 183
знание 185
принуждение 183
мыльный пузырь 221
Í
навыки администрирования 90
наем сотрудников 74
назначение заданий 93
накопление усталости 162
нарушения принципов проектирование
игнорирование стандартов 140
последствия 143
сильная взаимозависимость 142
слабая связность 142
наставничество 177
комплексное 178
целевое 178
неадекватность руководства 99
негативный эталон 131, 134, 148
вариации 149
гениальность не к месту 158
исключения 149
накопление усталости 162
неорганизованность 155
последствия 149
решения 149
симптомы 149
строительство империй тьмы 160
неорганизованность 155, 165
нереалистичный план проекта 70
253
новичок 156
нулевой этап проектирования 133
Î
объективность 46
объектно ориентированное проектирование 64
определение проекта 101
ответственность 198
открытая распределенная обработка (ODP) 129
отношения с начальством 193, 204
геройство 196
готовность к неожиданностям 200
опасность инерции 201
разумная оценка своих способностей 199
субординация 194
точка зрения начальника 193
участие в планировании 197
честность и принципиальность 195
отображение заданий 89
отслеживание тенденций в отрасли 201
Ï
Пастер, Луи (Louis Pasteur) 200
передача знаний 170
аргументация 171
введение в проблему 171
демонстрация прикладных аспектов
проблемы 171
заключение 171
иллюстрации 171
обсуждение 171
объяснение 171
переход между элементами изложения 171
план проекта
нереалистичный 70
реалистичный 70
планирование 51, 207
повышение
дисциплины 95
квалификации руководителя 74
организованности в масштабах компании 98
подготовка преемника 79
позитивный эталон 134
понимание 168
породы программистов 31
дворняги 36
любитель 36
профан 37
разгильдяй 36
тормоз 36
эклектик 37
ковбой 38, 100
распространенные 31
архитектор 31, 38, 43
инженер 33
254 Àëôàâèòíûé óêàçàòåëü
породы программистов (продолжение)
конструктивист 32, 38
лихач 34
ученый 33
художник 32, 38, 44
редкие 34
аналогист 35
волшебник 34
минималист 34, 42
трюкач 35
порочный стиль лидерства 147
последствия нарушений 143
практичность кода 53
предвидение 180
принципы
ведения совещаний 122
достижения успеха 105, 137
Кранца 198
лидерства 168, 191, 228, 231
проектирования 136
приоритет интересов клиента 203
причины программных катастроф 71
проверка 174
программисты
сотрудничество 104
техническое обеспечение 105
уединение 104
программная инженерия
за и против 101
концепция 213
определение 214
программная катастрофа 71
программный продукт
выращивание 126
замысел 69
конструирование 69, 126
проектирование 69
специфицирование 69
тестирование 69
программный проект 101
продвижение сотрудников по службе 77
продуктивность
методы повышения 181, 206
оценка 54
предел 152
проектирование
жизненный цикл адаптивной разработки 135
нулевой этап 133
принципы 136
этапы 134
проектные ограничения 129, 130
проектные совещания 110
просьбы подчиненных 65
Ð
разрастание проекта 68, 70, 71
распределенная группа 206
взаимодействие 208
распределенная группа (продолжение)
личные контакты 210
планирование 207
проблемы 206
проверка 209
реалистичный план проекта 70
ретроспективные совещания 119
руководитель
в стиле Скарлетт О’Хара 155
временщик 156
всезнайка 150
генерал 151
диктатор 151
неорганизованный 155
новичок 156
руководство
адекватность 99
и лидерство 81, 231
инфраструктурой 103
концентрация 228
культурный фактор 210
многонациональной группой 210, 212
мотивация 211
язык 210
неадекватность 99
порочный стиль 165
программными проектами 26, 45, 99
разработка архитектуры 128
техническое лидерство 124, 126
процессами 101, 103
раздражители 228
распределенной группой 206
собой 46, 58, 62
документирование 53
естественный отбор 50
контроль 51
объективность 46
оценка 54
планирование 51
продуктивность 54
распределение заданий 53
самооценка 49
самосовершенствование 48
слабости 55
экономические функции 223
Ñ
самооценка 49
самосовершенствование 48
связность 142
систематизация заданий 89
служба мгновенных сообщений 67
совещания
беседы один на один 116
еженедельные 107
консенсус 122
ненужные 51
неэффективные 51
Àëôàâèòíûé óêàçàòåëü
совещания (продолжение)
подготовка 121
принципы ведения 122
проектные 110
результаты 122
ретроспективные 119
совместные с другими группами 117
телеконференции 120
совместные совещания 117
сотрудничество 206
стратегическое планирование 225
строитель империй тьмы 160, 165
Сун Цзу (Sun Tzu) 222
Сьюелл, Лора (Laura Sewell) 128
Сьюелл, Марк (Marc Sewell) 128
Ò
телеконференция 120
тестирование
итоговое 73
как этап производства 69
комплексное 103
контрольные сценарии 103
техническое лидерство 124, 146
аналитические позиции 129, 130
кодовая полиция 139, 140
конструирование 126, 127
обязанности архитектора 128
перспективы 145
привыкание к роли 125
проектирование 134
проектные ограничения 129, 130
разработка архитектуры 128
самоконтроль 145
успех 137
философия и практика 143
технологическая революция 221
технология 52
Томас, Дэвид (David Thomas) 126
Тьюринг, Алан (Alan Turing) 180
Ó
уверенность 198
увольнение сотрудников 76
удаленная работа 230
уединение 206
упорство 198
успех 137
Уэлч, Джек (Jack Welch) 57, 188
Ô
факторы притяжения 231
фокусировка 65
формирование команды 74
харизматический лидер 167
Хэмфри, Уотс (Watts Humphrey) 69
Ö
целевое наставничество 178
×
Черчилль, Уинстон (Winston Churchill) 75
чистота кода 53
член команды
денежное поощрение 77
наем 74
продвижение по службе 77
увольнение 76
чтение
чтобы быть в курсе 56
чтобы оставаться «на уровне» 56
чтобы стать мудрее 57
чтобы углубить свои знания 56
чувство времени 202
Ø
Шенк, Дэвид (David Shenk) 55
Ý
Эйнштейн, Альберт (Albert Einstein) 184
экстремальное программирование (XP) 217
электронная почта 66
электронный администратор 86, 233, 237
достоинства 86
задача как объект 86
источники 87
исходный код 86
назначенные задания 87
отображение и систематизация заданий 89
пользовательский интерфейс 88, 89
проекты 87
эталон
негативный 131, 134
позитивный 134
этапы производства программного продукта 69
замысел 69
конструирование 69
проектирование 69
специфицирование 69
тестирование 69
Последние комментарии
1 день 7 часов назад
1 день 12 часов назад
1 день 14 часов назад
1 день 16 часов назад
1 день 22 часов назад
1 день 22 часов назад