Ричард Шеридан - Работа мечты. Как построить компанию, которую любят

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Возможно, вам доводилось видеть, как в ваши компании входит бюрократия, ломающая все на своем пути, вследствие неудачного внедрения таких систем управления, как Lean, «шесть сигм» [15]или ISO. Или, скорее, пытаясь взять ситуацию под контроль, вы наблюдали только увеличение количества процедур: становилось больше совещаний, больше комиссий или просто больше уровней иерархии. Эти усилия, несмотря на благие намерения, увеличивают себестоимость проекта, объем работы и документации, но не оказывают существенного влияния на взаимодействие сотрудников, их производительность и качество конечного результата.

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