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

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

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

СОДЕРЖАНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

Swarming: one-piece flow

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

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

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

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

Предположим, команда пытается увеличить выработку путем параллельной работы, когда каждый сотрудник работает над одним элементом Бэклога Продукта (PBI). Работая в одиночку, члены Команды разработки с большей вероятностью сосредоточатся на разработке элемента, а не на его тестировании, в частности, потому что специалистов, обладающих компетенциями и желанием проводить тестирование, намного меньше, чем специалистов для творческих задач проектирования и разработки. Если в ходе Спринта возникает задержка нескольких элементов, возрастает риск того, что к концу Спринта PBI не придут к статусу «Готово». Что еще хуже, некоторые разработчики из Кремниевой долины и Европы, работающие над сложным программным обеспечением, обнаружили, что если не выявить и не исправить ошибку в ходе Спринта, один час тестирования кода может превратиться в 24 часа тестирования три недели спустя. Если команда откладывает тестирование, а не применяет Сворминг, то элемент, который можно было бы поставить через месяц, будет поставлен через два года. Читать далее «Swarming: one-piece flow»

Инкрементальный дизайн и архитектура

Перевод оригинальной статьи Рона Джеффриза «Incremental Development»

Суть подхода Big Design (детальное проектирование до начала разработки, англ. Big Design Up Front, BUFD) заключается в том, что у нас есть тщательно отобранный набор идеальных требований, и при помощи нескольких достаточно формализованных практик мы создаем красивую архитектуру для воплощения этих требований. Этот дизайн подобно солнцу освещает мир программирования, позволяя программистам без каких-либо глубоких раздумий идеально воплощать идеальную архитектуру для выполнения этих идеальных требований.

Даже если бы это было правдой (спойлер: это не правда), в большинстве случаев Big Design не смог бы удовлетворить наши потребности. Я бы сказал, он никогда не удовлетворяет наши потребности, и уж точно не в случае, который волнует меня больше всего —

В случае работающего продукта

За свою полувековую карьеру в разработке ПО я узнал многое — и самостоятельно, и работая с командами. Если бы я мог вернуться в прошлое и вынести только одну мысль, она была бы такой:

Какой бы продукт вы ни разрабатывали, поставляйте реально работающий продукт каждые две недели, а если возможно, то каждый день.

Читать далее «Инкрементальный дизайн и архитектура»

Создаем прозрачность и ответственность в команде

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

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

Когда команды избегают продуктивного конфликта

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

Команды ТОП-менеджеров тоже не являются исключением. Они часто дополнительно обременены политическими конфликтами, подковерными играми и борьбой за организационные “колодцы”. Читать далее «Создаем прозрачность и ответственность в команде»

Три самых эффективных способа, позволяющих руководителям заслужить доверие

Одна из наших любимых тем — доверие. Мы уделяем ей значительное время в рамках Аджайл-консалтинга, работая с командами и организациями. В продолжении развития это темы сегодня публикуем перевод статьи  «The 3 most effective ways to build trust as a leader».

Читать далее «Три самых эффективных способа, позволяющих руководителям заслужить доверие»

Как заставить говорить ваш Cumulative Flow Diagram?

Участвуя как спикер на разных конференциях я наибольшее удовольствие получаю не от выступлений на сцене с докладом и слайдами, а от живого общения на различных мастер-классах и воркшопах. Камерная атмосфера дает возможность апробировать интересные инструменты и извлечь уникальные инсайды. Не обошлось без этого и на Agile Days 2019, где я выступал с мастер-классом про накопительные диаграммы потока (CFD). Ниже тезисы моего воркшопа. Читать далее «Как заставить говорить ваш Cumulative Flow Diagram?»

8 причин хронического незавершения работы в Спринте

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

Системы, паттерны и структуры.

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

Поиск структуры.

Задача Скрам-мастера — в партнерстве с командой найти структуру, которая вызывает паттерн и изменить ее. Для этого Скрам-мастер может предложить команде использовать на Ретроспективе инструменты системного мышления:

  • Пять почему
  • Fishbone
  • Causal-Loop Diagrams(CLD)
  • Дерево реальности
  • Метод А3

Фундаментальные причины, к которым приходят команды, могут сильно различаться. Приведу те, с которыми встречался в своей практике.
Читать далее «8 причин хронического незавершения работы в Спринте»

Модель коммуникации определяет продуктивность команды

Наука или искусство

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

Паттерны коммуникации успешных команд

В статье The New Science of Building Great Teams профессор Сэнди Пентлэнд пишет, какие паттерны коммуникации и поведения определяют успешные команды:

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

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

Исследование очень сильно перекликается с многолетним исследованием Эми Эдмондсон о психологической безопасности, которое легло в основу проекта Аристотель (исследование в компании Google). Мне кажется, что психологическая безопасность является основополагающим фактором, который “открывает” людей и затем дает возможность раскрыться команде с помощью эффективных паттернов коммуникации.

Как это может изменить вашу работу как Скрам-мастера и агента изменений? 🙂

Как найти пользователей на Обзор Спринта

Проблема с поиском пользователей на Обзор Спринта

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

Амбициозная цель

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

Где мы искали гостей

Я разместила приглашение на Обзор Спринта в группе Scrum Russia на FB. Несколько ребят подтвердили свое участие. Команде удалось найти четырех пользователей среди тех, кто обращался в техническую поддержку. А отдел продаж привлек ключевого b2b-клиента. Ура!

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

Читать далее «Как найти пользователей на Обзор Спринта»

Как убить очереди и ускорить команду при помощи моббинга

Команда организовывает свою работу

Команда Разработки в Скраме самоорганизующаяся и кросс-функциональная, и поставляет к концу каждого Спринта “готовый” к выпуску инкремент продукта. Команда сама определяет, как ей организовать работу в Спринте:

По результатам Планирования Спринта Скрам-команда решает: каким будет Инкремент в конце Спринта; как организовать работу, чтобы получить готовый Инкремент Продукта (Скрам Гайд, 2017).

Есть полезные современные практики организации работы команды в Спринте, которые вы можете взять на вооружение. И одна из них “моббинг” или “моб-программирование”.

Разработка в стиле “моббинг” или “моб-программирование”

Википедия определяет моббинг как “форму психологического насилия в виде травли сотрудника”, а вот определение “моб-программирования” от автора подхода Вуди Зила:

замечательные люди, работающие вместе над одной задачей в один момент времени в одном месте за одним компьютером.”

По сути, моббинг — стиль работы, когда команда постоянно работает вместе и вместе “набрасывается” на любые задачи.
Читать далее «Как убить очереди и ускорить команду при помощи моббинга»