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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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