Как выстроен процесс работы команды над фичей?

Как выстроен процесс работы команды над фичей

Процесс разработки фичи — это жизненный цикл, в котором участвуют разные специалисты: Product Manager, дизайнер, инженеры, тестировщик. Мой опыт показывает, что хороший процесс критичен для доставки качества и скорости.

Общая схема

Discovery (1-2 недели)
    ↓
Design (2-4 недели)
    ↓
Development (1-3 недели)
    ↓
QA/Testing (1 неделя)
    ↓
Release (1 день)
    ↓
Monitoring & Feedback (2+ недели)

Фаза 1: Discovery (Открытие)

Что происходит:

• Product Manager проводит исследование: интервью с юзерами, анализ конкурентов, метрик
• Команда мозговой штурм: "Как мы можем это сделать?"
• Определяем success metrics: какие числа говорят о том, что фича сработала

Кто участвует:

• Product Manager (я) — ведущий
• Engineering lead — дает оценку технической сложности
• Designer — предварительно думает о UX
• Иногда sales/support — собирают feedback от клиентов

Выход:

• Документ "Product Requirement Document" (PRD) или Jira issue с description
• Success metrics
• Приблизительная оценка complexity (small, medium, large)

Пример PRD:

Title: Search functionality with filters

Goal:
Пользователи смогут находить нужные курсы за < 2 секунды

Success Metrics:
- Search conversion: 10% → 18%
- Time to find: 45 sec → 15 sec
- Search bounce rate: < 5%

Requirements:
1. Полнотекстовый поиск по названию и описанию
2. Фильтры: категория, уровень, язык
3. Автодополнение при вводе
4. Сохранение истории поиска

Out of scope:
- Рекомендации (будет потом)
- Поиск по рецензиям

Estimated effort: 6-8 недель

Фаза 2: Design (Дизайн)

Что происходит:

Дизайнер создаёт mockups и прототип:

1. Wireframes — черновой макет, где что находится
2. Design mockups — финальный вид со всеми элементами
3. Prototype — интерактивный прототип для юзер-тестирования

Процесс:

• Дизайнер создаёт варианты (обычно 2-3)
• Product Manager и lead инженер смотрят, дают feedback
• Обсуждаем: "Это ли мы хотели?" "Это технически возможно?" "А давайте упростим?"
• Дизайнер делает финальную версию

Юзер-тестирование:

• Иногда дизайнер показывает прототип 3-5 реальным пользователям
• Слушаем их feedback: "Что здесь не понятно? Как ты бы это использовал?"
• Делаем правки

Выход:

• Design spec в Figma
• Все компоненты (buttons, inputs, cards, etc.) задокументированы
• Animations и transitions описаны
• Responsive views для mobile/tablet/desktop

Обычно занимает:

• 2-4 недели, в зависимости от complexity
• Может идти параллельно с refinement требований

Фаза 3: Sprint Planning (Планирование спринта)

Когда это происходит:

• В конце предыдущего спринта (обычно в пятницу)
• Участники: Product Manager (я), инженеры, дизайнер
• Где: Meeting room или Zoom

Порядок:

1. Presentation требований:

• Я показываю фичу в Figma
• Объясняю, почему мы её делаем (метрики, feedback, стратегия)
• Отвечаю на вопросы

2. Technical breakdown:

• Engineering lead разбивает фичу на tasks:
  • Backend API endpoint
  • Frontend component
  • Database migration
  • Search index setup
  • Integration tests
  • Deployment checklist
• Для каждого таска оценка (2, 3, 5, 8, 13 story points)

3. Story point estimation (Planning poker):

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

Пример:

Task: "Search API endpoint with full-text search"
Estimates: 5, 5, 8, 5
Consensus: 5 points (примерно 1 день work)

Task: "Search index synchronization"
Estimates: 8, 13, 13, 8  
Consensus: 8 points (после дискуссии)

4. Sprint commitment:

• Team говорит: "В этот спринт (2 недели) мы можем сделать X story points"
• Обычно это 40 points на team из 5 инженеров
• Выбираем, какие задачи влезают в спринт

Выход:

• Список tasks в Jira/Linear
• Каждый task имеет описание, acceptance criteria, story points
• Owner назначен для каждого task

Фаза 4: Development (Разработка)

День 1-3: Initial Development

Инженеры начинают писать код:

• Backend engineer: API endpoints, database changes
• Frontend engineer: React components, state management
• DevOps (если нужно): Deploy configuration

Ежедневные sync:

• Утром 15-минутный standup
• "Что я вчера делал? Что делаю сегодня? Есть ли блокеры?"
• Решаем проблемы на месте

День 4-7: Code review и integration

Когда инженер закончил часть работы:

• Pushит в feature branch
• Создаёт Pull Request (PR)
• Коллеги делают code review:
  • Проверяют логику
  • Проверяют на баги
  • Проверяют best practices
  • Дают feedback
• Инженер делает правки
• PR мёржится в main

Code review checklist:

☐ Code follows style guide
☐ Tests included (unit + integration)
☐ Documentation updated
☐ No hardcoded values
☐ No console.log / debug code
☐ Backwards compatible
☐ Performance acceptable
☐ Security reviewed

День 7-10: Feature integration

• Backend и frontend интегрируются
• Тестируют вместе в staging environment
• Исправляют баги
• Подготавливают к QA

Обычно:

• 1-2 дня чистки и optimization
• Мониторят performance
• Finalize feature flags

Фаза 5: QA / Testing (Тестирование)

Что QA делает:

Manual testing:

• Проверяет все acceptance criteria из issue
• Тестирует разные браузеры/устройства
• Ищет edge cases: "Что если пользователь делает X, потом Y, потом Z?"
• Проверяет performance: "Как быстро ищет? Не зависает ли?"

Regression testing:

• Проверяет, что старые фичи не сломались
• Прогоняет smoke tests

Пример тест-плана:

✓ Search box appears on homepage
✓ Can type characters without delay
✓ Auto-complete shows suggestions
✓ Can select suggestion with keyboard/mouse
✓ Search results load in < 2 seconds
✓ Filters work independently
✓ Filters + search work together
✓ Mobile view is readable
✓ No console errors
✓ Old features still work (regression)

Если QA нашёл баги:

Bug в Jira → Back to engineer → Fix → Code review → QA retesting → Closed

Обычно 2-3 итерации исправления багов.

Фаза 6: Release (Выпуск)

Feature Flag Release (рекомендуемый подход):

Feature flag OFF  → Deploy to production (никто не видит)
                  ↓
Feature flag ON 1% → Smoke test, посмотреть логи на ошибки
                  ↓
Feature flag ON 25% → Мониторим метрики, есть ли проблемы
                  ↓
Feature flag ON 50% → Слышим feedback от реальных пользователей
                  ↓
Feature flag ON 100% → Все пользователи видят фичу
                  ↓
Feature flag REMOVED → Cleanup, код становится постоянным

Преимущества:

• Если что-то пошло не так, просто отключаешь флаг (< 1 минута)
• Не нужен откат и новый deploy
• Можно тестировать постепенно

Обычный процесс:

День Release:

• Engineering lead проверяет: все ли обновления в production-ready
• DevOps делает deploy
• Мониторим логи на ошибки (первые 30 минут)
• Постепенно открываем флаг: 1% → 25% → 50% → 100%

Post-release checklist:

☐ Deployment completed without errors
☐ No spike in error rates
☐ Page load times normal
☐ Success metrics tracking properly
☐ No customer complaints in first hour
☐ Team available for quick fixes if needed

Фаза 7: Monitoring & Feedback (Мониторинг)

Первые 24 часа:

• Product Manager мониторит метрики
• Инженеры готовы к hotfixes
• Support следит за feedback от пользователей

Первая неделя:

• Смотрим на success metrics
• Собираем feedback: "Что нравится? Что не нравится?"
• Правим маленькие баги

Через 2 недели:

• Post-launch review:
  • Достигли ли success metrics?
  • Если нет, почему?
  • Что нужно улучшить?
• Product Manager документирует learnings

Обычные learnings:

✓ Success: Search adoption 15% (goal was 10%)
✓ Users love autocomplete
⚠️ Performance issue: searches > 100 chars slow
⚠️ Filter UI confusing for mobile users

Next iteration:
- Optimize search for long queries
- Redesign filter for mobile

Типичная timeline

Итого: 8-10 недель от идеи до стабильной фичи

Коммуникация

Синхронизация:

• Daily standup (15 min) — быстрый sync
• Mid-week sync (30 min) — если нужно обсудить decision
• Sprint retro (1 hour) — анализируем, что хорошо/плохо

Документация:

• PRD (Product Requirement Document) в Confluence
• Design spec в Figma
• Technical design в Notion/Confluence
• Release notes в Notion

Escalation:

Если появился риск (blocking issue, timeline threat):

1. Говорю engineering lead
2. Обсуждаем решение
3. Быстро принимаем решение
4. Информирую stakeholders

Проблемы, которые я вижу часто

Инструменты

• Product management: Jira, Linear, Asana
• Design: Figma
• Documentation: Notion, Confluence
• Communication: Slack, Zoom
• Analytics: Google Analytics, Amplitude
• Code review: GitHub, GitLab
• Deployment: GitHub Actions, Jenkins, Dokku
• Feature flags: LaunchDarkly, Unleash

Итог

Хороший процесс разработки фичи обеспечивает:

1. Ясность — все знают, что делают и зачем
2. Скорость — нет долгих meeting или ждания
3. Качество — баги находятся до production
4. Accountability — понятно, кто за что отвечает
5. Learning — после каждой фичи улучшаются

Когда это работает, команда может выпускать quality features каждый спринт, и пользователи видят постоянное улучшение продукта.