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

Введение

Оглавление

Инженерное искусство просто. Сложность – в людях.

Билл Когрэн (Bill Coughran), бывший старший вице-президент по инжинирингу компании Google

Жизнь полна неожиданных поворотов, и мы оба никогда не думали о том, что однажды напишем книгу о разработке ПО.

Как и многие компьютерные гики, мы поняли, что наше хобби и страсть – работа с компьютерами – отличный способ заработать на жизнь после колледжа. В середине 1990-х мы, подобно большинству фанатиков-программистов, собирали персональные компьютеры из комплектующих, устанавливали предварительные версии Linux с дискет и учились администрировать Unix-машины. Мы работали системными администраторами, а на заре эпохи «дот-комов» – программистами в небольших компаниях. Когда пузырь «дот-комов» лопнул, мы обосновались в выживших фирмах Силиконовой долины (вроде Apple), а затем были приглашены в стартап-компанию CollabNet в качестве штатных сотрудников для работы над Subversion – системой контроля версий с открытым кодом.

Нечто неожиданное случилось между 2000 и 2005 годами. Во время работы над Subversion наши обязанности стали понемногу изменяться. Мы больше не сидели весь день в изоляции, занимаясь написанием кода, а руководили проектом с открытым исходным кодом. В течение дня мы общались в чате с дюжиной программистов-волонтеров и следили за их работой. Мы почти полностью координировали разработку новых функций через список рассылки. В процессе этой работы мы поняли, что для успеха проекта недостаточно создавать хороший код. Не менее важно то, как люди взаимодействуют друг с другом для достижения конечной цели.

В 2005-м мы открыли технический офис Google в Чикаго и продолжили программистскую карьеру. В то время мы уже были активно вовлечены в мир открытого кода; мы не только работали над системой Subversion, но и участвовали в сообществе Apache Software Foundation (ASF). Мы перенесли Subversion в инфраструктуру BigTable, разработанную Google, и запустили службу хостинга проектов с открытым кодом (аналогичную SourceForge) под флагом Google Code. Мы начали посещать конференции для разработчиков, а затем и выступать на них – OSCON, ApacheCon, PyCon и, наконец, Google I/O. Работая в обеих корпорациях и занимаясь проектами с открытым кодом, мы незаметно собрали кладезь знаний и историй о том, как работают настоящие команды разработчиков ПО. Серия забавных докладов о неэффективных процессах разработки («Худшие практики Subversion») в конечном счете превратилась в выступления о защите команд от деструктивно настроенных людей («Как избавить проект от вредоносных участников»). Все большие и большие толпы людей собирались на наших презентациях, которые больше напоминали сеансы групповой терапии для разработчиков. Каждый участник осознавал свою причастность к проблемам, о которых мы рассказывали, и хотел поделиться ими с группой.

Спустя шесть лет в нашем арсенале было множество докладов о социальных проблемах разработки ПО, проходивших исключительно в переполненных залах. Мэри Треселер, редактор издательства O’Reilly Media, рекомендовала нам оформить эти доклады в виде книги. Остальное – достояние истории.


Если вы хотите делать отличные программы, то эта книга – для вас

Для кого предназначена эта книга

Эта книга предназначена в первую очередь для разработчиков ПО, стремящихся строить свою карьеру и создавать высококлассные программы. К целевой аудитории книги не относятся генеральные директоры, психологи, управленцы, теоретики-компьютерщики и специалисты по электронике (хотя все эти профессионалы тоже могут получить удовольствие от чтения). При написании книги мы руководствовались следующими предпосылками:

• читатель работает в команде программистов, например принимает участие в проекте с открытым исходным кодом;

• читатель получает удовольствие от разработки ПО и считает ее достойным и увлекательным занятием. Если вы преобразуете нули в единицы и обратно с целью отделаться от кредиторов, то вы вряд ли заинтересованы в саморазвитии и карьерных достижениях.

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

Внимание: эта книга не является техническим пособием

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

В этой книге вы не найдете ничего подобного.

Наша книга посвящена человеческим аспектам разработки ПО. Люди – сложные существа, или, как мы любим говорить на конференциях, «огромные скопления перемежающихся ошибок». Проблемы и решения, о которых мы рассказываем, расплывчаты и с трудом умещаются в строгие логические рамки. Эту книгу следует воспринимать как серию эссе, поскольку, в сущности, так оно и есть. В каждой главе мы рассматриваем набор взаимосвязанных проблем (как правило, в виде историй), а затем переходим к изучению решений, относящихся ко всей теме в целом. Чтобы полностью усвоить материал, удерживайте в голове содержимое нескольких страниц одновременно, устанавливайте взаимосвязи с помощью правого полушария мозга или, наконец, просто спите с этой книгой!

Мы хотели бы сделать еще пару оговорок. Как мы обычно говорим на выступлениях, «изложенная информация является исключительно нашим мнением, основанным на личном опыте. Если вы не согласны с ним, то милости просим выступить с собственным докладом». Как и на устных выступлениях, мы приветствуем любые дискуссии, которые могут возникнуть вокруг тем, представленных в этой книге. Мы рады обсудить с читателями отзывы, исправления, мнения и разногласия. С нами можно связаться через сайт http://www.benandfitz.com/. Содержимое этой книги отражает наш личный «боевой» опыт и уроки, извлеченные из многочисленных ошибок.

Все имена, использованные в примерах, были изменены для сохранения конфиденциальности как положительных, так и отрицательных героев.

Эта книга о том, чему не учат в вузах

Большинство известных нам программистов потратило от 4 до 10 лет на обучение компьютерным технологиям и программированию. На момент написания этой книги мы не знаем ни одного курса,[1] обучающего студентов навыкам общения и совместной работы в команде или компании. Конечно, во время учебы большинству студентов приходится хотя бы однажды участвовать в групповом проекте, но обучать человека методам успешной работы с другими людьми и принуждать его к командной работе – совершенно разные вещи. Для большинства студентов такой опыт заканчивается разочарованием.


Ключевая идея книги

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

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

1

Мы прочитали замечательную книгу Тома Де Марко (Tom DeMarco) «Человеческий фактор» (PeopleWare), но она адресована не столько инженерам, желающим научиться эффективнее взаимодействовать с людьми, сколько менеджерам, стремящимся сделать свои команды более успешными.

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

Подняться наверх