Как были устроены процессы на последнем месте работы?

Процессы на последнем месте работы: Agile-трансформация в FinTech

На последнем месте работы я был BA в FinTech компании, которая занималась платежами. Компания выросла с 20 до 150 сотрудников за 2 года, и процессы все еще развивались.

Общая структура организации

Компания была разделена на 3 основных подразделения:

• Backend и API (10 разработчиков)
• Frontend и мобильное приложение (8 разработчиков)
• Ops и инфраструктура (5 человек)
• Product и BA (я и еще один BA)

Процесс разработки: Agile

Мы использовали Scrum с двухнедельными спринтами. Вот как это выглядело:

Planning В начале спринта (понедельник 10:00) проходит Planning на 2 часа:

• Product Owner презентует требования (обычно я их подготавливал)
• Команда оценивает с помощью Planning Poker (Fibonacci: 1, 2, 3, 5, 8, 13)
• Договариваемся о количестве историй, которые можно сделать за 2 недели

Средняя velocity была 50-65 story points за спринт.

Daily Standup Каждый день 15 минут (9:30):

• Что я сделал вчера?
• Что делаю сегодня?
• Какие блокеры?

Это быстро, но очень полезно для синхронизации.

Требования Требования фиксировались в Jira как User Stories с форматом:

Как [роль], я хочу [действие], чтобы [выгода]
Примеры сценариев:
- Пользователь платит картой
- Если платеж неудачный, показать ошибку
- Интегрироваться с Stripe

Acceptance Criteria:
- [ ] Платеж успешен за <1 секунду
- [ ] Ошибки JSON с кодом ошибки
- [ ] Поддержка всех карт

Каждая история содержала:

• Описание (As a... I want... So that...)
• Acceptance Criteria (AC)
• Estimate в story points
• Links к связанным историям
• Mockups или дизайны (если UI)

Review и Retrospective В конце спринта (пятница 15:00):

• Sprint Review (1 час): демонстрация готовых историй Product Owner и stakeholders
• Sprint Retrospective (1 час): что прошло хорошо? Что можно улучшить?

В ретро часто находили:

• Недостаток времени на requirements (я делал больше upfront work)
• Зависимости между командами (нужна лучшая коммуникация)
• Технические долги (в следующий спринт добавляли более технические задачи)

Моя роль BA в процессе

Подготовка требований (Pre-Planning) За неделю до Planning я готовил требования:

1. Интервью с Product Owner и stakeholders (менеджеры, дизайнеры, клиенты)
2. Рисовал процессы в Miro (user flows, BPMN)
3. Создавал mockups в Figma
4. Писал user stories в Jira
5. Проводил "grooming" встречу (обсуждал с развивающей командой, чтобы они поняли)

На Planning Презентовал историю, объяснял AC, отвечал на вопросы разработчиков.

Во время спринта

• Был доступен для уточнений (обычно Slack или daily standup)
• Следил за блокерами (если разработчик не понимает требование)
• Помогал с тестированием (создавал test cases)

На Review Показывал готовую фичу заказчику, собирал фидбек.

Управление требованиями

Product Backlog Все требования жили в одном бэклоге Jira, приоритизированном Product Owner:

• Now (следующий спринт, 100% готовы)
• Next (2-3 спринта, частично готовы)
• Future (длинный хвост идей)

Все истории были в одном месте, что облегчало отслеживание.

Зависимости Мы отслеживали зависимости между историями:

• Frontend история "Страница платежа" зависит от Backend истории "API платежей"
• Jira автоматически показывала эти связи

Это помогало планировать спринты: если Backend задержится, Frontend может взять другую историю.

Интеграции между командами

Backend и Frontend работали параллельно, что требовало хорошей координации:

API Contract First Мы сначала определяли API контракт (JSON, endpoint, статусы ошибок), потом Frontend и Backend разрабатывали параллельно.

Вот пример:

POST /api/v1/payments
Request:
{
  "amount": 10.50,
  "currency": "USD",
  "card_token": "tok_visa",
  "user_id": "123"
}

Response (200):
{
  "id": "pay_123",
  "status": "success",
  "timestamp": "2024-01-15T10:00:00Z"
}

Response (400):
{
  "error": "INVALID_CARD",
  "message": "The card has expired"
}

Frontend разработчик может сразу начать писать код, используя mock-сервер. Backend разработчик разрабатывает реальный API.

Integration Testing Когда обе стороны готовы, проводим интеграционное тестирование (обычно в конце спринта).

Трудности в процессе

1. Быстрый рост компании Процессы не масштабировались с ростом.

Решение: Я внедрил более строгий процесс подготовки требований и grooming встречи.

2. Нечеткие требования от stakeholders Менеджеры иногда говорили: "Я видел у конкурента фичу, давайте сделаем тоже".

Решение: Я просил конкретный пример, рисовал user journey, спрашивал выгоду для пользователя. Это помогло фильтровать идеи.

3. Технический долг Разработчики просили времени на рефакторинг, но Product Owner хотел новых фич.

Решение: Я предложил чередовать спринты: 1 спринт новые фичи, 1 спринт технический долг. Это снизило бугов и скорость разработки немного выросла.

4. Зависимости между историями Иногда история попадала в спринт, но зависимость не была готова.

Решение: На grooming я явно отмечал зависимости в Jira. На Planning учитывали эти зависимости.

Инструменты

Jira для управления требованиями и спринтами Confluence для документации (архитектура, runbooks) Miro для моделирования процессов и обсуждений Figma для дизайнов (фронтенд) Slack для быстрой коммуникации Git для версионирования кода

Трансформация в процесс

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

1. Grooming встречи раз в неделю, где обсуждали требования до Planning

2. Шаблоны историй с одинаковой структурой

3. Definition of Done для каждой истории:

   • Code reviewed and merged
   • Unit tests passed (coverage >80%)
   • Integration tests passed
   • QA tested
   • Deployed to staging
   • Stakeholder approved

4. Метрики спринта: velocity, burn down chart, bug rate

Это заняло ~3 месяца, но качество историй значительно улучшилось, и переделок стало меньше.

Мое видение идеального процесса

На этой работе я понял, что хороший процесс это не про инструменты или методологию, а про:

1. Ясные требования с конкретными примерами
2. Регулярная коммуникация (daily standup, grooming, review)
3. Разделение ответственности (Product Owner определяет "что", разработчики определяют "как")
4. Непрерывный feedback loop (тестирование, user feedback)
5. Гибкость (готовность менять планы, если получили новую информацию)

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