Сегодня мы продолжаем знакомство с книгой «Team Geek: идеальная IT-компания» Брайана Фитцпатрика и Бена Коллинз-Сассмэна, посвящённой общению «по работе» во всех его проявлениях. В прошлый раз мы начали с внутрикомандных коммуникаций и говорили в основном о том, как влияет на них образ мышления каждого отдельного сотрудника. На этот раз нам предстоит взглянуть на команду шире – как на объединённую группу с собственной внутренней культурой, которая как-то образуется и для чего-то нужна.
Культура команды — это набор знаний, ценностей и целей, характерных для конкретной группы программистов. Сюда входят и методы создания программного кода, и стиль общения между людьми, и способы организации рабочего процесса – составляющих очень много. Некоторые из них не слишком критичны, легко приходят и уходят (например, обычай заказывать пиццу и играть в настолки по пятницам), другие составляют «костяк» культуры и могут переживать целые поколения программистов (скажем, процедуры процессов инспекции кода, тестирования, документирования и так далее).
В своём изначальном виде культура, как правило, задаётся основателями и первым составом технической группы. Впоследствии она неизбежно развивается и претерпевает изменения, но у сильных, зарекомендовавших себя команд (в качестве примера можно привести Google, Apple, Microsoft, Oracle) чаще всего в какой-то мере сохраняет своё исходное лицо – связь с корнями не утрачивается полностью.
Вопреки распространённому заблуждению, культура команды не находится полностью в руках и на совести руководителя. Если она действительно существует (о том, что происходит, если культуры толком нет, мы поговорим чуть позже), её транслируют практически все сотрудники. Это становится очевидным, если посмотреть на то, как обычно происходит интеграция в команду новичка. Новый разработчик составляет представление о том, как здесь принято, что важно, а что неважно через взаимодействие с коллегами: на что обращают внимание в его коде, чем и в каком тоне объясняют необходимость исправлений, как разрешают конфликты.
Самоподдержание командной культуры: хлебопекарная метафора
Зачем работать над культурой команды?
Итак, культура команды представляет собой некую диффузную смесь различных установок и соглашений, которая позволяет людям, работающим вместе, оставаться на одной волне. Возникает естественный вопрос: стоит ли особенно беспокоиться по этому поводу? Взаимное влияние сотрудников друг на друга в процессе работы происходит естественным образом, так что какая-никакая культура, вероятно, образуется сама собой.
Проблема здесь в том, что, как и со всеми спонтанными процессами, стихийно развивающаяся культура породит больше энтропии и может дать непредсказуемые результаты. Другими словами, рано или поздно найдутся люди, которые решат собственноручно определить, «как здесь принято». Если они окажутся здравомыслящими и будут действовать в одном направлении, финал будет счастливым. Но чаще всего это оборачивается всё теми же старыми добрыми офисными войнами или, ещё того хуже, очагами разложения внутри команды.
Так что пустить дело на самотёк – не лучший выбор. Выше мы говорили о том, что культуру нельзя привить насильственно, но к её формированию можно подойти с осознанностью. Если каждый участник не только ведёт себя в соответствии с принципами из прошлой главы, но и старается вывести их на уровень команды, пресекает опасные для сотрудничества действия, не боится обговаривать общие для всех правила, риск неприятных сюрпризов снижается.
Какой должна быть командная культура?
Однозначно и исчерпывающе ответить на этот вопрос, разумеется, невозможно. Культуры крайне разнообразны, а диапазон здоровых, продуктивных вариаций очень широк. Хорошо поставленной и комфортной может быть работа как в хаотичном стартапе, где все «свои в доску», так и в крупной компании с чёткими процессами и сохранением дистанции. Пытаться задать эталон для каждого из многочисленных элементов бессмысленно.
В самых общих чертах культура должна быть:
- Устойчивой. Это необходимое условие самосохранения. Круговорот людей в компаниях неизбежен, поэтому культура должна уметь отторгать вредоносные влияния извне за счёт участников, которые её поддерживают и оберегают. Кстати, именно благодаря этому свойству сильные культуры обеспечивают самоотбор сотрудников: неподходящие люди просто не проходят процесс найма или интеграции.
- Гибкой. С другой стороны, закостеневшая культура нежизнеспособна, хотя бы потому, что включает в себя методы разработки, которые меняются с развитием технологий. Да и другие элементы иногда требуют обновления. Оптимальна такая степень открытости, когда небольшие изменения интегрируются без проблем, а радикальные – встречают сопротивление.
- Продуктивной. Это выглядит само собой разумеющимся, но бывают и такие команды, где все живут душа в душу, но не слишком заинтересованы собственно в разработке: им интереснее общение с единомышленниками, или активность в сообществе, или борьба с другими отделами. Время такие группы проводят хорошо, но им сложнее достигать практических целей и удерживать специалистов хорошего уровня – талантливые, увлечённые разработчики быстро начинают скучать и уходят.
- Прозрачной. Передача и усвоение элементов культуры происходит гораздо проще, когда новые люди ясно понимают, что от них ожидается. Поэтому успешность культуры во многом определяется тем, как проходит коммуникация в команде. Чем лучше отлажен обмен информацией и чем больше существует источников с прописанными правилами, тем быстрее будет проходить адаптация.
Каналы коммуникации – та составляющая культуры, которую проще всего контролировать, и больше всего внимания авторы уделяют именно им. Однако, прежде чем переходить к их подробному описанию, они дают пару советов относительно других, более трудноуловимых элементов.
Если говорить о способах принятия решений, то в большинстве своём программисты отдают предпочтение демократичным моделям. Возможно, это связано с их пресловутым стремлением к независимости, а может, дело в том, что профессия, по сути своей, творческая, но факт остаётся фактом: для разработчиков важно иметь права голоса и возможность делиться собственными мыслями. Руководителям следует учитывать это, организуя процессы принятия решений. Необязательно решать все вопросы общим голосованием, достаточно, чтобы к сотрудникам действительно прислушивались и система предполагала достаточно консенсуса, чтобы они ощущали свою сопричастность.
Что касается манеры общения, она должна тяготеть скорее к подчёркнутой вежливости, чем к агрессивности. Проблема с командами, в которых принято утверждать своё «я» криком или напористым тоном, в том, что они отталкивают и затирают людей более спокойного склада. Человек, склонный к конфликтам, будет чувствовать себя вполне комфортно и в агрессивной среде, и среди вежливых людей. Спокойный, замкнутый человек (каких среди программистов немало), напротив, не сможет как следует раскрыться в агрессивном коллективе. Соответственно, поощряя или просто принимая, наступательную манеру общения, мы автоматически отсекаем часть потенциальных сильных сотрудников. Это непрактично.
Вместе с тем, следует понимать, что культура корректности и взаимоуважения более хрупка и уязвима по отношению к внешним влияниям. Достаточно одного напористого новичка, чтобы гармония пошатнулась. Поэтому очень важно на корню пресекать любые попытки идти против принятой манеры общения и не давать людям одерживать победы через деструктивное поведение. Лучший способ для этого – простой отказ от коммуникации в агрессивном тоне.
Каналы коммуникации
Мы выяснили, что определяющую роль в командной культуре играет фиксация и передача информации. В современных условиях нам доступно множество инструментов для этой цели; в этом разделе приведён обзор только самых расхожих.
Общая черта успешных команд состоит в том, что они активно пользуются различными каналами коммуникации для того, чтобы каждый оставался в курсе как общего направления движения, так и текущего хода работ. Упор при этом делается на те каналы, которые, во-первых, делают информацию общедоступной, а во-вторых, по максимуму используют возможности асинхронного общения.
Далее авторы рассматривают ряд конкретных инструментов, через которые происходит общение в технических командах; уточняя их назначение и правила использования.
Определение миссии
От такого заголовка читатель-программист, вероятно, перекрестится, но на самом деле, всё не так страшно. В технической работе миссия формулируется на уровне отдельных проектов и ставит своей целью не восхвалить компанию в туманно-витиеватых выражениях, а чётко обозначить, что именно делается и что не делается. Иными словами, формулировка миссии — это лаконичное определение направления разработки продукта и ограничение его масштаба.
Допустим, так:
Миссия GWT — радикальное улучшение удобства работы пользователей во Всемирной паутине путем предоставления разработчикам возможности использовать существующие инструменты Java при создании AJAX-приложений для любого современного браузера.
Как люди, активно задействованные в проектах с открытым кодом, Фитцпатрик и Сассмэн на собственном опыте могли убедиться, сколько времени, сил и нервов такая мера может сэкономить для команды в долгосрочной перспективе. Когда к работе постоянно присоединяются новые участники, каждый со своими амбициями, замечаниями и светлыми идеями, «ядро» группы должно иметь ясное и единообразное представление о сути проекта. В противном случае работа либо пойдёт по сценарию басни о лебеде, раке и щуке, либо будет постоянно тромозиться из-за попыток прояснить эти вопросы по ходу дела.
Соответственно, определение миссии полезно в двух отношениях. Во-первых, если среди ключевых участников есть разногласия относительно целей и рамок проекта, это всплывёт сразу же и будет разрешено без отлагательств. Во-вторых, итогом обсуждения станет документ с основными тезисами, к которому можно будет отсылать непонятливых или излишне ретивых новичков.
Формулировка миссии даёт команде точку опоры в любых решениях относительно проекта, но при этом считать её абсолютно неприкосновенной не следует. Иногда случается (в первую очередь, в стартапах), что цели или обстоятельства работы меняются радикальным образом. Во внештатных ситуациях имеет смысл честно оценить, актуальна ли ещё исходная миссия, и внести в неё соответствующие изменения.
Проектная документация
Если миссия призвана выработать единый для всех участников проекта ответ на вопрос «что», то проектная документация подразумевает аналогичную работу над вопросом «как».
Проектный документ представляет более детальный набросок будущего проекта и его технической начинки. Как правило, у него бывает один владелец, два-три автора и изрядное количество рецензентов, вносящих свои замечания. Создание документации, как ни тяжело с этим смириться, должно предварять работу над кодом – момент, когда не написано ещё ни строчки, лучше всего подходит, чтобы выслушивать критику и корректировать планы по реализации. Готовый проектный документ очень удобно использовать при составлении дорожной карты, выделении этапов работы и так далее.
Проектная документация по своей природе значительно гибче формулировки миссии, это не догма, а живая субстанция. В процессе разработки обязательно приходится пересматривать какие-то детали, и в идеале документация должна отражать все эти изменения в реальном времени, чтобы команда могла держать руку на пульсе. В реальности её, увы, чаще редактируют уже после выпуска продукта.
Совещания
Многие подумают, что перекреститься не мешало бы и здесь – у собраний довольно плохая репутация в среде разработчиков. По мнению авторов, причина в том, что их плохо организуют и часто применяют там, где разумнее было бы обратиться к асинхронному каналу коммуникации.
Хороший пример неудачного подбора формата – «летучки», которые проводят с заданной регулярностью (обычно раз в неделю) и массой народа. Обычно там зачитываются важные объявления, подводятся общие итоги и так далее. По сути, всё содержание «летучек» очень легко и продуктивно переводится в формат электронной рассылки, за исключением тех случаев, когда необходимо именно широкое коллективное обсуждение.
Что до совещаний, без которых действительно не обойтись, при их проведении следует помнить о следующих правилах:
- На совещании должен присутствовать строго необходимый минимум сотрудников. Посмотрите на общую атмосферу в кабинете – если многие участники пассивны, отвлекаются на мессенджеры и другие дела, значит, позвали много лишних. Особенно жёсткий лимит авторы ставят на собрания для «мозгового штурма» — не более пяти человек. Большее число допустимо, только если конечное решение будет принимать кто-то один.
- У каждого собрания должен быть куратор, который наметит его план, хотя бы в виде списка вопросов для рассмотрения. Желательно разослать план всем участникам заранее, примерно за день. После того как все пункты плана выполнены, совещание заканчивается, невзирая на временные сроки.
- Собрание должно проходить согласно составленному плану. Задача куратора – не давать участникам слишком удаляться от повестки дня или увлекаться пространными монологами.
- Следует назначать собрания как можно ближе к естественным перерывам в работе (обед, конец рабочего дня). По возможности имеет смысл разгрузить от совещаний конец недели, когда многие завершают и сдают задачи – такая традиция внедряется в Google давно и с переменным успехом.
Почтовые рассылки
Электронная почта – очень полезный инструмент документирования истории проекта в фоновом режиме. Извлекать из неё информацию гораздо проще, чем из мессенджеров, где куда больше трафика и куда меньше регламента. Поэтому целесообразно отправлять в рассылках всю важную информацию, независимо от того, где она звучала до этого: копии планов и заметок с совещаний, итоги обсуждения тех или иных проблем, проектные документы, разборы ошибок. Таким образом формируется централизованное хранилище данных, куда на любом этапе можно будет вернуться, чтобы не только найти те или иные сведения, но и проследить истоки решений и ход дискуссии. Конечно, архив при этом должен быть снабжён индексированным поиском.
Важность документации и, соответственно, рассылок определяется тем, насколько компактно размещена команда в пространстве. Если некоторые сотрудники работают удалённо или появляются в офисе нерегулярно, устойчивая практика дублирования основных проектных новостей по почте становится острой необходимостью. Иначе большая часть информации, которая «витает в воздухе» (обсуждения в коридорах и возле столов, устная передача новых сведений тем, кто не был на собрании) будет проходить мимо них.
Если команда крупная и процессы идут бурно, участники скоро начнут тонуть в потоке разнородных объявлений. При таком раскладе документация разбивается на разные тематические рассылки (разработка, анализ программного кода, поддержка пользователей, тестирование и так далее), в которые включаются заинтересованные сотрудники. Начинать, впрочем, лучше с одного потока – если появится потребность в разделении, до вас быстро это донесут.
Онлайн-мессенджеры
Мессенджеры стоят где-то посередине между синхронным и асинхронным общением. Для документации они не оптимальны, но для быстрого решения вопросов незаменимы, особенно в распределённых командах. С точки зрения командной культуры здесь важны два аспекта.
Во-первых, водораздел между приватными и общими дискуссиями. Подавляющее большинство и внутренних, и коммерческих мессенджеров дают пользователю возможность выбирать между общением с конкретным человеком или группой людей, и это очень удобно. Однако, по мнению Фитцпатрика и Сассмэна, в последнее время наблюдается тенденция к замкнутости – обсуждения всё чаще проходят с глазу на глаз.
В каких-то отношениях это неплохо – частные вопросы точно не будут «забивать эфир» всем сотрудникам. Но с другой стороны, люди лишаются возможности следить за ходом дискуссии, вставлять свои замечания, сразу узнавать об изменениях. Многое теряют и новички, которые могли бы получить массу ценной информации, просто молча читая активные обсуждения в общем чате. Нередко дискуссии уходят в приват не потому, что они слишком нишевые, а всё из-за того же страха уязвимости: не хочется задавать вопросы или вносить предложения у всех на глазах – вдруг они окажутся глупыми? Разработчикам стоит ловить себя на такой мотивации и стараться не прятать то, чему разумнее оставаться в общем доступе.
Во-вторых, нужно помнить, что мессенджеры, несмотря на всю мгновенность реакций – не полная замена живому общению. В них нет интонаций и мимики, которые могли бы смягчить или прояснить какие-то фразы. Из-за этого риск недоразумений, которые угрожают принципам скромности, уважения и доверия, возрастает, и это следует иметь в виду.
Система отслеживания ошибок
Этот инструмент не так распространён, как те, о которых говорилось выше. Он может приносить немалую пользу при определённых условиях:
- Наличие процедуры обработки и сортировки ошибок, которая обеспечивает их своевременную регистрацию и исправление. Если отладке системы не уделили достаточно внимания, люди либо не станут ей пользоваться, либо будут злоупотреблять по мелочам.
- Дублирование очных обсуждений. Если «разбор полётов» прошёл в устной форме, краткая выжимка со всеми официальными заключениями должна быть внесена в систему.
- Ограничение масштаба дискуссии. Продолжительные споры со множеством участников следует переносить в почту – она лучше приспособлена для разветвлённых обсуждений.
- Модерация. Когда речь заходит об ошибках, корректное поведение имеет особенно большое значение, оскорбления и провокации недопустимы.
Общение как часть разработки
Коммуникация в технической команде происходит не только вокруг, но и непосредственно внутри кода. Основной канал здесь – конечно же, комментарии разработчиков.
Авторы мельком касаются основных правил комментирования кода, которые, вероятно, всем знакомы: объяснять, не что делается, а почему это делается, стараться комментировать на уровне функций и методов, быть лаконичным и не увлекаться подробностями. В остальном стиль комментирования – вещь субъективная, каждая команда вырабатывает свой в зависимости от потребностей и общей атмосферы. Главное, чтобы этот общий стиль существовал в принципе; сам факт единообразия в этом случае важнее конкретных характеристик.
Другой способ коммуникации внутри кода – указания авторства, то есть подпись разработчика в файле. Обычай оставлять своё имя в документе пришёл к нам из давних времён; в старых программах сплошь и рядом можно видеть вот такие автографы:
Фитцпатрик и Сассмэн настаивают на том, что сегодня эти подписи следует считать анахронизмом. С психологической точки зрения, желание указать авторство, разумеется, остаётся естественным и понятным: это проявление гордости и чувства ответственности за сделанную работу. Однако с практической стороны это даёт больше проблем, чем пользы. Сейчас разработка, как мы уже установили в первой части статьи, стала командным видом деятельности. К одному фрагменту кода может быть в реальности причастно сразу несколько людей, а значит, решение вопроса об авторстве может вызвать споры, обиды и, в конечном счёте, потерю времени впустую.
В текущих условиях целесообразнее вести учёт авторства на уровне проекта, а не непосредственно в коде. Когда необходимо узнать, к кому именно обращаться с вопросами о той или иной части кода, на помощь придёт система контроля версий.
Теперь, когда мы со всех сторон рассмотрели ядро «человеческого измерения» в IT-компании, можно переходить к периферийным слоям: инородным элементам, окружающим командам и пользователям.
