среда, 22 июня 2022 г.

[prog.management] Утащу к себе текст чужого поста из LinkedIn. Про влияние удаленки на проектные команды во времена COVID-а

Текст найден в LinkedIn вот здесь: цинк. Автор процитированного ниже Константин Владимиров:

Журнал Nature опубликовал прекрасное исследование об эффектах удалёнки. Исследовалось примерно 70000 сотрудников Microsoft.

The effects of remote work on collaboration among information workers

Там аккуратным научным языком изложено всё, о чём я кричал с 2020-го. Удалёнка имеет тактические плюсы, но за коротким подъёмом продуктивности следует спад коммуникации, дробление команд и потеря связности коллективов. После чего -- долгосрочное падение продуктивности.

От себя хочется добавить: после года удалёнки собрать большую мультикоманду заново уже очень сложно.

Допустим у нас есть 60 человек разбитые на 6 команд по 10 человек (скажем три команды разной разработки, а также валидация, аналитики, инфраструктура). Тогда при переходе на удалёнку вы через год получите примерно такой эффект:

(1) Общение между тремя командами разработки прекратится вообще. Всем очень повезёт если останется общение внутри команд (значит там были лидеры которые не дали сгнить хотя бы внутренней коммуникации). Никто в первой команде разработки не будет знать что делает вторая и как дела у третьей. Никакие специальные усилия не помогут: такие вещи как реальное состояние дел в разработке никто не оглашает на формальных митингах, этим делятся вполголоса у кофемашины. Больше кросс-командных удалённых митингов означает больше трескотни и больше спящих на этих митингах человек.
(2) Конструктивное взаимодействие между разработчиками и валидаторами может остаться только при личных контактах. Оно будет минимальным.
(3) Точно также прекратится конструктивное взаимодействие между разработчиками и аналитиками.
(4) Команда инфраструктуры замкнётся в себе и содержательно помогать другим командам оттуда будут разве что по старому знакомству.
(5) Никто не будет знать новых членов команд в том числе своей команды. Их ramp-up будет практически невозможен, т.к. в нём никто не будет заинтересован.

И самое плохое в таком состоянии то, что потом из него будет очень сложно собрать коллектив заново, потому что да, хождение в офис это принуждение и неудобство. Ваши же ключевые люди вам потом скажут "ну я же эффективен на удалёнке, вот баги хорошо решаю, не хочу обратно". А без них офис будет уже не тот. И гниение продолжится.


От себя добавлю вот что. Если мне не изменяет слероз, то Джо Армстронг, родитель языка программирования Erlang, считал одним из ключевых факторов успеха разработки софта для AXD301 то, что всю проектную команду удалось собрать в одном месте. Тем самым решив проблему эффективной коммуникации между разработчиками. Если кто-то не в курсе про AXD301 (а это прям-таки икона успешного успеха для Erlang-а), то вот здесь есть ссылки на разное по этой теме.

2 комментария:

Alex комментирует...

Солидарен. То, что при непосредственном контакте решается за 10-15 минут, при удалёнке решается от нескольких дней/недель или не решается вовсе.
Код становится рыхлым. Куча затрат на рефакторинг.
Уровень недопонимания зашкаливает.
В целом потери на бесконечные коммуникации/согласования/созвона/перепроверки таковы, что дешевле всех вернуть в офис. Рассчитывать на ответственность и сознательность каждого бессмысленно: единожды развратившись, вернуться на путь истинный дано единицам

Skynin комментирует...

Утянул и себе в бложик со всеми ссылками на авторство.
Рулил на удаленке разработкой, как тех лид, да, сложности именно такие :(

Только вовлеченность, проактивность программистов может частично нивелировать эти сложности.
Но эта штука - не управляется, либо чел такой либо - нет.
В офисе реактивного, а не проактивного, атмосфера побуждает к продуктивности.

Но потеря инсайдерской информации от других команд, "у кофе-машины" - невосполнима все равно...

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