Работа мечты. Как построить компанию, которую любят
Шрифт:
Хотя я не имел четкого видения, во что выльется такая трансформация, два элемента работали в мою пользу. Во-первых, после практически полного угасания мое внутреннее пламя разгорелось. Я снова начал верить.
Во-вторых, гораздо более важным для успеха радикального переосмысления рабочего пространства стало присутствие среди моих сторонников Джеймса Гебеля. Как многие другие важные вехи на моем пути к радости, встреча с Джеймсом оказалась случайной и, на первый взгляд, не слишком важной. Этот человек был одним из ведущих консультантов местной компании Appnet – я заключил с ним договор на обучение моей команды новому подходу с помощью его техники трансформации. С собой он привел нескольких высококлассных программистов
Джеймс еще никогда не встречал людей, похожих на меня, – тех, кто все время готов проводить серьезные и радикальные эксперименты. Я также никогда не видел кого-либо, похожего на Джеймса, – он был человеком, способным снова и снова предлагать сумасшедшие и захватывающие новые идеи. Ему предстояло стать моим партнером на пути перемен.
У меня был СЕО. У меня была команда. У меня был партнер. Осталась еще одна группа людей, которую требовалось поднять на борт, – команда программистов.
Кровь, хаос, убийства
Моя команда знала, что я ищу новые подходы для решения некоторых из наиболее актуальных наших проблем. Эти проблемы, в конце концов, лежали на виду у всех. Сроки сдачи работ подходили тогда, когда у нас еще не было работающего кода и вообще завершением работы даже и не пахло. Когда программа оказывалась якобы законченной, команда обеспечения качества не могла даже запустить ее! Разработчик, уже переключившийся на другой проект, заявлял: «На моем компьютере все летало», и на этом разговор заканчивался. Когда, наконец, после нескольких месяцев тестирования программа начинала работать, результаты в редких случаях оказывались соответствующими тому, чего на самом деле хотел клиент. И даже если результат удовлетворял требованиям заказчика, пользователи не понимали, как работать с программой, так что приходилось писать пользовательскую документацию и запускать тренинги, чтобы отправить «чайников» дальше по кривой обучения [13] .
13
График, характеризующий процесс постепенного приобретения опыта. Прим. пер.
Я собрал свою команду из четырнадцати разработчиков ПО и рассказал им обо всем, что почерпнул в «Экстремальном программировании». Эти идеи были новыми для них и, честно говоря, радикально отличались от всего, с чем они работали и чего могли ожидать.
«Ну, и что вы думаете обо всем этом?» – спросил я.
Ответом мне была полная тишина.
Моя команда немедленно почувствовала опасность. «Вице-президент Рич придумал что-то ненормальное, и он попытается воплотить это в жизнь, если мы не поспешим затоптать его идею».
«Так что вы думаете?» – спросил я снова.
Еще больше тишины в ответ. Мертвой тишины.
В конце концов руку поднял Джил.
«Джил, что ты думаешь?»
«Кровь, хаос, убийства, – сказал он спокойно, но с твердым убеждением в голосе. – Не делайте этого, Рич. Не заставляйте нас повторять. Не выгоняйте нас из наших кабинетов. Не заставляйте меня пускать за компьютер кого-то еще. И, пожалуйста – пожалуйста! – не заставляйте меня показывать кому-то свой код. Это мой код».
«Джил, насколько я помню, мы – публичная компания, – ответил я. – Полагаю, код все-таки принадлежит акционерам».
«Не важно, Рич. Это мой код».
О боже! Я понял: будет нелегко.
Первый эксперимент
После той непростой встречи Боб и Клейр, двое опытных разработчиков, подошли ко мне. Они хотели рискнуть поучаствовать в эксперименте по экстремальному
В предыдущие два года я разрешил Клейру предпринять в конечном итоге неудавшуюся попытку изменений, которую мы называли «Цикл разработки программного обеспечения» (ЦРПО). В нашей отрасли мы обращаемся к такому стилю, как водопадная разработка [14] . Процесс предполагает соблюдение некоторых основных принципов, регулярные встречи, обязательное утверждение руководителем участков работы, контроль промежуточных результатов с принятием решения продолжать или не продолжать, несчетное количество постоянно действующих комиссий для проверки документов в процессе работы – и так до бесконечности.
14
Ее также часто называют «каскадная разработка». Прим. ред.
После нашей попытки безболезненно выполнить первый проект, придерживаясь цикла водопадной разработки, мы решили, что нам нужна облегченная версия ЦРПО, чтобы можно было выполнять небольшие и занимающие не так много времени проекты без особой помпы. Но за несколько месяцев ЦРПО и его порождение, облегченная версия, тихо умерли. Мы регулярно забывали запланировать нужные встречи, на которые все равно никто не приходил. Клейр впал в уныние, потому что тот проект был его детищем. Его внутреннее пламя погасло, как и мое.
Возможно, вам доводилось видеть, как в ваши компании входит бюрократия, ломающая все на своем пути, вследствие неудачного внедрения таких систем управления, как Lean, «шесть сигм» [15] или ISO. Или, скорее, пытаясь взять ситуацию под контроль, вы наблюдали только увеличение количества процедур: становилось больше совещаний, больше комиссий или просто больше уровней иерархии. Эти усилия, несмотря на благие намерения, увеличивают себестоимость проекта, объем работы и документации, но не оказывают существенного влияния на взаимодействие сотрудников, их производительность и качество конечного результата.
15
О концепции «шести сигм» вы можете прочитать, например, в книге М. Джорджа «Бережливое производство плюс шесть сигм в сфере услуг. Как скорость бережливого производства и качество шести сигм помогают совершенствованию бизнеса» (М.: Манн, Иванов и Фербер, 2011). Прим. ред.
Раз уж попытки внедрения ЦРПО были прекращены – и поскольку Клейр и Боб сами изъявили желание, – я быстро согласился на предложенный ими эксперимент по экстремальному программированию. Они вдвоем немедленно сделали «открытую лабораторию» (маленькую комнату без двери) своим рабочим местом. Там они сидели рядом за одним компьютером, писали автоматизированные тесты модулей, работали с рукописными индексными карточками и каждую неделю делали обзор своей работы. В общем, они в полной мере испытали на себе принципы экстремального программирования и адаптировали все методы, которые Джил и большинство его коллег с ходу отвергли.
Через три недели эксперимента Клейр остановил меня на парковке и спросил, собираюсь ли я по-прежнему платить ему за то, что он здесь работает.
«Что ты имеешь в виду?» – удивился я.
«Я здорово провожу здесь время и не чувствую, что я на работе, – ответил он. – Я не уверен, что ты должен мне за это платить».
А ведь за несколько недель до эксперимента Клейр просил меня дать ему рекомендации, потому что он решил уйти из компании и искал работу. Стало очевидно, что благодаря этому эксперименту мы напали на золотую жилу.