Подобно парню, желающему "стать J2ЕЕ-разработчиком", о котором шла речь в совете № 9, большинство из нас не отождествляет себя с фирмами, дающими нам работу. Я имею в виду, что я прежде всего программист и только потом человек, помогающий компании Fortune 500 продавать посудомоечные машины. Я разработчик архитектуры приложений, а не служащий энергетической компании. Это неудивительно, если смотреть на создание программного обеспечения как на ремесло. Выбранное нами ремесло обычно никак не связано с отраслью, в которой мы его применяем. Архитектор, проектирующий офис для военного ведомства, остается архитектором, а не превращается в военного подрядчика.
Подобное сохранение идентичности приводит к некоторым проблемам, так как наши макроцели могут войти в противоречие с нашими микрообязанностями. Если архитектор создает офис, не подходящий для нанявшего его военного подрядчика, ценность его работы равна нулю. И как бы красиво ни выглядело его творение, это плохой архитектор.
Нам платят за создание ценностей. Отсюда следует, что пора вылезти из удобного кресла и приняться за реальные дела. На одних способностях далеко не уедешь. На финишную прямую выходят только лучшие - те, кто умеет доводить дело до конца.
Доводить дела до конца - здорово. Часто людям сложно приучить себя к систематической работе (посмотри значение термина прокрастинация), но как только ты ощутишь огонь воодушевления, останавливаться уже не захочешь. Так давай зажжем этот огонь.
Совет 19
Прямо сейчас
Представь, что ты принимаешь участие в конкурсе с призом 100 000 долларов наличными. Приз достается команде, успевшей первой создать программу для получения новых неоплаченных счетов. Твоя рабочая группа подала заявку на участие. Работа должна быть выполнена за выходные. Код должен обеспечить реализацию минимального набора указанных функциональных возможностей, и его следует полностью протестировать. Вы приступаете в субботу утром. Выигрывает команда, которая до утра понедельника первой предоставит готовое приложение. Если до этого момента ни одна из команд не закончит работу, приз достанется тому, кто реализует максимальное количество функциональных возможностей.
Что можно сделать прямо сейчас?
Ты уверенно читаешь технические требования. Глядя на перечень функциональных возможностей системы, ты понимаешь, что масштабом и параметрами она напоминает те многочисленные системы, с которыми тебе приходилось работать раньше. И в то время как целью группы является завершение проекта к середине воскресенья, ты начинаешь задавать себе вопрос: каким образом приложение, по масштабу аналогичное тем, над которыми ты работал в офисе неделями, может быть закончено за одни выходные?
Но как только наступает время приняться за работу и ты принимаешься писать код, становится понятно, что группа достигнет поставленной цели. Все в ударе, реализуют одну функциональную возможность за другой, исправляют ошибки, за доли секунды принимают проектные решения, и работа оказывается выполненной. Это потрясающее ощущение. В офисе во время анализа проектов и планерок ты часто предавался мечтам о том, как здорово было бы с небольшой командой оторваться от бюрократической среды и сотворить новое приложение в рекордные сроки.
Об этом мечтают многие. Мы знаем, что рабочий процесс нас тормозит. И не только он. Скорость окружения также негативно влияет на сроки выполнения.
Закон Паркинсона гласит: "Работа заполняет все отпущенное на нее время". Печально то, что даже не желающие подчиняться этому закону могут попасть в ловушку, особенно при наличии задач, решать которые нет никакого желания.
В случае соревнования, длящегося всего пару дней, у тебя попросту нет времени на откладывание задач. Ты не можешь задержаться с принятием решения и не задерживаешься. Ты не можешь избежать скучной работы и знаешь, что все нужно сделать настолько быстро, что ни одна задача не успеет тебе надоесть слишком сильно.
Закон Паркинсона является результатом наблюдений, а не неизбежным приговором. Ощущения неотложности, даже надуманного, достаточно, чтобы легко удвоить, а то и утроить твою продуктивность. Попробуй и сам убедишься. Ты можешь справиться с делом быстрее. Можешь сделать все прямо сейчас. Можешь закончить работу, а не обсуждать, как ее закончить.
Восприняв рабочий процесс не как пребывание в тюремной камере, а как соревнование, ты сможешь завершить его куда быстрее. Создавай движение. Становись тем, кто толкает вперед. Не расслабляйся.
Всегда будь тем, кто спрашивает: "А что мы можем сделать прямо сейчас?"
Действуй!
1. Посмотри на список стоящих перед тобой задач. Найди задачи, попавшие туда в незапамятные времена, проекты, которые уже начали покрываться плесенью, или те, выполнение которых несколько застопорилось - из-за бюрократии или неоправданно больших затрат на анализ и проектирование.
Выбери задачу, решением которой ты можешь заняться в рабочий перерыв, в то время, которое обычно тратится на просмотр сайтов в интернете, проверку почты или долгие перекусы. Преврати многомесячный проект в задачу, которую нужно решить меньше чем за неделю.
Совет 20
Читай чужие мысли
Довелось мне работать с парнем по имени Рао. Он родился в Южной Индии, в штате Андхра-Прадеш, но жил в США и работал в нашей фирме. Рао мог превратить в код все, что вы попросите. К нему обращались, когда требовалось низкоуровневое программирование систем. Если речь заходила о высокоуровневом программировании приложений, он тоже мог удовлетворить практически любой запрос.
Но по-настоящему уникальным Рао был потому, что он делал все до того, как его об этом просили. Он обладал необъяснимой способностью предугадывать, какую задачу ему могут поручить, и решал ее еще до того, как начальству в голову приходила подобная идея. Это напоминало магию. Кажется, в какой-то момент я обвинил его в обмане, но было непонятно, как он это делает. Я сказал: "Рао, я решил поменять способ инкапсуляции контроллера в среде разработки приложений. Достаточно внести небольшие изменения, и мы сможем использовать эту среду не только для веб-приложений. Что ты по этому поводу думаешь?"
"Я уже сделал это на той неделе, - ответил он. - Это зафиксировано в системе управления версиями. Посмотрите". И такие вещи происходили с Рао постоянно. Это случалось настолько часто, что объяснить подобные совпадения можно было, только представив, что Рао проделывает все мыслимые изменения каждого фрагмента кода, поддержкой которого занималась наша группа.
В это время я руководил группой, отвечающей за архитектуру приложений. Кроме всего прочего, мы занимались созданием и поддержкой программных сред, на основе которых работали выпускаемые нашей компанией приложения. Мои коллеги тратили много времени на обсуждение способов улучшения разработки программного обеспечения. Много говорилось и о роли, которую в этих улучшениях играли базовые компоненты инфраструктуры.
Именно здесь скрывалась основа магических трюков Рао. Он практически не принимал участия в этих разговорах, но очень внимательно слушал. И в отличие от настоящих фокусников он поделился со мной своим секретом. Он выполнял только те пожелания, которые я озвучивал. Но пожелания озвучивались настолько неявно, что даже я сам этого не осознавал.
Например, стоя в очереди за кофе, я мог рассуждать о том, как здорово было бы реализовать в коде новые более гибкие функциональные возможности. И если подобные рассуждения звучали достаточно часто или я высказывался достаточно убедительно, несмотря на отсутствие этих задач в списке текущих дел нашей группы, Рао заполнял перерывы в работе, проверяя целесообразность реализации моих пожеланий. И если это можно было легко (и дешево) внедрить, писал код и проверял его.
Хороший трюк с телепатией приводит к тому, что люди начинают от тебя зависеть.
Телепатия применима не только к руководству, но и к заказчикам. Наводящая информация дает возможность добавлять функциональные возможности, о которых заказчик только собирается попросить или о которых он попросил бы, если бы считал, что это возможно. Всегда делая, что просят заказчики и когда они это просят, ты доставляешь им удовольствие. А сделав больше или раньше, чем тебя просят, ты восхитишь их - разумеется, если способность читать мысли тебя не подведет.
Трюк с чтением мыслей не совсем безопасен. Без страховки на этот канат лучше не ступать. Вот перечень основных рисков (с вариантами сглаживания отрицательных последствий):
♦ Делая работу, которую тебя никто не просил делать, ты тратишь деньги фирмы. А что, если ты ошибаешься? Начинай с малого. Реализуй свои догадки только в перерывах, чтобы это никак не отражалось на выполнении твоих рабочих обязанностей. Если у тебя есть к этому склонность, делай дополнительную работу в свободное время.
♦ Каждое добавление кода в систему рискует сделать ее менее отказоустойчивой. Избегай работы, которая может повлиять на архитектуру системы или каким-то образом ограничить ее функциональность. Если влияние изменений достаточно велико, нужно принимать бизнес-решение. Разработчики практически никогда не имеют полномочий самостоятельно решать подобные вопросы.
♦ Модификация некой функциональной возможности в соответствии с пожеланиями заказчика может отрицательно сказаться на функциональности приложения в целом или дать другие нежелательные последствия. Когда дело доходит до пользовательского интерфейса, с догадками лучше быть крайне осторожным.
Руководство людьми и проектами - трудная и интересная работа. Люди, обеспечивающие бесперебойную работу над проектом без многочисленных указаний сверху, высоко ценятся постоянно занятыми начальниками и заказчиками. Правильно применяемый трюк с чтением мыслей приведет к тому, что люди начнут от тебя зависеть - отличный рецепт карьеры, направление которой ты выбираешь сам. Эту способность стоит осваивать и развивать.
Действуй!
1. Первый рецензент этой книги Карл Брофи предлагает тебе записывать свои соображения по поводу возможных просьб руководства и заказчиков для твоего следующего проекта или поддерживаемой системы. Будь изобретательным. Попытайся посмотреть на систему с их точки зрения. Составляя список неочевидных функциональных возможностей, которые могут потребоваться, подумай о способах их максимально эффективной реализации. Вспомни о граничных ситуациях, о которых пользователи могут сразу не вспомнить.
Столкнувшись с проектом или с заявками на расширение, подсчитай число своих угадываний. Какое количество записанных тобой функциональных возможностей действительно попросили реализовать? Когда о них зашла речь, смог ли ты воспользоваться идеями, рожденными во время мозгового штурма?
Совет 21
Ежедневные победы
Нам всем нравится верить в силу собственных знаний, в то, что мы хорошие программисты, способные легко обеспечить решение задач и достичь высот производительности. Немногие счастливчики (коим, я настаиваю, сказочно повезло) действительно добиваются успеха при помощи подобной стратегии.
А вот извлечь выгоду из планирования и мониторинга может кто угодно. Здравый смысл подсказывает, что для попадания в список лучших достаточно превзойти ожидания руководства. Превышение ожидания работодателя является вполне достойной целью, однако на удивление немногие из нас знают, как достичь этой цели.
Как всегда бывает с подобными задачами, в выдающегося исполнителя проще всего превратиться при наличии конкретной запланированной работы. Когда ты в последний раз выходил за пределы своих должностных обязанностей? Твой начальник об этом знал? Как сделать более заметными проявления подобного поведения?
Мой друг и коллега Джеймс Макмурри на заре нашей с ним карьеры поделился разработанной им системой, которая гарантировала хороший результат работы. Система поразила меня своей глубиной, особенно если учесть небольшой опыт ее создателя (возможно, он учел уроки, полученные от родителей), и я пользуюсь ею до сих пор. Не уведомляя руководство, он фиксирует хиты дня. Его задача - каждый день делать нечто такое, о чем можно было бы с гордостью доложить наверх. Это может быть пришедшая ему в голову идея или некое действие, могущее улучшить работу его отдела (см. Одна неделя хитов).
Простое обозначение целей (на день, на неделю, на сколько можешь) и фиксация достигнутых результатов позволит быстро поменять твое поведение. Необходимость составления списка хитов естественным образом заставляет оценить свою деятельность и расставить приоритеты в соответствии с коммерческой ценностью отдельных рабочих заданий.
Одна неделя хитов
Понедельник. - Автоматизировать сборку!
Вторник. - Написать тесты для синтаксического разбора кода.
Среда. - Разобраться с инструментами объектно-реляционного проецирования, чтобы можно было больше вообще не писать SQL-запросы.
Четверг. - Написать сценарий развертывания веб-приложения.
Пятница. - Избавить проект от предупреждений компилятора.
Достаточная частота фиксации хитов гарантирует отсутствие простоев: человек, который должен создавать хит каждый день, уже просто не сможет тратить две недели на совершенствование результатов своего труда. Такой тип мышления и работы становится привычкой. И подобно разработчикам, испытывающим энтузиазм при виде зеленой полосы в интерфейсе тестирования модулей, ты ощутишь внутреннюю потребность в каждодневных достижениях. Тебе не придется слишком заботиться о мониторинге состояния работ, так как функционирование на данном уровне больше напоминает нервный тик, чем выполнение заданий из списка, созданного в приложении Microsoft Project.
Действуй!
1. Выбери для себя полчаса, сядь с карандашом и бумагой в тихом месте, где никто тебе не помешает. Вспомни о небольших проблемах, с которыми твоя группа сталкивается каждый день. Перечисли их на бумаге. Что это за досадные мелочи, заставляющие группу каждый день впустую тратить несколько минут, с которыми никто не может или не хочет ничего сделать?
Какие выполняемые вручную задания текущего проекта можно было бы автоматизировать? Перечисли их. Как насчет сборки или развертывания? Есть ли там аспекты, которые нужно привести в порядок? Как уменьшить количество сбоев при сборке? Запиши все идеи, пришедшие тебе в голову.
Выдели на подобные раздумья двадцать минут. Запиши все идеи, как хорошие, так и плохие. Не отвлекайся от процесса, пока двадцать минут не истекут. Когда список будет готов, на новом листе выпиши пять наиболее раздражающих тебя позиций. На следующей неделе в понедельник сделай что-нибудь с первым пунктом получившегося списка. Во вторник проработай второй пункт. В среду - третий и т. д.
Совет 22
Помни, на кого работаешь
Легко сказать: "Позаботься о том, чтобы твои цели и твоя работа совпадали с целями нанявшей тебя на работу компании". Легко сказать, но трудно сделать, особенно если ты программист и над тобой столько организационных слоев, что ты с трудом представляешь себе работу самой компании. В начале моей карьеры мне довелось попасть в группу разработчиков программного обеспечения в крупную фирму, занимающуюся доставкой грузов. Там существовала настолько огромная иерархическая структура, что я на своем уровне ни разу не столкнулся ни с чем, что позволило бы мне проникнуть в суть бизнеса доставки грузов. Вспоминаю, как во время посещения ежеквартальных общих собраний члены нашей группы чувствовали себя совершенно разобщенными и чужими. "Что за достижение мы празднуем? Что значат все эти показатели?"
Конечно, на том этапе своей карьеры я больше интересовался построением элегантных систем и исследованием программ с открытым исходным кодом, чем сутью бизнеса по доставке грузов. (Должен признать, что и сейчас мои приоритеты не изменились) Но если бы у меня тогда возникло желание согласовать свою работу с основными целями фирмы, не уверен, что знал бы, с чего начинать.
Итак, у нас есть прекрасный постулат о том, что мы должны согласовывать свою деятельность с целями компании, чтобы гарантированно влиять на конечный результат работы и все такое. Но по правде говоря, многие из нас со своего уровня просто не видят, как этого добиться. За деревьями леса не видать.
Возможно, это не наша вина. Возможно, мы хотим от себя слишком многого. Возможно, идея непосредственно влиять на конечный результат работы фирмы напоминает попытку вскипятить океан. Итак, нам требуется более детальное представление, разбивающее океан бизнеса на отдельные доступные для кипячения лужицы.
Начинать имеет смысл с самой очевидной лужи - своей рабочей группы. Скорее всего, она достаточно мала и специализированна, чтобы ты смог составить представление о ее сущности. Скорее всего, ты понимаешь проблемы, с которыми она сталкивается. Ты знаешь, над улучшением каких аспектов она работает, будь это производительность, доход, сокращение ошибок или что-то еще. Информацию, в которой ты не уверен, можно уточнить у своего непосредственного начальства.
В конечном счете в хорошо структурированной среде цели руководства являются целями группы. Реши проблему своего начальника и ты решишь проблему группы. Кроме того, если ваш начальник придерживается аналогичного подхода, то проблемы, которые ты решаешь для него, на самом деле являются проблемами уже его начальства. И так далее, вплоть до самых верхов фирмы - генерального директора, акционеров или даже заказчиков.
Делая свою небольшую часть работы, ты вносишь вклад в достижение целей фирмы. Это позволяет почувствовать свое предназначение. И придает твоей работе смысл.
Возможно, у тебя не возникнет желания следовать подобной стратегии. "Я не собираюсь делать за него работу". Или "он просто поставит мои результаты себе в заслугу!"
Ну да. Примерно так это и работает. Том ДеМарко и Тимоти Листер пишут в книге "Человеческий фактор. Успешные проекты и команды" (Peopleware: Productive Projects and Teams), что роль хорошего начальника - это не подмена подчиненных, не знание, как выполнить работу всей группы, не приход на помощь в трудных ситуациях. Хороший начальник расставляет подчиненным приоритеты, следит за тем, чтобы у группы было все, что требуется для выполнения рабочих обязанностей, поддерживает мотивацию и продуктивность и в конечном счете обеспечивает нужный результат. Хорошая работа группы означает хорошую работу ее начальника.
Успех твоего начальника - это и твой успех тоже.
Если работа твоего начальника - знать и расставлять приоритеты, а не лично выполнять все задания, то твоя работа состоит именно в выполнении всех заданий. Ты делаешь не работу начальника, а свою работу.