Сегодня предлагаю поговорить горячую тему: а возвращать сотрудников в офис или нет, а если возвращать, то кого и зачем?
Я работаю с удаленщиками еще с 2004 года. Тогда это называлось «распределенная команда», и распределена она была где-то между Мельбурном, Самарой, Тольятти, Москвой и Лондоном. И, хотя все честно ходили в офис по месту пребывания, уже тогда возникал вопрос: а нафига ходить в офис, если главное, чтобы скайп и аська (тогда еще эти слова были популярными) работали, и чтобы было электричество подключить ноут?
С тех пор с распределенными офисами я сталкивался почти на каждом рабочем месте. Картина, когда менеджер и аналитики в офисе, а разработчики фиг знает где, мне стала привычной задолго до ковида. При этом, вплоть до 2020го, весь крупняк по-прежнему требовал присутствия в офисе всей команды, неважно кто ты: разработчик, аналитики или менеджер. Топай в офис.
Потом случился ковид, который уравнял всех, работать из офиса стало запрещено. Удаленка стала обязательной, и большим компаниям пришлось хоть как-то отладить процессы удаленной работы: коммуникации, постановку задач и их контроль. Сделали это все в разной степени успешно. И, насколько я вижу, именно от успешности внедрения процессов выше во многом и зависит ответ: «а звать всех назад или нет?».
Если вас интересуют темы проектного управления, управления командами, и как эти знания структурировать и использовать – подписывайтесь на мой ТГ канал «Морковка спереди, морковка сзади», а также читайте мои статьи тут, на Хабре (их уже больше 20ти и все на тему управления ИТ командами).
Итак, кто что говорит на тему удаленки?
Компании говорят: падает производительность, сотрудники делают непойми что, а некоторые не делают вообще ничего. Сотрудники ворчат, что менеджерам стоило бы научиться ставить понятные задачи исполнителям, да и вообще: зачем тратить минимум 2 часа в день на дорогу?
Спор, что я вижу на текущий момент, не выглядит продуктивным, и убедительных аргументов я не видел ни от тех, ни от других. У меня есть моя собственная аргументация, основанная на опыте работы с удаленными командами с 2004 года: истина посередине, со смещением в сторону удаленки. Но для разных ролей подход видится разным, единого правила для всех тут не будет.
Если пробежаться по ролям в команде проекта/продукта, то картина выглядит так:
Вообще не надо в офис: разработчикам, тестировщикам и сотрудникам техподдержки всех уровней.
Разработчикам нужна нормальная постановка задачи, а шум и галдеж в офисе только отвлекают. Тестировщикам нужен план тестирования и объем, а техподдержке – доступ в ITSM. И всем нужен понятный и прозрачный процесс работы + 2-3 настроенных инструмента для работы в них. Если вы видите у себя на работе, что указанные роли работают из офиса или их зовут в офис, я бы сказал, что коллеги менеджеры или не могут нормально выстроить процессы, или тому есть Очень уважительная причина, о которой можно их напрямую спросить. Если вы знаете эту причину сейчас – напишите в комментарии, мне очень интересно будет узнать.В офис надо, но редко: аналитикам.
В тот момент, когда указанные граждане работают головой, их лучше не отвлекать. Писать хорошую постановку на разработку точно также требует спокойствия и тишины, как и сама разработка. Но аналитики работают не только с ТЗ и постановками, но и с людьми тоже. И вот тут важно помнить про эффективность каналов коммуникации (см статью про это Каналы коммуникации и встречи) – иногда нужно говорить очно. Поэтому аналитикам а) надо ездить к заказчику и б) быть в офисе для общения с менеджером. Тот, кто общается с заказчиком от имени компании, даже если это простой аналитик, должен хорошо понимать цели проекта и проблемы, которые надо решать. И вот тут важно иногда приезжать в офис, чтобы пообщаться с Руководителем проекта/продукта, чтобы сверить часы и обсудить насущное. Ну и, разумеется, надо иногда ездить на очные встречи к заказчику. Просто, чтобы держать нормальный человеческий контакт.-
В офис надо: Руководителям проектов.
Не каждый день, но надо, извините ребята )
Если про линейных менеджеров и продуктологов можно поспорить (первым незачем приезжать в офис, если вся команда на удаленке, вторые ближе к аналитикам, пусть сидят дома и ковыряют беклог), то РП – это работа с заказчиком. Заказчиков у РП два: его руководство и бизнес. И с теми, и с другими важна очень хорошая коммуникация. Формально РП может отчитываться по проектному плану, проводить 1:1 с начальником и так далее.Но на моем личном опыте, начинает очень незаметно падать вовлеченность РП в работу, а затем падает time-to-market. Нет, проект будет сделан в срок. Но лишнего, чтобы сделать его быстрее, скорее всего, сделано не будет, потому что под боком не будет пинателей.
Даже при качественно описанных процессах и контроле, у меня возникло ощущение замедления работ. Как будто менеджер, который работает на удаленке, дольше не просит о помощи, а я не вижу и не слышу, что она ему нужна. В итоге иногда выходит, что приходится реагировать на проблемы по факту вместо того, чтобы услышать о проблемах краем уха заранее, когда все сидят в офисе и болтают.
Потому для РП я бы ставил график офис/дом, как 3+2 или 2+3, по ситуации. Но никак не реже 2х раз в неделю в офисе. Еще раз, 100% фактурой подтвердить не готов, но вот такое вам мнение РПО. Ну и не забываем: лучший контакт, это личный контакт. Перестаете общаться лично – теряете его.
Итого:
разработчиков шлем на удаленку и контролируем по исполнению задач и списанию времени (да, я сторонник списаний);
аналитиков зовём в офис и к клиентам несколько раз в месяц, остальное время – из дома норм;
руководителей проектов ждем в офисе 2-3 раза в неделю.
разумеется, это все должно поддерживаться не просто "ух!" менеджментом, а прозрачными процессами, которые позволяют ставить четкие задачи на исполнение и контролировать их выполнение.
Если надо чаще – скорее всего, это решается не вызовом персонала в офис , а докручиванием процессов работы и инструментов. Если у вас реже и все летит с отличной маржой, эффективностью и так далее – отлично, делитесь опытом в комментариях.
Финально
Удаленка – это давний тренд, а ковид просто ускорил его. Удаленка несет много плюсов: она расширяет рынок труда работодателям (особенно сейчас, на фоне взрывного роста IT), она расширяет выбор для работников. Как любое новое, она же несет проблемы. Руководителю уже недостаточно просто выйти в оупенспейс и рынкуть на всех, приходится отстраивать процессы и внедрять инструменты, у сотрудников может падать лояльность к компаниям (как можно быть лояльным к людям, которых видишь раз в год на корпоративе?!).
В теории, в идеальной системе в вакууме, должно быть можно выстроить процессы так, что все заработает в онлайне полностью. А с другой стороны, наша работа – это все таки не алгоритмы, а люди. А человек не поддается автоматизации на 100%, и человеческое общение не заменить ничем. Так что какой-то процент общения останется всегда.
Но тренд неоспорим. Вместо того, чтобы с ним бороться, я предпочитаю его возглавлять.
Поэтому я и за процессы, и за развитие софтскиллов у РП. Ведь именно РП или техлид становится в онлайн командах ключевым связующим звеном и интегратором, тем, кто объединяет, выслушивает и ставит цели.
У кого будут эффективные процессы и РП, умеющие работать с людьми – тот и будет выигрывать. И выглядеть эта победа будет незаметно и рутинно: будет больше работы, больше заказов, больше треша под Новый год. Но будет и больше денег. А умная компания, в лице ее руководства, обычно умеет делиться с командой, которая помогает хорошо зарабатывать.
Так что желаю всем в 2025м не работать лишнего из офиса, но и держать баланс коммуникаций так, чтобы все, кто для вас важен, не забывали, как вы выглядите, особенно если вы - Руководитель :)
Комментарии (33)
vhlv
23.12.2024 05:13Непонятно желание бизнеса засадить в офис тех сотрудников, чья команда распределена по всей стране: один сотрудник - в одном филиале, второй - в другом. И так вся команда. Да, все сидят в офисе. Но по факту они как на удаленке, так как общаются-то они все так же в чатах и по видео. Живого общения, за которые многие ратуют, нет.
peterzh Автор
23.12.2024 05:13исключительно контроль. я бы даже сказал "мечты о контроле".
Я посажу сотрудника и посажу администратора, чтобы сотрудника пинал. Но по-моему, это неэффективно работает
Grikhan
23.12.2024 05:13Обобщение неверно в силу категоричности. Естественно, для интеллектуальной работы, требующей длительной концентрации, обязаловку "с 9 до 18" вообще уже странно обсуждать. Наилучший результат достигается при организации наилучших условий, для которых удаленка имеет существенные ограничения. Если вы не можете создать условия для разработки в офисе лучше, чем дома, то мои соболезнования вам и вашим заказчикам.
peterzh Автор
23.12.2024 05:13спорно также в силу категоричности. Давайте начнем сутра, когда сотрудник просыпается в своей ипотечной квартире где то в Саларьево, Кудрово (или подставить любой новый район города-миллионника РФ) и едет минимум час на работу (вечером обратно). вместо того чтобы поспать/позавтракать и даже погулять.
Это не заменить модным офисом никак вообще и это одна из самых важных причин.
Вторая - бедность :) вы говорите про соболезнования тем, кто не может обеспечить идеальные условия, но таких - 95% рынка, не поверите. Я работал в очень многих компаниях, в модных тоже. Набирают удаленщиков, потому что они дешевле. Даже сейчас сотрудник из Мск будет подороже, чем из условного Томска. Ну и как вы Томича привезете в Мск?
А вот если вы про то, что написанное мной не должно отменять наличия классного офиса, в который при желании можно приехать - вот тут согласен. Потому что далеко не все вообще любят работать из дома (к примеру, я сам).
cmyser
23.12.2024 05:13А списание времени, это как ? Это отличается от тайм трекера ?
Для меня звучит как , отработал часы, нажал кнопку или что то подобное
aleksandy
23.12.2024 05:13Списание времени - это когда вместо тайм трекера ты сам в конце рабочего дня/рабочей недели/etc. расписываешь как такую-то задачу делал X часов, а другую Y. И в итоге надо набрать пресловутые 40 часов в неделю.
JuliaEfimka
23.12.2024 05:13Мудрый подход без перекоса в ту или иную сторону, приятно почитать. По поводу присутствия в офисе добавлю, что если разрабатываемый продукт вполне себе физический (в моём случае машинка), то даже тестеру нужно иногда подъезжать в офис, чтобы посмотреть на прототипы. Но это наверно вот как раз ближе к аналитике, о чём и говорится, что аналитик должен бывать в офисе немного чаще.
А можете раскрыть концепцию "списания времени" для разработчиков, я такое впервые слышу, любопытно. Или может слышала, но под другим названием.
peterzh Автор
23.12.2024 05:13Как это в первый раз? Этому холивару уже 20 лет. Называется "разработчик это творец или исполнитель"? ))
Это просто план/факт по каждой задаче. Исполнитель дает оценку, обычно в трекере, затем в трекере же списывается. В итоге получаем статистику, насколько исполнитель попадает в свои же оценки. По сути, это ровно тоже самое, что требуется от самого РП, только спроецированное на исполнителей.
JuliaEfimka
23.12.2024 05:13Ну это типа стори-пойнты или футболки/майки? Такое видела, но не видела, чтобы собирали статистику по попаданию и списывали как-то это время. К тому же иногда задачу может оценивать и вся команда, и тимлид - в общем, не только разработчик сам для себя.
Спасибо, буду знать теперь)
botyaslonim
23.12.2024 05:13В Jira есть учёт времени по любой задаче, просто ставишь сколько времени ушло
peterzh Автор
23.12.2024 05:13ой, ну вы что :)
это классика списания которая была задолго до того как придумали этот покер с оценками. Как ниже написали, два параметра: time estimated; time spent - все тупо :)
JuliaEfimka
23.12.2024 05:13А, ну ясно, я не так давно в ИТ, поэтому не в курсе) Скорее даже в около-ИТ
wolodik
23.12.2024 05:13Как верно замечено, копий на эту тему сломано уже много, и до истины не добраться - везде есть свои нюансы и обстоятельства. Для меня краеугольными камнями являются условия работы и самодисциплина. Почему-то по-умолчанию считается что разработчики живут одни, вокруг не крутятся дети-жена-тёща, и в квартире есть хоть немного оборудованный рабочий уголок, а не табуретка в ванной с ноутом на коленях. Уж чего я не насмотрелся на ВКС в ковид, даже у людей на вполне серьёзных должностях - кроме оборудованного рабочего места, не говоря уж про отдельный кабинет. Также считается что разработчики нацелены на максимальную производительность и не подвержены соблазнам "холодильника или ютюба", не говоря уж про желание брать халтурку на стороне. И понятие "рабочая атмосфера" придумана не просто так, "эффект толпы" работает - когда вокруг люди заняты делом, меньше соблазнов отвлечься на нерабочие моменты, и задать короткий вопрос на рабочем месте или по дороге в столовую, который ты не будешь задавать в мессенджере - экономит часы рабочего времени.
Разработчики не шахтёры, где можно выработку считать в кубометрах - любые метрики адаптируются под методики их измерения. Причём ползучим образом - невозможно заметить, что то что в офисе делалось за полгода на удалёнке делается за 6.5 месяцев. А потом за семь. А через 5 лет за год. И каждый раз будут убедительные объяснения про усложнение ПО и новые фреймворки, когда руководитель будет искренне удивляться почему раньше трава была зеленее а проекты делались быстрее и качественнее.peterzh Автор
23.12.2024 05:13а вот тут спорить будем :) Я ж говорю, я с удаленщиками работаю давно и долго. Я готов сказать, что при должном контроле оценок (которые есессно все иногда завышают) и контроле списаний (когда можно иногда попросить рассказать что реально было сделано), производительность на удаленке не отличается. Более того, есть граждане, которые бакланить будут что дома, что на работе.
Для меня вот эта история про "я позову человека в офис, потому что он дома сосредоточится не может" - какая то безответственная. Мне пофигу откуда ты работаешь, но у меня есть задача, ты дал оценку, мы согласовали и ты должен попасть в срок. Та самая пацанская договоренность. Если ты не пацан - я поставлю над тобой пацана - лида. Чтобы пинал отвечал за тебя и учил. А если пацан, то я тебя и контролировать не буду - зачем?
У меня последние 5 лет была очень хорошая скорость time to market. Наверное быстрее, чем за весь прошлый опыт (оценочно, по жопомеру). И в офисе не было ни одного программиста. Вообще. Ну или приезжали просто потусить и пива попить. Но у нас реально были классные процессы, за исполнением которых следили.
botyaslonim
23.12.2024 05:13Присоединюсь тут. Последние 2,5 года работаю в одном полустартапе, вся команда разработки удалённая. И MVP запустили в рекордно короткие сроки, и потом много фич поставили. Вопрос постановки процессов, контроля, а также отбора сотрудников: безответственных балбесов, которым постоянно нужен надсмотрщик, просто не берём на работу. Лентяев выгоняем, были и такие случаи
babysas
23.12.2024 05:13поддержу. эффективность от людей и процессов, а не от места.
прячется сотрудник от детей/кошки дома или от любителей перекуров и потрындеть о вчерашней пьенке - нет разницы ;)
Разница лишь в том, кто обеспечивает рабочую атмосферу.
RigidStyle
Вот я всегда не понимал, какой больной придумал "опенспейс". Как посмотрю на некоторые офисы, где сидят разрабы рядами как на галерах, и чето там проектируют, так сразу задаюсь вопросом, как вообще можно в таких условиях что то делать.
И зачем людей тащат в эти офисы... Мне кажется что организованная удаленка (с тайм трекерами и прочим "онлайном") намного эффективней в итоге будет, чем офисы. Ну при условии, конечно, что у сотрудника не детский сад дома.
BlAnge
Вот насчёт тайм-трекеров - тема очень холиварная. Метрики конечно же считать нужно. Но считать это разумно, а не по "количеству кликов в минуту" (наслышан о таких). И если удалёнщик выполняет все нужные работы с нужным качеством, и за ним не нужно "заносить хвосты" - зачем ему тайм-трекер ? Чтобы недопустить превышения количества походов на кухню за кофе ? Чтобы регламентировать перерыв на "работу с гантелями" или "взять ноут и выехать поработать несколько часов в парке"? Так такие перерывы только прибавят производительности! Техника "помодоро" рулит. И интервалы у каждого свои.
Вообще я за мягкий гибрид. Что б чувствовалась вовлечённость в процесс каждого. Что б "лицо на том конце дейлика" было конкретным человеком. И в то же время чтобы можно было на месяц-другой свалить на удаленку в другую страну. //геополитические "особенности" тут не обсуждаем.
akod67
Time tracker - это инструмент для time material для аутсорсеров / аутстафферов в первую очередь. Делать ли из него инструмент контроля - это уже вторичный вопрос.
peterzh Автор
Давайте я отвечу, как сторонник учета времени.
Я, как менеджер, даю срок Заказчику внутреннему и внешнему. По этому сроку мне приходят деньги или мой VP и я получаем премию или нет.
Срок выше я даю на основании оценки исполнителя. С рисками, траливали и все все, но - на основании оценки разработчика. Он слово дает.
И если разработчик не держит слово, слово не держу я. Я лишаюсь премии, мой шеф ее лишается, а в худшем случае (у меня они были), компания не получает деньги на зп сотрудникам (в том числе ошибившемуся разработчику).
То есть все строится на договоренностях. И если проектная система - это мои договоренности с заказчиками, то трекер - это моя система договоренностей с исполнителями. Он нужен для фиксации договоренностей и отслеживания их исполнения.
anitspam
Доброго дня.
Вас не затруднит дать несколько комментариев про оценку времени исполнителем.
1. В год, например, вы запрашиваете оценку по условно 1000 задачам. Сколько из них реально попадают в первичную оценку?
2. Если по вашему опыту оценка некорректная, то тогда что? Договариваетесь с исполнителем снизить его оценку?
3. Почему вы сами не ставите время выполнения задачи?
Спасибо.
peterzh Автор
около 90%. Оценка варьируется от умения человека попадать в свои оценки, но в среднем за последние 5 лет так (мы внимательно считали). Любопытно, что есть люди, которые учатся попадать, а есть хронические оптимисты. 5 лет чувак работает а все равно всегда х2 к его оценкам приходится добавлять чисто статистически. Но там психологическое желание быть лучше, чем он есть, по моему мнению.
спрашиваю, почему она такая, прошу объяснить, так как не понимаю ее. Иногда снижаем, если оба согласны. Иногда я понимаю что не понимал и оставляю как есть или докидываю (заодно понимаю риски и что говорить заказчику)
потому же, почему я не берусь выполнять сроки, данные не мной: это не моя оценка и не мое слово. Я привык отвечать за свои слова, но за слова других отвечать - тема мутная.
akod67
А как вы поступаете с задачами, где реалистичную оценку дать затруднительно из-за характера самой задачи? (требуется RnD и т.п.)?
peterzh Автор
даем на то, что ясно. Если ничего не ясно - даем несколько дней, чтобы наметить план. Результат - сделать хоть ченить, затем обсудить, куда дальше.
Важно чтобы этот RnD шел контролируемо, а не в стиле "РП поставил задачу на исследование, сам забыл, а разраб ковырялся 2 месяца и выжрал бюджет". Ясно что это не проблема разраба, он молодец вообще то.
Но менеджеру башку оторвать за такое планирование :)
anitspam
К вопросу 3 ещё такое уточнение для обмена опытом.
Допустим, пришёл заказ на сайт. У вас есть дизайнер, который красиво нарисует, и разработчик, который подготовит страницы и опубликует их.
Также допустим, ваша команда уже делала подобные заказы и вы предполагаете, что через 3 недели покажете сайт заказчику и подпишите акт выполненных работ.
В этом случае вы будете ждать оценки времени от дизайнера и разработчика?
И не получится ли так, что пока вы будете ждать эти оценки, заказ уйдёт другой команде?
Если от вас как от руководителя не ждут таких оценок, то тоже ок, просто другой опыт по работе со временем.
(Вместо сайта, дизайнера и разработчика можно подставить другую область и исполнителей)
peterzh Автор
дааа, люблю такую историю.
Когда я был неопытный, я всегда шел спрашивать лида/архитектора или кого то, кто готов взять ответственность. Для джунов и миддлов, я считаю, это норм.
Для синьора нормально уметь прикинуть оценку самому (плюс-минус), так, чтобы потом разработка в эти деньги уложилась и еще осталось маржи. А если не рассчитал, он должен уметь обосновать заказчику увеличение. Я как то писал в статье про "допущения и ограничения" - вот тут оно очень помогает.
Если про меня - я уже лет 5 сам даю оценки, которые или не отличаются от оценок разработчиков или выше их только потому что я еще считаю риски, аанлитику, тестирование, запасы и тп. И в оценки попадаю. Но тут просто опыт и насмотренность. И да, там не про сайты, там про проекты больше 100 млн)
botyaslonim
О, узнаю себя! Это я такой хронический оптимист был. Пока работал программистом, всегда давал оценки, в которые чтобы вписаться, нужно было порваться на британский флаг. Зачем? - Не знаю, автоматически
botyaslonim
Сейчас подвожу итоги года в своей команде, из 700+ задач процентов 40 были выполнены быстрее первоначальной оценки, процентов 30 в оценке, 30 медленнее оценки
peterzh Автор
залез поглядеть. у нас 10-20% где то.
9oleynik
Гугл придумал посадить кучу разработчиков в как можно более тесные офисные помещения, чтобы происходило "творчество", об этом много где написано, в частности у Шмидта в "How Google Works". Возможно это и правда необходимо, если процесс находится в бесконечном R&D на пике научной мысли, но вот оттуда все начали эти практики применять, особо не анализируя необходимость.
peterzh Автор
Что хорошо для Гугля, то вредит промышленной разработке, где вместо НИОКРа надо просто прикрутить личный кабинет к биллингу и чтобы баланс отображался (например)))
и поскорее)) тут не творчество нужно, ясно дело...
budnikovsergey
про опенспейсы писал ещё Демарко, сильно задолго до Гугла. Но я заметил серьёзное отличие от западных опенспейсов и наших. Там обычно кубиклы с небольшим персональным пространством, а у нас локоть к локтю :(