Важность письменного общения для инженерных групп

В то время как хорошие инженеры-менеджеры умеют программировать, великие также умеют общаться.

Письменное общение, в частности, является неотъемлемой частью управления и масштабирования инженерных команд, говорит Хуан Пабло Буритика, который руководил несколькими успешными командами инженеров, последний раз в качестве вице-президента по инженерии в музыкальной компании Splice.

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

Чтобы успешно развивать и масштабировать инженерные команды, Buritica предлагает создать библиотеку практик, написанную и хранящуюся в доступном для всех месте, будь то Google Диск или инструмент управления знаниями, такой как Confluence или Guru.

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

Вот его трехэтапная стратегия использования письменного общения для повышения производительности команды инженеров:

1. Создайте структуру коммуникации и принятия решений с первого дня

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

Одним из основополагающих документов является то, что Buritica называет коммуникационной архитектурой: правила того, как команда общается — через Slack, Microsoft Teams, электронную почту, телефонные звонки и/или Zoom — и ожидания в отношении времени отклика.

Например, предположим, что группа инженеров считает ночные сообщения в Slack разрушительными. В коммуникационной архитектуре Buritica подробно описала, как инженеры должны реагировать, если кто-то пингует их в нерабочее время. Возможно, было решено, что никто не должен отвечать на сообщения Slack после 18:00. Если ситуация является чрезвычайной, протокол может рекомендовать текст или телефонный звонок.

Чтобы прийти к этому решению, говорит Буритика, первый шаг — опросить команду по поводу проблемы: «Как мы должны разговаривать друг с другом? Как мы должны сообщать о нашей доступности? Что не работает? Что может работать лучше? Как нам действовать в чрезвычайных ситуациях?»

«Каждый может внести предложения, и я вернусь с черновиком сводных предложений», — говорит он. «Затем, как команда, мы обсуждаем это, внедряем и тестируем».

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

В качестве другого примера, Buritica создала стратегический документ в Splice, чтобы описать, как команда инженеров собирается достичь своих бизнес-целей. Цель состояла в том, чтобы ускорить выпуск продукта за счет более быстрой доставки программного обеспечения, а это означало, что команде нужно было уменьшить трения. В стратегическом документе были изложены необходимые шаги, «и мы начали пилотирование, тестирование, отчетность и обсуждение наших идей», — говорит он. «Все начали вносить свой вклад в документ и стали действительно мотивированными». В конце концов команда достигла своей цели, сократив время доставки с шести месяцев до шести недель.

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

Как он заставляет людей доверять документам? «Я им пользуюсь, — говорит он. «Я живу своим собственным процессом. Если я их не использую, как еще я могу ожидать, что это сделает кто-то другой?»

2. Позвольте команде стать владельцем документов

Команда должна принимать участие не только в создании документов, но и в их развитии. «Инженеры — это те, кто использует процессы и информацию, — говорит он. «Чем ближе они к документу, тем больше они должны владеть им».

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

Крайне важно отказаться от авторитета ради авторитета и быть открытым для идей команды. «Я ценю людей, которые бросают мне вызов на собраниях, задают трудные вопросы и побуждают других делать то же самое», — говорит он. «Например, в одном документе я написал, что мы должны объединить пулл-реквесты через 36 часов. Один из моих инженеров спросил: «Почему 36 часов?» и он привел аргументы в пользу того, чтобы изменить это».

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

Если это небольшая команда, Buritica дает права на редактирование всем. Если это большая группа, он оставляет права редактирования только нескольким членам команды, хотя любой может вносить предложения. В случае возникновения конфликтов или противоречивых мнений решение принимает менеджер. «Документ не претендует на демократичность или консенсус», — говорит он. «Не все должны соглашаться».

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

3. Повышение сложности существующих фреймворков для масштабирования команд

Структуры принятия решений еще более важны, когда команды распределены.

«Если вы научитесь работать на расстоянии — будь то физическое или культурное — и знаете, как использовать эти рамки, вам будет легче расти быстрее, даже если вы нанимаете людей со всего мира», — говорит Буритика. Документы можно использовать для быстрого привлечения большего числа людей и повторения успеха.

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

Поэтому он сделал свой документ более подробным. «Затем этот менеджер прошел через процесс и попытался пройти собеседование, и в конце концов она изменила то, что я написал, отметив, что работает, а что нет. Со временем он перестал быть моим документом и стал документом команды. И продолжает развиваться».

Сегодня, когда в команде 50 человек, этот документ расширился и теперь включает в себя процессы, связанные с скринингом, проведением технических бесед и встречами с существующими членами команды. «Есть рубрика, слепые обзоры и еще полировка», — говорит он. «Это следующий уровень. Люди, которые не участвуют в процессе, могут лучше его понять».

Будущее работы написано

По всем этим причинам Буритика отдает приоритет навыкам письменного общения, когда возглавляет команду.

«Можете ли вы хорошо общаться в письменной форме? Я не оцениваю чью-то способность быть грамматически правильным. Английский даже не мой родной язык. Я хочу знать, может ли кандидат донести свою точку зрения и иметь влияние», — говорит он. Каждый член команды должен оттачивать свои навыки письма, чтобы он мог эффективно вносить свой вклад в рамки коммуникации.

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