Приведи пример кейса с недочётами с прошлого проекта

Кейс с недочётами: как я его пропустил и чему научился

Это честный рассказ о проекте, где я допустил ошибки.

Проект: CRM система для sales команды (40 человек)

Контекст:

• Компания выросла с 5 до 40 sales reps
• Нужна была система управления deals
• Бюджет: 80K, срок: 4 месяца
• Я был BA и главным аналитиком

Что я пропустил

Ошибка 1: Не разговаривал с end-users напрямую

Ошибка была в процессе:

• Я встречался с Sales Manager и Product Owner
• Но не говорил напрямую с sales reps
• Думал, что manager расскажет все требования

Результат:

• Разработали систему по требованиям manager
• Sales team её ненавидела
• Потеря 20% реального context

Примеры:

• Нужно поле next action date
• Нужен быстрый экспорт в Excel
• Нужен калькулятор комиссии

Эти требования вышли только когда я спросил непосредственно.

Ошибка 2: Не определил Acceptance Criteria

Я писал requirements слишком кратко:

US-1: User can create a deal
- Form has fields: name, amount, stage
- Validation: amount > 0

Но не определил:

• Какие value ranges для amount?
• Какие stages доступны?
• Может ли редактировать deal после создания?
• Кто видит чужие deals?

Результат:

• Разработчики сделали минимум
• Переделки и frustration

Ошибка 3: Не провел pilot/UAT

Процесс был Waterfall: Requirements → Design → Dev → QA → Deploy

Но я забыл про user acceptance phase.

Результат:

• 10 ошибок обнаружены за неделю в production
• Срочные hotfixes
• Потеря доверия

Ошибка 4: Не документировал решения

Всё держал в голове. Через месяц забыл причины. Новый аналитик спросил почему 4 stages а не 5. Я не помнил.

Результат:

• Сложно поддерживать
• Долгий onboarding новых разработчиков

Ошибка 5: Не согласовал scalability

Не спросил: "А через год?"

• На момент: 40 reps, 1000 deals
• Через полгода: 80 reps, 5000 deals
• Система начала медленно работать
• Нужны были индексы и оптимизации

Результат:

• Extra budget
• Extra time
• Система должна была быть готова изначально

Как я это исправил

1. Правило: Talk to end-users directly

Теперь я:

• Провожу интервью с end-users
• Наблюдаю как они работают
• Спрашиваю что раздражает

2. Обязательный Detailed Acceptance Criteria

Теперь требование полное:

US-1: User can create a deal

• Форма с полями: name, amount, stage, expected_close_date
• Amount validation: Min 100, Max 10M, decimal до 2 знаков
• Stage dropdown: Prospecting, Proposal, Negotiation, Closed Won
• Date picker для expected_close_date
• Deal редактируемый creator и admin
• Только creator и admin могут удалять
• Rep видит свои и team deals
• Подтверждение после создания
• Deal виден в списке сразу

Это занимает 10 мин больше, но спасает неделю переделок.

3. Обязательный UAT phase

Теперь процесс: Requirements → Design → Dev → QA → Pilot (5 users, 1 неделя) → Feedback → Fixes → Deploy

Проблемы находятся до production.

4. Документирование решений

Теперь для каждого требования wiki-страница:

Title: Deal Creation Logic Author: [me]

Decision: Deal has 4 fixed stages Rationale: sales team uses standard methodology, more stages = confusion Alternatives: Custom stages (rejected), 6 stages (rejected) Implementation: Fixed enum in DB

5. Требование к scalability в requirements

Теперь спрашиваю:

• Сколько users через год? 5 лет?
• Сколько records?
• Какая пиковая нагрузка?

и документирую как Non-Functional Requirements:

Scalability:

• Support 500+ concurrent users
• Handle 100K+ deals
• Response time < 2 sec
• Page load time < 3 sec

Performance:

• Index on deal.created_date и deal.stage
• Paginate list (default 50 items)
• Cache team list

Что я извлёк из ошибок

1. Слушай end-users напрямую

• Managers видят высокоуровневую картину
• End-users видят детали
• Обе перспективы нужны

2. Пиши детальные acceptance criteria

• Экономит время на переделки
• Разработчик чётко знает что нужно

3. Проводи UAT

• Находи проблемы рано
• Пользователи чувствуют себя услышанными
• Падает количество bug reports

4. Документируй решения

• Помогает новым людям
• Помогает тебе через 6 месяцев
• Показывает почему выбрано то или иное

5. Планируй на рост

• Не только на текущие нужды
• На год вперёд
• Non-functional requirements должны это отражать

Вывод

Хороший BA не только делает процесс правильно, но и учится на ошибках. Этот CRM проект был болезненным, но научил меня правильно анализировать, слушать end-users, документировать и проводить UAT.

Теперь я этот опыт транслирую другим аналитикам - они избегают таких же ошибок.