Получите бесплатно — все материалы с наших курсов и тренингов
Тренинги, Курсы, Обучение — Agile, Scrum, OKR
Тренинги, Курсы, Обучение — Agile, Scrum, OKR
Тренинги, Курсы, Обучение — Agile, Scrum, OKR

Что такое Ground Rules, как они работают в IT и на тренингах, примеры Ground rules для удаленки

Обновление от 24 мая, 2023 г.
13 отзывов, в среднем 5 из 5

Как составить Ground rules для удаленной команды и что делать, если правила нарушают.

Что такое Ground Rules?

Основные или базовые правила. Это могут быть правила поведения на тренинге, проведения рабочих встреч в IT–команде, правила командной работы на удаленке.

Зачем IT-командам Ground Rules?

Для них это инструмент, который помогает устранить негативное поведение, мягко напомнить о взаимных ожиданиях.

Что делать с нарушителями Ground Rules?

Единичные промахи можно оставить без внимания. При повторении — повторно изложить основные правила. Если сотрудник команды нарушает правила несколько раз подряд, надо объявить перерыв в собрании (если это происходит прямо на встрече) и поговорить с нарушителем наедине.

Ground Rules

Ground rules  переводится как основные или базовые правила. Это могут быть правила поведения на тренинге, проведения рабочих встреч в IT–команде,  командной работы на удаленке.

Чаще всего про Ground rules  говорят именно в контексте тренингов и организации работы в IT–командах.

Ground rules на тренинге

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

Какие это могут быть Ground rules:

  • Не опаздывать
  • Отключить телефоны
  • Соблюдать конфиденциальность (что сказано на тренинге, то там и остается)
  • Говорить по одному
  • Давать всем обратную связь
  • Активно участвовать в работе.

Знакомо?

Эти правила пишут на листе, который потом приклеивают где–то в углу и все про него забывают. Вспомнят  только если кто–то начнет говорить по телефону во время тренинга. Тогда будет повод мягко пожурить: «Эй, помнишь, ты соглашался с этими правилами? Выключай телефон.»

Чтобы Ground rules  лучше работали, тренеры придумали размечать табличку по дням тренинга. В конце каждого просят участников пробежаться по списку. Обсуждают, какие правила соблюдались, а какие  — нет. Опоздания были? Галочка красная. Перебивали друг друга? Нет. Галочка зеленая.

Это работает как манипуляция: участники хотят, чтобы правила выполнялись, если из–за одного все получают «двойку» — это грустно. Поэтому все стараются не подводить остальных. И если кто вынужденно нарушает, то извиняется перед другими участниками.

Ground rules для удаленной команды

IT–команды, за редким исключением, не привыкли удаленно работать.  А раз уж нам всем суждено жить в эпоху вынужденного социального дистанцирования, то надо обсуждать, как дальше работать вместе.

Как часто устраивать онлайн–митинги? Кому в какое время удобно? Как сказать, если недоволен коллегой?  Как сообщать о срочных вопросах, которые требуют немедленного решения?  Как родители могут сказать команде, что  им нужно отлучиться, чтобы помочь своим детям?

Удаленные команды в Америке прописывают Ground rules, чтобы отвечать на такие вопросы. Это помогает им не скатиться в хаос.

Как разработать Ground rules  для удаленной команды:

  1. Рассказать, зачем это нужно, что будет, если правила не составить.
  2. Попросить каждого участника команды предложить 1-2 базовых правила. Важных для него.
  3. Обсудить правила участников. Принять только те, с которыми все согласны. Например, есть правило: отвечать на емэйлы в течение одного дня. Но разработчика письма отвлекают, ему проще выделить один день и разгрести всю почту за час. Правило не принимается.
  4. Принятые правила фиксируют и размещают виртуально во время встреч.
  5. Правила могут родиться на ретроспективе, когда уже выявили проблему, обсудили и придумали решение.

Ground rules команды воспринимают как  инструмент, который помогает устранить негативное поведение, мягко напомнить о взаимных ожиданиях.

Примеры Ground rules для IT-команд

Ground rules не должны быть карательными или ограничивающими. В идеале они должны отражать характер и стиль работы  команды.

Например, это могут быть такие правила:

  • Начинать и заканчивать собрания вовремя
  • Ограничить созвоны 45 минутами
  • Обсуждать проблему, а не цель
  • Не проводите совещания по пятницам после 12 дня
  • Предупредить руководителя за 48 часов до того, как планируете взять отгул
  • Избегать «волейбола» с электронной почтой: звонить если письмо трижды посылали туда–сюда без решения проблемы
  • Высказал жалобу — предлагай два решения.

Ground rules не являются незыблемыми. Их всегда можно изменить  или откорректировать

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

Если правила не работают или состав команды изменился, Ground rules следует пересмотреть и обновить. Но даже без этого командам хорошо бы один/два раза в год пересматривать правила, чтобы убедиться, что они по–прежнему им подходят.

А без правил нельзя?

Можно. Но если ничего не обсуждать заранее, есть риск, что вы столкнетесь с кучей препятствий в процессе работы. Вспыхивают мини–конфликты, которые надо разбирать каждый по отдельности. Без офиса это становится в сто раз сложнее, и тормозит работу.

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

Что делать если Ground rules нарушают

  1. Единичные промахи можно оставить без внимания.
  2. При повторении — повторно изложить основные правила.
  3. Если сотрудник команды нарушает правила несколько раз подряд, надо объявить перерыв в собрании (если это происходит прямо на встрече) и поговорить с нарушителем наедине.

Это происходит, пока вы позволяете

Собака не будет слушаться, пока вы позволяете ей это делать. Ребенок кусается, пока вы позволяете это.

Также и с работой в командах.

Компания Lucid Meetings разработала онлайн–платформу для управления совещаниями разработчиков. Однажды они задумались, как повысить вовлеченность во время командных собраний.  Спросили у зарегистрировавшихся людей, какую проблему они бы хотели решить.

  • Одни спросили, как справиться с человеком, который не перестает говорить и мешает остальным вставить слово.
  • Другие — спрашивали о том, как заставить людей приходить вовремя или вообще приходить.

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

В таких ситуациях выручают Ground rules. Они дают возможность всем управлять Иваном, включая его самого! Когда команда установит правило, что каждый участник встречи будет говорить кратко и по делу, то все смогут поддерживать друг друга в этом.

Ground rules дают инструмент, который все члены команды могут использовать.

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

Ground rules команды разработки (когда все плохо)

Тимлид на Habr поделился своим опытом по организации рабочего процесса в IT–команде. Краткое предисловие: европейский проект, коммуникации с заказчиком на английском, процессы в проекте не отлажены (дедлайны, переработки, непонятно, кто за что отвечает, заказчик негодуэ, в команде текучка).

Тимлид приходит в проект, по соглашению с СЕО берет на себя всю ответственность по нему.  Первым делом он установил такие  Ground rules в команде (сокращенно, полная версия на Хабре):

  • Все задачи создаем в Jira
  • Каждую задачу описываем детально
  • Все задачи маркируем: для бэкенда или для фронтенда
  • Выполненная задача сразу переводится в статус ревью кода (создаем пулл реквест на коллегу)
  • Исполнитель задачи, после выполнения, трекает свое время
  • Если на этапе тестирования заказчик находит баги, он возвращает задачу на доработку. Ей присваивается статус: «возвращена на доработку»
  • Разработчики тестируют свой код сами, в том числе как пользователь сайта. Не допускается слияние ветки с основной, если не известно, что код работает
  • Приоритеты всем задачам расставляет заказчик или тимлид
  • Каждый день в 12.00 проводим митинг между всеми членами команды
  • На митинге все рассказывают, что сделали вчера, что планируют сегодня
  • Каждый разработчик должен коммуницировать с заказчиком
  • Все диаграммы/блок–схемы/логику сохраняем в Конфлюенсе или Жире. Там же заказчик в комментариях подтверждает правильность реализации.