Приведи пример ответственной задачи, с которой справился

Пример: Спасение запускаемого проекта через аналитику и переговоры

Контекст: Критическая ситуация

Это произошло в стартапе e-commerce платформе. Компания запускала новый мобильный приложение (MVP), инвестировала 500K в разработку, квартал разработки был завершен, и вот...

За 2 дня до запуска на App Store PM внезапно предложил "маленькие улучшения":

• Изменить цвет кнопки (3 часа)
• Добавить новое поле в профиль (5 часов)
• "Оптимизировать" алгоритм рекомендаций (неизвестное время)
• Перевести на новый API (20+ часов)
• Переделать навигацию (40+ часов)

Всё это должно было быть готово к запуску. Разработчики возмущены, CTO в панике, сроки рушатся.

Моя роль: BA, который должен был бежать за PM, кричать разработчикам и надеяться на чудо. Но я поступил иначе.

Фаза 1: Диагностика (30 минут)

Вместо паники я сделал простой анализ:

Вопросы к PM:

1. "На чём основаны эти требования? Есть ли данные?"
2. "Сколько пользователей это коснётся?"
3. "Это критично для launch или может быть в v1.1?"

Вопросы к CTO:

1. "Сколько часов на каждое требование?"
2. "Какое из них точно сломает приложение, если не сделать?"
3. "Что мы можем отложить без потери качества?"

Результаты (цифры):

• Изменение цвета: косметика, не влияет на функцию
• Новое поле профиля: хотел PM, но не просило ни одного пользователя
• Оптимизация алгоритма: это не задача для MVP, это тесты без данных
• Новый API: 20 часов, но текущий API работает хорошо
• Навигация: это было обсуждено 3 недели назад и одобрено

Сумма: 68+ часов работы в последний день перед запуском. Невозможно.

Фаза 2: Определение критичности (1 час)

Я создал таблицу для каждого требования:

Требование | Часов | Пользователей | Must-have | Почему
───────────────────────────────────────────────────────────
Цвет кнопки | 3 | 100% | НЕТ | Косметика, не влияет на UX
Поле профиля | 5 | 0% | НЕТ | Никто не просил, в v1.1
Алгоритм | ? | 50% | НЕТ | Работает, можно A/B тест после
Новый API | 20 | 0% | НЕТ | Текущий работает, рефакторинг
Навигация | 40 | 100% | МОЖЕТ | Была одобрена неделю назад

Вывод: 58 часов требований, которые МОГУТ подождать до v1.1.

Фаза 3: Ударные переговоры (2 часа)

Теперь я имел данные. Я пришел на встречу с:

• Таблицей выше
• Вероятностью успеха launch с каждым сценарием
• Риском каждого требования

Мой аргумент PM:

ПМ: "Это маленькие правки, давайте быстро"

Я: "Посмотри: это 68 часов. У нас 16 часов разработки до запуска.
Это три сценария:

1. Делаем всё: запуск отложится на неделю, конкуренты запустят раньше
2. Делаем спешно: запустим с багами, риск crash, плохой первый рейтинг
3. Отложим косметику: запустим в срок, качественно, потом добавим улучшения

Какой выбираешь?"

PM задумалась. Она видела данные, а не эмоции.

Мой аргумент CTO:

Я: "Давайте определим: какой риск сломает launch?"

CTO: "Если алгоритм рекомендаций упадёт или новая навигация сломается"

Я: "Алгоритм работает (68% пользователей используют), навигация была
одобрена неделю назад и уже протестирована. Риск минимален.
Остальное (цвет, поле профиля, рефакторинг) — это want-to-have, не need-to-have.

Согласен отложить 5 требований и запустить?" 

CTO согласилась. Она видела, что риск управляемый.

Фаза 4: Документирование решения (30 минут)

Я создал документ, который озвучили на встречу лидерству:

📱 Mobile App Launch: Requirements Decision Log

Дата: 2024-XX-XX
Статус: APPROVED

Для launch v1.0 включили:
- Базовая функциональность (checkout, профиль, поиск)
- Навигация (одобрена PM на прошлой неделе)
- Алгоритм рекомендаций (текущая версия работает)

Отложили на v1.1:
- Цвет кнопки (косметика)
- Новое поле профиля (не просили пользователи)
- Оптимизация API (рефакторинг, текущий работает)
- Оптимизация алгоритма (нужны данные от реальных пользователей)

Риск: МИНИМАЛЬНЫЙ (основная функция протестирована и готова)
Выгода: запуск в срок, качественный первый impression

PM согласна: ДА
CTO согласен: ДА
CEO согласен: ДА

Все подписали. Никто не может потом сказать "но я просил другое".

Результат: Успех

День запуска:

• Приложение вышло в App Store в запланированную дату ✓
• Качество высокое, рейтинг 4.7* в первый день ✓
• Никаких критических багов ✓

После запуска:

• За первую неделю 50K downloads
• v1.1 вышло через 3 дня с отложенными требованиями
• PM видела реальные данные пользователей и приоритизировала правильно
• Инвесторы увидели успешный launch

Почему я справился с этой задачей

1. Не паниковал

Легко было кричать "это невозможно!" и ждать чуда.
Вместо этого я проанализировал проблему → нашел решение.

2. Перевел в цифры

"Маленькие правки" → 68 часов кода
Эмоция (PM хочет) → факт (пользователи не просили)

3. Предложил варианты, не решение

Я не сказал: "Это невозможно".
Я сказал: "У нас есть 3 варианта, плюсы и минусы каждого. Вы выбираете".

Лидерству легче выбрать из вариантов, чем решить конфликт.

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

Это не просто обсуждение. Это письменное решение с подписями.
Так никто не может потом пожалеть.

5. Признал чужую экспертизу

Я не технолог, поэтому спросил CTO о рисках.
Я не маркетолог, поэтому спросил PM о бизнес-целях.
Я собрал их input и синтезировал в решение.

Lessons Learned (мой вывод)

Эта задача показала мне, что BA — это не писарь требований. Это интегратор. Мы стоим на пересечении:

• Бизнеса (PM, CEO) — они хотят функцию
• Технологии (CTO, Dev) — они говорят это сложно
• Пользователей (данные, analytics) — они показывают реальность

Добрый BA берет информацию из всех трёх источников, анализирует и предлагает решение, которое хорошо для всех.

Это не просто ответственная задача. Это задача, которая научила меня основной навык профессии: управление неопределённостью через данные и коммуникацию.