Чтение онлайн

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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