Читать онлайн «Работа мечты. Как построить компанию, которую любят». Страница 7

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

В 1999 году, после двух лет интенсивных поисков лучшего способа работать и управлять командой, в течение нескольких недель в моей жизни произошли два важных открытия. Первым из них была вики (ранняя форма блогов) парня по имени Кент Бек. Он вскорости опубликовал свою книгу «Экстремальное программирование»[11]. Бек описывал радикальный подход к созданию программного обеспечения, основанный на резком изменении существующего подхода: открытое рабочее место, управление проектами с помощью рукописных заметок, разбивка больших проектов на маленькие, измеримые циклы и внедрение в команде практики работать в парах.

Через несколько недель после чтения вики Бека я посмотрел выпуск Nightline[12] об IDEO, известной компании промышленного проектирования из Пало-Альто. Я увидел пример практического применения того, о чем говорилось в «Экстремальном программировании». Стиль IDEO я бы не назвал идеальным примером описанного Беком подхода, но я увидел компанию, где вдоволь было энтузиазма, командного сотрудничества, отличных отношений с клиентами и сознательного проектировочного мышления.

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

Но теперь я знал, что создать другое рабочее место – реально. Поиски модели компании, в которой бы царила радость, закончились. У меня было руководство пользователя и видео.

Я показал выпуск Nightline своим коллегам из высшего руководства нашей усталой, старой компании и сказал им: «Вот что я собираюсь здесь сделать». (Мне повезло, что они согласились со мной за те тридцать минут, пока мы смотрели видео.) Они оказались так же воодушевлены возможностями новой системы, как и я. Когда мой самый жесткий критик спросил: «И когда же мы снесем стены?» – я понял, что мы способны на это. Команда была на борту. Мой босс меня поддержал. Все прониклись этой идеей.

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

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

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

У меня был СЕО. У меня была команда. У меня был партнер. Осталась еще одна группа людей, которую требовалось поднять на борт, – команда программистов.

Моя команда знала, что я ищу новые подходы для решения некоторых из наиболее актуальных наших проблем. Эти проблемы, в конце концов, лежали на виду у всех. Сроки сдачи работ подходили тогда, когда у нас еще не было работающего кода и вообще завершением работы даже и не пахло. Когда программа оказывалась якобы законченной, команда обеспечения качества не могла даже запустить ее! Разработчик, уже переключившийся на другой проект, заявлял: «На моем компьютере все летало», и на этом разговор заканчивался. Когда, наконец, после нескольких месяцев тестирования программа начинала работать, результаты в редких случаях оказывались соответствующими тому, чего на самом деле хотел клиент. И даже если результат удовлетворял требованиям заказчика, пользователи не понимали, как работать с программой, так что приходилось писать пользовательскую документацию и запускать тренинги, чтобы отправить «чайников» дальше по кривой обучения[13].

Я собрал свою команду из четырнадцати разработчиков ПО и рассказал им обо всем, что почерпнул в «Экстремальном программировании». Эти идеи были новыми для них и, честно говоря, радикально отличались от всего, с чем они работали и чего могли ожидать.

«Ну, и что вы думаете обо всем этом?» – спросил я.

Ответом мне была полная тишина.

Моя команда немедленно почувствовала опасность. «Вице-президент Рич придумал что-то ненормальное, и он попытается воплотить это в жизнь, если мы не поспешим затоптать его идею».

«Так что вы думаете?» – спросил я снова.

Еще больше тишины в ответ. Мертвой тишины.

В конце концов руку поднял Джил.

«Джил, что ты думаешь?»

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

«Джил, насколько я помню, мы – публичная компания, – ответил я. – Полагаю, код все-таки принадлежит акционерам».

«Не важно, Рич. Это мой код».

О боже! Я понял: будет нелегко.

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

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