Делай как вGoogle
 Скачать 5.77 Mb.
|
|
ЧАСТЬ II Культура ГЛАВА 2 Успешная работа в команде Автор: Брайан Фитцпатрик Редактор: Риона Макнамара В этой главе рассмотрены культурные и социальные аспекты программной инжене- рии в Google, и сначала мы сосредоточимся на изменяемой величине, которую вы можете контролировать, — на вас самих. Люди по своей природе несовершенны. Мы любим говорить, что люди — это комплекс периодически возникающих ошибок. Но прежде чем искать ошибки в своих колле- гах, научитесь распознавать ошибки в себе. Подумайте о своих реакциях, поведении и отношениях и получите более или менее полное представление о том, как стать более эффективным и успешным инженером-программистом, который тратит мень- ше энергии на решение проблем с людьми и больше — на создание отличного кода. Главная идея этой главы в утверждении, что разработка ПО — это командная работа. Чтобы добиться успеха в команде инженеров или другом творческом коллективе, нужно организовать свое поведение в соответствии с основными принципами: сми- рением, уважением и доверием. Но не будем забегать вперед и начнем с наблюдения за обычным поведением инже- неров-программистов. Помоги мне скрыть мой код За последние двадцать лет мы с моим коллегой Беном 1 не раз выступали на разных конференциях по программированию. В 2006 году мы в Google запустили услугу хостинга для проектов с открытым исходным кодом (OSS, open source software) (в настоящее время не поддерживается) и получали много вопросов и просьб. Но примерно в середине 2008 года мы начали замечать определенную направлен- ность запросов: «Не могли бы вы добавить в поддержку Subversion в Google Code возможность скрывать определенные ветки?» «Не могли бы вы добавить возможность создать проект с открытым исходным кодом, который изначально закрыт, а потом открывается, когда будет готов?» 1 Бен Коллинз-Сассмэн, один из авторов этой книги. Миф о гениальности 45 «Привет, я хочу переписать весь свой код с нуля, не могли бы вы стереть всю историю?» Заметили, что объединяет эти просьбы? Ответ: неуверенность. Люди боятся, что другие увидят и оценят их работу. С одной стороны, неуверенность — это часть человеческой натуры, никто не любит, когда его критикуют, особенно за то, что еще не закончено. Осознание этого помогло нам заметить более общую тенденцию в разработке ПО: неуверенность на самом деле является признаком более серьезной проблемы. Миф о гениальности Многие неосознанно творят себе кумира и поклоняются ему. Для инженеров-про- граммистов это могут быть: Линус Торвальдс, Гвидо Ван Россум, Билл Гейтс — все они выдающиеся личности, изменившие мир. Линус в одиночку написал Linux, верно? На самом деле Линус написал всего лишь начальную версию Unix-подобного ядра для проверки идей и опубликовал его код в списке рассылки. Безусловно, это большое и впечатляющее достижение, но оно было только началом. Современное ядро Linux в сотни раз больше той начальной версии и разрабатывается тысячами умных людей. Настоящее достижение Линуса в том, что он сумел взять на себя руководство этими людьми и скоординировать их работу. Linux — блестящий результат, но не его перво- начальной идеи, а коллективного труда сообщества. (И ОС Unix была написана не только Кеном Томпсоном и Деннисом Ритчи, а группой умных людей из Bell Labs.) Аналогично: разве Гвидо Ван Россум один создал весь Python? Да, он написал первую версию. Но в разработке последующих версий, реализации новых идей и исправлении ошибок принимали участие сотни других людей. Стив Джобс ру- ководил командой, которая создавала Macintosh. И хотя Билл Гейтс известен тем, что написал интерпретатор BASIC для первых домашних компьютеров, его самым большим достижением стало создание успешной компании вокруг MS-DOS. Все они стали лидерами и символами коллективных достижений своих сообществ. Миф о гениальности — это общая тенденция, следуя которой мы, люди, приписываем успех команды одному человеку. А что насчет Майкла Джордана? Та же история. Мы идеализировали его, но он не сам выиграл каждый баскетболь- ный матч. Его истинная гениальность в том, как он взаимодействовал с командой. Тренер Фил Джексон был чрезвычайно умен, и его приемы стали легендарными. Он понимал, что один игрок никогда не выигрывает чемпионат, и поэтому собрал целую «команду мечты» вокруг Майкла. Эта команда работала как исправный механизм — играла столь же впечатляюще, как и сам Майкл. Итак, почему мы постоянно стремимся найти кумира? Покупаем товары, одобрен- ные знаменитостями, хотим купить платье, как у Мишель Обамы, или обувь, как у Майкла Джордана? 46 Глава 2. Успешная работа в команде Тяга к известности — вот одна из причин. У людей есть естественный инстинкт на- ходить лидеров и образцы для подражания, преклоняться перед ними и пытаться подражать им. Нам всем нужны герои для вдохновения, и в мире программирования тоже они есть. Феномен «технократической знаменитости» почти перетек в мифоло- гию. Мы все хотим написать что-то, что изменит мир, как Linux, или спроектировать еще один потрясающий язык программирования. В глубине души многие инженеры хотят, чтобы их считали гениями. Эта фантазия выглядит примерно так: y у вас возникает потрясающая новая идея; y вы запираетесь в своем убежище на несколько недель или месяцев, создавая со- вершенное воплощение этой идеи; y затем «выпускаете» в мир готовое ПО и шокируете всех своей гениальностью; y ваши коллеги преклоняются перед вашим умом; y люди выстраиваются в очередь, чтобы заполучить ваше ПО; y слава и удача преследуют вас. А теперь остановимся и посмотрим, что мы имеем в реальности. Вы, скорее всего, не гений. Не обижайтесь! Конечно, мы верим, что вы очень умный человек. Но понимаете ли вы, насколько редки настоящие гении? Конечно, вы пишете код, и это сложный на- вык. Но даже если вы гений, этого для успеха недостаточно. Гении, как и все, делают ошибки, а блестящие идеи и редкие навыки программирования не гарантируют, что ваш софт станет хитом. Хуже того, вы можете обнаружить, что способны решать только аналитические проблемы, но не человеческие. Быть гением не означает быть «не от мира сего»: любой человек — гений он или нет — с плохими социальными на- выками, как правило, является плохим партнером по команде. Для работы в Google (и в большинстве других компаний!) не требуется иметь гениальный интеллект, но точно требуется обладать минимальным уровнем социальных навыков. Взлет или падение вашей карьеры, особенно в такой компании, как Google, во многом зависит от того, насколько хорошо вы умеете сотрудничать с другими людьми. Оказывается, этот миф о гениальности — еще одно проявление нашей неуверенно- сти. Многие программисты боятся выкладывать на всеобщее обозрение свою работу, которую только начали, потому что тогда коллеги увидят их ошибки и поймут, что автор кода не гений. Вот что однажды сказал мой друг: «Я знаю, что КРАЙНЕ не уверен в людях, и опасаюсь показывать им что-то, что еще не закончено, как будто они осудят меня или подумают, что я идиот». Это чрезвычайно распространенное чувство среди программистов, и естественной реакцией на него становится желание спрятаться в своем убежище, чтобы работать, работать, работать, а затем полировать, полировать, полировать и пребывать в уве- Сокрытие вредно 47 ренности, что никто не увидит глупых ошибок и вы обнародуете шедевр, когда он будет закончен. Спрятать код, пока он не станет идеальным. Другой распространенный мотив прятать свою работу — это страх, что кто-то дру- гой сможет понять вашу идею и воплотить ее раньше вас. Сохраняя в секрете, вы контролируете идею. Мы знаем, о чем вы сейчас могли подумать: ну и что? Разве плохо, если люди будут работать так, как хотят? На самом деле — да, плохо. Мы утверждаем, что так работать — это неправильно, и это очень важно. И вот почему. Сокрытие вредно Работая все время в одиночку, вы увеличиваете риск ненужных неудач и мешаете росту своего потенциала. Даже при том что разработка ПО — это интеллектуальная работа, требующая глубокой концентрации и уединения, вы не должны забывать о ценности (и необходимости!) совместной работы и анализа. Подумайте сами: как, работая в одиночку, вы сможете понять, что выбрали верный путь? Представьте, что вы увлекаетесь проектированием велосипедов и однажды вам в голову пришла блестящая идея совершенно нового механизма переключения передач. Вы заказали детали и закрылись на несколько недель в гараже, пытаясь создать прототип. Когда ваш сосед — также конструктор-энтузиаст — спросил вас, почему вы избегаете встреч, вы решили не рассказывать ему о своей идее, пока она не воплотится. Проходит еще несколько месяцев; вы не можете заставить прототип правильно работать и не спрашиваете совета у друзей. И вот в один прекрасный день сосед показывает вам свой велосипед с радикально новым механизмом переключения передач. Оказывается, он конструировал что-то похожее на ваше изобретение, но с помощью друзей из магазина велосипедов. Вы испытываете удар по самолюбию и показываете ему свой результат. Он быстро находит простые недостатки вашего дизайна, которые можно было исправить в первую неделю работы. Из этой истории можно извлечь несколько поучитель- ных уроков. Раннее выявление Если вы скрываете свою прекрасную идею от мира и отказываетесь показывать что- либо кому-либо, пока реализация не будет отшлифована, вы фактически пускаетесь в авантюру. На ранней стадии разработки легко допустить фундаментальные ошибки. Вы рискуете заново изобрести колесо 1 . А также лишаетесь преимуществ совместной 1 В прямом смысле, если вы конструируете велосипед. 48 Глава 2. Успешная работа в команде работы: обратите внимание, насколько быстрее продвигался сосед, сотрудничая с друзьями. Люди пробуют воду, прежде чем нырнуть: убедитесь, что движетесь в правильном направлении и ваш проект не был создан раньше. Шансы допустить ошибку в начале пути высоки. И чем больше отзывов вы получаете на ранних этапах, тем меньше рискуете 1 . Вспомните проверенную временем мантру: «Ошибки должны выявляться как можно раньше, как можно быстрее и как можно чаще». Раскрытие своей идеи на раннем этапе ее реализации не только предотвращает личные ошибки и помогает проверить идею — оно помогает укрепить то, что мы называем фактором автобуса. Фактор автобуса Фактор автобуса определяет, сколько участников проекта должно попасть под автобус, чтобы проект провалился. Насколько рассеяны знания и опыт между участниками проекта? Если вы един- ственный, кто понимает, как работает прототип, вам должна быть обеспечена особая безопасность — если вас собьет автобус, проект прогорит. Но, взяв кого-нибудь в напарники, вы удвоите фактор автобуса. А если с вами будет работать неболь- шая команда специалистов, вместе создающих и разрабатывающих прототипы, ситуация улучшится еще больше — проект будет продолжен после ухода одного члена команды. Сотрудники могут жениться, уехать, уйти из компании или взять отпуск по уходу за родственником. Даже простое наличие хорошей документации и одного-двух ведущих специалистов в каждой области поможет обеспечить успех проекта в будущем и увеличит фактор автобуса проекта. Надеемся, что большинство инженеров понимают, что лучше быть частью удачного проекта, чем критической частью неудачного. Помимо фактора автобуса существует проблема общего темпа развития. Легко забыть, что работа в одиночку — это сложная задача, которая решается гораздо медленнее, чем хотелось бы. Как много вы узнаете, работая в одиночку? Как быстро вы движетесь к цели? Google и Stack Overflow являются отличными источниками мнений и информации, но они не могут заменить реальный человеческий опыт. Работа с другими людьми напрямую увеличивает коллективные знания. Когда вы остановились из-за абсурдной проблемы, сколько времени вы потратите, чтобы вы- тащить себя из ямы? Подумайте, насколько изменится ваш опыт, если пара коллег будет смотреть вам через плечо и сразу указывать на ошибки и варианты их устра- нения. Именно поэтому в компаниях, занимающихся разработкой ПО, члены одной команды часто сидят вместе (или даже занимаются парным программированием). Программирование — сложная наука. Программная инженерия — еще сложнее. Вам нужна эта вторая пара глаз. 1 Отметим, что иногда на ранних этапах процесса опасно получать слишком много отзывов, если вы не уверены в выборе направления или цели. Сокрытие вредно 49 КЕЙС: ИНЖЕНЕРЫ И ОФИСЫ Двадцать пять лет назад считалось, что единственный способ работать над решением за- дачи, не отвлекаясь на посторонние дела, — иметь отдельный кабинет с закрытой дверью. Думаю, большинству инженеров 1 не только не нужно находиться в отдельном кабинете, но и вредно. Современное ПО создается командами, а не одиночками, и постоянный контакт с другими членами команды ценнее соединения с интернетом. В отдельном кабинете вы будете иметь массу времени для обдумывания своих решений, но, двигаясь в неправильном направлении, вы потратите это время впустую. К сожалению, многие современные технологические компании (включая Google) качнули маятник в другую крайность. Зайдите в их офисы — и найдете сотни инженеров, сидящих вместе в огромных залах. В настоящее время ведутся жаркие споры о целесообразности опен-спейсов и, как следствие, растет неприятие их. Там, где самый малозначительный разговор становится публичным, люди перестают общаться, чтобы не раздражать соседей. Это так же плохо, как отдельные кабинеты! Мы считаем, что лучшее решение — золотая середина. Сгруппируйте команды по четыре- восемь человек в небольших комнатах (или больших офисах), чтобы упростить случайное общение между ними. Конечно, инженерам нужна возможность фильтровать шум. И они придумывали способы сообщить, что их не следует прерывать. Например, использовали протокол голосового прерывания — фразу «Прервись, Мэри», где Мэри — имя человека, с которым нужно по- говорить. По возможности Мэри поворачивалась лицом и слушала. Если она была занята, то отвечала: «Не сейчас». Также они ставили на свои мониторы флажки или игрушки, чтобы показать, что прерывать их можно только в случае крайней необходимости. В некоторых командах инженерам вы- давались наушники с шумоподавлением. К слову, во многих компаниях сам факт ношения наушников обычно расценивается как сигнал, означающий «не беспокой меня, если это не очень важно». Многие инженеры, приступая к написанию кода, переходят в режим работы «в наушниках», что может быть полезно, если период изоляции длится недолго и не создает в офисе глухих стен. Не поймите нас неправильно — мы все еще считаем, что инженеры должны иметь возмож- ность сосредоточиться на написании кода, но мы думаем, что им также необходимо беспре- пятственное общение с командой. Если коллега не может просто задать вам вопрос — это проблема, а найти правильный баланс — это искусство. Темп развития Еще одна аналогия. Вспомните, как вы используете компилятор. Тратите несколько дней, чтобы написать 10 000 строк кода, а затем нажимаете кнопку «компилировать». Так? Конечно нет. Представьте неприятные последствия такого подхода. Програм- мисты увереннее работают, когда пишут код небольшими фрагментами, используя 1 Понимаю, что интровертам, вероятно, нужно больше тишины и одиночества и спокойная обстановка; возможность выделить им отдельный кабинет могла бы способствовать более продуктивной их работе. 50 Глава 2. Успешная работа в команде короткие циклы с обратной связью: написали новую функцию — скомпилировали, добавили тест — скомпилировали, выполнили рефакторинг участка кода — скомпи- лировали. Это позволяет быстро выявлять и исправлять опечатки и ошибки в коде. Компилятор нужен нам для проверки каждого маленького шага. Некоторые среды программирования могут даже компилировать код сразу после ввода. Современная философия DevOps, направленная на повышение продуктивности, четко говорит о целях: получать отзывы как можно раньше, тестировать как можно раньше и начи- нать думать о безопасности в продакшене как можно раньше. Все это связано с идеей «сдвига влево» в рабочем процессе разработчика и удешевлении устранения ошибки. Короткий цикл обратной связи необходим не только на уровне кода, но и на уровне всего проекта. Амбициозные проекты развиваются быстро и должны адаптироваться к меняющимся условиям. Они могут сталкиваться с непредсказуемыми архитектур- ными ограничениями, политическими препятствиями или техническим несоответ- ствием. Требования могут меняться неожиданно. Как обеспечить быструю обратную связь, чтобы вовремя узнавать, когда следует менять планы или решения? Ответ: работать в команде. Большинству инженеров известна истина: «Чем больше глаз, тем заметнее ошибки». Но ее можно перефразировать иначе: «Чем больше глаз, тем успешнее проект справляется с вызовами». Люди, работающие в затворничестве, рискуют однажды обнаружить, что мир изменился, и несмотря на полноту и правиль- ность первоначальных представлений, проект стал неактуальным. Проще говоря, не прячьтесь! Итак, «сокрытие» сводится к следующему: работа в одиночку рискованнее, чем работа в команде. Вас не должно беспокоить, что кто-то украдет вашу идею или подумает, что вы не умны, гораздо хуже, если вы потратите время, двигаясь не туда. Не становитесь частью печальной статистики. Весь секрет в командной работе Итак, давайте оглянемся назад и соберем воедино все рассмотренные идеи. В программировании ремесленники-одиночки встречаются крайне редко, и ни- кто из них не достигает вершин самостоятельно: их достижения, меняющие мир, почти всегда являются результатом искры вдохновения, сопровождаемой упорной командной работой. Великая команда блестяще использует своих суперзвезд, и целое всегда больше, чем сумма его частей. Но создать команду из суперзвезд очень сложно. Сформулируем эту идею проще: программирование — это командная работа. Эта идея прямо противоречит представлению о гениальном программисте, знакомому многим из нас. Не пытайтесь изменить мир или вызвать восхищение у миллионов пользователей, пряча и шлифуя свое секретное изобретение. Работайте с другими |