Мало того, даже если разработчик работает день и ночь вкалывает не покладая рук, не видя что происходит руководитель начинает верить что разработчики не работают.
Если с плохо поставленными процессами как-то удавалось работать и двигать разработку в офисном пространстве, то при переходе на удаленный режим работы все начинает разваливаться. В некоторых компаниях наблюдается ситуация, когда людей просят выйти из карантина раньше положенного срока.
Изначально текст готовился для служебного пользования, но решил переформатировать в статью с обоснованием каждого пункта
Итак, поехали.
1. Железо. Гарнитура. Вебкамера. Доступный интернет.
У многих сотрудников дома может не быть компьютера. Это может показаться удивительным, но у многих разработчиков дома нет компьютеров. У многих нет гарнитуры. Совсем. Если попросить купить гарнитуру то возьмут самую дешевую для работы. Или будут общаться со встроенного в ноутбуке микрофона со всеми шумами вентилятора, плохой слышимостью и другими артефактами.
Необходимо убедиться, что у всех дома есть возможность работать из дома. Попросите подключить интернет. За счет компании предоставьте гарнитуру при необходимости. Закупите комплект гарнитур с хорошим микрофоном и наушниками и предоставьте возможность бесплатно получить гарнитуру для тех, у кого дома нет гарнитуры или гарнитура/микрофон плохого качества. Так же важно закупить вебкамеры (об этом ниже)
2. Корпоративный мессенджер с поддержкой аудио-видео связи.
В это трудно поверить (нет, не трудно), но даже сегодня огромное количество компаний без корпоративных мессенджеров. Особенно если компания до 200-300 человек. Работают командами в Telegram, WhatsApp, созваниются в Skype, Discord и т.д. и т.п. Кроме того, любой личный мессенджер плох тем что будет в обязательном порядке отвлекать часть сотрудников, так как у них не будет возможности «отключить» (отделить) личные сообщения и рабочие сообщения. Многим руководителям кажется, что это не является проблемой, тем более что другая часть сотрудников наоборот, считает, что это очень удобно, когда и личное и рабочее в одном мессенджере. Так же часто бывает, что часть сотрудников называет себя как хочет, кто латиницей, кто кирилицей, кто вообще никами. Также часть информации теряется совсем и т.д. и т.п. Очень частый аргумент менеджеров: «Мне удобно перекидывать задачу форваднув сообщение с заказчиком». Задачи все таки надо ставить через трекер, а не форвадом сообщений.
Необходимо внедрить ОДИН корпоративный мессенджер. Среди популярных решений Slack, Teams. ВСЕГДА найдутся недовольные новым мессенджером, надо внедрять в приказном порядке. Руководители обязаны первыми перейти на корпоративный мессенджер. Часто РП и тимлиды активнее всех саботируют переход на единый мессенджер под предлогом общения с заказчиками и т.п. По факту менеджеры могут общаться в двух мессенджерах, с заказчиком в отдельном, но внутри, все рабочие вопросы с сотрудниками должны обсуждаться в рабочем корпоративном мессенджере.
(Я предпочитаю Teams из-за концепции, Команд, которые группируют каналы по командам, но это кому что лучше подходит. Главное, чтобы во всей компании был ОДИН мессенджер. Кстати Teams объявили полгода бесплатного пользования в связи с короновирусом). Многие пытаются внедрять RocketChat и т.п. как бесплатную альтернативу Slack, Teams но если вы не наладите в нем качественную аудио-видео связь то нет никакого смысла внедрять подобные бесплатные инструменты, так как мессенджеры все равно будут плодиться для текста и для звонков.
Небольшие простые правила созвона:
1. При групповых звонках выключайте микрофоны, включайте только тогда, когда собираетесь говорить. Привыкайте к тому что, если задаете вопрос человеку, то ответ может прозвучать не сразу, а через 2-3 секунды, так как человек может сидеть с выключенным микрофоном и может потребовать немного времени включить микрофон и включится в разговор.
2. Любая встреча, любой созвон должен подкрепляться артефактом. Всегда. Письменно фиксируйте договоренности и кидайте в чат ссылку или текст. Это может быть Вики, Jira и т.д. В случае почты можно кратко отписаться «итоги отправлены почтой»
3. Договоритесь с домашними что вы на работе. Договоритесь о том, что на работе нельзя отвлекать и не может быть никаких «помоги на 5 минуточек», «подержи пожалуйста здесь», «вынеси пожалуйста мусор» и т.д. и т.п. Особенно актуально для тех, кто живет на дачах/в селах с родителями. Объясните, что работа может требовать сосредоточенности. (Я редко бываю у родителей, но когда езжу домой то о звонках по работе с компа можно забыть, так как племянники и родители могут лезть в экран с вопросами «а с кем ты это разговариваешь?» — приходится за 5 минут до звонка всех обходить и предупреждать что бы так не делали).
4. Уберите котиков из комнаты (Понимаю насколько трудно следовать этому совету, если я закрываю дверь, то кошка начинает истошно орать под дверью от одного факта что без нее может что-то интересное может происходить в комнате. Приходится запирать на кухне.)
3. Единый трекер. Единые правила работы с трекером. Прозрачная команда.
Часто в компаниях разводят зоопарк трекеров. Jira, Azure DevOps, Redmine, Trello и т.д. и т.п. Время списывается тоже абы как. Задачи могут планироваться с оценкой сразу на несколько дней. Возникает иллюзия планирования и из-за отсутствия прозрачности руководители не понимают прогресс по задачам, не доверяют разработчикам, а разработчики уверены, что менеджеры, мягко говоря, «нехорошие люди которые не разбираются ни в чем».
1. В компании в разработке должен использоваться единый трекер.
2. В компании рекомендуется использовать единый уровень структурирования задач. Задачи по проекту должны быть строго разделены по уровням. Нельзя что бы на канбан доске инженерные задачи были рядом с бизнес задачами. Пример «Добавить в корзину форму для ввода промокода» рядом с «Рефакторинг БД корзины».
3. Планирование итерации должно быть прозрачным. У РП должна быть возможность смотреть кто и насколько загружен. Но РП НЕ ДОЛЖЕН указывать
4. Максимальный размер декомпозиции технических задач не должен превышать 7 часов. Рекомендуется декомпозировать на задачи по 4 часа.
Обоснование этого пункта статьи тянет на одну большую отдельную статью. Если брать основное:
Пример:
(Рекомендация, у каждого могут быть свои случаи, главное, чтобы такая рекомендация на уровне компании была. Люди и беклог синтетические, созданы под статью, к сожалению фиктивный людей можно было заводить только как почтовые ящики)
Epic, Feature, User Story – резделение задач понятные на понятные бизнесу элементы, у каждого из этих уровней должна быть своя отдельная доска. Этот уровень прорабатывают и пишут ПМ, аналитики и т.д.
Task – инженерный уровень, у него тоже должна быть своя отдельная доска. Этот уровень декомпозируют (расписывают) строго только тимлиды и разработчики. Например, РП, при желании, может читать, но не может ставить задачи на этом уровне, так как потенциально он может даже не понимать зачем это нужно. РП может использовать этот уровень исключительно для того что бы понять насколько сильно загружена команда (об этом ниже).
Нельзя на одной доске размещать разные уровни. При этом все технические, не понятные бизнесу, задачи вроде «рефакторинг БД» «рефакторинг кода» и т.д. и т.п. должны быть привязаны к конкретным задачам бизнеса. Это позволит обосновать необходимость и своевременность проведения инженерных работ.
Планирование:
Предоставьте визуально наглядную информацию насколько люди загружены по проектам и почему физически нельзя брать больше задач на итерацию. Особенно это важно если у вас кроссфункциональная команда (команда узкоспециализированных специалистов), а не команда универсалов (команда фуллстек разработчиков).
Не надо путать планирование по людям с StoryPoint. StoryPoint можно использовать для того что бы высокоуровнего оценить задачи и распределить по итерациям, а внутри итерации можно сделать прозрачным для всех работу всей команды.
Для того что бы планирование по Ролям в кроссфункциональной команде работало, необходимо указывать людей и роли:
Так же эту визуализацию можно использовать для того что бы по мере «выжигания» спринта стало понятно, что взятый объем задач не успеем закрыть и почему:
Это позволит менеджеру видеть прозрачно и понятно, что происходит внутри команды и принять соответсвующие решения заранее (убрать задачу, или оставить задачу, а на ретроспективе заложить больше запаса времени на следующий спринт, запланировать найм еще бекенд разработчиков.
Крайне важно делить инженерные задачи на болки максимум в 4 часа. В особо крупных случаях можно 7-8 часов. Такая декомпозия решает ряд задач.
1. Убедиться, что техлид и разработчик одинаково понимают задачу и ничего не упустили/не забыли.
2. Повышение точности прогноза как Следствие 1-го пункта.
3. Менеджер может видеть прогресс по своим задачам ежедневно, вместо того что бы несколько дней не понимать, чем занимается разработчик. И делает работу по задаче прозрачной для менеджера, позволяет повысить доверие друг к другу между менеджерами и разработчиками.
Ты мне не доверяешь?
Очень часто разработчики или руководители не хотят обеспечивать необходимую прозрачность своей работы. На просьбу обеспечения прозрачности реагируют в духе «ты мне не доверяешь?» Мало того, многие руководители стараются максимально закрыть информацию между разработчиками якобы в целях безопасности. Видел команды где руководитель довел до состояния полного абсурда, когда бекенд и фронтенд были жестко разделены и они даже задачи друг друга не могли видеть, не говоря уже о коде. И это на голом REST API без Swagger и т.п. инструментов.
«Ты мне не доверяешь?» очень опасный аргумент. Доверие это, не инструмент и не цель. Доверие очень важно, но его надо заслужить. При этом «Доверие» самое по себе бесполезно в принципе. Но если вы понимаете работу друг друга, понимаете какая конечная цель и есть понимание кто что делает и можете синхронизироваться друг с другом и помогать друг другу, то получите доверие как побочный важный артефакт.
4. Стендапы (летучки). Общие рабочие часы. Рабочая форма одежды дома.
Многие люди, работая дома, расхолаживаются. В целом это нормально – это здоровая человеческая лень. Мало того, многие хорошие разработчики по своей природе ленивые. Мало того, именно здоровая лень позволила некоторым людям стать хорошими разработчиками. Проблема работы дома в том, что график может начать сбиваться. Можно поспать подольше под предлогом что сделаешь работу потом (какая разница, когда сделаю?). Но это работает только если не работаешь в команде. Но командная работа не похожа на перетаскивание песка – нельзя перетащить свой блок песка, когда захочется. Командная работа подразумевает сотрудничество. Если ты не делаешь свою часть работы, то можешь заблокировать работу других людей. (Лично я 1,5 года работал из дома один над одним проектом. Сначала было классно. Потом перестал замечать время, потом наступило это отвратительное ощущение что засыпаешь на работе, и просыпаешься на работе, через 1,5 года устроился в офис и получал огромное удовольствие от работы в офисе несмотря на то что путь в один конец занимал час поездки)
1. Необходимо ежедневно проводить утренние летучки. (Убедиться, что вся команда собралась и можно теперь рассчитывать друг на друга по необходимости).
2. Продолжительность летучки не может превышать 15 минут. Если столкнулись с какой-то проблемой, то не надо отвлекать всех. Надо зафиксировать проблему и после летучки обсуждать с конкретными заинтересованными участниками.
3. Необходимо выделить время для коммуникаций и время для тишины. (Например, с 12 до 16 запрещается звонить без острой необходимости, необходимо 4 часа в день дать разработчикам сосредоточиться для реализации сложных задач). Если задачи достаточно типовые и сложных задач мало, то можно ввести особый статус, в мессенджере, который означает что в определенный отрезок времени в сутках нельзя отвлекать, так как идет работа над особо сложными задачами.
4. (Рекомендация) В особо сложных случаях первое время можно ввести не только утренние, но и вечерние летучки для синхронизации друг с другом. Как правило утренние и вечерные летучки проводить бессмысленно. Но первое время для спокойствия можно вести, через месяц все равно возникнет желание отменить.
5. (Рекомендация) Надевать рабочую форму одежды ежедневно. При работе дома первое время легко отделить работу от личной жизни. Но постепенно граница размывается. Переодевание позволяет психологически дистанцироваться от «режима работы» и «режима отдыха».
6. (Рекомендация) Общаться с камерой. Если фон не очень хороший и не хочется показывать квартиру, то можно развернуть компьютер/камеру к стене (куда можно повесить плакат).
Общение с камерой решает две проблемы:
1. Психологическое — доверие. Каким бы социопатом и ненавистником не был человек, люди существа которым важно видеть лица других. Доверие друг к другу повышается психологически если люди видят лица друг друга. Трудно доверять человеку, лица которого не видишь. Доверие в команде играет важную роль.
2. Трудно удержать себя в тонусе. Иногда, когда тебя не видят трудно заставить себя переодеться, надеть рабочую форму одежды, а иногда даже элементарно привести себя в порядок. Когда перестаешь соблюдать самодисциплину наступает «размытие» работы и дома. Даже если видно только верхнюю часть туловища и на самом деле сидишь в рубашке/футболке без штанов, это все равно намного лучше, чем вообще никак не разделять режим работы и режим отдыха.
Понятно, что этот список не полный. Что эти пункты нужны не только для распределенной работы, но и для работы в офисе и что для полноценного здорового процесса разработки нужно намного больше пунктов расписать. Здесь постарался выделить самый минимум того, что мешает перейти на удаленный режим работы как руководителям, так и сотрудникам.
ссылка на оригинал статьи https://habr.com/ru/post/493638/
Добавить комментарий