Ремоут-советы от белорусских компаний. Делитесь своими

dev.by попросил белорусские ИТ-компании рассказать, с какими техническими, юридическими и организационными сложностями они столкнулись при переходе на удалённый режим работы — и дать рекомендации другим.

16 комментариев
Ремоут-советы от белорусских компаний. Делитесь своими

dev.by попросил белорусские ИТ-компании рассказать, с какими техническими, юридическими и организационными сложностями они столкнулись при переходе на удалённый режим работы — и дать рекомендации другим.

Увы, многие компании прислали в ответ пресс-релизы, которые показались редакции бесполезными. Вся надежда на комментаторов! Делитесь своими историями, опытом, конкретными советами под материалом или по адресу editor@dev.by. Мы выберем всё важное и составим подробную ремоут-инструкцию — возможно, она поможет компаниям, которые пока не входят в число этих 162-х

Melsoft

Андрей Ермоленко, Operations Director: 

Мы перешли на дистанционную работу 12 марта. Где-то в феврале поняли, что такая необходимость может возникнуть, поэтому в начале марта дважды провели «учебные» дни удалённой работы с некоторыми командами.

На что обратить внимание: 

  1. Готовность сетевой инфраструктуры: доступ к облачным хранилищам, максимальная нагрузка на VPN-шлюз, ширина канала от серверов компании в Интернет, настройки двухфакторной аутентификации. 
  2. Готовность и работоспособность сетевых лицензий и ПО. 
  3. Шифрование дисков: сотрудники забирают оборудование домой и возрастает риск утери устройств. 
  4. Корпоративный софт для видеоконференций больших команд (хорошо себя зарекомендовали Teams и Zoom). 
  5. На уровне бизнес-процессов продуктовым менеджерам нужно гораздо более дробно планировать задачи и посвящать больше внимания контролю выполнения работ. 
  6. Командам нужно задать ритмичный темп удалённых стендапов, и планировать апдейты с учётом возможной потери эффективности работы команды и удлинения сроков ревью со стороны платформ.
  7. На юридическом уровне наниматель должен издать приказ о переводе на дистанционную форму занятости и ознакомить с ним всех сотрудников под подпись. В идеале необходимо также подписать заявления об этом и допники к контрактам всех сотрудников. Эти документы должны отражать специфику удалённой работы и сдачи её результата.

Playtika

 В компании подготовили 7 рекомендаций:

  1. Заблаговременно провести тестирование режима работы из дома — поочередно разными командами.
  2. Поставить в известность всех вендоров заранее, чтобы исключить выставление необоснованных счетов.
  3. Продумать логистику работы служб, где бумажный документооборот необходим: бухгалтерия, кадры, т. д., получение и отправка корреспонденции.
  4. Продумать, как поступать с документами, имеющими очень личный статус (повестки в военкомат, справки о заработной плате, т. п.).
  5. Провести переговоры с арендодателем.
  6. Продумать, как можно помочь сотрудникам организовать работу из дома: недостающая мебель, wi-fi роутеры, т. д.
  7. Использовать этот период для проведения генеральной уборки офиса, наладки и сервиса всех систем и оборудования.

Анонимный HR

Техническая готовность:

  1. Всё должно быть доступно из-под VPN;
  2. VPN должен держать одновременное количество подключений, равное количеству сотрудников;
  3. Внешние шлюзы на офисный сервер должны держать скорость;
  4. Все инструкции, ссылки на VPN-клиент должны быть обновлены и актуальны;
  5. По возможности всех перевести на ноутбуки + периферия;
  6. Софт — слак, зум, дискорд — должны быть готовы к удаленке.

Юридическая:

  1. Приказ о переводе на удалёнку, положение об удалёнке, ознакомить и подписи собрать (здесь у каждой компании индивидуально, конечно).

Бизнесовая:

  1. Оцените падение продуктивности, скорости релизов;
  2. Маркетинг должен понимать, как откорректировать наливку трафа из-за изменения планов продуктов.

Хотите сообщить важную новость? Пишите в Телеграм-бот.

А также подписывайтесь на наш Телеграм-канал.

Горячие события

Gismart Online Meetup
9 декабря

Gismart Online Meetup

Минск

Обсуждение

1

Лайфхак на митинги
https://twitter.com/dz/status/1240344847292170240

Anonymous
Anonymous
4

1 По настоящему контролировать ремоут сотрудников нельзя. Никакие видеосвязи и треньканье времени не помогут. Т.к ловкие сотрудники все равно найдут способ их обойти, а вам надо все это отслеживать. Тут только остается перенести коммуникацию в письменную форму: почта, обсуждение в пул реквестах, коллабрация в гуглодоках, чатики. И меньше ориентироваться на человеко-часы.
2 В ишью трекере должен быть порядок. Отприоретизированный беклог, описание тасок, ссылки на гуглодоки, где можно провести какой-то мозговой штурм, etc.. Когда кто-то освободится он возьмёт таску и скажет об этом, задаст вопросы..
3 Асинхронная коммуникация - когда все распределены и удалены, то нужно по другому выстраивать патерны коммуникации. Нельзя ожидать что тебе ответят сразу же, как в офисе при личном общении. Т.е каждый может делать несколько тасок и уметь эффективно переключаться между ними. Думать наперёд, задавать вопросы сразу пачкой и предлагая решение, чтоб минимизировать количество неэффективной и медленной коммуникации. Люди должны понимать контекст, что и для чего делается в конечном итоге.
4 Боты в слаке для статус митингов: каждый описывает текущий статус каждый день. И не надо никого дергать по десять раз.
5 Стараться не дробить задачи слишком мелко. Организовывать их в пачки связанных друг с другом в противном случае. Тогда не будет проблем со слишком частым переключением контекста и оверкомуникацией в чатиках.
6 Самое главное - доверять людям и не микроменеджить. Т.к в случае удаленки от этого страдает производительность кардинально.

7 Иногда полезно устраивать сессии парного програмирования, для этого сейчас есть тулы и плагины к IDE. Очень помогает синхронизироваться с кем-то и не терять контакт.

8 Assertive behaviour. Не забывать, что работать удалённо будет сложнее, и стараться быть более вовлечённым и пытаться понять собеседника и помочь ему.

2

Что за сбор предрассудков некомпетентных от фаната "офисного сидения"!

"По настоящему контролировать ремоут сотрудников нельзя. Никакие видеосвязи и треньканье времени не помогут. Т.к ловкие сотрудники все равно найдут способ их обойти, а вам надо все это отслеживать." ---

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

"Тут только остается перенести коммуникацию в письменную форму: почта, обсуждение в пул реквестах, коллабрация в гуглодоках, чатики. И меньше ориентироваться на человеко-часы."
Перенести коммуникацию в письменную форму? а у вас в офисе ее небыло? все перекрикивались? Сурово ;)
Проблема эта в отсутствии БАЗОВЫХ компетентций менеджера ;))
Который САМОУСТРАНИЛСЯ от прямых обязанностей - а именно делать Эстимации, ставить дедлайны и определять промежуточные майлстоуны с анализами промежуточных результатов.
Прежде чем манагерить надо запастись не только подвязками, блатом, красивыми очами, а также гордым поротфолио с "отсиженными годочасами и сеньорностью" - а базовыми скиллами проектного управления.

"2 В ишью трекере должен быть порядок. Отприоретизированный беклог, описание тасок, ссылки на гуглодоки, где можно провести какой-то мозговой штурм, etc.. Когда кто-то освободится он возьмёт таску и скажет об этом, задаст вопросы.."
Он там должен быть всегда. кто сказал что отсутствие этого в ОФИСЕ допустимо?!

"3 Асинхронная коммуникация - когда все распределены и удалены, то нужно по другому выстраивать патерны коммуникации. Нельзя ожидать что тебе ответят сразу же, как в офисе при личном общении. Т.е каждый может делать несколько тасок и уметь эффективно переключаться между ними. Думать наперёд, задавать вопросы сразу пачкой и предлагая решение, чтоб минимизировать количество неэффективной и медленной коммуникации. Люди должны понимать контекст, что и для чего делается в конечном итоге."
Кто сказал что в ОФИСЕ этого не должно быть? )))))

4 Боты в слаке для статус митингов: каждый описывает текущий статус каждый день. И не надо никого дергать по десять раз.
См п 2,3.

5 Стараться не дробить задачи слишком мелко. Организовывать их в пачки связанных друг с другом в противном случае. Тогда не будет проблем со слишком частым переключением контекста и оверкомуникацией в чатиках.
--- это см отчасти п.1. учиться проектному менеджменту, Учиться и еще раз учиться. Дробить задачи сильно нужно для более точных эстимаций.
Чтобы небыло проблем с "переключением контекста" - задачи объединяются в "Пакеты задач". насчет того что такое всегда надо - см коммент к п. 2.3.

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

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

"8 Assertive behaviour. Не забывать, что работать удалённо будет сложнее, и стараться быть более вовлечённым и пытаться понять собеседника и помочь ему."
Тут есть одна фишка, опять же в п.1.
Грамотная постановка задач, эстимации, майлстоуны, обсуждения...
И будет людям счастье :)))

Anonymous
Anonymous
-3

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

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

-1

Заранее прошу простить меня за резкий тон - просто в офисе болел болезнями, было больно, поэтому зол слегка на апологетов "офисособирательства".

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

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

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

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

"И разработка подстаривается под хаотично меняющуюся картину мира и нет мейлстоунов на квартал вперёд."
см предыдущий пункт

Вообще я сторонник #noesitmates.
главное, чтобы потом вам за это заказчики не сказали #nomoney
как сертифицированный менеджер, не могу согласиться на своем проекте на политику #noestimates. Увы.

"Вот например: Тебе говорят, что пользователи жалуются что им тяжело что-то найти такие-то и такие-то вещи, вот детали. Ты подумал, ага надо добавить поиск, и тут возникают вопросы, как, что конкретно, где добавить, что они ищут. Но у тебя нет в команде аналитиков, продуктовиков и прочих, только такие же инди девелоперы как и ты - штуки 4. Каждый работает в такой же манере. И ты не можешь сидеть расписывать и детализировать, ты ещё сам не продумал и не посмотрел ничего - ни метрик, ни поговорил ни с кем. Тут ты сам решаешь что ты будешь делать и описываешь, потом шаришь со всеми. Конечно, когда задача выглядит, тут надо поднять эластик сёрч, такие-то и такие-то вещи надо искать, вот напилить тут форма, вот дизайнер все нарисовал - то ты берешь оцениваешь, а потом просто делаешь - но это не так интересно." -
В данной ситуации, горизонт планирование уменьшаем под темп поступления задач или запросов на изменения. (Кто такой инди девелопер не знаю, наверно индус. Слава богу, мы Беларусы.)
Любая "Новая форма" должна быть проанализрована на предмет соответствия ожиданиям заказчика, безопасной архитектуры, и главное то, как она будет вписана в общую концепцию проекта.
Поэтому те роли, которых у вас якобы нет - все равно должны быть как Accidental roles. Если работает один человек - значит он accidental role выполняет. Когда вы получаете задачу и начинаете анализировать ее функции для бизнеса - вы accidental business analyst, когда планируете, как встроете новый функционал в концепцию прилаги - вы accidental system architect, когда вы просчитываете эстимации, декомпозируя задачу, делая ИСР на данную итерацию - вы accidental manager, девелопите - девелопер. Я вот с работы ехал домой, какойто мужик ночью решил что я не имею права парковаться в его дворе, я не хотел быть accidental fighter, включил внутреннего accidental lawyer с целью разрулить в рамках правового поля.
Если у вас нет ДОЛЖНОСТЕЙ под какуюто роль, совсем не значит, что нужно не выполнять работу данной роли и не использовать методологии управления проектами.
Как тестер-безопасник, скажу, больше половины всех дыр, через которые можно очень круто положить систему могли бы никогда не увидеть мир, если бы команды разработки следовали здравым методологиям. Качество, как родина с картинки в букваре, начинается с правильных процессов.

В любом случае - если человек в офисе сидит, не факт что он эффективно работает. Решает все Хабстафф какойнибудь, да, он пишет, что на экране происходит. сначала не нравится людям "как так! надо мной контроль!" а на этапе сдачи проекта с почасовой оплатой очень помогает, как регик при ДТП.

У удаленки главный плюс, не болеешь заразой, которую привозят фанаты общественного транспорта. А здоровье дороже всего.

Спасибо за внимание
Всем добра и не болеть

1

Я везде обустраивал себе возможность "работы из дома" самостоятельно, не дожидаясь ничьего благословения. Ну и по возможности пользовался этим.

Естественно, никакой чернухи - типа пробоины в виде TeamViewer (хотя и он не плох), никакого нарушения правил.

Под правильной подготовкой понимается:
1.. Шифрование диска
2.. SSH ключи разделены "попроектно" (на случай, если что-то где-то как-то будет утеряно)
3.. Желязяки, софт, проектное окружение, лицензии на софт, опенсорсные версии софта - всё это всегда находится в "готовности к употреблению"
4.. Клиент и коллеги уже приучены к тому, что ты можешь поработать из дома
5.. Для тебя самого уже перестаёт быть шоком смена обстановки. К этому привыкаешь, распределяешь силы правильно, правильно коммуницируешь и разруливаешь потенциально стрёмные места. Типа, снижения доверия из-за уменьшившейся прозрачности -> добавляешь "прозрачности", показываешь что тебе нечего скрывать -> доверие возвращается на оптимальный уровень. Похожим образом поддерживаешь коммуникацию: начинаешь выпадать из "социальной памяти" коллектива, восполняешь это.

Это полезный опыт: с каждым разом ты делаешь это лучше и лучше. Все в плюсе.

-2

Шифрование диска
Ну все... Ваш драгоценный проект (который никому не нужен) под максимальной безопасностью!)
Не понимаю почему вы крипто ключ не используете. Как так?)

1

Ваши проекты никому не нужны? В этом нет моей вины

0

Иллюзия.. Вопрос про крипто ключ не раскрыт, вы даже тут халатны.)

13

1.. Провести инструктаж, рассказать сотрудникам как ходить в туалет по-большому менее чем за 5 минут;
2.. Установить на домашних компах timesummary;
3.. Установить возле рабочего места cctv камеру, а также систему голосового оповещения, чтобы сотрудника можно было срочно позвать к компу в любое время суток;

7

Также не стоит недооценивать эффективность анальных зондов

8

5.. Выбросить книжки, чтоб не было соблазна читать во время работы
6.. Спрятать чайник, чтоб не "пить часами чай"
7.. Не забываем, что «Результаты работы подтверждением не являются, так как не факт, что на их изготовление ушло задекларированное время»

Www Www
Www Www - в Будзьма!
11

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

0

Налево пойдешь — по голове получишь!
Направо пойдешь — по голове получишь!
Прямо пойдешь — по голове получишь!

И давай думай быстрее... а то по голове получишь!

2

Нужно ещё измерять показатели тела, если нет потливости, скачков давления и температуры. Значит недостаточно усердно работает гаденыш.)

0

Анальный зонд лучше других средств решает задачу измерения напряжения!

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже