Приведи пример своей инициативы

Моя инициатива: Requirements Review Board

Одна из моих самых успешных инициатив возникла из реальной боли, которую я видел в marketplace проекте.

Проблема

Мы часто находили баги в production, потому что требования были неполными или противоречивыми. Типичный сценарий:

• Я пишу требование: "Покажи список заказов"
• Разработчик спрашивает: "А в каком порядке?"
• Я отвечаю: "Не указал"
• QA не знает, что тестировать
• В production клиенты видят случайный порядок

Это повторялось постоянно. Среднее количество уточнений требования во время разработки: 40%.

Как я это решил

Я предложил создать Requirements Review Board — еженедельный meeting (30 минут), где 4 ключевых человека проверяют требования ДО разработки:

1. Я (BA) — представляю требование
2. Техлид — говорит о технических ограничениях
3. QA — говорит, может ли это протестировать
4. PM — уточняет, зачем это нужно

Как это работает

Перед meeting:

• Я подготавливаю 3-5 требований
• Пишу их в нужном формате (User Story с AC)
• Готовлю примеры и диаграммы

На meeting (30 минут):

1. Я читаю требование (2 минуты)
2. Техлид задаёт вопросы (5 минут)
3. QA задаёт вопросы (5 минут)
4. PM задаёт вопросы (5 минут)
5. Я уточняю/переписываю (8 минут)
6. Принимаем решение: Ready / Needs rework

Критерии "Ready":

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

Примеры улучшений

Требование 1 (ДО):

Покажи список заказов

Требование 1 (ПОСЛЕ Review Board):

Когда пользователь открывает страницу /orders:
- Система показывает таблицу со всеми его заказами
- Колонки: ID, Client name, Amount, Status, Created date
- По умолчанию: сортировка по дате (новые сверху)
- Пользователь может переключать порядок (ASC/DESC)
- Максимум 20 заказов на странице
- Пагинация: Next/Prev кнопки
- Если заказов нет: показать "No orders yet"
- Время загрузки < 1 секунда (P95)

Требование 2 (ДО):

Обработай ошибку платежа

Требование 2 (ПОСЛЕ Review Board):

Если API банка вернёт ошибку платежа:
- Система логирует ошибку (timestamp, user_id, error_code, error_message)
- Пользователю показывается дружеское сообщение (не technical error)
- Сообщение зависит от типа ошибки:
  - INSUFFICIENT_FUNDS: "На вашем счёте недостаточно средств"
  - FRAUD_DETECTED: "Платёж заблокирован по соображениям безопасности"
  - TIMEOUT: "Платёж не обработан, попробуйте позже"
- У пользователя есть кнопка "Retry" (не более 3 попыток)
- Admin видит ошибки в dashboard (для анализа)

Результаты

Метрики (за 6 месяцев):

Feedback от команды:

• Техлид: "Теперь я знаю, что будет в требовании, когда начну кодить"
• QA: "Я могу написать тесты ДО разработки, потому что требование ясно"
• PM: "Мы реже меняем требования в процессе"

Почему это сработало

1. Это решило реальную боль

• Все видели проблему (переделки требований)
• Все выиграли от решения

2. Это потребовало минимум ресурсов

• Просто meeting (мы уже тратили это время на обсуждения)
• Никаких новых инструментов

3. Результаты видны сразу

• Первый месяц видно улучшение
• Люди начинают верить в процесс

4. Это создало культуру质質

• Люди начали думать о деталях
• Меньше "а давайте это выясним потом"

Как я продвигал эту инициативу

Шаг 1: Собрал данные

• Проанализировал 50 последних требований
• Посчитал % переделок
• Показал эту метрику команде

Шаг 2: Предложил решение

• Не приказал, а предложил
• "Давайте попробуем 2 недели, посмотрим, поможет ли"

Шаг 3: Выбрал правильные люди

• Техлид, который думает о качестве
• QA, которая хочет лучше тестировать
• PM, который заботится о сроках

Шаг 4: Сделал это привлекательным

• Показал, что это экономит время (не тратит)
• Показал примеры, как требование становится лучше

Шаг 5: Итерировал

• После месяца спросил feedback
• Изменил формат (было 60 минут, стало 30)
• Изменил критерии (добавил "тестируемость")

Масштабирование

Этот процесс стал настолько популярным, что:

• Другие команды в компании запросили то же
• Я обучил других BA проводить Review Board
• Теперь это part of standard process во всей компании

Вывод

Хорошая инициатива:

• Решает реальную проблему (не придуманную)
• Требует минимум ресурсов
• Дает быстрые результаты
• Создает культуру улучшения

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