Брайан Фитцпатрик - Идеальная IT-компания. Как из гиков собрать команду программистов Страница 5

Помимо автобус-фактора, существует также проблема общей скорости продвижения проекта. Легко забыть о том, что работа в одиночку часто бывает трудной и идет значительно медленнее, чем требуется. Сколько нового вы узнаете, работая изолированно? Как быстро вы продвигаетесь? Всемирная паутина наполнена информацией, однако она не заменяет реального человеческого опыта. Работа с другими людьми напрямую увеличивает коллективный опыт, стоящий за усилиями. Когда вы «зависаете» над бессмысленной задачей, сколько времени вы тратите на то, чтобы выбраться на правильный путь? Подумайте, как изменился бы процесс работы, если бы рядом находилась пара коллег, которые могли заглянуть через ваше плечо и без промедления указать на ошибки и способы их исправления. Именно поэтому в компаниях, разрабатывающих ПО, участники команд сидят вместе или занимаются парным программированием: вторая «пара глаз» часто оказывается необходимой.

Вот еще одна аналогия: задумайтесь о том, как вы работаете с компилятором. Создавая большую программу, нажимаете ли вы кнопку «компилировать» в первый раз через несколько дней или недель написания кода, когда уверены в том, что все готово и идеально? Разумеется, нет. Представьте, какая неудача ожидает вас при попытке скомпилировать 50 тысяч строк кода с нуля! Как программисты, мы лучше всего работаем в коротких циклах обратной связи: пишем новую функцию и компилируем, добавляем тест и компилируем, реорганизуем код и компилируем. Сгенерировав код, мы исправляем ошибки и опечатки как можно раньше. Компилятор подстраховывает нас на каждом маленьком шаге; некоторые среды разработки способны выполнять компиляцию в то время, когда мы набираем код. Таким способом мы поддерживаем высокое качество кода и гарантируем корректную и поступательную разработку нашего ПО.

Такая же обратная связь требуется не только на уровне кода, но и на уровне проекта в целом. Амбициозные проекты развиваются быстро и должны «на марше» адаптироваться к изменениям внешней среды. По ходу развития проекта могут возникать непредсказуемые препятствия при моделировании, политические проблемы и просто ситуации, когда все работает не так, как планировалось. Иногда неожиданно изменяются требования. Как обеспечить обратную связь, которая в нужный момент подскажет, что планы или модели нуждаются в корректировке? Ответ: работая в команде. В связи с этим часто цитируют высказывание Эрика Рэймонда «много глаз видят все ошибки», однако, возможно, лучшая интерпретация звучала бы так: «много глаз обеспечивают проекту адекватность и правильное направление». Люди, работающие в «пещерах», внезапно обнаруживают, что их исходное миропонимание, возможно, и является полным, но сам мир изменился и их продукт перестал быть актуальным.

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

Мы полагаем, что большинству инженеров не только необязательно, а опасно работать в отдельной комнате.[2] Сегодня ПО разрабатывается коллективами, а не отдельными людьми, и постоянная оперативная связь разработчика с коллегами важнее, чем непрерывное подключение к Интернету. Можно работать хоть 24 часа в сутки, но двигаясь в неверном направлении, вы просто теряете время. Зайдите в офис любой быстроразвивающейся высокотехнологичной компании, созданной в XXI веке, и вы увидите, что инженеры сидят группами в кабинках или за общими столами; случаи, когда инженеры изолированы друг от друга в отдельных кабинетах, встречаются редко.

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

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

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

Итак, наши рассуждения сводятся к следующему: работа в одиночку более рискованна, чем работа в команде. Опасаясь, что кто-то может украсть вашу идею или усомниться в вашем интеллекте, не забывайте опасаться потерять кучу времени, работая в неправильном направлении.

К сожалению, проблема хранения идей «под подкладкой» характерна не только для разработки ПО: она распространена во всех сферах деятельности. Например, считается, что профессиональная наука предполагает свободный и открытый обмен информацией, однако отчаянное следование принципу «Публикуй или погибнешь!» и борьба за гранты приводят к совершенно противоположному эффекту. Великие мыслители не делятся идеями. Они цепляются за них, держат исследования в секрете, скрывают ошибки, совершаемые в пути, и в конечном счете выдают публикацию, в которой весь процесс представляется легким и очевидным. Результаты часто оказываются плачевными: непреднамеренное повторение чужой работы, незамеченная ошибка на ранней стадии проекта или создание того, что представляло интерес в прошлом, но утратило свою актуальность. Количество потерянного времени катастрофически велико.

Не вносите свой вклад в эту печальную статистику.

Все дело в команде

Итак, давайте остановимся и соберемся с мыслями.

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

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

Сформулируем эту мысль проще:

Разработка программного обеспечения – это командный вид спорта.

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

Помните, что разработка ПО – это командный вид спорта

Недостаточно быть блестящим одиночкой, запертым в собственной «пещере». Вы не измените мир и не поразите воображение миллионов пользователей компьютеров своим секретным изобретением. Вам необходимо работать с другими людьми. Рассказывайте о своих идеях. Трудитесь вместе с другими людьми. Учитесь у коллег. Создайте первоклассную команду!

Сколько вы можете назвать успешных и популярных программ, созданных одним-единственным человеком? Некоторые приведут в пример программу LaTeX, однако ее едва ли можно назвать широко используемой, если только не считать, что люди, пишущие научные работы, составляют статистически значимую часть всех пользователей ПК!

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

Три кита

Итак, мы сформулировали основную мысль о командной работе. Если командная работа – лучший способ разработки отличного ПО, то как создать (или найти) отличную команду?

Это непросто. Чтобы достичь коллективной нирваны, сначала следует понять и усвоить то, что мы называем «тремя китами» социальных навыков. Эти три принципа – не просто «смазка» механизма взаимоотношений, а основа, на которой строится адекватное взаимодействие и сотрудничество между людьми.

 Скромность

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