Сегодня, в связи в переходом большого количества организаций на частично или полностью удаленный режим работы я хочу обсудить конструктивный вопрос: как сделать свою работу дома максимально эффективной?
За более чем 15 лет опыта удаленной работы в MySQL консалтинге и около я опробовал различные методики работы которыми сейчас хочу поделиться.
Плавного всем перехода и рабочих побед! :)
(с) 2020 Владимир Федорков.
За более чем 15 лет опыта удаленной работы в MySQL консалтинге и около я опробовал различные методики работы которыми сейчас хочу поделиться.
- Четко отделите рабочее и нерабочее время. В противном случае Вы рискуете либо не включиться в полноценную работу, когда ваши мысли сосредоточены на деле, либо обнаружить себя живущим на работе, забывшим про личное время. Первое ударит по эффективности и вызовет вопросы руководства, второе может аукнуться выгоранием и довременными негативными последствиями.
- Определите и согласуйте с руководством часы, которые будете проводить в своем домашнем офисе. Сообщите о них коллегам. Выделите себе обеденный перерыв. Это даст время в середине дня для отдыха и даже, возможно, прогулки.
- Коммуницируйте с коллегами. Поприветствуйте их когда начинаете работать. В офисе видно кто за компьютером, кто пошел обедать, а кто отошел. Сеть непрозрачна. Когда отходите от компьютера в рабочее время, напишите в рабочий чат фразу «afk 10 минут», давая понять когда вы вернетесь и ответите на сообщения. AFK обозначает Away From Keyboard (не за клавиатурой). Такая привычка позволит избежать ситуаций когда коллеги ждут Вашего ответа неопределенное время.
- Настройтесь на работу. Продолжайте выполнять утреннюю рутину так, как будто собрались ехать в офис. Наденьте рабочую одежду. Это настроит Вас на рабочий лад и даст понять вашим близким, что с этого момента Вас не стоит беспокоить (спасибо за идею Tom Basil)
- Организуйте рабочее пространство. Уберите со стола все, что не относится к работе, сделайте удобное освещение, подумайте об эргономике. Возможно сейчас то самое время, что бы купить себе новое компьютерное кресло :)
- Для того, что бы сохранить свежесть делайте перерывы. Каждые 50 минут делайте перерыв 10 минут. Одна из самых больших проблем удаленной работы — прерывания и приоретизация. Выключите уведомления в неприоритетных чатах и поставьте уведомления на упоминание Вашего ника. Это позволит избежать траты времени на постоянное вычитывание чатов. Поставьте таймер на 15-20-30 минут и не отвлекайтесь ни на что кроме одного дела (прочитайте про технику Pomodoro)
- Когда заканчиваете рабочий день — снимите рабочую одежду, сходите в душ и возвращайтесь в домашний режим :)
Плавного всем перехода и рабочих побед! :)
(с) 2020 Владимир Федорков.
muhaa
astellar Автор
В каждой команде свой локальный чатик. Вот там.
Bedal
и для таких чатиков ничего лучше скайпа нет. Видео на всех, планирование звонков, опросы… в моём проекте часть народа в Пятигорске, часть в Смоленске, а часть вовсе в Томске, опыта набрались изрядно. (upd: забыл, ещё один из Сочи работает).
Замечу, что голосовой чат — почти обязателен, а видео — ещё лучше, если нужно создать именно коллектив, а не группу работающих по отдельности людей.
Дополню: лучше иметь отдельный аккаунт для работы, если скайп используется и для общения с друзьями-родственниками. При необходимости можно в параллель запустить десктопный скайп в одном аккаунте, а веб-скайп — в другом. Очень, кстати. удобно.
А про «поприветствуйте» — это, конечно, глупость.
astellar Автор
Чат это базовая коммуникация. С тем что видео нужно и важно я безусловно согласен, но его не должно быть много. Видеозвонок ест очень много времени. Если звонок на 6 человек идет 30 минут — тратится 3 часа времени команды. Если звонок идет 2 часа — потрачено будет уже 12 часов. Поэтому мой опыт говорит — установочный звонок один или два раза в неделю на 30-40 минут, остальное текстом.
Висеть на голосовых и видео звонках часами не эффективно. Такие звонки вырождаются либо в бесцельный треп либо команда сидит и ждет когда же это кончится
Bedal
Кстати, забыл добавить к достоинствам скайпа возможность показывать экран.
для группы — да.
если нужно в чём-то разобраться, даже на пару — лучше голос с показом экрана. Просто быстрее. Но результат обсуждения при этом, конечно, нужно текстово зафиксировать.
astellar Автор
«Много» это два и больше часов времени видео звонков в день для линейного сотрудника, если это конечно не оператор колл-центра. Если два человека сидят в офисе вместе больше двух часов, то они очевидно решают проблему. Если два человека сидят вместе по два часа в день каждый день за одним монитором, то очевидно с постановкой работы есть проблемы. Либо кому-то не хватило монитора!!!
Bedal
В моём проекте — программеры. Если мелкая, быстро решаемая автономными кодерами задача — чатиться практически не нужно. «Опись, протокол, сдал, принял»…
Но у нас задача инженерная, с приличным погружением в предметную область. И — долгая, нужен именно коллектив, где друг другу помогают, подпирают, можно сказать. В частности, ввод падавана и подтягивание до уровня — значительно упрощается при возможности личного общения. Иначе всё свалится на меня, как руководителя — а оно мне надо? :-)
Кстати, работа парой за одним компом — вполне себе технология, причём эффективная. Очень трудно организационно, правда.
Закончу тем, что с самого начала сказал: лучше всего для этих целей именно скайп. Всё остальное гораздо хуже.
muhaa
astellar Автор
Я очень долго работал именно в распределенных командах, там чатик это основа коммуникации. Возможно процесс нужно будет адаптировать для удаленки.
У каждого проекта должен быть лид и соответственно люди которые с этим лидом работают — вот уже виртуальная команда.
muhaa
astellar Автор
Не обязательно на полное время. Лично для меня работа с группой людей или удаленной командой начинается именно с приветствия. Поздоровался, сообщил о том, что буду делать, довел необходимую информацию и погнали.
Но в целом да, я работаю в составе фиксированной группы и коммуницирую с другими. Отсюда и такой взгляд.
JustDont
Бессмысленные текстовые сообщения гораздо хуже таковых вербальных (потому что их читать намного дольше). Приветы в текстовом чате — это вообще рак. Хуже общих приветов только личные, когда вместо сути дела кто-нибудь пишет в чат «привет!» и молчит. Такое вообще надо выводить на корню.
Если работа подразумевает необходимость вопросов в любой момент рабочего дня и ответов коллегам в течении какого-то ограниченного времени, то достаточно какого-то «рабочего» чата, присутствие в котором в нормальном статусе (не DND или Away) означает фактическое присутствие работника на рабочем месте и готовность реагировать.
Но, скажем, программистская деятельность подобного не требует, и более того, вопросы программистам в любой момент с ожиданием быстрого ответа — контрпродуктивны.
Любая периодическая деятельность (code review, совещания, итп) выносится в заранее запланированные временные слоты и совершается заранее предсказуемым образом без вообще какого-либо информационного шума в чатах.
astellar Автор
Текст читается гораздо быстрее чем отслушивается речь. Кроме того текст можно проглядеть по диагонали и решить тратить ли на него свое время или нет.
Если программист не способен быстро (в течении 5-ти минут) ответить на вопрос об ожидаемом поведении своего кода, встает вопрос о профессионализме такого «программиста»
Кроме того, случается необходимость в экстренных изменениях. Поменял — прогнали тесты — выкатили в прод. Утверждение «программистская деятельность подобного не требует» выглядит по меньшей мере странно.
JustDont
Объем текста — да. «Привет» — это не текст, это эквивалент красной лампочки индикатора непрочитанных сообщений, на присутствие которой нужно отвлечься, чтоб убедиться, что ничего важного не было пропущено. Вербальный «привет» легко отсекается на уровне восприятия как белый шум.
Если программисту нужно регулярно быстро отвечать на вопросы об ожидаемом поведении своего кода — встаёт огромный вопрос о профессионализме тимлида, техлида, и так далее по цепочке до CTO. Потому что когда программисту нужно регулярно отвечать на вопросы о своем коде — пишется документация и становится не нужно.
Если в команде вместо документации регулярно, обыденно, и в течении долгого времени испольуется приём «спроси того, кто это написал» — в такой команде тимлида (или кого-то выше, если этот подход был навязан с верхних уровней) нужно немедленно увольнять.
Экстренные события на то и экстренные, чтоб случаться как можно реже. И чатик для них никто не выключал.
astellar Автор
Мне кажется Вы теоритезируете.
1. Если для Вас любое новое сообщение в чатике — «эквивалент красной лампочки» и Вы опасаетесь пропустить что-то важное — работать Вам будет некогда. Чатик должен присылать уведомление о том, что Вас упомянули. Все остальное ждет.
2. Программисту нужно регулярно отвечать на вопросы. Регулярно это несколько раз в день. Происходит такое из-за общей сложности системы. Если Вы напрограммировали один скриптик на два экрана — документация ответит на все вопросы. Но в случае взаимодействия систем и их активного развития вопросы будут как к Вам так и у Вас. И документацией это не решается.
3. Вы точно теоретик. Потому что после второго вопроса человек сам пишет доку и третий вопрос уже отсылает к написанной доке. Документация это не абстракт который рождается по велению тимлида, и не стена охраняющая медитативный сон программиста. Это инструмент решения конкретных насущных вопросов. Если доку написать можно — она пишется. Если нельзя — ее не будет.
JustDont
Вы начинаете говорить взаимоисключающими параграфами. Если чатик никто не читает за пределами упоминаний — писать «привет» в него не имеет ни малейшего смысла.
Согласен, это для определенных случаев вполне нормальная оценка. Ненормальная часть в этом — требовать пятиминутной реакции. Если отложенная реакция в течении часа-двух вместо пяти минут тормозит работу — в вашей консерватории что-то сильно нужно править. Блокирующие работу других программистов вопросы не должны решаться через «спросить» — если завтра у вас программист сляжет с коронавирусом — у вас что, работа встанет, если вам надо будет его о чем-то спросить?
А если эти вопросы не блокирующие — а вы точно уверены, что если работник А будет отвлекать вопросами программиста Б и мешать ему писать код — то для конторы в целом это будет лучше? Мне б вашу уверенность.
Я как раз практик, в том числе и работы распределенной между командами по всему миру. А вы — видимо «практик от сохи», что-то делающий только потому, что это, вроде бы, как-то работает, и что-либо менять страшно.
Если вы разрабатываете что-то сложное, и не выделяете подсистемы и не документируете их внешние API (иногда даже до написания кода, потому что требования по взаимодействию подсистем часто можно проработать и без него) — то удачи это всё поддерживать через «спросить». Особенно когда половина это писавших у вас уволятся.
Документация — это в том числе и часть техзадания. И если вы техзадания где-то записываете, а не рассказываете в общем чатике (после ваших откровений я и не в такие ужасы поверю), то почему вы считаете, что документация должна записываться только тогда, когда программиста допекут??
tommyangelo27
Поддерживаю. Когда вижу в сообщениях «Good day» без конкретного вопроса — хочется в ответ написать что-то вроде: "@#!, ну пиши же, что у тебя случилось-то, нах@# мне твой привет."