Совет 26
Камешек в ведре воды
Что произойдет, если ты встанешь и выйдешь из офиса, чтобы никогда туда не возвращаться? Я знаю многих программистов, которые утешаются, представляя подобную сцену. Ты просто встаешь, идешь в кабинет начальника и кладешь ему на стол заявление об уходе. Они еще поймут, какого ценного работника потеряли! Подобные мечты неплохо помогают пережить по-настоящему неудачные дни, но предаваться им постоянно - не самая лучшая позиция.
Начнем с того, что на самом деле это неправда. Люди увольняются с работы каждый день. Многих увольняют. Многие увольняются сами. Некоторые даже реализуют твою мечту и демонстративно уходят без уведомления. Но покидаемые ими фирмы крайне редко ощущают последствия их ухода. В большинстве случаев, даже когда речь идет о ключевых позициях, эффект оказывается на удивление слабым. Для фирмы твое присутствие на работе подобно камешку в ведре воды. Конечно, от его наличия общий уровень воды немного поднимется. Ты выполняешь свои обязанности. Ты вносишь свой вклад. Но если убрать из ведра камешек и посмотреть на поверхность воды, вряд ли кто-то сможет увидеть разницу.
Я не пытаюсь тебя унизить. Нам всем нужно чувствовать, что наш вклад что-то значит. И это действительно так. Но мы настолько привыкаем смотреть на все сквозь призму собственной личности, что забываем о наличии вокруг других личностей. Все окружающие тебя сотрудники компании - разумные и автономные существа, намертво сцепленные со своими личностями и смотрящие на свою работу исключительно с точки зрения своего "я". Подумай вот о чем: если завтра ты уволишься, это произведет (в среднем) примерно такой же эффект, как увольнение любого из твоих коллег.
Однажды мне довелось работать с одним из наиболее производительных директоров по информационным технологиям одной из самых влиятельных фирм в мире. Он и его команда (частью которой был я) получали все награды и задавали в фирме все стандарты в области информационных технологий. Очевидно, этот парень нашел рецепт магического эликсира, который распылял в бесплатные закуски, подававшиеся на организуемых им Y2K-вечеринках.
Один из наиболее действенных советов, которые я услышал от этого директора, - и он повторял его снова и снова - звучал так: ты никогда не должен чувствовать себя слишком комфортно. Он рассказывал, что каждый день после пробуждения намеренно и недвусмысленно напоминал себе, что может в любой момент лишиться своего высокого поста. Это может случиться даже сегодня.
Его сотрудники смотрели с недоверием. Нет. Сегодня этого не произойдет. Все идет так хорошо. Все работает на вас.
Но это была его точка зрения. Такое качество, как скромность, вырабатывают не для того, чтобы претендовать на большую духовность. Оно позволяет давать более четкую оценку своим действиям. Наш директор по информационным технологиям учил, что чем более ты успешен, тем выше вероятность сделать роковую ошибку. Когда все работает на тебя, ты начинаешь намного реже сомневаться в своих суждениях. Если используемый подход всегда срабатывал, вряд ли ты будешь искать новые лучшие подходы. Ты становишься самонадеянным, что ведет к появлению областей, в которых ты не разбираешься. Чем более незаменимым ты себя считаешь, тем менее незаменимым ты становишься (и тем меньше людей хотят с тобой работать).
Чувство незаменимости является плохим симптомом, особенно у разработчика программного обеспечения. Заменить нельзя только того, кто справляется со своей работой особым, недоступным другим способом. Хотя мы все хотели бы претендовать на гениальность, крайне немногие разработчики настолько уникальны, что их и в самом деле нельзя заменить.
Помни о том, как ослепляет собственный успех.
Я слышал, как программисты полушутя говорили, что создать "гарантированное рабочее место" можно, просто написав трудный в сопровождении код. Мне доводилось даже встречать тех, кто предпринимал подобные попытки. И каждый раз эти люди становились мишенями для других. Разумеется, в фирме боялись их увольнять. Но в конечном счете страх - это худшее, что может возникнуть в подобном случае. Пытаясь стать незаменимым при помощи оборонительных маневров, человек вызывал враждебные чувства у своего работодателя (и коллег), а существовать в подобной атмосфере становится затруднительно.
Логика подсказывает, что, пытаясь стать незаменимым, нужно строить дружеские рабочие отношения. Заменить можно любого. Те из нас, кто в состоянии это признать и начать работать с учетом этого факта, начинают выделяться из остальной массы и неосознанно повышают свои шансы. Кроме того, раз ты заменим, ничто не мешает тебе искать новую более выгодную работу.
Действуй!
1. Составь список написанного или поддерживаемого тобой кода и всех выполняемых заданий. Отметь все аспекты, в которых группа полностью от тебя зависит. Возможно, ты единственный, кто полностью понимает процесс развертывания своего приложения. Или существуют фрагменты кода, понять которые остальным членам группы особенно сложно.
Помести все эти позиции в список текущих дел. Задокументируй, автоматизируй или перепроектируй каждый фрагмент кода или задание таким образом, чтобы их легко мог понять любой член группы. Когда все дела из списка будут завершены, ознакомь с документацией группу и ее руководителя. Убедись, что доступ к этим документам есть у всех членов группы.
Периодически повторяй это упражнение.
Совет 27
Возлюби поддержку
Несколько лет назад мне пришлось с нуля создавать центр разработки программного обеспечения на 250 человек. Мы начали с пустого здания, имея задачу нанять весь персонал и полностью организовать рабочий процесс. При этом мы столкнулись с совершенно неожиданными трудностями. Все хотели создавать новые системы, но никто не горел желанием заниматься поддержкой старых. Мы рассчитывали сформировать новую креативную среду, поэтому с самого начала было важно понять приоритеты новых сотрудников.
Созидание нравится всем. Мы расцениваем это как возможность оставить свой след. Ощутить причастность. Выразить себя в своем творении. Кроме того, существует мнение, что проектные работы являются наиболее заметными в глазах руководства. Ведь славу и признание получают те, кто создает новое, не так ли? О том, насколько распространена такая позиция, я знал от программистов, с которыми сотрудничал ранее. Но столкнувшись с парой сотен разработчиков, предоставленных нам кадровой службой, я обнаружил совершенно неожиданные крайние проявления такого подхода.
Разработчики программного обеспечения являются, как правило, творческими, свободолюбивыми людьми, но при этом программистский "социум" демонстрирует удивительную кастовость. Программисты хотят быть проектировщиками, которые, в свою очередь, мечтают быть архитекторами, и т. д. Работа по техническому сопровождению не позволяет ни проявить себя, ни даже похвастаться конкретной высокой должностью (как, например, архитектор) перед родителями или бывшими сокурсниками.
Итак, мотивирующими факторами у нас являются способность проявить творческий потенциал и обязанности, выполнение которых потенциально ведет к повышению в должности. Забавно то, что работа над проектом тоже далеко не всегда предоставляет подобные возможности.
Работы по техническому сопровождению, как правило, тесно связаны со старыми, плохо функционирующими системами и надоедливыми конечными пользователями. Так как считается, что в таких случаях программное обеспечение уже существует, отдел информационных технологий сосредоточивается на удешевлении сопровождения системы и ищет максимально дешевые способы поддержания ее работоспособности.
Обычно это означает выделение крайне незначительных ресурсов на надзор за этими системами и отсутствие финансирования на обновление оборудования.
В то же время хорошая работа - это работа, которая начинается с прекрасного, чистого, совершенно нового листа. В хорошо работающей компании каждый проект способствует заработку или экономии денег, поэтому обычно на их внедрение выделяются достаточные фонды (хотя случаи бывают разные). При этом отсутствует минное поле старого кода, по которому программисту приходится ходить на цыпочках, а значит, "корректно" разрабатывать новые подсистемы можно с куда меньшим числом помех, чем было бы в уже существующей системе. Короче говоря, внедрение новых проектов происходит в куда более благоприятных условиях.
Допустим, что я даю тебе тысячу долларов и прошу принести чашку кофе. Меня сильно расстроит, если ты вернешься с меньшей суммой и без кофе. Не вызовет у меня восторга и ситуация, когда ты принесешь мне прекрасный кофе, но через два часа. С другой стороны, если я не дам тебе денег и попрошу принести кофе, то достаточно высоко оценю выполнение моей просьбы, но пойму, если ты этого не сделаешь. Работа над проектом соответствует первому сценарию. Работа по технической поддержке - второму.
Когда стандартных ограничений - устаревшего кода или недостатка финансирования - нет, руководство и заказчики с полным правом ожидают от нас большего. Предполагается, что любой новый проект положительно скажется на деятельности фирмы. Если так не происходит, это означает, что ты не справился с задачей. Так как фирмы рассчитывают на увеличение доходов, зачастую они строго контролируют, что будет создаваться, каким образом и в какие сроки. И внезапно вместо полигона для творчества мы оказываемся в центре военной операции - каждое наше движение регламентируется сверху.
В режиме сопровождения надеются лишь на бесперебойную работу программного обеспечения при максимально низких затратах. Никто не ожидает от группы технической поддержки эффектных свершений. Пока все идет хорошо, клиенты воздерживаются от вмешательств в повседневное управление работой технических специалистов. Исправляй ошибки, делай небольшие доработки, о которых тебя попросили, и обеспечивай бесперебойную работу системы. Вот и все твои обязанности.
А как быть, если ошибка приводит к необходимости модернизации подсистемы приложения? Но то же самое относится к исправлению ошибок, не так ли? Проект может оказаться старым и допотопным, а вся система заполненной разбитыми окнами. Это возможность испытать твои навыки переделки. Насколько элегантной можно сделать эту систему? Насколько быстрее можно будет исправить или улучшить этот раздел в следующий раз после выполненной сейчас переделки?
Отдел технической поддержки также может стать местом свободы и творчества.
Пока ты обеспечиваешь работоспособность системы и достаточно быстро реагируешь на запросы пользователей, служба поддержки является местом свободы и творчества. Ты одновременно руководитель проекта, архитектор, дизайнер, кодер и тестировщик. Можно сколько угодно проявлять свои творческие способности, самостоятельно отвечая за все видимые успехи и неудачи.
Поддерживая систему, можно планировать заметные улучшения. Например, в созданной три года назад системе могут отсутствовать некоторые новые полезные элементы пользовательского интерфейса, доступные в современных браузерах. И если ты умеешь исправлять недостатки, сохраняя работоспособность системы, можно значительно повысить комфорт конечных пользователей. Можно неожиданно для заказчика корректно добавить дополнительные функциональные возможности - это все равно, что принести жене цветы без повода или убрать квартиру родителей, пока их нет дома. Не сталкиваясь с бюрократией, неизбежной для полномасштабных проектов на стадии реализации, ты получаешь удивительное количество возможностей. И вполне можешь удивить заказчика.
В отличие от многих современных проектных групп, работающих по контракту, у службы поддержки есть скрытое преимущество - возможность непосредственно общаться с заказчиками. Это позволяет заводить многочисленные знакомства, формируя собственную группу поддержки. Кроме того, такая должность дает прекрасные возможности изучить, как функционирует отрасль, в которой ты занят, изнутри. Полностью отвечая за сопровождение бизнес-приложения и реагируя на проблемы и запросы конечных пользователей, можно без особых усилий понять, какую же нагрузку несет это приложение. Правила ведения бизнеса закодированы в логической схеме приложения, просчитать которую обычно не так-то просто. Я сталкивался с ситуациями, когда полностью специфику бизнес-процессов в компании понимал только программист из службы поддержки. Больше ни у кого не было непосредственного представления о кодировании бизнес-логики.
Самая большая ирония при противопоставлении работ над проектом и в службе поддержки состоит в том, что их нельзя разделить. После появления первой строки кода все следующие пишутся уже на ее базе. Разумеется, такой код чище и вызывает меньше проблем, чем код устаревшего приложения, но, по сути, действия ничем не отличаются друг от друга. Новые функциональные возможности добавляются к уже существующему коду и в этом же коде исправляются ошибки. А кто может справиться с этим лучше, чем человек, полюбивший техническую поддержку и поставивший себе цель научиться обеспечивать ее на отлично?
Действуй!
1. Измерь, исправь, измерь. Для большинства важных приложений или кода, поддержкой которого ты занимаешься, составь список измеримых показателей, дающих представление о качестве работы. Это может быть время реакции приложения, количество необработанных исключений, выбрасываемых во время функционирования, или время безотказной работы программы. Если ты занимаешься непосредственно сопровождением, не оценивай качество приложения напрямую. Важной частью работы с приложением является скорость твоей реакции на запросы пользователей.
Выбери наиболее важные из перечисленных атрибутов и приступай к их измерению. Измерив базовый уровень, поставь реальную цель повысить производительность приложения (или собственной работы). Внеся усовершенствования, снова выполни измерения, чтобы убедиться в достижении намеченной цели. Если цель достигнута, поделись этим с коллегами и заказчиками.
Выбери следующий показатель и повтори процедуру. После первого раза ты обнаружишь, насколько интересным и похожим на игру является этот процесс. Улучшение измеримых показателей вполне может стать твоей привычкой.
Совет 28
Восьмичасовое пламя
Одним из многочисленных поводов для полемики вокруг движения "экстремального программирования" является исходное утверждение о том, что члены группы должны работать не более сорока часов в неделю. Такие разговоры сильно расстраивают руководителей - поклонников рабского труда, жаждущих добиться от подконтрольных групп максимальной продуктивности. Порой это расстраивает и самих программистов. Количество непрерывно отработанных часов становится своего рода мужской гордостью разработчиков, напоминающей гордость за количество выпиваемых залпом кружек пива в студенческие годы.
Боб Мартин, один из корифеев сообщества экстремального программирования, перевернул эту фразу таким образом, что умудрился примирить с ней обе партии, не отступая от первоначальных постулатов Кента Бека. Мартин переименовал сорокачасовую рабочую неделю в "восьмичасовое пламя". Основная идея состоит в том, что человек должен работать настолько интенсивно, что просто не сможет работать больше восьми часов.
Прежде чем перейти к рассмотрению процесса горения, ответим на вопрос, почему акцент делается на уменьшении числа рабочих часов? Этот раздел посвящен работе над какими-то вещами. Имеет ли смысл разговор об увеличении продолжительности рабочего дня?
Когда дело доходит до работы, меньшее может превратиться в большее. Экстремальные программисты любят повторять, что уставший человек не может работать с той же эффективностью, что и отдохнувший. Когда мы доходим до предела, творческий подход угасает, а качество работы существенно снижается. Мы начинаем делать глупые ошибки, которые стоят нам времени и денег.
Большинство проектов являются долгосрочными. Невозможно пробежать марафон в том же темпе, что и спринт. Если ты начнешь засиживаться допоздна на работе, краткосрочная продуктивность повысится, но в долгосрочной перспективе ты рано или поздно надорвешься настолько серьезно, что затраченное на восстановление время не оправдает результатов, достигнутых за восьмидесятичасовые рабочие недели.
Проект - это не спринтерская дистанция, а марафон.
Ко времени можно относиться как к деньгам. Юношей я работал неполный рабочий день за минимальную плату и был бы счастлив, будь у меня столько же денег, сколько сейчас я трачу на всякую ерунду. Сейчас у меня так много денег, что я уже не обращаю внимания на разнообразные мелкие расходы. Тем не менее в прошлом я каким-то образом умудрялся жить. У меня были квартира и машина, я не голодал.
Все это есть у меня и сейчас. Но нельзя сказать, чтобы я вел роскошную жизнь. Просто в те времена, когда мне не хватало денег, я пытался оптимизировать свои расходы. Получая в итоге, по сути, аналогичный результат.
Скудные ресурсы мы считаем более ценными и стараемся использовать их эффективно. Этот подход применим не только к деньгам, но и ко времени. Представь четвертый день своей семидесятичасовой рабочей недели. Без сомнения, ты будешь прилагать героические усилия. Но с четвертого дня ты, непременно, начнешь расслабляться. Стрелки показывают всего 10:30 утра, а ты знаешь, что останешься на рабочем месте еще на несколько часов после того, как все остальные уйдут домой. Что мешает некоторое время уделить чтению информации о последних технологических новинках?
Если рабочего времени слишком много, его реальная ценность заметно снижается. При семидесяти часах ценность одного часа куда меньше, чем в случае, когда их у тебя всего сорок.
Если стоимость доллара падает вследствие инфляции, для покупки такого же, как и раньше, набора вещей потребуется большая сумма. При снижении ценности часа на выполнение одной и той же работы будет уходить больше времени. Восьмичасовое горение Боба Мартина налагает на тебя ограничение и дает тебе стратегию действий в новых условиях. По дороге на работу ты думаешь: у меня всего восемь часов! Быстрее, быстрее, быстрее! Наличие жестких временных рамок естественным образом позволяет распределить время более эффективно. Можно начать с набора заданий на сегодня, определить их приоритеты и приступить к выполнению по одной за раз.