На проекте дефекты теряются между разработкой, QA и эксплуатацией. Какой механизм распределения ответственности устранит этот пробел?
Используйте матрицу ответственности RACI для ключевых этапов качества и явно назначьте владельца результата, а не только исполнителей отдельных действий. Для каждого типа решения должно быть понятно, кто выполняет работу, кто несёт конечную ответственность, кого консультируют и кого информируют.
Подход с явным распределением ответственности появился как ответ на проблему коллективной ответственности: когда в процессе участвуют несколько ролей, каждая предполагает, что финальное решение принимает кто-то другой. Особенно заметно это при переходе от отдельной команды тестирования к сквозному процессу поставки.
RACI не заменяет инженерные практики тестирования. Его задача — устранить организационные разрывы, в которых дефект зарегистрирован, но никто явно не отвечает за его приоритизацию, исправление, повторную проверку или решение о выпуске.
Дефект может переходить между командами из-за неясного владельца: разработка считает его задачей QA, QA ждёт решения владельца продукта, а эксплуатация узнаёт о проблеме только после релиза. В результате увеличивается время устранения, теряется контекст, а решение о выпуске принимается неформально.
Простого списка ролей недостаточно. Нужно связать роли с конкретными результатами: например, кто отвечает за готовность исправления, кто утверждает остаточный риск, кто проверяет исправление и кто получает уведомление об изменении статуса.
В RACI используются четыре типа участия:
Для процесса качества можно отдельно описать такие точки: классификация дефекта, назначение приоритета, подготовка исправления, повторная проверка, оценка влияния на релиз, принятие остаточного риска и уведомление эксплуатации.
Ключевое правило — у каждого результата должен быть один Accountable. Несколько исполнителей допустимы, но несколько конечных владельцев часто приводят к спору о том, кто должен принять решение. При этом RACI не означает, что QA отвечает за всё качество продукта: качество создаётся всеми участниками, а QA отвечает за определённые проверки, прозрачность рисков и предоставление объективной информации.
Матрицу следует проверять на практических сценариях, а не создавать как формальный документ. Если дефект высокой критичности всё равно может несколько дней находиться без владельца, распределение ответственности неполно или не связано с рабочим процессом.
Ограничение подхода — риск бюрократии. Для каждой мелкой операции отдельная матрица избыточна; достаточно определить ответственность за критичные решения и переходы между подразделениями. Также RACI не решает конфликт приоритетов сам по себе: для этого нужны правила эскалации и полномочия владельца решения.
В продуктовой компании дефекты, найденные после релиза, часто оставались без движения. QA регистрировала проблему, разработка ожидала подтверждения от владельца продукта, а эксплуатация не понимала, кто должен оценить влияние на пользователей.
Рассматривались три варианта. Передать все решения QA было бы быстро, но создало бы ложную ответственность QA за бизнес-приоритеты. Оставить решения на усмотрение команды сохранило бы гибкость, но не устранило бы пропуски. Создать подробный регламент для каждой операции обеспечило бы формальность, но замедлило бы работу.
Выбрали компактную RACI-матрицу только для критичных дефектов и релизных решений. QA стала ответственной за регистрацию, воспроизведение и повторную проверку; технический руководитель — за исправление; владелец продукта — за бизнес-приоритет и принятие остаточного риска; эксплуатация — за оценку влияния на рабочее окружение и информирование об инциденте.
В результате у каждого критичного дефекта появился однозначный владелец решения, а спорные случаи стали эскалироваться по заранее известному маршруту. При этом QA не получила полномочий единолично решать, допустим ли бизнес-риск, что сохранило разделение технической оценки и ответственности за продукт.
1. Можно ли назначить QA одновременно Responsible и Accountable за качество всего продукта?
Нет, такая формулировка обычно скрывает неверную модель ответственности. QA может быть Responsible за выполнение определённых проверок и Accountable за качество конкретного артефакта процесса, например отчёта о тестировании. Но конечное качество продукта зависит от требований, архитектуры, реализации, эксплуатации и бизнес-решений, поэтому его нельзя корректно свести к ответственности одной QA-команды.
2. Чем RACI отличается от простого назначения исполнителя в задаче?
Назначение исполнителя отвечает только на вопрос, кто выполняет действие. RACI дополнительно фиксирует, кто принимает итоговое решение, кого нужно привлечь до него и кого уведомить после него. Это важно, когда исправление подготовлено, но ещё требуется решение о приоритете, готовности к выпуску или принятии остаточного риска.
3. Что делать, если для одного решения претендуют несколько владельцев?
Нужно разделить решение на независимые результаты либо назначить одного Accountable, сохранив остальных как Consulted. Например, технический руководитель может отвечать за техническую готовность исправления, а владелец продукта — за принятие бизнес-риска при выпуске. Если ответственность нельзя разделить, должны быть заранее определены полномочия одного владельца и маршрут эскалации, иначе матрица лишь зафиксирует конфликт, но не устранит его.