|
Рубрика:
Карьера/Образование /
Управление командой
|
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|
Руслан Бородин,
инженер-тестировщик, Bell Integrator
Практики взаимодействия:
как специалистам по обеспечению качества
не утонуть в коммуникациях
В крупных распределённых организациях слабым звеном становится не столько решение технических задач, сколько коммуникации между специалистами.
Инструменты разработки постоянно эволюционируют. Современные код-ассистенты ускоряют написание автотестов и утилит, однако этот выигрыш часто нивелируется временем ожидания: погружением в контекст, запросами смежникам и уточнением требований.
Знакома ситуация, когда написанию небольшого куска кода предшествуют долгие переговоры и согласования? Ключевая проблема кроется не в объёме коммуникаций, а в непредсказуемости времени ответа. Обратная связь может прийти как через 10 минут, так и через полдня, что часто приводит к срыву сроков.
Другая сложность — навигация в сетке коммуникаций с коллегами. Матрицы компетенций или сетки команд полезны, но их поддержка трудоёмка, и такие документы быстро устаревают.
Ниже собраны практики, которые были отмечены в процессе работы с разными проектными командами и доказали свою эффективность в упрощении коммуникаций.
Система точек входа: группы и доменные каналы
Запрос информации может превратиться в блуждание по лабиринту: нужно вспоминать ответственного сотрудника, писать запросы в общий чат (@team-name), где все ждут, что ответит кто-то другой, или искать информацию в разрозненной базе знаний. Этот подход непредсказуем по результату и требует значительных временных затрат.
Решение — переход от крупных чатов к доменным каналам и группам пользователей. Запрос направляется не в общий чат отдела (например, #qa) или лично эксперту, а в специализированный канал по теме (#devops-help, #dba-support).
Этот подход решает сразу две проблемы:
- Распределение нагрузки. Когда все обращаются к одному эксперту, он перегружен. Система доменных каналов распределяет нагрузку равномерно.
- Снижение когнитивной нагрузки. Не нужно держать в голове «карту контактов». Запрос попадает в нужную «очередь», что особенно важно при регулярном обновлении состава команд«.
Теперь, специалист на прямой призыв («@ivan, глянь логи») обычно отвечает просьбой использовать тег команды (#some_team). И его логика прагматична: «Я занят срочной задачей. Укажи тег нашей команды — запрос подхватят»«.
Дежурство: первая линия передачи контекста
Сама по себе система каналов работает только в том случае, если за сообщениями следит ответственный за это человек. Чтобы запросы не «зависали» в каналах без ответа, существует практика дежурств. При решении типовых запросов («упал прогон», «не работает стенд») сотрудникам не нужно искать кого-то конкретного; дежурный отслеживает вопросы в рамках определенного канала или тега.
Дежурный принимает входящие запросы по тегу (например, #duty), оценивает их приоритет и либо решает сам, либо оперативно подключает людей. Ротация дежурств даёт каждому инженеру целостное представление о работе всей системы.
Итого, данная практика гарантирует, что запрос не «зависнет» и будет обработан.
Не теряем контекст: правило публичных тредов
Это ключевое правило. Любой диалог, влияющий на обмен контекстом, должен происходить в открытом треде, а не в личных сообщениях.
Открытые треды решают несколько проблем:
- Дисциплина и скорость: публичность мотивирует к более оперативному ответу. Все участники на виду, что позволяет при необходимости эскалировать вопрос.
- Прозрачная история: служат для фиксации решений и сохранения истории, чтобы любой специалист мог быстро войти в курс дела. Если ваш мессенджер позволяет сохранять ссылку на тред, обязательно указывайте её в связанной задаче.
Централизация усилий: единая точка ответственности
Результат коммуникаций — это созданные задачи. Но если задача носит глобальный характер (например, миграция на стенде тестирования), возникает конфликт приоритетов. Практика закрепления QA-специалистов за продуктовыми командами в этом случае не работает: продуктовые команды не склонны отвлекать своих специалистов от решения собственных задач.
Решение — создать выделенное звено, отвечающее за глобальные и критические задачи. Начать можно с одного опытного сотрудника, а по мере роста нагрузки — сформировать полноценную команду (Core QA, QA Tools).
Автоматизация и выбор инструментов
Эффективность практик напрямую зависит от возможностей вашего корпоративного мессенджера.
При выборе или оценке мессенджера убедитесь, что он поддерживает:
- создание гибких тегов и групп пользователей;
- ведение веток обсуждений (треды);
- сохранение истории и ссылок на сообщения;
- гибкую настройку уведомлений.
О масштабе и применимости
Ключевой принцип внедрения этих практик — пропорциональность. Для маленького стартапа из 5–10 человек такая формализация избыточна. Практики стоит применять тогда, когда старая модель начинает давать сбои: коммуникации затягиваются, информация теряется.
Цель этих практик — не усложнять процессы, а упрощать их. Когда коммуникация предсказуема и прозрачна, разбираться в проблемах становится проще, а уровень стресса в команде падает.
Ключевые слова: коммуникации в IT, управление командой, QA, тестирование, DevOps, организация процессов, распределённые команды, корпоративный мессенджер, взаимодействие команд
Подпишитесь на журнал
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|
Практики взаимодействия: как специалистам по обеспечению качества не утонуть в коммуникациях
