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

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

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

СОДЕРЖАНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

У вас “Chief Product Owner” и Copy Paste Scrum?

О чем статья

Компании часто неверно интерпретируют отдельные положения Скрама, когда разрабатывают большие продукты. Особенно часто встречается непонимание роли Владельца Продукта. Структура “одна команда один Владелец Продукта”, которую я часто вижу, выглядит примерно так:

Мы называем эту модель Copy Paste Scrum и она вызывает целый ворох проблем:

  • Зависимости между командами и вынужденную координацию;
  • Отсутствие сквозных приоритетов и работу над менее важным;
  • Хрупкость системы;
  • Оторванность разработчиков от бизнеса и клиентов;

В общем случае Copy Paste Scrum — фейковый Скрам. В этой статье я объясню почему, а затем мы разберемся в том, как разрабатывать большие продукты, используя Скрам профессионально.

Читать далее «У вас “Chief Product Owner” и Copy Paste Scrum?»

Скрам-мастер паттерн**

Перевод паттерна Scrum Master**

В 1953 году участники британской экспедиции Эдмунд Хиллари и Шерпа Тенцинг Норгей, во главе с Джоном Хантом, впервые в истории взошли на Эверест. Признание получают те, кто достигает цели при поддержке фасилитаторов, играющих не такую заметную, но ключевую роль в миссии. Часто Скрам-Мастер работает незаметно.

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

✥ ✥ ✥

Без полного понимания Скрама и применения его принципов и ценностей Команды Разработки, Владельцы Продуктов и организации не смогут воспользоваться преимуществами, которые он дает.

Читать далее «Скрам-мастер паттерн**»

Организационный коучинг: целое не может быть разделено на части

О чем эта статья

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

Низкое качество, снижение продаж

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

Целое не может быть разделено на части

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

“Более 90% проблем, которые возникают в корпорациях, должны решаться не там, где они возникли” (R. Ackoff)

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

В традиционном организационном дизайне частой и повторяющейся темой является локальная оптимизация — “эффективность”, которая противоречит оптимизационной цели системы.

Производительность системы зависит от взаимодействия частей, а не от того, насколько эффективно они работают по отдельности. (R. Ackoff)

Читать далее «Организационный коучинг: целое не может быть разделено на части»

Как подготовить и провести Обзор Спринта с помощью освобождающих структур

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

Цель Обзора Спринта

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

Читать далее «Как подготовить и провести Обзор Спринта с помощью освобождающих структур»

Непрерывная интеграция

Перевод неустаревающей статьи Мартина Фаулера про Непрерывную Интеграцию. Несмотря на то, что статья написана в 2006 году и упоминаемые в ней инструменты уже устарели, описание самой практики остаётся актуальной и по сей день.


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

1 мая 2006 г

Мартин Фаулер

Содержание

Читать далее «Непрерывная интеграция»

Пример цепочки освобождающих структур для знакомства участников

Знакомьтесь, это Барри (справа), один из команды The Liberators. Барри (Barry Overeem) и Кристиан  (Christiaan Verwijs) — пионеры немецкого сообщества освобождающих структур. Ребята не просто развивают освобождающие структуры, но и делают это в организациях и командах, которые работают по Скраму.

Читать далее «Пример цепочки освобождающих структур для знакомства участников»

Ретроспектива: отдых, работа или наказание?

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

А еще он мне рассказал про простую метафорическую модель, которой теперь делюсь с вами. 

Кто приходит на ретроспективу?

Согласно модели, условно бывает 4 типа участников ретроспективы:
— Исследователь
— Отпускник
— Покупатель
— Заключённый

Читать далее «Ретроспектива: отдых, работа или наказание?»

Фасилитация Overall Retro

Если вы уже знакомы с  масштабируемым Скрамом (LeSS), то для вас не секрет, что Общая Ретроспектива обеспечивает работу эмпирического контроля на уровне всей системы (продуктовой группы и организации). Мы инспектируем взаимоотношения, инструменты и процессы на уровне системы. На Ретроспективе присутствуют представители от команд, Владелец Продукта, менеджеры и Скрам-мастера, которым нужно основательно подготовиться. Эта статья поможет вам провести Общую Ретроспективу позитивно и продуктивно! 

Читать далее «Фасилитация Overall Retro»

Владелец Продукта в больших организациях

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

Скачать брошюру

Владелец Продукта в небольшой компании

Руководство по Скраму описывает контекст небольшой компании или стартапа. В этом случае все просто: 7-9 человек обладают всеми необходимыми навыками и выполняют всю работу. Владелец Продукта определяет видение и порядок Бэклога Продукта, а Команда Разработка хорошо понимает бизнес и проблемы своих клиентов, уточняя требования напрямую с ними. Маленькая организация — это отсутствие бюрократии, передач и минимум потерь. Скрам изначально был создан и успешно зарекомендовал себя в работе с небольшими командами. 

Читать далее «Владелец Продукта в больших организациях»