Как программистам общаться друг с другом и точно ли без этого не обойтись – одна из вечных тем обсуждения в сообществе. В книге «Team Geek: идеальная IT-компания» Брайан Фитцпатрик и Бен Коллинз-Сассмэн, двое бывалых программистов и технических лидеров крупных команд Google, предлагают свой взгляд на этот пласт проблем.
Оба автора пришли в индустрию достаточно давно, чтобы на себе испытать, как менялись типичные условия работы среднего программиста из десятилетия в десятилетие. От уединенного постижения Unix тихими зимними вечерами они перешли к единоличному системному администрированию в эпоху доткомов, затем оказались в окружении горстки коллег в стартапах и наконец стали возглавлять крупные проекты с открытым кодом. На каждом этапе этого пути людей вокруг становилось всё больше и больше, сложностей, связанных с ними – тоже, и авторы начали обобщать свои наблюдения в докладах и на онлайн-площадках. Постепенно эти заметки сложились в систему – так появилась эта книга, кратким пересказом которой мы планируем поделиться.
Целевую аудиторию своего труда Фитцпатрик и Коллинз-Сассмэн определяют так: рядовые разработчики ПО, которые работают в составе команды, хотят создавать качественные продукты и не возражают против карьерного роста. Цели научить читателя управлять людьми они не ставили, хотя многие выкладки могу оказаться полезными и для технических лидеров.
В общем и целом, книга посвящена многослойному «человеческому измерению» в разработке – всем социальным взаимодействиям, который на сегодняшний день составляют неизбежный фон деятельности среднестатистического программиста. Прежде всего, это, разумеется, круг его коллег и начальство, далее – люди из других команд, с которыми периодически приходится вести дела, и наконец, сторонние клиенты и пользователи. Текст организован по принципу движения из центра к периферии: сначала подробно рассматриваются отношения внутри команды как ключевой фактор для успешного протекания технических процессов, затем – всё, что приходит в неё извне и может влиять на местный климат.
Сегодня мы остановимся на первых главах, посвященных «ядру» социальной жизни разработчика – внутрикомандному общению.
Командный вид спорта
Авторы начинают свои рекомендации с аксиомы, которую необходимо принять, чтобы двигаться дальше:
В наши дни разработка – командный вид спорта. Базовой рабочей единицей является команда программистов.
Если смотреть на дело так, становится ясно, почему мягким навыкам, межличностным отношениям и прочей вроде бы внешней шелухе уделяется столько внимания. В любом композитном механизме должен быть баланс и порядок, иначе он не будет функционировать. Решение пустить всё на самотёк и не выстраивать взаимодействие в команде целенаправленно не сэкономит времени и сил – их неминуемо съест «текущий ремонт»: выяснение отношений, пресечение конфликтов, поиск виноватых. В итоге, времени на разработку будет оставаться не больше, а меньше.
Однако за программистами не зря закрепилась репутация одиночек-затворников: многие сознательно или несознательно отторгают такой взгляд на вещи и, даже работая в составе команды, стремятся обособиться в автономную «капсулу», которая выполняет свои задачи сама по себе. Авторы видят этому несколько объяснений. Во-первых, в нас ещё жива историческая память о временах, когда успешные продукты делались в гаражах. Во-вторых, в профессии действительно наблюдается высокая концентрация интровертов и просто необщительных людей. Но самый большой вес имеет третья причина – ревностное отношение к результатам своей работы.
Фитцпатрик и Коллинз-Сассмэн вспоминают следующую характерную историю. В 2000-х они оба занимались хостингом проектов с открытым кодом в Google и, соответственно, получали богатую обратную связь о том, чего именно хочет от этого сервиса сообщество. Едва ли не чаще всего пользователи просили о приватности, о возможности скрыться от чужих глаз в той или иной форме:
Создайте, пожалуйста, возможность скрытия определенных ветвей кода в Subversion на Google Code.
Сделайте так, чтобы было можно «спрятать» проект с открытым кодом в начале работы над ним и опубликовать его в уже готовом виде.
Я хочу переписать весь код с нуля, не могли бы вы полностью очистить архив проекта?
Обычно за желанием до поры до времени спрятать плоды своих трудов кроется сразу несколько побуждений. С одной стороны, мы все по-человечески не любим ошибаться, особенно в присутствии других людей. Чем дольше разработчик остаётся со своей работой наедине, тем больше у него шансов довести её до мыслимого совершенства и не дать никому знать, сколько просчётов он допустил в процессе.
С другой стороны, в программистах особенно громко говорит честолюбие: кому не хочется стать следующим Линусом Торвальдсом или Ричардом Столлмэном? Если не делиться идеей и трудностями в процессе, то по завершению не придётся делиться и славой.
Чтобы не позволить этим двум (по сути, понятным и естественным) побуждениям тормозить продуктивную работу, можно попытаться разобрать их рационально. Для начала, стоит напомнить себе о том, что образ одинокого гения давно уже стал мифологическим. На деле, даже достижения, которые приписываются звёздам IT, чьи имена у всех на слуху, обычно являются результатом работы целого коллектива.
Тот же Линус Торвальдс, упоминавшийся выше, не «создал Linux своими руками» — он написал и обнародовал прототип Unix-подобного ядра. Это было огромным вкладом, но всё-таки именно вкладом в совместную деятельность сотен людей. Чаще всего гений даёт идею, первый импульс, который затем подхватывается и развивается другими талантливыми разработчиками. То, что известность из них получает только кто-то один – издержки нашей индивидуалистичной культуры и глубинного стремления находить объекты для подражания. Но это не меняет того факта, что программисты, которые идут путём одинокого гения, пытаются повторить схему, которая в реальности практически не встречается.
Важно понимать и то, что прятать до последнего свою работу со всеми её достоинствами и недостатками не только бессмысленно, но и крайне затратно. Преимущество открытости в том, что она предоставляет в ваше распоряжение так называемый коллективный опыт – то есть все те практические знания, которыми располагают ваши коллеги. Ваш собственный опыт, скорее всего, окажется в разы уже, а значит, на устранение ошибки или спорного момента вы потратите в разы больше времени. Лицо вы при этом, возможно, и сохраните, но в ущерб той самой разработке, которая, согласно принятой шкале ценностей, должна стоять выше «эмоциональной шелухи».
Кроме того, промахи и неудачные решения на протяжении целой карьеры всё-таки неизбежны (даже для гениев). И при таком раскладе, чем раньше вы узнаете об ошибке, тем меньше ущерба от неё понесёте. Именно на ранних этапах работы над продуктом рациональнее всего подключать коллег и собирать отзывы – ошибки при проектировании часто имеют критические последствия.
Здесь можно провести аналогию с компиляцией: никому в здравом уме не придёт в голову впервые запускать компилятор, когда проект в пятьдесят тысяч строк уже завершён. Наоборот, разработчики обычно предпочитают, чтобы компилятор подстраховывал их на небольших промежутках, и сразу проверяют на ошибки и опечатки свеженаписанную функцию или тест. Значит, в ситуации с автоматическими напарниками мы признаём важность поступательного контроля качества. Остаётся применить ту же логику для обратной связи со стороны людей – как на уровне кода, так и на уровне проекта в целом.
Три кита командной работы
Итак, основной тезис изучен и принят – разработку ПО в текущих условиях целесообразнее всего вести в симбиозе с коллегами. Теперь перед нами встаёт старый как мир вопрос: как создать этот симбиоз?
По убеждению Фитцпатрик и Коллинз-Сассмэн, продуктивная и здоровая атмосфера в команде складывается при наличии трёх составляющих:
- Скромность. Каждый член команды понимает, что способен ошибиться и что ему есть куда расти; никто не воспринимает себя как центр мироздания.
- Уважение. Каждый член команды помнит, что вокруг – такие же люди, как он сам, что их достоинство нельзя затрагивать, а способности и достижения следует ценить.
- Доверие. Каждый член команды убеждён, что остальные достаточно компоненты и действуют в интересах общего дела.
Если вникнуть в природу практически любого рабочего конфликта, как правило, вскрывается недостаток одного или нескольких из этих трёх компонентов.
В отрыве от конкретных примеров эти добродетели выглядят абстрактно и не слишком красноречиво. Чтобы прояснить, как они проявляются, авторы приводят ряд типовых рабочих ситуаций, в которых хорошо заметна разница между наличием и отсутствием «трёх китов». Что ещё ценнее – с опорой на эту информацию можно выстраивать свою собственную линию поведения так, чтобы не отдалять атмосферу в команде от идеала.
Дискуссии и споры
Как не должно быть: Обычно, когда сталкиваются две или больше точек зрения, быстро становится очевидно, кем считают друг друга собеседники — людьми «в одной лодке» или конкурентами.
Во втором случае можно наблюдать две характерных особенности. Во-первых, в беседах обозначаются «выскочки» — люди, которые говорят, просто чтобы лишний раз напомнить о себе. Ценность их замечаний сильно варьирует, но высказываются они постоянно. Им важно оставить за собой последнее слово, указать на любую, пусть даже малозначимую неточность, щегольнуть знанием чего-то, не имеющего прямого отношения к делу. Фактически это непрерывный поток саморекламы. Один или два таких человека могут волей судеб затесаться в любую команду, но если они многочисленны – обычно это не случайность, а закономерность: обстановка располагает вести себя именно так.
Во-вторых, движение к консенсусу идёт крайне туго – участники спора закрыты для влияния со стороны. Все сосредоточены на том, чтобы продвинуть свою точку зрения и почти не воспринимают то, что говорят остальные. Признать свою неправоту, пусть хоть частичную, считается зазорным; люди готовы изворачиваться и отрицать очевидное, чтобы этого избежать.
Что можно сделать: Прежде всего, стоит понаблюдать за собой – не слишком ли вы заняты тем, чтобы сиять на фоне окружающих, и с каким настроем обычно вступаете в споры. Если придёте к выводу, что действительно отличаетесь упёртостью, заведите привычку сначала выслушивать других, а затем высказываться самому – так вы сможете корректировать свою точку зрения по ходу дела, и никто об этом не узнает. Соглашаться с другими психологически проще, когда для этого не приходится публично отказываться от своих слов.
Критика
Как не должно быть: По сути, критика чужого кода – это высший пилотаж, который требует, чтобы все три компонента держались на высоте. Тут нужно и уважать результаты чужого труда (причём обеим сторонам), и верить в добрые намерения коллеги, и уметь признавать свои ошибки. То, насколько болезненно или безболезненно проходят в команде обзоры кода – отличная лакмусовая бумажка для общей оценки рабочей среды.
Если с командным духом дела обстоят не очень, это может проявиться на любой из сторон процесса. Иногда некорректны сами замечания и рекомендации – проверяющий впадает в агрессивный или пренебрежительный тон, позволяет себе личные нападки или лишает автора возможности улучшить код (умалчивает о проблемах, переписывает молча). Иногда критика вполне конструктивна, но автор принимает её в штыки и считает личным оскорблением. В любом случае, если в коллективе обнаруживается много людей, которые не способны должным образом давать или принимать обратную связь, это плохой знак.
Что можно сделать: Если у вас проблемы с принятием критики, тут можно посоветовать только твердить себе как мантру: «Я и мой код – не одно и то же». Ваша самооценка не должна напрямую коррелировать с результатами работы – ищите другие источники для её подкрепления.
Что касается разборов чужого кода, это более тонкое дело. Общая закономерность, как ни парадоксально, такова: чем напряжённее атмосфера в команде, тем нейтральнее и осторожнее следует быть в формулировках. Люди, которые привыкли, что на них нападают, обычно готовы занять оборонительную позицию по малейшему поводу, так что не ленитесь тщательно подбирать слова, пока это не войдёт в привычку.
Авторы советуют придерживаться следующих правил при комментировании чужого кода:
- Говорить строго о коде, не отвлекаясь на привычки и характер его автора;
- Не впадать в категоричный тон – предлагать и советовать вместо того, чтобы требовать;
- Избегать оценочных, обвинительных реплик («Ты наделал ошибок в…», «У тебя какая-то путаница с…»). Вообще, вместо реплик с «ты» безопаснее говорить от себя или обезличенными конструкциями («Мне непонятна логика…», «Здесь не хватает…»).
Разборы полётов
Как не должно быть: Выше мы говорили о том, что ошибки неизбежны, так что рано или поздно вы обязательно получите возможность понаблюдать, как ведёт себя команда при столкновении с этой неизбежностью. Речь тут даже не о том, выступает начальник в роли хорошего или плохого полицейского – важны общие настроения и процедуры.
Нередко бывает так, что на первый план при обнаружении серьёзных проблем выступает проблема преступления и наказания: находятся виновные, принимаются карательные меры, проводятся мероприятия по устранению последствий и на этом инцидент считается исчерпанным. Такой подход культивирует в людях страх ошибиться, что, как мы выяснили раннее, разобщает команду. Ошибка воспринимается как нелестное достояние одного человека, с которым нужно поскорее покончить. При таком взгляде на вещи сложно не воспринимать скромность («я тоже могу ошибиться») как опасную уязвимость.
Характерной чертой здорового коллектива является склонность отделять ошибку от личности её автора и помещать её в багаж своего коллективного опыта. Разбор производится не для того, чтобы определить меру вины, а для того, чтобы извлечь всю информацию, которая может пригодиться в будущем. Документирование, post mortem-ы – это практики, которые показывают, что команда на верном пути.
Что можно сделать: Конечно, многое в отношении людей к ошибкам определяется тем, какой посыл исходит сверху. Тем не менее, от себя вы можете привнести правильный настрой. Не бойтесь подробно и публично анализировать собственные промахи, а говоря о чужих делайте упор на конструктивную сторону. Если вам придётся солировать в post-mortem-е, помните: ваша цель – не покаяться, а дать компании максимум полезной информации.
Хорошо составленные «результаты вскрытия» должны содержать в себе следующее:
- краткий отчет;
- хронологию проблемы — от ее обнаружения до исследования и разрешения;
- основную причину проблемы;
- оценку последствий и ущерба;
- список действий, направленных на немедленное решение проблемы;
- список действий для предотвращения повторения проблемы;
- сделанные выводы.
Рокировки
Как не должно быть: Чем лучше разработан механизм, тем больше гибкости может позволить себе команда. В некоторых случаях кажется, что дела идут отлично, пока все занимают строго установленные места. Но затем происходит сдвиг, в результате которого роли немного смещаются или в контакт вступают пары сотрудников, которые раньше не взаимодействовали – и всё резко разлаживается. Подобное хрупкое равновесие свидетельствует о том, что в команде были подспудные проблемы, которые могут дать о себе знать на любом крутом вираже.
Здоровая команда обычно оказывается способна выдержать подобные стрессы с небольшими потерями. Сотрудники, привыкшие с уважением относиться к окружающим, в том числе и когда те поневоле испытывают терпение, сумеют мало-помалу притереться даже к собственному антиподу, пусть и не без конфликтов. Если все, включая рок-звёзд местного разлива, научились спокойно относиться к неудачам, возможность освоить новую роль скорее вызовет у них интерес, чем страх. В результате коллектив становится более мобильным, проще адаптируется к переменам и быстрее растёт в профессиональном плане за счёт нового опыта.
Что можно сделать: Здесь образ действий достаточно прозрачен – не отторгайте новые возможности на подходе, даже если они выглядят как серьёзный вызов. Не давайте себе коснеть на одном месте, не развиваясь, просто потому что в новых задачах вряд ли сможете сразу блестяще показать себя. Не отказывайтесь иметь дело с коллегой после первого же недопонимания – постарайтесь до чего-то договориться.
Фитцпатрик вспоминает здесь о собственном опыте парного программирования с другим членом команды для разрешения некоторых проблем с конвертацией CVS-репозиториев. Коллега предпочитал погружаться в проблему неспешно и основательно, сам же автор привык думать и перебирать решения на ходу. Вопреки ожиданиям первых дней они не убили друг друга, научились смотреть на проблему под разными углами и справились с задачей.
Теперь, когда мы определились с тем, что составляет ядро социального взаимодействия – зачем нужна команда, какие основные правила общения формируют её климат и как это всё выглядит в повседневной жизни, пришло время перейти на следующий слой. Во второй части конспекта мы рассмотрим понятие корпоративной культуры и роль, которую играет в её создании и укреплении лидер.
