Перейти к основному содержимому

Матрица RACI

1. Выбранный функционал и границы​

Функционал: Owner-check — механизм безопасной передачи находки: до подтверждения владельца общение ограничено (только вопросы/ответы), после подтверждения — обычный чат.

Цель функционала:

  • снизить риск «отдать не тому» и мошенничества;

  • повысить доверие к платформе и долю закрытых объявлений.

2. Стейкхолдеры по Owner-check​

1) Заказчик​

Интерес: чтобы продукт давал ценность (возвраты, доверие и т.д.). Что решает:

  • нужен ли owner-check в MVP и в каком виде;

  • насколько жёсткие ограничения чата допустимы;

  • критерии успеха (KPI).

2) Системный аналитик​

Интерес: требования были однозначные, проверяемые и реализуемые. Что делает: сценарии (Use Case), бизнес-правила, критерии приёмки, крайние случаи.

3) UX/UI дизайнер​

Интерес: чтобы пользователь понял, почему чат ограничен, и не бросил процесс. Что делает: UX-поток, тексты, состояния (“ожидаем ответы”, “подтверждено”, “отклонено”).

4) Архитектор / Tech Lead​

Интерес: чтобы решение было технически целостным, безопасным и поддерживаемым. Что решает: модель данных/статусы, API-подход, где ограничения гарантируются (сервер/клиент), логирование, антиспам.

5) Backend-разработчик​

Интерес: стабильная серверная логика. Что делает: статусы owner-check, API, валидации, запреты до подтверждения.

6) Frontend-разработчик​

Интерес: корректный UX и состояния приложения. Что делает: UI owner-check, блокировки, сообщения, обработка ошибок.

7) Тестировщик (QA)​

Интерес: чтобы не было дыр/обходов и регресса. Что делает: позитивные/негативные сценарии, проверка статусов/ограничений, баг-репорты.

8) Модератор​

Интерес: меньше мошенничества и понятный процесс разборов. Что решает/влияет: правила жалоб, красные флаги, что считаем злоупотреблением.

9) Пользователь “Нашедший”​

Интерес: безопасно отдать находку и не попасть на мошенника. Как влияет: даёт требования “какие вопросы работают” и в реальном сценарии принимает решение “подтвердить/отклонить”.

10) Пользователь “Потерявший” (Owner)​

Интерес: быстро вернуть вещь/животное. Как влияет: показывает, какие “секретные признаки” реально можно вспомнить.

11) Юрист​

Интерес: чтобы не было утечек персональных данных и опасных сценариев. Как влияет: формулировки запретов, рекомендации, что блокируем до подтверждения.

12) Организации (приюты, бюро находок, учреждения)​

Интерес: понятная и безопасная процедура выдачи, снижение конфликтов. Как влияет: консультируют по существующим методам подтверждения владельца и по типовыми кейсами мошенничества.

3. Активности в рамках реализации функционала​

Ниже активности для внедрения owner-check в MVP:

  1. Сформировать бизнес-цель и KPI для owner-check.

  2. Собрать требования и риски (мошенничество, утечки данных, “отдать не тому”).

  3. Спроектировать сценарии (Use Case, альтернативы, исключения).

  4. Определить правила ограничений чата до подтверждения (что можно/нельзя отправлять).

  5. Определить шаблоны контрольных вопросов (2–3 вопроса) и возможность “свой вопрос”.

  6. Спроектировать UX поток (карточка → отклик → owner-check → обычный чат).

  7. Спроектировать модель данных и статусы (диалог, owner-check status).

  8. Реализовать API/Backend (создание диалога, вопросы/ответы, решение, смена режима).

  9. Реализовать UI/Frontend (экраны, статусы, блокировки, сообщения).

  10. Настроить обработку ошибок/крайних случаев (нет ответа, повторная отправка, сбои).

  11. Подготовить тесты и провести тестирование.

  12. Провести приёмку функционала и утвердить релиз.

  13. Включить мониторинг и базовую аналитику (сколько проверок, конверсия в подтверждение).

  14. Организовать поддержку/процесс жалоб (что делать при споре/мошенничестве).

4. RACI-матрица (для функционала Owner-check)​

Обозначения:

  • R (Responsible) — делает работу руками (исполняет).

  • A (Accountable) — утверждает результат и несёт ответственность.

  • C (Consulted) — консультирует (двусторонняя коммуникация).

  • I (Informed) — информируется (односторонняя коммуникация).

АктивностьЗаказчикСистемный аналитикUX/UIАрхитекторBackendFrontendТестировщикМодераторНашедшийВладелецЮристОрганизации
1. Цель и KPI owner-checkARIIIIIIССIС
2. Сбор требований и рисковARIIIIICCCCC
3. Use Case и альтернативы/исключенияARIICIIICCIС
4. Правила ограничений чата до подтвержденияARIIIIIIIICI
5. Шаблоны контрольных вопросовARIIIIIICCCC
6. UX поток и тексты/подсказкиACRIIIIICCCI
7. Модель данных и статусыICIARCIIIIII
8. Backend реализация и APIICIARICIIIII
9. Frontend реализация (экраны/блокировки)ICCAIRIIIIII
10. Ошибки и крайние случаи (реализация и обработка)ICIARRCIIIII
11. Тестирование (включая негативные кейсы)IAIICCRIIIII
12. Приёмка релиза (UAT)ARIIIICIIIII
13. Мониторинг и метрикиICIARIIIIIII
14. Процесс жалоб/поддержки owner-checkACIIIIIRIICI

5. Роли в принятии решений и реализации​

Заказчик​

  • Принимает ключевые продуктовые решения по функционалу: нужен ли owner-check в MVP, какие ограничения допустимы, чтобы не ухудшить пользовательский опыт.

  • Утверждает (A) результат на этапах, связанных с бизнес-ценностью: цели/KPI, требования и правила ограничений, приёмка релиза, процесс поддержки/жалоб.

  • Отвечает за последствия решения: компромисс между безопасностью и удобством, влияние на метрики и репутационные риски.

Системный аналитик​

  • Собирает и формализует требования к owner-check: основной сценарий, альтернативные потоки, исключения, бизнес-правила.

  • Декомпозирует функционал для разработки: что нужно реализовать в backend/frontend, какие статусы/ограничения должны быть.

  • Формирует критерии приёмки и проверяет, что функционал соответствует требованиям (в том числе участвует в приёмке и в контроле покрытия тестами).

UX/UI​

  • Проектирует пользовательский поток owner-check: как пользователь попадает в проверку, что видит на каждом шаге, какие статусы и подсказки есть.

  • Готовит тексты, чтобы пользователю было понятно зачем чат ограничен и что нужно сделать для подтверждения.

  • Снижает риск ошибок и конфликтов через понятный интерфейс и корректные состояния.

Архитектор​

  • Утверждает техническое решение по реализации функционала: модель данных, статусы, подход к API.

  • Отвечает за технические риски: устойчивость, безопасность на уровне архитектуры, защита от обхода ограничений.

  • Определяет подход к мониторингу/логированию и обработке ошибок на уровне системы.

Backend​

  • Реализует серверную логику : статусы owner-check, хранение/проверка вопросов и ответов, переходы между режимами.

  • Гарантирует ограничения на сервере (невозможность обойти правила через прямые запросы к API).

Frontend​

  • Реализует интерфейс: экраны owner-check, отображение статусов, блокировки полей/действий до подтверждения.

  • Обеспечивает корректные пользовательские состояния при ошибках: повторная отправка, отсутствие ответа, нестабильная сеть и т.п.

Тестировщик​

  • Проводит тестирование функционала: позитивные сценарии и негативные кейсы (ошибки, недоступность сети, попытки обойти ограничения, некорректные данные).

  • Проверяет корректность переходов статусов owner-check и соответствие критериям приёмки.

  • Фиксирует дефекты и контролирует регресс после исправлений.

Модератор​

  • Исполняет процесс поддержки и обработки жалоб: принимает обращения пользователей, проверяет контент/переписку по жалобе, применяет меры согласно правилам.

  • Участвует консультационно при проработке требований, связанных с жалобами и типовыми злоупотреблениями.

  • Обеспечивает управляемость спорных кейсов после релиза (когда owner-check не помог или возник конфликт).

Нашедший​

  • Консультирует по требованиям как пользователь: какие контрольные вопросы реально помогают отличить владельца от мошенника, сколько шагов приемлемо.

  • В рабочем процессе инициирует проверку и принимает решение: подтверждать владельца или отклонять, если ответы выглядят сомнительно.

  • Даёт обратную связь о том, где интерфейс/правила мешают или вызывают недоверие.

Владелец​

  • Консультирует требования как пользователь: какие признаки владения он реально может назвать, какие вопросы могут быть невозможны/несправедливы.

  • В рабочем процессе проходит проверку, отвечая на вопросы, чтобы подтвердить владение вещью/животным.

  • Даёт обратную связь по сложности, скорости и понятности процесса.

Юрист​

  • Консультирует по вопросам персональных данных и формулировок ограничений: какие данные нельзя запрашивать/передавать до подтверждения.

  • Помогает сформулировать предупреждения и правила безопасного общения, чтобы снизить юридические и репутационные риски.

Организации​

  • Консультируют по практикам “как подтверждают владельца в реальной жизни” (приюты, бюро находок и т.п.).

  • Подсказывают типовые мошеннические сценарии и “сильные признаки владения”.

  • Их опыт используется для улучшения сценариев owner-check и повышения доверия к сервису.