Работа в офисе или удаленно?

Перевод статьи Мартина Фаулера «Remote versus Co-located Work«

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

СОДЕРЖАНИЕ

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

Однако, когда дело доходит до разработки программного обеспечения, большинство разработчиков не хотят использовать новые возможности. Например, пару лет назад компанию Yahoo! раскритиковали за то, что они вернули сотрудников в офис. Топовые ИТ-компании, такие как Netflix или Google однозначно предпочитают, чтобы их персонал был колоцирован.

Другие же тыкают в них пальцем и смеются над этим. Лучше всех слышно такие ведущие стартапы, как Etsy, Basecamp или Github, чьи сотрудники никогда не работали в офисах. Они считают, что за удаленной работой — будущее, а те, кто противится этому, останутся в проигравших.

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

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

Степень распределенности

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

Колоцированная команда — это команда, в которой все сотрудники работают в одном помещении. В идеале члены команды находятся в нескольких шагах друг от друга, и  могут видеть, чем заняты их коллеги и могут быстро обсудить проблему (без необходимости организовывать процесс коммуникации). Большинству команд нравится единое пространство, потому что оно максимально упрощает коммуникацию. Им мешают даже кубиклы, у Аджайл-коучей есть много историй про отвертки.

Мульти-офисная команда состоит из двух и более групп, работающих в разных офисах в рамках одной большой команды. Иногда у такой модели между подкомандами есть формальные границы и у каждой своя ответственность. Хороший пример такой организации: команда разработки, которая располагается в Мельбурне и Сиани.

Работники-спутники — большинство сотрудников работают в одном офисе, но некоторые работают удаленно, из дома или другого офиса.

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

Степень распределённости варьируется. Иногда достаточно разместить команду на двух этажах одного здания, чтобы люди перестали чувствовать сплоченность. Если расстояние будет больше и, ко всему прочему, добавляются часовые пояса, то ощущение удаленности усилится. Многие утверждают, что разница становится наиболее заметна, когда сотрудники перестают находиться в шаговой доступности друг от друга. Переломная точка наступает тогда, когда вам проще отправить e-mail, чем дойти до коллеги чтобы что-то обсудить.

Большинство людей эффективнее работают вместе

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

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

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

Причина кроется в простоте коммуникации. Конечно, такие инструменты как чаты (в том числе и с видео), совместный доступ к экрану и т. д. сильно упрощают работу удаленных сотрудников. Но возможность просто обернуться и поговорить с коллегой делает коммуникацию намного эффективнее. Кроме того, сотрудники в офисе могут общаться друг с другом и на другие темы, что улучшает отношения между ними и работу команды в целом. В результате формируется усиливающийся цикл, который поддерживает дух товарищества и налаживает коммуникацию. Поскольку коммуникация — это центральная часть разработки программного обеспечения, она сильно влияет на продуктивность. Заметьте, я имел в виду большинство команд. Люди очень разные, хотя в одном мы схожи: мы склонны считать, что все ведут себя одинаково. Поэтому можно с легкостью предположить, что есть те, кто эффективнее работает удаленно. Я думаю, таких меньшинство (здесь может сыграть роль фактор поколения. Молодые люди более привычны к коммуникации по интернету).

Команды, работающие удаленно, чаще более продуктивны

Итак, если людей, ориентированных на удаленную работу, меньше, значит ли это что вы должны отдавать предпочтение колоцированным командам? Как оказалось, что часто это не так.

Хотя я часто слышу, что команда эффективнее когда все находятся в одном офисе, это сильно ограничивает выбор сотрудников. Значит, что у вас нет возможности нанять лучших специалистов. Можно найти лишь тех, кто согласится переехать. Если вы организуете удаленную работу, то выбор специалистов у вас больше. Команда, работающая удаленно, возможно будет не так эффективна, как если бы те же участники работали в офисе, но она может быть намного эффективнее колоцированной команды, которую вы могли бы сформировать.

Удаленность не только помогает избежать проблем с долговременными переездами, но и предлагает больше возможностей сотрудникам, когда у них есть возможность работать из дома. Люди ценят то, что они работают в комфортной среде и им не нужно тратить время и энергию на дорогу, например, чтобы забрать детей из школы. Благодаря этому условия найма становятся привлекательнее. Компании могут создавать более разнообразные команды, ведь, например, женщинам, сложнее работать в офисе, так как они чаще берут на себя заботы по дому.

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

Обращайте внимание на паттерны коммуникации

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

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

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

В мульти-офисной команде нужно разделять работу на полностью автономные компоненты. Каждая из команд должна быть full-stack и ответственной за создание продукта от идеи до реализации. Не разделяйте их по слоям (фронтенд, бэкенд, база данных) или по функциям (анализ, разработка, тестирование). Как между слоями, так и между активностями происходит постоянное взаимодействие. Не забывайте о важности закона Конвея.

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

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

Распределенность и Аджайл

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

Безусловно, Аджайл-методы стимулируют сплоченность команды. Например одна из основных практик Экстремального Программирования (XP) называется «Сидите вместе». Ее суть заключается в том, что «чем больше сотрудники общаются в реальности, тем человечнее и продуктивнее проект». Аджайл Манифест гласит: «Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды».

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

Выводы

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

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

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

Нам стоит больше работать с Аджайл-лидерами!

Весной 2019 мы провели первый двухдневный тренинг для Аджайл-лидеров Professional Agile Leadership (PAL), который был очень хорошо принят участниками. Ключевая аудитория — менеджеры среднего/высшего звена, которые работают с Аджайл-командами.

Это руководители бизнес-юнитов и продуктовых групп, например, трайб-лидеры. В Аджайл-сообществе распространены тренинги для Владельцев Продуктов и Скрам-мастеров, а что мы предлагаем лидерам и менеджерам? Ведь их роль и влияние ОГРОМНЫ. В их руках находятся ключи к организационному дизайну компаний, а значит, и гибкости (Business Agility). Кажется, что стоит больше работать с менеджментом, поддерживать его и обучать.

Поэтому мы проведем в середине ноября уникальный трехдневный тренинг Advanced Professional Agile Leadership (PAL-E). Добавили в программу темы ответственности и системного мышления. И теперь это взрывная смесь!

Эшелоны Полёта: уровни организационного улучшения

Перевод оригинальной статьи  «Flight Levels: The Organizational Improvement Levels»

Когда вы записываете какую-либо идею, вы смотрите на неё, обдумываете и продолжаете её разрабатывать. Именно так произошло и с моделью Эшелонов Полёта (Flight Levels). Её уже много раз обсуждали на консультациях с клиентами, на тренингах и презентациях. Несмотря на это, как только была опубликована моя книга «Канбан на практике», я изменил свою точку зрения насчёт Эшелонов Полёта благодаря обратной связи от читателей, слушателей и участников тренингов.

Читать далее «Эшелоны Полёта: уровни организационного улучшения»

6 мифов об Аджайл-разработке (Майк Кон)

Перевод оригинальной статьи Майка Кона Six Agile Product Development Myths — Busted

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

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

Однако при том, что у Аджайл философии есть много преимуществ, похоже, что и заблуждений не меньше. В этой статье я хотел бы разрушить шесть мифов о разработке Аджайл-продуктов. Читать далее «6 мифов об Аджайл-разработке (Майк Кон)»