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

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

Подобно парню, желающему «стать J2ЕЕ-разработчиком», о котором шла речь в совете № 9, большинство из нас не отождествляет себя с фирмами, дающими нам работу. Я имею в виду, что я прежде всего программист и только потом человек, помогающий компании Fortune 500 продавать посудомоечные машины. Я разработчик архитектуры приложений, а не служащий энергетической компании. Это неудивительно, если смотреть на создание программного обеспечения как на ремесло. Выбранное нами ремесло обычно никак не связано с отраслью, в которой мы его применяем. Архитектор, проектирующий офис для военного ведомства, остается архитектором, а не превращается в военного подрядчика.

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

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

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

 

Совет 19

Прямо сейчас

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

Что можно сделать прямо сейчас?

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

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

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

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

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

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

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

Всегда будь тем, кто спрашивает: «А что мы можем сделать прямо сейчас?»

Действуй!

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

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

 

Совет 20

Читай чужие мысли

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

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

«Я уже сделал это на той неделе, — ответил он. — Это зафиксировано в системе управления версиями. Посмотрите». И такие вещи происходили с Рао постоянно. Это случалось настолько часто, что объяснить подобные совпадения можно было, только представив, что Рао проделывает все мыслимые изменения каждого фрагмента кода, поддержкой которого занималась наша группа.

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

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

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

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

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

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

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

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

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

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

Действуй!

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

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

 

Совет 21

Ежедневные победы

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

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

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

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

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

Одна неделя хитов

Понедельник. — Автоматизировать сборку!

Вторник. — Написать тесты для синтаксического разбора кода.

Среда. — Разобраться с инструментами объектно-реляционного проецирования, чтобы можно было больше вообще не писать SQL-запросы.

Четверг. — Написать сценарий развертывания веб-приложения.

Пятница. — Избавить проект от предупреждений компилятора.

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

Действуй!

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

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

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

 

Совет 22

Помни, на кого работаешь

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

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

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

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

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

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

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

Возможно, у тебя не возникнет желания следовать подобной стратегии. «Я не собираюсь делать за него работу». Или «он просто поставит мои результаты себе в заслугу!»

Ну да. Примерно так это и работает. Том ДеМарко и Тимоти Листер пишут в книге «Человеческий фактор. Успешные проекты и команды» (Peopleware: Productive Projects and Teams), что роль хорошего начальника — это не подмена подчиненных, не знание, как выполнить работу всей группы, не приход на помощь в трудных ситуациях. Хороший начальник расставляет подчиненным приоритеты, следит за тем, чтобы у группы было все, что требуется для выполнения рабочих обязанностей, поддерживает мотивацию и продуктивность и в конечном счете обеспечивает нужный результат. Хорошая работа группы означает хорошую работу ее начальника.

Успех твоего начальника — это и твой успех тоже.

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

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

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

Действуй!

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

 

Совет 23

Будь на своем месте

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

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

Будь честолюбив, но не показывай этого.

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

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

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

Разумеется, нет. Он — посредственный исполнитель с плохими психологическими установками. Так что даже если он и обладает высоким потенциалом, он его никак не демонстрирует. Его потенциал не приносит фирме дохода. Акционеры не будут держаться за свои инвестиции, если их ожидания не оправдаются. Более того, такая позиция вызовет у руководства желание прекратить вкладываться в подобного сотрудника.

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

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

Но разве у людей не должно быть честолюбия? Разве появились бы компании Microsoft или General Electric, будь их основатели лишены честолюбия и не имей они далеко идущих целей?

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

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

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

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

Действуй!

1. Забудь на неделю о своих карьерных устремлениях. Составь список планов, связанных с текущей работой. Думай не о том, на какое место ты хочешь попасть после повышения, а о задачах, которыми придется заняться, завершив текущие дела. Что выдающегося ты можешь сделать на текущей должности? Напиши стратегический и тактический планы. В течение недели используй разработанную тактику для достижения долгосрочной цели — «завершить» выбранную работу.

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

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

 

Совет 24

Великолепная задача на сегодня

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

Насколько интересной ты мог бы сделать свою работу?

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

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

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

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

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

Так как же нам задействовать свой творческий потенциал и бросить вызов своим способностям в рутине будничных служебных обязанностей (которые у большинства из нас занимают более 80 % рабочего времени)?

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

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

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

Действуй!

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

 

Совет 25

Сколько ты стоишь?

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

Очень легко привыкнуть все время ждать большего. По всей видимости, это общечеловеческая склонность. После увеличения зарплаты человек некоторое время радуется, а потом начинает думать о следующем повышении. «Получай я на 10 % больше, можно было бы позволить себе этот новый…» Мы все так чувствуем. В какой-то момент величина зарплаты становится абстрактной. Речь идет уже не о дополнительных 5000 долларов в год. Нужно, чтобы увеличивалась базовая ставка. Не получив удовлетворяющего нашим требованиям повышения зарплаты, мы начинаем выражать недовольство своей работой и фирмой. «Почему они меня не ценят?»

Сколько ты стоишь на самом деле? Как я уже упомянул, это больше, чем твоя зарплата. Для простоты допустим, что твоя цена равна двум твоим окладам. То есть если ты зарабатываешь в год $60 000, фирма тратит на тебя около $120 000.

Пока все просто. Но пришла пора ответить на неприятный вопрос: какой доход ты принес в прошлом году? Каково твое положительное влияние на чистую прибыль компании? Мы уже знаем, что ты стоишь компании (в нашем воображаемом сценарии) примерно $120 000. Как ты компенсировал эту сумму? Сколько денег ты помог сэкономить? Какой вклад ты внес в годовой доход?

Превосходит ли это число две твоих зарплаты?

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

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

В качестве точки отсчета вспомним проценты по типичному сберегательному счету. Они не очень велики, не так ли? Тем не менее это лучше, чем ничего. Будь у тебя выбор, под какие проценты ты бы поместил свои годовые накопления: 0 или 3? Способность приносить доход в размере двукратной зарплаты представляет для фирмы такую же непривлекательную перспективу, как для тебя счет с 0 % годовых. Они на год замораживают расходы на тебя до 120 000 долларов, а ты не приносишь дохода, покрывающего даже уровень инфляции. В этом случае безубыточность оборачивается потерями.

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

Спроси себя: «Сколько я сегодня стоил?»

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

Действуй!

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

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

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

 

Совет 26

Камешек в ведре воды

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

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

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

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

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

Его сотрудники смотрели с недоверием. Нет. Сегодня этого не произойдет. Все идет так хорошо. Все работает на вас.

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

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

Помни о том, как ослепляет собственный успех.

Я слышал, как программисты полушутя говорили, что создать «гарантированное рабочее место» можно, просто написав трудный в сопровождении код. Мне доводилось даже встречать тех, кто предпринимал подобные попытки. И каждый раз эти люди становились мишенями для других. Разумеется, в фирме боялись их увольнять. Но в конечном счете страх — это худшее, что может возникнуть в подобном случае. Пытаясь стать незаменимым при помощи оборонительных маневров, человек вызывал враждебные чувства у своего работодателя (и коллег), а существовать в подобной атмосфере становится затруднительно.

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

Действуй!

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

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

Периодически повторяй это упражнение.

 

Совет 27

Возлюби поддержку

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Действуй!

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

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

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

 

Совет 28

Восьмичасовое пламя

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

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

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

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

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

Проект — это не спринтерская дистанция, а марафон.

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

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

Скудные ресурсы мы считаем более ценными и стараемся использовать их эффективно. Этот подход применим не только к деньгам, но и ко времени. Представь четвертый день своей семидесятичасовой рабочей недели. Без сомнения, ты будешь прилагать героические усилия. Но с четвертого дня ты, непременно, начнешь расслабляться. Стрелки показывают всего 10:30 утра, а ты знаешь, что останешься на рабочем месте еще на несколько часов после того, как все остальные уйдут домой. Что мешает некоторое время уделить чтению информации о последних технологических новинках?

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

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

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

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

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

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

Действуй!

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

 

Совет 29

Научись проигрывать

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

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

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

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

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

Любая фальшивая нота находится рядом с верной.

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

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

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

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

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

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

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

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

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

Стрессовая ситуация дает прекрасную возможность для формирования лояльности.

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

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

 

Совет 30

Умей говорить «нет»

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

Говоря «да», чтобы избежать разочарования, мы попросту врем.

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

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

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

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

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

А что случится, если тебя попросят выполнить важную работу, а ты ответишь отказом? Как руководитель местной и офшорной групп могу сказать, что приму такой ответ с чувством облегчения. Умение подчиненного сказать «нет» дает мне уверенность, что когда он говорит «да», он на самом деле это подразумевает. Обязательства такого человека заслуживают большего доверия и имеют больший вес. Если он действительно выполнит взятые на себя обязательства, в следующий раз я не буду задавать дополнительных вопросов, если он ответит мне отказом.

Человек, всегда говорящий «да», либо обладает невероятными способностями, либо лжет. Чаще всего действительности соответствует второй вариант.

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

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

Но не переусердствуй с количеством отказов. Исполнительность по-прежнему в цене, и здорово, когда человек готов взять на себя повышенные обязательства. Если ты не уверен, что справишься, но хотел бы попробовать, так и скажи. «Это будет сложная задача, но я хотел бы попробовать» — великолепный ответ. Хотя порой лучше ограничиться простым «да».

Имей смелость быть честным.

Действуй!

1. Наш рецензент Карл Брофи предложил вести список взятых на себя обязательств.

♦ Что тебя попросили сделать к определенному сроку?

♦ Что ты пообещал?

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

♦ Запиши дату выполнения.

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

 

Совет 31

Не паникуй

Карьеру программиста я начал из-за видеоигр. Интерактивные приключения с эффектом присутствия очаровали меня еще во времена Commodore 64 с его видеолентами. Я стеснялся своего пристрастия, но теперь понимаю, что нечего было стыдиться. Компьютерные игры превращали невыразительные картинки, которые я видел на экране (полагаю, это был интерфейс операционной системы), в среду, где мне было комфортно и интересно.

Моя любимая игра на все времена — Doom от id Software. Я был в восторге от одиночного прохождения, дуэлей с реальными игроками и «боев насмерть». Компьютеры соединялись по модему или через последовательный порт, и игроки сражались друг с другом на небольших, быстро меняющихся площадках. Я достиг больших успехов в «боях насмерть». Я часто шучу, что, может быть, это и сейчас единственное, в чем я достиг максимального успеха. Игра в этом режиме удивительно сложна. Как с технической, так и с психологической точки зрения она напоминает безумную смесь шахмат с фехтованием на повышенной скорости.

Для повышения своих навыков полезно наблюдать за работой мастеров. Во времена моего активного увлечения Doom был один такой мастер, выступавший под ироническим псевдонимом Noskill (Неумеха). По факту он был главным чемпионом в Doom. Игроки из Северной Америки платили за междугородные телефонные соединения, чтобы попытать счастья в бою против него. Эти матчи записывали при помощи встроенной в Doom программы. И я посмотрел их все.

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

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

Герои никогда не паникуют.

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

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

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

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

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

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

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

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

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

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

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

Действуй!

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

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

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

 

Совет 32

Скажи это, сделай это, покажи это

 

Чтобы не доводить дела до логического конца, достаточно не брать на себя никаких обязательств. Если срок исполнения не указан, ничто не заставляет и не мотивирует тебя на трудовые подвиги. Это особенно верно, когда приходится делать нечто не особо интересное.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В Бангалоре, в нашем центре программного обеспечения, была группа, которая более года работала в ночь. Из семи входящих в нее человек двум всегда доставалась ночная смена. Еженедельно они менялись, в итоге каждую третью или четвертую неделю каждому члену группы приходилось работать с 7 вечера до 3 утра. Группа постепенно выдыхалась, страдая от постоянной смены суточных ритмов. Но эта группа играла важную вспомогательную роль, и заказчики из США считали, что не справятся без специалистов из Бангалора, помогающих в режиме реального времени.

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

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

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

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

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

 

Неудачи и копирование

Патрик Коллисон, студент Массачусетского технологического института

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

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

Знаю, что ошибаюсь чаще других программистов. Большинство моих проектов заканчиваются провалом. В папке — /Projects можно найти целый ворох забытых попыток сделать нечто интересное. Шансы на успех у каждой из них были примерно такими же, как шансы лобстера уплыть из кастрюли в океан. Кое-чем они привлекают внимание. Успешные проекты, как и счастливые семьи, похожи друг на друга, а вот неудачные проекты завершаются по-разному.

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

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

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

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

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

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

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

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

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

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

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

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

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

Понять, как это может помочь, не так уж сложно. Копирование нарабатывает мышечную память. Ты начинаешь чувствовать нюансы и форму оригинала — детали, которые при быстром сканировании теряются.

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

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

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

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