Распределенная команда что это
Простая стратегия и полезный флуд. Шесть правил для распределённых команд от ФРИИ
Как сделать работу удалённой команды эффективной и не превратиться в руководителя-снежинку? Рассказывает Анна Антонова из ФРИИ.
Дима Руденок для Skillbox Media
Анна Антонова
Директор акселератора для ИТ-стартапов «Спринт» (в составе Фонда развития интернет-инициатив, ФРИИ).
Больше десяти лет работает в институтах поддержки предпринимательства, больше пяти — во ФРИИ, крупнейшем венчурном фонде России для ИТ-стартапов. Специализируется на управлении распределёнными командами.
Уже полтора года мы живём в «дистанционном» мире, где нельзя похлопать коллегу по плечу, чтобы что-то уточнить. Для кого-то переход в онлайн ничего не изменил — эти специалисты и до пандемии работали из дома, кафе или бунгало на Бали. Для других трансформация не прошла безболезненно.
Совмещение двух разных майндсетов — одна из самых сложных вещей, с которыми я столкнулась при запуске акселератора. Я сформулировала для себя шесть правил — они помогают создать надёжный каркас для распредёленной команды. Делюсь этими принципами с другими руководителями.
Простая стратегия: всего четыре вопроса
Когда мы запускали «Спринт», я потеряла много времени на поиск идеального формата стратегии. Мне казалось, что это должно быть что-то очень комплексное и хитрое. Однако всё оказалось проще.
Достаточно было задать себе четыре вопроса:
У вас получится простая таблица. В ней будут задачи с измеряемым результатом, сроки исполнения и ответственные. Этого достаточно.
С такой таблицей можно идти к команде и синхронизировать задачи, а дальше отслеживать их выполнение по реперным точкам. Плюс раз в год проводить общий сет с целями и рефлексией.
Отказ от микроменеджмента: берите только то, что можете унести
Руководителю нельзя превращаться в менеджера-снежинку, который замыкает на себе много процессов. Если это произойдёт, то по мере роста проекта и команды перегрев неизбежен.
Пропускная способность лидера падает, процессы начинают сыпаться, и страдает команда. Как выяснилось, менеджеры часто допускают такую ошибку. Это происходит в двух случаях: либо при переходе с одного уровня руководства на другой внутри компании, либо после бурного роста собственного стартапа. Менеджер или основатель по инерции продолжает затыкать все дыры.
Руководитель — не специалист, он не должен выполнять задачи своими руками. Задача руководителя — управлять ресурсом.
Мне с этой проблемой помогает справляться трекинг. Мне повезло, так как в команде акселератора есть сильные эксперты в этой области.
Трекер помогает замечать приступы микроменеджмента: когда такое происходит, я задаю себе вопрос «как это сделать иначе?» и постепенно разгружаюсь. Изучение своих ошибок — не самый приятный процесс, но он ведёт к росту.
Daily-синхронизация: флуд неизбежен
Удалённой команде необходима регулярная синхронизация. Мой любимый формат для этого — Daily Scrum. Это ежедневные пятнадцатиминутные встречи-стендапы с чёткими правилами.
На них все сотрудники коротко рассказывают, что сделали вчера, что планируют сделать сегодня и какие проблемы у них возникли. Это отличный инструмент для синхронизации команды и удобный способ контроля: вы видите всю команду и происходящие процессы.
По канону Daily должны длиться 15 минут. Однако у нас после перехода на удалёнку 15 минут превратились в 30. Когда люди долго друг друга не видят, на встречах начинается флуд, из-за чего всё затягивается. Сначала я хотела вернуть команду в тайминг, но потом бросила эти попытки. Похоже, на удалёнке флуд жизненно необходим: он заменяет кофе с коллегами в офисе.
Daily подходит только для малочисленных команд — не больше восьми человек. Иначе короткие встречи невозможны. Когда моя команда в акселераторе «Спринт» выросла до 70 человек, я стала проводить Daily только с руководителями. Они уже самостоятельно решают, как синхронизироваться со своими сотрудниками. Общая планёрка для всех у нас проходит только раз в неделю.
Планирование и отчёты: саморегуляция, а не контроль
Когда мы отстроили процессы в команде «Преакселератора», мы запустили эксперимент по подсчёту фактически затраченных на каждый проект часов. Мы делили все активности на категории и считали, сколько времени потратили на каждую в течение недели.
На первом этапе каждый в удобном ему формате фиксировал, что он делал в течение дня. Упражнение может показаться утомительным, но оно помогает обнаружить интересные причинно-следственные связи.
Проанализировав несколько недельных спринтов, мы нашли общие для всех сотрудников типы работ. Например: проект 1, проект 2, стратегия/планирование, коммуникация/команда, саморазвитие, пауза/простой.
В зависимости от количества отработанного времени за неделю каждый сотрудник относил себя к одной из пяти цветовых зон:
Потом появились серая и белая зоны: они показывают простой.
Такой инструмент помог сделать работу команды предсказуемой. Если я видела, что кто-то вторую неделю находится в красной или оранжевой зоне, я понимала, что нужно обратить внимание на этого сотрудника. Либо у него слишком много задач, либо сломаны процессы. Если человек долго находится в красной зоне, это опасно ошибками в работе.
Через три месяца после внедрения этого инструмента сотрудники научились прогнозировать нагрузку и самостоятельно её корректировать. При перегрузе у нас можно брать три дня мини-отпуска.
В результате мы с командой пишем план-факт каждый понедельник: фиксируем, что было сделано на прошлой неделе и что будет сделано на этой. Для меня это в первую очередь инструмент саморегуляции команды, а не только контроля.
Конструктивное общение: фокус на том, ради чего собрались
Первое правило конструктивной коммуникации — фокус на том, зачем «все мы здесь сегодня собрались». На любых планёрках, собраниях и в личном общении важно, чтобы сотрудники обсуждали то, что соответствует задачам и формату встречи. Особенно если команда большая и времени не хватает.
Неконструктивную коммуникацию легко определить по таймингу. Если сотрудник перескакивает с темы на тему, выносит на общее обсуждение то, что можно обсудить маленькой группой, и не «держит фокус», он редко укладывается в отведённое время. Чтобы избежать этого, нужно определить повестку встречи и модерировать выступления участников.
Письменная коммуникация также должна быть эффективной. В распределённой команде чаты играют огромную роль: они могут быть как эффективным инструментом взаимодействия, так и «чёрной дырой». Минимальные правила для работы в чатах: тегать пользователей, чьё внимание вы хотите привлечь, и использовать функцию «ответить».
Я подарила «Новые правила деловой переписки» Максима Ильяхова и Людмилы Сарычевой всем сотрудникам «Преакселератора». Я по-прежнему советую книгу тем, кто много общается письменно. Всё, что я могу сказать по этой теме, уже написано там.
Обязательные рефлексии: нельзя выяснять отношения
Проводить рефлексии полезно после завершения важных этапов. У нас это запуск отбора в акселератор, окончание формальной проверки, внутренняя экспертиза заявок. После всех важных точек нужно задержаться и обсудить, что прошло хорошо, а что нужно сделать лучше. Но, как я говорила, такое общение нужно модерировать.
Главное — не выяснять отношения. Ещё очень важно, чтобы организатор встречи был держателем процесса, ответственным за внедрение одобренных предложений. Если рефлексия не ведёт к качественным улучшениям, она перестаёт быть инструментом.
У работы онлайн есть минусы. Создать команду сложнее, а скорость выполнения некоторых задач снижается примерно на 30%. Однако дистанция — это свобода и своеобразный порядок, который мне нравится.
Проще контролировать тайминг встреч, ограничивать их продолжительность, оставаться в рамках деловых отношений, проще, в конце концов, работать как и где удобно, не спотыкаясь о формальности.
Главное — найти ту уникальную комбинацию правил, которая подойдёт вашей команде. Но не забывайте тестировать новые инструменты и проявлять к коллегам эмпатию.
Как работает ИТ на удаленке: советы по управлению распределенными командами
Считается, что ИТ-компании в России не пострадали от кризиса пандемии. Они одними из немногих смогли оперативно перенести свои бизнес-процессы «на дом». Как эффективно организовать удаленную работу с распределенными командами делится опытом Николай Сокорнов, директор департамента разработки ПО компании «Рексофт».
Сегодня в разработке программного обеспечения распределенная или гибридная команда – это норма. В «Рексофт» (да и любом другом разработчике) порядка 75% команд работают именно по такому принципу. У нас офисы расположены в пяти городах: Санкт-Петербурге, Воронеже, Ростове-на-Дону, Москве, Стокгольме. Также мы привлекаем отдельных разработчиков из других городов, например, Твери. Кроме того, к работе над проектами часто присоединяются из различных точек мира сотрудники заказчиков, курирующие задачи. У нас стандартная ситуация, когда руководитель проекта находится в Москве, а разработчики в Санкт-Петербурге и Воронеже. И даже если они находятся в офисах «Рексофт», по факту – это дистанционная работа.
Существует нехватка квалифицированных кадров. Компаниям, занимающимся разработкой, это проблема не оставляет выбора. Главное, чтобы были хорошие специалисты, а где они находятся — уже вторичный вопрос. Обратного пути нет. В ближайшем будущем все команды будут распределенными.
Основной принцип в управлении распределенными или гибридными командами состоит в том, что процесс построен так, как будто вся команда работает удаленно. Не надо принимать во внимание, что кто-то из коллег сидит рядом в офисе. Руководитель должен воспринимать всех участников процесса как членов распределенной команды. Для всех участников проекта должны быть введены единые объективные критерии работы.
Что я имею ввиду. У руководителя всегда есть соблазн кого-то посадить рядом с собой, чтобы постоянно контролировать, или поручить наиболее важные задачи сотрудникам рядом, чтобы всегда иметь возможность лично обсудить ситуацию на проекте, а, например, задачи по выявлению проблем в коде отдать удаленным коллегам. Такой подход ведет к развалу команды.
Кроме того, одно из главных искушений для тех, кто работает в офисе – это собраться за кофе и быстро что-то обсудить. Естественно, те, кто работает удаленно, из этого обсуждения выпадают. Поэтому работа в гибридной команде требует более четкого соблюдения всех процедур, документирования всех этапов и решений в системах и почте. Это позволяет удаленным участникам команды не чувствовать информационный голод.
Еще один важный элемент для создания эффективной распределенной команды – это регулярные личные встречи всего коллектива. На мой взгляд, такие очные совещания правильнее делать раз в месяц, но не реже раза в квартал. Это позволяет не только усилить командный дух, но и сглаживает разницу в общении с удалёнными сотрудниками, понять, чем сотрудник дышит, как он чувствует себя в проекте.
Особенность удаленной коммуникации состоит в «срезании» каналов передачи информации. На расстоянии, как правило, мы общаемся письменно или голосом. Уходит язык жестов, эмоций. Хороший руководитель не только слушает сотрудника или читает его отчеты, а пытается понять настрой и мотивацию сотрудника, уловить скрытые проблемы, которые не всегда коллеги готовы обсуждать в открытую. Выяснить такие вещи при личной встрече намного проще. Да, и сотрудник в личной беседе скорее обозначит волнующий его вопрос.
Сегодня все используемые в совместной разработке инструменты и платформы имеют дистанционный доступ через интернет, поэтому рабочая среда практически никак не меняется от того, где находится разработчик в офисе или на удаленке.
Исключением являются проекты, когда необходимо написать приложение для какого-то конкретного оборудования или аппаратуры заказчика. Например, «Рексофт» делал подобный проект для «Роскосмоса». Такой стенд возможно организовать только в офисе, и часть команды должна присутствовать на рабочем месте. Примерно та же ситуация с тестировщиками, работающими с огромным количеством устройств. Компания просто не в состоянии обеспечить такой набор техники для каждого сотрудника.
Управление распределенной командой в режиме многопроектности (обзор и видео доклада)
23-24 сентября в Санкт-Петербурге проходила конференция Saint TeamLead Conf 2019. «Флант» принял в ней активное участие: Игорь Цупко (наш директор по неизвестному) провел митап, на котором участники разобрались в способах поиска и выявления тайных знаний внутри организации, а Сергей Гончарук (менеджер проектов) выступил с докладом «Управление распределенной командой в режиме многопроектности». По традиции, мы публикуем обзор доклада и его видео (
«Распределенная команда» и «многопроектность»
Под распределенной командой разные компании понимают очень разные вещи — например, филиальную сеть или офис и удаленных работников… Но в нашем случае офиса в его «настоящем» понимании вообще нет.
Сейчас у нас работает более 80 сотрудников, которые живут в более чем 20 городах России и не только. Большинство из нас видит друг друга «в живую» только 2 дня в году, на дне рождения «Фланта».
В остальное время мы живем в Москве, Самаре, Тюмени, Нижнем Новгороде или любом другом городе, работаем под пение птиц или запах кофе. Вместо аренды места, инвестируем деньги во что-то действительно полезное. И так как все работают удаленно, у нас нет деления на «филиалы» или «касты».
А главное — мы нанимаем лучших, несмотря ни на какие границы! Вот что значит «распределенность» в нашем понимании.
Давайте теперь разберемся с многопроектностью, но для начала важно немного погрузиться в устройство «Фланта».
Мы инженерная компания, у нас много инженеров. Пять-семь инженеров под управлением тимлида и менеджера составляют команду. Таких команд несколько, и у каждой команды есть свой набор из проектов.
Проект для нас — это инфраструктура клиента для одного продукта либо одной команды разработки. То есть у проекта есть четкие границы, но нет ограничений по росту и развитию!
У каждого проекта есть свои потребности, которые нужно как-то донести до команды
Это делает менеджер. Таковы основы «многопроектности».
Теперь, когда у нас есть общее понимание терминов из названия доклада, вопрос: что нужно, чтобы в таких условиях всё не просто работало, а работало хорошо?
За решение этого вопроса отвечает менеджер команды. Быть «переводчиком» с клиентского на инженерный — это одна из его ключевых компетенций. Вторая — организация конструктивного общения внутри команды и с клиентами. А третья базовая компетенция — нахождение баланса между потоком дел и реальными возможностями инженеров:
Разберем подробнее каждую компетенцию.
1. Трансляция ожиданий
Даже у одного и того же клиента могут быть противоречивые ожидания. Например, бизнес клиента требует, чтобы приносящий деньги production был стабилен. И к тому же, постоянно пополнялся новыми функциями, которые помогают увеличить выручку.
Ну, а если уж и случится какая-то авария (бизнес готов к тому, что аварии бывают), то она будет устранена в максимально короткий срок. Звучит очень предсказуемо, не так ли?
Но у этого же клиента есть и разработчики. И их ожидания, оказывается, совсем иные! Для разработчиков dev важнее production’а (ведь на них тоже давит бизнес), а еще они ждут, что любая их просьба будет услышана и сделана прямо сейчас (обычно это описывается фразой «ведь там дел на 5 минут»).
Единственное, что объединяет и бизнес и разработчиков в требованиях, — и те, и другие ожидают, что плановые задачи будут сделаны точно и в обещанные сроки.
Посмотрим на картину в целом… Да тут же полно взаимоисключающих параграфов!
И мы понимаем, что сами требования противоречивы, а значит — напрямую транслировать их невозможно.
2. Коммуникации
В трансляции ожиданий действительно есть проблемы. Хорошо, может быть, тогда хотя бы с коммуникациями все проще?
Для общения между собой и с клиентами мы используем Slack для текста и Google Meet для митингов и случаев, когда сказать проще, чем написать. Но в чате мы часто получаем сообщения, которые не несут в себе полезного смысла или содержат столько ошибок, что смысл распознать сложно!
Почему мы обращаем на это внимание? Дело в том, что, например, только за июль 2019 года мы получили 1993 обращения от клиентов в Slack, требующих обязательной реакции. И, естественно, с ростом количества клиентов есть и устойчивый тренд по росту количества таких обращений. Около 165 инженеро-часов мы потратили в июле на реакцию на такие обращения. А ведь по каждому обращению требовалось еще и что-то сделать!
Нам очень жаль, когда время инженеров, которое могло бы быть инвестировано в плановые задачи, реакцию на другие обращения или даже на починку аварий, тратится впустую.
Проблема в чатах очевидна, но у видеоконференций наверняка нет проблем?
Мы говорили выше, что используем Google Meet для ежедневных командных митингов, а остальное время делаем задачи, которые разобрали на митинге. Каждый день мы тратим на митинги порядка часа. Мы стараемся тратить на непосредственную работу не менее семи часов в день, то есть на выполнение задач остается 6 часов. Но у нас очень разные по длительности задачи.
Вот и получается, что за час митинга мы могли бы завершить несколько небольших, но, вероятно, важных для наших клиентов задач. И нам надо понять, действительно ли нужны часовые митинги или все же лучше пойти и поработать это время?
Если попробовать собрать проблемы коммуникаций вместе, получаем, что чат генерирует бесполезные прерывания и регулярные митинги «отъедают» рабочее время.
Эффективные коммуникации не выстраиваются сами по себе.
3. Планирование
Что ж, нам надо решать проблемы в коммуникациях и трансляции ожиданий, но в планировании, наверное, нет никаких подводных камней? Давайте разберемся.
Каждый день создается большое количество новых задач. Хотелось бы, чтобы мы закрывали задачи так же быстро, как они растут. Но в жизни идеал редко бывает достижим. Во-первых, в инфраструктуре иногда что-нибудь да ломается. Во-вторых, всегда есть какие-то мелкие дела, которые проще сделать сразу. В-третьих, есть задачи, о решении которых мы договорились на командном митинге:
А иногда случается так, что из-за аварий и дерганий по мелочам до плановых вообще не удается добраться! При этом новые задачи не перестают прибывать — все обещанные сроки срываются.
Наш рецепт
Но на все проблемы с трансляцией ожиданий, с коммуникациями и планированием, методом набивания шишек удалось получить, как нам кажется, правильный ответ.
Одним из ключевых бизнес-процессов, затрагивающих все три базовые компетенции, является командный митинг. И у нас появилось предположение, что если сделать командный митинг эффективным мы сможем достигнуть 80% результата двадцатью процентами усилий? Мы проверили эту теорию.
Как вы помните, у нас есть команда, обслуживающая свой набор проектов. И у нее есть некий перечень требований от этих проектов. Но каждое требование, как правило, лишь одно в цепочке взаимосвязанных задач. И так в каждом проекте! И прежде, чем взять в работу новую задачу, нам надо понимать, сделали ли мы предыдущий этап?
Вчера задачу А-1 выполнял Егор, задачу Б-1 — Семен, а задачу В-1 — Жанна. Но как нам погрузить всех инженеров во все проекты настолько глубоко, чтобы Егору удалось успешно справиться с задачей Б, а Семёну — с двумя небольшими задачами А и В. «Зачем все эти сложности?» — спросите вы. Да дело в том, что Жанна сегодня в отпуске и плановых задач выполнять не будет!
В нашем фокусе внимания много подобных задач. В среднем в каждую команду мы получаем около 25 новых задач каждый рабочий день. И так как задач много, связи между ними запутаны и нет понимания, выполнены ли все задачи предыдущего дня. Для того, чтобы распутывать все это, нужен командный митинг, причем каждый рабочий день, иначе мы не сможем управлять этим потоком.
Учитывая объемы потока, к митингу стоит заранее подготовиться. Мы на подготовке без инженеров не сможем понять, какие именно задачи сделаны полностью, а какие — нет. И, конечно, не сможем передать знания от инженера к инженеру. Но нам однозначно по силам определить приоритеты взятия новых задач в работу.
Приоритезация задач
На чем мы основываемся при приоритезации задач? Во-первых, у нас есть стратегические договоренности с клиентом о целях, которые нужно достичь. Во-вторых, раз в неделю мы уточняем тактические планы на online-встрече с заказчиком. Потребности клиента при подготовке как раз отстаивает менеджер, а техническую необходимость и порядок выполнения той или иной задачи — тимлид команды. Именно так, на основании паритета мнений тимлида и менеджера, формируется список задач на день.
Культура проведения командных митингов
Как только список задач на день определили, чтобы уточнить, что сделано, и погрузить в подробности коллег, начинаем командный митинг, на котором каждый инженер должен подробно рассказать, что он сделал вчера, а вся команда — услышать и, главное, понять произошедшие изменения. Но это проще сказать, чем сделать.
Мы ввели ряд культурных особенностей проведения митинга, которые позволили достигнуть требуемого результата:
В начале митинга, пока все собираются, мы тратим 10-15 минут на разговоры о жизни. О новостях и событиях, не связанных с работой, об увлечениях коллег. Так инженеры, которые находятся в разных городах и почти не видятся, становятся приятелями или даже друзьями. И эти 10-15 минут в день помогают команде быть более сплоченной.
После тимбилдинг-беседы приступаем к содержательной части. Вернемся немного назад.
Помните вот эту иллюстрацию? Дело в том, что ни Семен, ни Егор до начала митинга не знают, какие задачи и в каких проектах они будут выполнять сегодня. По целому ряду причин: отпуска, командировки, болезнь, дежурства и т.п. — задача может менять исполнителей изо дня в день, пока не будет полностью решена. И каждый инженер понимает, что сегодня задача может быть назначена и на него, то есть все инженеры уже изначально заинтересованы вникнуть в подробности каждой задачи.
Мы разбираем на митинге всей командой возникшие блокировки. Мы настаиваем, чтобы в решении проблемы докладчика приняла участие вся команда. Так мы мотивируем погружаться в задачи и решать их вместе.
Если команда работает в офисе, неформальное общение часто происходит «у кулера». Но и в распределенной команде потребность в таком общении существует. Именно поэтому во время обсуждения задач разговор зачастую утекает куда-то не туда. Но мы пресекаем любые отвлечения. Как именно? Нам это удается довольно легко: ведь для отвлеченных разговоров есть специально выделенное время, а сейчас — время работы. Поэтому даже обычного устного «давайте по делу» хватает, чтобы все вернулись к деловой повестке. Пресекая отвлечения в процессе разбора задач, мы настраиваем команду на рабочий лад.
Мы стараемся контролировать время доклада каждого инженера. Порой для погружения в детали нам нужен длинный и подробный рассказ о задаче. Тем не менее, в большинстве случаев, мы стараемся не растянуть митинг.
Эффективные митинги — серебряная пуля?
Благодаря подготовке к митингу на основе паритета мнений тимлида и менеджера и нашим культурным особенностям проведения митинга мы действительно сделали их эффективными. Но получилось ли закрыть 80% по всем компетенциям? Не совсем.
Мы хорошо поработали с трансляцией ожиданий, но в коммуникациях все еще проблемы с неинформативными сообщениями в чатах, а в планировании остались прерывания, которые не дают эффективно делать плановые задачи.
Да, но ведь и неинформативные сообщения в чате — тоже прерывания. И нам необходимо найти механизм, который поможет нам эффективно обрабатывать прерывания всех видов.
Борьба с прерываниями
Мы подумали, а что, если у нас будет отдельный человек, который будет «закрывать» собой команду, работающую над плановыми заданиями от потока прерываний?
Идея не новая и в общем хорошая, но кто именно будет это делать? Мы рассматривали два варианта: поиск и найм такой службы или использование уже имеющихся инженеров. Поиск новых людей требовал времени и финансовых ресурсов, а существующие инженеры уже были «проверены в бою» и погружены во все проекты команды. Поэтому вариант с наймом новых людей был отвергнут.
Осталось определиться с вопросом, как организовать такую службу из текущих инженеров. Тут решение было на поверхности: просто применили дежурства по графику, с ротацией инженеров из команды. Само расписание дежурств мы ведем в Google Calendar, плюс настроили уведомления в Slack о том, кто дежурит сегодня.
Казалось бы, все теперь должно быть отлично? Ура? Нет, на самом деле осталась проблема. Помните, чуть раньше мы говорили, что только в Slack получаем почти 2000 обращений в месяц, а это около 16 обращений в день в каждую команду. Но кроме Slack дежурный должен будет обработать сообщения и от систем мониторинга, а в день это:
Чтобы без волшебства и суперспособностей с этим справился любой инженер из команды, мы собрали алерты от всех источников прерываний в одном месте. Этот инструмент мы назвали Madison, а каждое сообщение в него — Инцидентом.
Но Madison лишь собирает инциденты и хранит состояние о них. Нам же нужно понимать, какой инцидент брать в работу первым, то есть произвести триаж, иметь четкий порядок обработки и эскалации, чтобы легко выполнить его в стрессовой ситуации.
Мы создали и такой инструмент — назвали его Polk:
Polk — это рабочее место дежурного инженера. Он позволяет дежурному фокусироваться только на инцидентах, не отвлекаясь на плановые задачи, получать инциденты из всех источников в одном месте, помогает с определением критичности инцидента по заранее определенному Severity, имеет набор четко описанных статусов и алгоритм обработки, определяющий движение по этим статусам.
Технические и культурные особенности общения в чатах
Отлично: теперь дежурный, снабженный таким мощным инструментом, действительно закрывает команду от прерываний. Но даже с таким инструментарием дежурство выматывает, а бесполезные прерывания только подливают масло в огонь.
Для борьбы с бесполезными прерываниями в чате мы можем применить небольшой набор технических средств, но основное решение этой проблемы точно лежит в культурной плоскости.
В частности, мы акцентируем внимание на том, что обращение к @flant для нас, в первую очередь, это действие с обязательной реакцией, а @channel и @here для большей части команды — просто прерывание, которое к тому же безадресно и может быть проигнорировано, отвлекая при этом всю команду от решения плановых задач, в том числе по данному проекту.
Но в чат приходят новые коллеги со стороны клиентов, которые не знают о боте. Другие просто забывают. Если так происходит, мы мягко напоминаем о его существовании.
Для общения же между инженерами мы используем те же правила для @channel
и @here : не использовать их без крайней необходимости. И еще, мы настаиваем на придерживании правила «Не говори просто „привет“ в чате — сразу сформулируй мысль». Это правило обязательно к прочтению всеми новичками. Тем, кто его забыл, об этом обязательно напомнят — если потребуется, развернуто.
Итого: с введением дежурств и исправлением проблем общения в чате мы справились и с большей частью бесполезных прерываний и с влиянием прерываний на выполнение плановых задач.
Прокрастинация и блокировки
Мы проверили, как улучшились наши показатели после этого: действительно, они стали явно лучше, но все еще осталась проблема в планировании.
Когда командный митинг закончился, приходит время поработать. Но зачастую инженеры, особенно работающие удаленно, склонны прокрастинировать. Или, во время работы, упереться в проблему и ходить по кругу в попытке ее решить.
Давайте попробуем разобраться с прокрастинацией. Как ее побороть? Задач в Redmine (нашем трекере задач) слишком много — нужен фокус на тех, что будут в работе именно сегодня. И даже среди них нужно понять, какие задачи сделать в первую очередь, то есть — определить приоритеты. И идеально, если примерно запланировать время, которое мы готовы потратить на каждую задачу…
Мы создали инструмент, который помогает все это решить, и назвали его Ford:
Именно в нем инженер получает задание на рабочий день в виде карточек, расположенных в приоритетном порядке. У всех плановых задач мы проставляем примерное время, которого инженер должен придерживаться при их решении. Инженер учитывает время, которое он потратил на решение задачи. И если время примерно совпало, а задача не решена — это маркер того, что инженер зашел в тупик.
Что с этим можно сделать? Кроме приоритета, в котором расположены карточки,
мы ввели еще и категории приоритетов, выделили их цветами:
Но очевидно, что если инженер заблокировался по задачам в желтой или красной зонах, то ждать следующей встречи не стоит: нужно звать на помощь команду в соответствующем канале для общения инженеров по проекту, в котором поставлена задача. И, в соответствии с нашей культурой, инженеры команды или тимлид обязательно придут на помощь.
Стоит оговориться, что возможности Ford значительно шире и мы затронули только «верхушку айсберга», которую вы можете реализовать с помощью других, открытых инструментов.
Итоги
Получается, что для борьбы с прокрастинацией и блокировками мы используем Ford как техническое решение и простые правила в командной культуре.
Помогли ли нам эти инструменты? Да! Но почему-то не на 100%?
Дело в том, что мир меняется и движется вперед. И мы в этих условиях тоже меняемся, стремимся к идеалу, но он, как известно, недостижим.
О достижении идеалов и роли менеджера
Всё великое, что создано человечеством за все время его существования, сделали команды профессионалов, у которых были крутые менеджеры.
Мы, «Флант», тоже команда профессионалов. И было бы классно, если бы крутых менеджеров в нашей команде стало больше. Приходите к нам работать и помогать делать наши процессы лучше: