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

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

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

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

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

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

Прагматическое программирование ведет свое начало от философии прагматического мышления. В данной главе приводятся основные положения этой философии.

Страх показаться слабым есть величайшая из всех слабостей.

(Ж. Б. Боссюэ, Политика и Священное Писание, 1709)

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

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

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

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

Не стоит перекладывать вину на кого-либо (или на что-либо) или выдумывать отговорки. Не стоит сваливать все на субподрядчика, язык программирования, менеджмент или коллег по работе. Все они могут сыграть свою роль в неудаче, но вашим делом является решение проблем, а не отговорки.

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

Подсказка 3: Представьте варианты решения проблемы, а не варианты отговорок

Перед тем как подойти к кому-либо, чтобы высказать, почему что-либо не может быть сделано или уже сломалось, остановитесь и прислушайтесь к себе. Поговорите с резиновым утенком, стоящим на вашем мониторе, или с котом. Как звучит ваша отговорка, разумно или глупо? И как ее воспримет ваш шеф?

Смоделируйте разговор в уме. Что, вероятнее всего, скажет ваш собеседник? Спросит ли он: "А так вы пробовали?" или "А это вы учли?" Как ответить? Перед тем как пойти и сообщить плохие новости, может, попробовать что-то еще? Иногда вы просто знаете, что он собирается сказать, поэтому избавьте его от лишних забот.

Вместо отговорок представьте варианты решения проблемы. Не говорите, что это не может быть сделано, объясните, что может быть сделано для спасения ситуации. Может быть, взять да и выбросить исходный текст? Развивайте эти варианты, используя реорганизацию (см. "Реорганизация"). Стоит ли тратить время на разработку прототипа, чтобы определить лучший способ, который необходимо использовать (см. "Прототипы и памятные записки")? Стоит ли внедрять более совершенные процедуры тестирования (см. "Программа, которую легко тестировать" и "Безжалостное тестирование") или автоматизации (см. "Вездесущая автоматизация"), чтобы предотвратить дальнейшие неудачи? Возможно, вам понадобятся дополнительные ресурсы. Не бойтесь спрашивать или признаться, что нуждаетесь в помощи.

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

• Прототипы и памятные записки

• Реорганизация

• Программа, которую легко тестировать

• Вездесущая автоматизация

• Безжалостное тестирование

• Как вы отреагируете, когда кто-нибудь – кассир в банке, механик в автосервисе, или клерк придет к вам с подобными отговорками? Что в итоге можно подумать о них лично и об их фирме?

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

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

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

Причина – одно-единственное разбитое окно.

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

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

Подсказка 4: Не живите с разбитыми окнами

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

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

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

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

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

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

• Суп из камней и сварившиеся лягушки

• Реорганизация

• Команды прагматиков

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

• Можно ли сказать, когда разбивается первое окно? Какова ваша реакция? Если это произошло в результате чьего-либо решения, или по воле руководства, то как вести себя в этом случае?

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

Это не смутило солдат, они вскипятили котел воды и аккуратно положили в него три камня. Удивленные крестьяне вышли посмотреть.

"Это суп из камней", – объяснили солдаты крестьянам. "И это все, что вы в него кладете?" – спросили крестьяне. "Абсолютно все – хотя на вкус он будет намного лучше, если положить в него немного моркови". Один из крестьян убежал и быстро вернулся с корзиной моркови из своего погреба.

Через некоторое время крестьяне вновь спросили: "И это все?"

"Да", – сказали солдаты, "но пара картофелин сделает суп посытнее", И другой крестьянин убежал.

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

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

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

Иногда в этой жизни вам бы хотелось оказаться на месте солдат.

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

Подсказка 5: Будьте катализатором изменений

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

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

Подсказка 6: Следите за изменениями

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

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

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

• Энтропия в программах

• Программирование в расчете на совпадение

• Реорганизация

• Западня требований

• Команды прагматиков

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

Для лучшего добро сгубить легко.

(У. Шекспир, Король Лир, действие 1, сцена 4)

Существует старый анекдот об американской фирме, которая заказала 100000 интегральных схем на предприятии в Японии. В условиях контракта указывался уровень дефектности: один чип на 10000. Несколько недель спустя заказ прибыл в Америку: одна большая коробка, содержащая тысячи интегральных схем, и одна маленькая, в которой находилось десять схем. К маленькой коробке был приклеен ярлычок с надписью "Дефектные схемы".

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

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

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

Обычно вы пишете программы для других людей. Часто вы вспоминаете о том, что хорошо бы получить от них требования [2]. Но как часто вы спрашиваете их, а насколько хорошими они хотят видеть эти программы? Иногда выбирать не из чего. Если вы работаете над передовыми технологиями, космическим челноком, или низкоуровневой библиотекой, которая будет широко распространяться, то требования будут более строгими, а варианты – ограниченными. Но если вы работаете над новым продуктом, то у вас будут ограничения другого рода. Маркетологам придется сдерживать обещания, вероятные конечные пользователи могут строить планы, основанные на дате поставки программы, а ваша фирма, конечно, будет ограничена в денежных средствах. Профессионалы не могут игнорировать требования пользователей – просто добавить к программе новые средства или «отшлифовать» еще раз тексты программ. Мы не призываем к паническим настроениям: одинаково непрофессионально обещать невероятные сроки и срезать основные "технические углы" чтобы уложиться вовремя.

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

Подсказка 7: Сделайте качество одним из пунктов требований

Часто вы будете оказываться в ситуациях, когда необходимо идти на компромисс. Удивительно, но многие пользователи предпочтут использовать программы с некоторыми недоработками, но сегодня, чем год ожидать выпуска мультимедийной версии. Многие IT-департаменты, имеющие ограничения по бюджету, могли бы согласиться с этим утверждением. Хорошие программы (но сегодня) зачастую являются более предпочтительными по сравнению с отличными программами (но завтра). Если вы заранее дадите другим пользователям поиграться с вашей программой, то часто их отзывы будут способствовать выработке лучшего конечного решения (см. "Стрельба трассирующими").

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

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

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

• Стрельба трассирующими

• Западня требований

• Команды прагматиков

• Большие надежды

• Обратите внимание на производителей инструментальных программных средств и операционных систем, которыми вы пользуетесь. Можете ли вы найти свидетельство тому, что эти компании не испытывают неудобства, поставляя программное обеспечение, хотя им известно, что оно несовершенно? Как пользователь, вы скорее: (1) подождете, пока они устранят все ошибки, (2) выберете усложненную версию программы и примете отдельные ошибки или (3) выберете упрощенную версию программы, но с меньшим числом дефектов?

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

Инвестиции в знания окупаются лучше всего.

(Бенджамин Франклин)

Ах, старина Франклин! Никогда не лез в карман за многозначительным наставлением. Если бы мы рано ложились и рано вставали, мы стали бы великими программистами, не так ли? Ранняя птичка никогда не остается без червячка, но что при этом происходит с червячком?

Хотя в данном случае Бенджамин действительно попал в точку. Знание и опыт являются самыми важными профессиональными активами.

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

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

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

1. Серьезные инвесторы инвестируют регулярно – это как привычка.

2. Диверсификация – это залог успеха в течение длительного времени.

3. У проворных инвесторов портфель всегда сбалансирован – в нем имеются и консервативные, и высокорисковые, высокодоходные инвестиции.

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

5. Портфели нуждаются в периодическом пересмотре и повторной балансировке.

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

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

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

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

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

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

Из всех этих директив, самой важной и самой простой в исполнении является

Подсказка 8: Инвестируйте регулярно в ваш портфель знаний

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

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

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

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

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

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

• Экспериментируйте с различными операционными средами. Если вы работали только в среде Windows, поиграйте со средой Unix дома (для этой цели прекрасно подходит бесплатно распространяемая версия Unix). Если вы использовали только сборочные файлы и редактор, попробуйте интегрированную среду разработчика и наоборот.

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

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

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

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

Итак, вы жадно и много читаете, находитесь в курсе всех новейших разработок в вашей сфере (это не так-то легко) и кто-то задает вам вопрос. У вас нет даже намека на идею, каким должен быть ответ, но вы не признаете это открыто, как и многие.

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

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

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

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

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

Подсказка 9: Критически анализируйте прочитанное и услышанное

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

С глобальным принятием сети Интернет, гуру внезапно стали ближе – на расстоянии нажатия клавиши Enter. Итак, как найти гуру и вызвать его на разговор?

Здесь есть несколько простых уловок.

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

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

• Как только вы сформулировали вопрос, остановитесь и вновь поищите ответ. Выхватите несколько ключевых слов и поищите их в Интернете. Поищите подходящие списки часто задаваемых вопросов и ответов на них.

• Решите, каким образом вы зададите вопрос: в открытой форме или же частным образом. Группы новостей Usenet – прекрасное место встреч для экспертов практически по любой теме, но некоторые опасаются открытого характера этих групп. Кроме того, вы всегда можете отправить сообщение непосредственно вашему гуру по электронной почте. В любом случае используйте строку темы сообщения со смыслом. (Сообщение "Нужна помощь!" не останется незамеченным.)

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

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

• На этой неделе начните учить новый язык программирования. Всегда программировали на С++? Попытайтесь выучить язык Smalltalk [URL 13] или Squeak [URL 14]. Работаете с Java? Попробуйте поработать с языком Eiffel [URL 10] или ТОМ [URL 15]. Информация о других бесплатных компиляторах и средах разработчиков содержится в Приложении А.

• Начните читать новую книгу (но сначала прочтите эту книгу до конца!) Если вы занимаетесь детальной реализацией и программированием, прочтите книгу по проектированию и архитектуре. Если вы занимаетесь высокоуровневым проектированием, прочтите книгу о методиках программирования.

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

Лучше быть проигнорированным вовсе, чем недооцененным.

(Мэй Уэст, Красавица 90-х, 1934.)

Может быть, мы способны выучить урок, преподанный мисс Уэст. Важно не только то, что у вас есть, но и как оно упаковано. Лучшие идеи, лучшие программы или самое прагматичное мышление практически не приносят результата, если вы не можете общаться с другими людьми. Без эффективного общения удачная идея может осиротеть.

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

Мы обобщили ряд идей, которые находим полезными.

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

Планируйте то, что вы хотите сказать. Напишите «рыбу». Затем спросите себя: "Не противоречит ли это тому, что я пытаюсь высказать?" Совершенствуйте содержание, пока не наступит момент выступления.

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

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

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

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

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

Необходимо уяснить для себя приоритеты аудитории, чтобы лучше понять то, что она хочет услышать от вас. Поймайте менеджера, получившего выговор от шефа, потому что потерялась часть исходного текста программы, и вы найдете в его лице слушателя, который лучше воспринимает ваши идеи о централизованных БД данных исходных текстов. То, что вы говорите, должно быть уместным по времени и содержанию. Иногда для этого достаточно лишь задать вопрос типа: "Удобно ли сейчас поговорить о…?"

What do you want them to learn? (Чему вы хотите их научить)

What is their interest in what you have got to say? (Какова их заинтересованность в вашей речи?)

How sophisticated are they? (Насколько искушена ваша аудитория?)

How much detail do they want? (Насколько детальным должно быть выступление?)

Whom do you want to own the information? (Кто должен обладать информацией?)

How can you motivate them to listen to you? (Как мотивировать слушателей?)

Буквы оригинала складываются в слово «Wisdom» – мудрость (англ.)

Рис. 1.1. Акростих WISDOM – о понимании аудитории

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

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

Ваши идеи важны. Они заслуживают хорошего способа их подачи вашей аудитории.

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

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

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

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

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

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

Подсказка 10: Важно, что говорить и как говорить

Поскольку вы не работаете в безвоздушном пространстве, вам необходимо уметь общаться. Чем эффективнее это общение, тем более влиятельным вы становитесь.

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

Наши подсказки относительно электронной почты довольно просты:

• Перед тем как щелкнуть мышкой на кнопке SEND (Отправить), тщательно проверьте текст.

• Проверьте правописание.

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

• Используйте форматы RTF или HTML, если вы точно знаете, что все получатели смогут прочесть послание. Простой текст универсален.

• Старайтесь сводить цитирование к минимуму. Никто не любит получать назад свое собственное сообщение в 100 строк, снабженное пометкой "согласен".

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

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

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

• Архивируйте и организуйте вашу электронную почту – как получаемые, так и отсылаемые материалы.

Как обнаружили служащие фирм Microsoft и Netscape во время расследования Министерства юстиции США (1999 г.), электронная почта – это бессмертно. Постарайтесь заботиться об электронной почте так, как вы заботитесь о любой написанной записке или отчете.

• Прототипы и памятные записки

• Команды прагматиков

• Есть несколько хороших книг, описывающих взаимодействие внутри команд разработчиков [Bro95, МсС95, DL99]. Следует обратить на это особое внимание и попытаться прочесть все три книги течение следующих 18 месяцев. В дополнение к этому, книга "Dinosaur Brains" [Вег96] посвящена эмоциональному багажу, который мы вносим в рабочую среду.

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

Примечания:

1

При этом можно утешаться изречением, приписываемым контр-адмиралу д-ру Грэйсу Хопперу: "Легче просить прощения, чем получать разрешение".

2

Это, конечно шутка!

3

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

4

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

5

В оригинале английское слово annoy происходит от старофранцузского enui что также означает "наскучить".