Расскажи про свой опыт написания запросов

Опыт написания запросов (RFP, Requirements Specification, Design Docs)

Введение

В роли System Analyst'а я писал сотни различных "запросов" — от простых User Stories до 50+ страничных Design Documents. Это критически важный skill, потому что плохой запрос = плохой результат.

Типы запросов, которые я пишу

1. RFP (Request for Proposal) — 20 проектов

• Для внешних вендоров
• Объём: 5-30 страниц
• Используется для найма подрядчиков

2. Requirements Document (SRS) — 50+ проектов

• Для своей команды разработчиков
• Объём: 10-100 страниц
• Основной документ проекта

3. Design Document (Architecture + Functional Design) — 30+ проектов

• Для разработчиков и архитекторов
• Объём: 20-50 страниц
• Описывает ТАК ИМЕННО реализовать требования

4. User Stories + Acceptance Criteria — сотни

• Для sprints
• Объём: 0,5-2 страницы
• Работают как tickets

5. API Specification — 50+ документов

• Для интеграции между системами
• Используется OpenAPI / Swagger
• Объём: 5-20 страниц

Case 1: RFP для выбора платёжного провайдера (3 месяца)

Ситуация: Маркетплейс нужен платёжный провайдер. На рынке 10+ вариантов. Нужно выбрать лучший.

Что я сделал:

Фаза 1: Выявление требований (2 недели)

• Провёл workshop со всеми stakeholder'ами:
  • CTO: требования к API
  • CFO: требования к комиссиям
  • COO: требования к поддержке
  • Юрист: требования к compliance
  • UX: требования к UX интеграции
• Собрал список требований: 40 пунктов

Фаза 2: Структурирование RFP

═══════════════════════════════════════════════════
RFP: Платёжный провайдер для Marketplace.ru
Выпущено: 01.01.2026
Дедлайн предложений: 15.01.2026
═══════════════════════════════════════════════════

1. EXECUTIVE SUMMARY
   - Контекст: нужен платёжный провайдер для маркетплейса
   - Объём: 1M транзакций/год
   - Бюджет: до $50k/год в комиссиях
   - Timeline: 3 месяца на интеграцию

2. REQUIREMENTS

   A. FUNCTIONAL REQUIREMENTS
      FR-1: Support онлайн платежей
         - Карты (Visa, Mastercard)
         - Альтернативные методы (Apple Pay, Google Pay)
      
      FR-2: Support платежей с рассрочкой
         - 3, 6, 12 месячные планы
         - Must integrated с БЭК
      
      FR-3: Возвраты и refunds
         - Full refund в течение 5 дней
         - Partial refund поддержка
      
      FR-4: Fraud protection
         - 3D Secure обязателен
         - Скоринг систему
         - Вручную review опция
      
      FR-5: Reporting и analytics
         - Dashboard в реальном времени
         - Daily settlement отчёты
         - Export в CSV/Excel
   
   B. NONFUNCTIONAL REQUIREMENTS
      
      NFR-1: PERFORMANCE
         - Payment processing < 3 сек
         - API response < 500ms
         - Uptime: 99.9% минимум
      
      NFR-2: SECURITY
         - PCI DSS Level 1 compliance
         - SSL/TLS 1.2+ обязателен
         - API key rotation поддержка
      
      NFR-3: SCALABILITY
         - Support 10k TPS (transactions per second)
         - Auto-scaling инфраструктура
      
      NFR-4: AVAILABILITY
         - 24/7 support в России
         - SLA: 99.9% uptime
         - Максимум 4 hours downtime в месяц
   
   C. REGULATORY REQUIREMENTS
      - PCI DSS compliance
      - Соответствие ФЗ-115 (AML)
      - Лицензия в России (если требуется)
      - GDPR compliance для EU клиентов

3. TECHNICAL SPECIFICATIONS
   
   A. API Requirements
      - REST API с JSON
      - API versioning (v1, v2)
      - Rate limiting: 100 req/sec
      - Webhook support для notifications
      - Mock API для тестирования
   
   B. Integration Options
      - Direct integration (REST)
      - Pre-built integrations (Shopify, WooCommerce)
      - Plugin для нашей платформы
      - SDK доступен (Python, Node.js, Java)
   
   C. Documentation
      - API documentation (OpenAPI format)
      - SDK documentation
      - Code examples (на популярных языках)
      - FAQ и troubleshooting

4. COMMERCIAL REQUIREMENTS
   
   A. PRICING
      - Комиссия: не более 2.5% за карту
      - Setup fee: не более $5k
      - Monthly fee: не более $500
      - Volume discount при 100k+ транзакций/месяц
   
   B. CONTRACT TERMS
      - Минимум 1 год контракта
      - 30 days notice для расторжения
      - No lock-in clause
      - Possible early termination
   
   C. SLA TERMS
      - 99.9% uptime guarantee
      - Penalty: 5% комиссии за каждый % ниже
      - Maximum downtime: 4 часов в месяц

5. EVALUATION CRITERIA (как мы будем выбирать)
   
   Вес каждого фактора:
   - Functionality (30%): поддержка нужных платёжных методов
   - Price (25%): комиссии и fees
   - Support (20%): доступность и время отклика
   - Security (15%): compliance и protection
   - Integration (10%): сложность и время

6. PROPOSAL SUBMISSION REQUIREMENTS
   - Максимум 50 страниц
   - Должен включать: краткое резюме, детали по каждому требованию
   - Сроки: proposals до 15.01.2026
   - Demo обязателен для финалистов

7. SELECTION PROCESS
   - Письменные предложения оцениваются (неделя 1-2)
   - Top 3 приглашаются на demo (неделя 3)
   - Reference checks (неделя 4)
   - Final decision и negotiation (неделя 5)

8. CONTACT & QUESTIONS
   - Questions deadline: 10.01.2026
   - Contact: rfp@marketplace.ru
   - Q&A document будет отправлен всем участникам

═══════════════════════════════════════════════════

Фаза 3: Распространение и evaluation (6 недель)

• Отправил RFP 8 провайдерам
• Получил 6 proposal'ов
• Провёл оценку по критериям
• Выбрали 3 финалиста
• Провёл demo с каждым
• Выбрали: Stripe (лучший по всем параметрам, но дороже)

Результат:

• Интеграция заняла 2.5 месяца вместо плана 3
• Комиссии сократились на 20% через переговоры
• System работает stable 2+ года

Case 2: SRS (Software Requirements Specification) для CRM (6 месяцев)

Ситуация: Компания (B2B SaaS) нужна новая CRM. Старая система устарела, staff жалуется.

Что я сделал:

Фаза 1: Выявление требований (2 месяца)

• 30+ интервью со staff
• Наблюдение реальной работы
• Анализ конкурентов (Salesforce, HubSpot, Pipedrive)
• Выявил: 80 функциональных требований

Фаза 2: Структурирование SRS

═══════════════════════════════════════════════════════════════
SRS: Customer Relationship Management System
Версия: 1.0
Дата: 15.03.2026
Автор: Я (System Analyst)
Статус: APPROVED
═══════════════════════════════════════════════════════════════

1. INTRODUCTION
   1.1 Purpose
      Документ описывает функциональные и нефункциональные
      требования для новой CRM системы компании ABC Inc.
   
   1.2 Scope
      Система будет использоваться 50+ сотрудниками
      для управления отношениями с клиентами.
   
   1.3 Intended Audience
      - Product Manager
      - Development Team
      - QA Team
      - Stakeholders
   
   1.4 Document Conventions
      - MUST = обязательно
      - SHOULD = желательно
      - MAY = опционально

2. SYSTEM OVERVIEW
   2.1 Current System Issues
      - Несоответствие между sales и marketing данных
      - Manual data entry (50% времени на это)
      - Нет visibility клиентских interactions
      - Нет reporting capabilities
   
   2.2 Business Objectives
      - Сократить время на data entry на 50%
      - Увеличить sales velocity на 30%
      - Improve customer retention на 25%
      - Enable data-driven decisions
   
   2.3 System Constraints
      - Budget: $100k
      - Timeline: 6 месяцев
      - Team size: 2 разработчика
      - Migration needed from old system

3. FUNCTIONAL REQUIREMENTS
   
   3.1 User Management
      FR-1.1: User authentication
         MUST support email + password login
         MUST support single sign-on (SSO) с Office 365
         MUST enforce password policy (12 chars min)
      
      FR-1.2: Role-based access control
         MUST support roles: Admin, Manager, User, View-only
         MUST restrict access по dept / team
         MUST log all access attempts
   
   3.2 Contact Management
      FR-2.1: Create contact
         MUST capture: name, email, phone, company, title
         MUST validate email format
         MUST prevent duplicates (auto-check)
      
      FR-2.2: Search contacts
         MUST support search по: name, company, email
         MUST support advanced filters
         MUST show results < 500ms
      
      FR-2.3: Contact timeline
         MUST show all interactions с контактом
         MUST support: calls, emails, meetings, notes
         MUST sort по date
   
   3.3 Opportunity Management
      FR-3.1: Create opportunity
         MUST link к contact
         MUST track: status, value, expected close date
         MUST support custom stages (Define → Qualify → Demo → Proposal → Close)
      
      FR-3.2: Sales pipeline
         MUST show opportunities по stage
         MUST calculate: total value per stage
         MUST show forecast
      
      FR-3.3: Activity management
         MUST create tasks automatically
         MUST notify owner при close date approaching
         MUST track completion
   
   3.4 Reporting
      FR-4.1: Sales dashboard
         MUST show: pipeline value, closed deals, conversion rate
         MUST update in real time
         MUST exportable в PDF
      
      FR-4.2: Custom reports
         MUST allow non-technical users создавать reports
         MUST support filters, grouping, sorting
         MUST schedule reports (email daily/weekly)
   
   3.5 Integration
      FR-5.1: Email integration
         MUST sync emails из Outlook / Gmail
         MUST auto-log emails к contacts
         MUST track open/click events
      
      FR-5.2: Calendar sync
         MUST sync meeting appointments
         MUST send meeting summary к CRM
      
      FR-5.3: Slack integration
         MUST send alerts про opportunities
         MUST send daily digest

4. NONFUNCTIONAL REQUIREMENTS
   
   4.1 Performance
      - Page load time: < 2 сек
      - Search response: < 500ms
      - Database query: < 1 сек
      - Support 100 concurrent users
   
   4.2 Availability
      - Uptime: 99.5%
      - Scheduled maintenance: 1x per month, 4 hours
      - Max downtime per month: 3.6 hours
   
   4.3 Security
      - SSL/TLS encryption
      - Password hashed (bcrypt)
      - Audit log for all changes
      - GDPR compliance
      - Data backup: daily, 30 days retention
   
   4.4 Scalability
      - Support growth to 500 users
      - Support 10 million contacts
      - Horizontal scaling capabilities
   
   4.5 Usability
      - Mobile-friendly interface
      - Training materials provided
      - <5 minute onboarding

5. DATA REQUIREMENTS
   5.1 Data Migration
      - From old system: 500k contacts
      - Validation rules для data quality
      - Parallel run на 1 месяц перед cutover

6. ASSUMPTIONS & DEPENDENCIES
   Assumptions:
   - Users have modern browsers
   - Office 365 subscription exists
   - Staff trained before launch
   
   Dependencies:
   - Email server for notifications
   - Active Directory for SSO

7. ACCEPTANCE CRITERIA
   ✓ All FR's tested and working
   ✓ Data migrated successfully
   ✓ Performance tests passed
   ✓ 95% user acceptance in UAT
   ✓ Documentation complete
   ✓ Training completed for all users

8. APPROVAL SIGNATURES
   Product Manager: ________  Date: _______
   CTO: ___________________  Date: _______
   Head of Sales: __________  Date: _______

═══════════════════════════════════════════════════════════════

Фаза 3: Review и refinement (1 месяц)

• Отправил SRS на review stakeholder'ам
• Получил feedback
• Провёл 3 итерации refinement
• Финальное approval: все stakeholder'ы подписали

Фаза 4: Разработка (4 месяца)

• Разработчики использовали SRS как blueprint
• Меньше вопросов, потому что всё было написано
• Система готова к дате

Результат:

• Проект завершился в срок и в бюджет (редко!)
• User satisfaction: 4.5/5
• Staff adoption: 90% через месяц
• ROI: окупилась за 3 месяца

Case 3: Design Document для платёжной системы (3 месяца)

Ситуация: Для требований (SRS) нужно спроектировать техническую реализацию.

Что я сделал:

Фаза 1: Архитектура (3 недели)

• Встреча с CTO и lead разработчиком
• Обсудили варианты:
  • Вариант 1: Synchronous (REST) — проще, но рискнее при сбоях
  • Вариант 2: Asynchronous (Kafka) — сложнее, но надёжнее
  • Вариант 3: Hybrid — best of both
• Выбрали Вариант 3: Hybrid

Фаза 2: Детальный Design Document

═══════════════════════════════════════════════════════════════
Design Document: Payment Processing System
Автор: CTO + I (System Analyst)
Дата: 01.04.2026
Version: 1.0
═══════════════════════════════════════════════════════════════

1. ARCHITECTURE OVERVIEW

Frontend (Client)

         |
         | REST
         v

API Gateway

      /    \

/
Sync Async | | v v Payment Event Service Queue (Kafka) | | +----+----+

       |
       v

DB (PostgreSQL)

2. COMPONENT SPECIFICATIONS

2.1 Payment Service (Synchronous path)
   Language: Python 3.9+
   Framework: FastAPI
   Response time: < 2 sec guaranteed
   
   Endpoints:
   POST /api/v1/payments
     Request: {amount, currency, card_id, customer_id}
     Response: {payment_id, status, timestamp}
     Error handling:
       - 400: Invalid input
       - 402: Payment declined
       - 503: Service unavailable (retry)
   
   Logic:
     1. Validate input
     2. Check customer credit limit
     3. Call external gateway (Stripe)
     4. Log transaction (async)
     5. Return response

2.2 Event Queue (Asynchronous path)
   Technology: Kafka
   Topics:
     - payment.initiated
     - payment.completed
     - payment.failed
   
   Purpose: Decouple payment service from analytics/logging
   Retention: 30 days

2.3 Database Schema
   ```sql

  CREATE TABLE payments (
      id UUID PRIMARY KEY,
      customer_id UUID NOT NULL,
      amount DECIMAL(10,2),
      currency VARCHAR(3),
      status ENUM ('pending', 'completed', 'failed'),
      external_ref VARCHAR(255),
      created_at TIMESTAMPTZ,
      updated_at TIMESTAMPTZ,
      FOREIGN KEY (customer_id) REFERENCES customers(id)
  );
  
  CREATE INDEX idx_customer_id ON payments(customer_id);
  CREATE INDEX idx_created_at ON payments(created_at);

      ```

3. DEPLOYMENT
   Environment: Kubernetes
   Replicas: 3 (for HA)
   Resource limits: 2GB memory, 1 CPU
   Health check: /health endpoint

4. MONITORING
   Metrics:
   - Request latency (p50, p95, p99)
   - Error rate
   - Payment success rate
   - Queue lag (Kafka)
   
   Alerts:
   - Error rate > 1% → critical
   - Response time > 3 sec → warning
   - Queue lag > 1 min → warning

5. SECURITY
   - API key in Authorization header
   - All traffic over HTTPS
   - Rate limiting: 100 req/sec per customer
   - Encrypt sensitive data in transit and at rest

═══════════════════════════════════════════════════════════════

Фаза 3: Validation с разработчиками

• Встреча: провёл с 3 разработчиками
• Обсудили design
• Внесли изменения (например, добавили circuit breaker для external gateway)
• Finalised design

Результат:

• Разработчики писали код без архитектурных вопросов
• Система готова в срок
• Architecture выдержала 10x growth без переделок

Lessons learned за годы

1. Ясность > краткость

• Лучше 50 страниц понятного документа
• Чем 10 страниц неясного
• Потом разработчики не спрашивают "А что имелось в виду?"

2. Диаграммы > текст

• Нарисовать архитектуру в 2 минуты
• Описать словами: 20 минут
• Диаграммы дешевят misunderstandings

3. Итеративный подход

• Не пиши 100 страниц, затем показывай
• Пиши 20, показывай, iterate
• Feedback рано = меньше переделок позже

4. Sign-off обязателен

• Без written approval от stakeholder'ов
• Они потом скажут: "Я не согласен"
• Получи signature перед разработкой

5. Примеры > абстракция

• Вместо: "System shall support payment methods"
• Напиши: "System shall support Visa, Mastercard, ApplePay. Example: customer pays $100 with card XXX..."
• Примеры убирают ambiguity

Best practices для написания запросов

1. Структура

• Используй стандартные шаблоны (RFP, SRS, Design Doc)
• Последовательность: Overview → Details → Appendix
• Numbering system: 1.1, 1.2 для easy reference

2. Язык

• Чётко, без воды
• Используй "MUST", "SHOULD", "MAY" (RFC 2119)
• Избегай "будет", "может быть"

3. Диаграммы

• UML для архитектуры
• Flowcharts для процессов
• Wireframes для UI
• Tables для сравнения

4. Validation

• Показывай draft stakeholder'ам рано
• Получай feedback
• Iterate несколько раз
• Не ревю конечный документ в одиночку

5. Maintenance

• Документ — это живой артефакт
• Обновляй при изменениях
• Версионируй: 1.0 → 1.1 → 2.0
• Трекируй changes (что изменилось и почему)

Вывод

Написание запросов — это 30% моей работы как аналитика. За 10+ лет я выработал подход:

1. Выяви требования (интервью, наблюдение, анализ)
2. Структурируй чётко (используй стандартные шаблоны)
3. Валидируй с stakeholder'ами (feedback loop)
4. Напиши примеры (убери ambiguity)
5. Получи sign-off (written approval)
6. Итерируй (живой документ)

Хороший документ спасает недели разработки и избегает конфликтов. Плохой документ — это боль всем.

Моя метрика успеха: когда разработчики говорят "Спасибо, всё понятно, нет вопросов". Это значит, я написал хорошо.