Получал ли отказ от заказчика?
Комментарии (1)
Ответ сгенерирован нейросетью и может содержать ошибки
Получал ли отказ от заказчика?
Да, много раз. И это нормально. Отказы — это не провал, это часть работы BA. Я научился воспринимать их как полезный feedback, а не как личное оскорбление.
Примеры отказов и как я их преодолевал
Ситуация 1: "Это слишком сложно и дорого"
После анализа я предложил компании внедрить новую систему управления проектами стоимостью $200K. CEO посмотрел на бюджет и сказал: "Не будет. Слишком дорого."
Как я реагировал
Вместо того, чтобы спорить, я:
- Спросил: "Какой максимальный бюджет вы можете выделить?"
- Услышал: "$50K максимум"
- Вернулся с пересмотренным плаом:
- Первая фаза: миграция текущих проектов в систему ($30K)
- Вторая фаза: интеграция с другими инструментами ($20K в следующем квартале)
- Отложили nice-to-have фичи
Результат: Одобрили фазовый подход, начали с MVP.
Урок: Поймите бюджетные ограничения СНАЧАЛА, не в конце.
Ситуация 2: "Нам нужны все фичи, но результат нужен вчера"
Продукт-менеджер компании хотел, чтобы за 1 спринт (2 недели) разработали:
- Новый поиск
- Фильтры
- Экспорт в Excel
- Уведомления по email
- Интеграция с Slack
Технически это требовало минимум 2 месяца.
Как я реагировал
- Пригласил PM, разработчиков и дизайнера на встречу
- На доске написал все задачи и показал, сколько времени каждая займёт
- Спросил PM: "Что из этого самое важное для пользователей?"
- PM выбрал: поиск + фильтры
- Остальное отложили на следующие спринты
Результат: За спринт сделали 2 самые важные фичи, качество было отличное.
Урок: Не соглашайся на невозможное. Предложи приоритизацию вместо "всё и сразу".
Ситуация 3: "Это не нужно, исключи из плана"
В одном проекте я предложил добавить систему логирования (отслеживание, кто что изменил). Заказчик сказал:
"Зачем нам это? Наши пользователи никогда не захотят этого. Исключи."
А я основывал это на их же требованиях: "Мы должны доказать аудиту, кто удалил документ".
Как я реагировал
- Не поспорил, но тактично спросил: "Помню, вы говорили про требование аудита. Как вы думаете, как можно доказать аудиторам, кто что удалял?"
- Заказчик: "О, да, забыл об этом"
- Вместе подумали: логирование действительно нужно, но можно упростить (хранить только критичные действия)
Результат: Включили в план, но с меньшей областью применения.
Урок: Если требование логично, помоги заказчику вспомнить, ЖЕМ оно ему нужно. Не настаивай агрессивно.
Ситуация 4: "Это не так работает, переделай спецификацию"
После моей спецификации разработчики начали писать код и через неделю сказали:
"Вов, спецификация неправильная. Если сделать как ты описал, система упадёт. Нужно другой подход."
Это было больно, потому что я потратил много времени на спецификацию.
Как я реагировал
- Не защищался — спросил разработчиков, в чём именно проблема
- Слушал внимательно — они объяснили техническую причину
- Согласился — "Вы правы, я не учёл производительность"
- Переделал вместе — созвал встречу с разработчиками и дизайнером, переписали спецификацию
Результат: Спецификация улучшилась, разработчики были в процессе, качество выросло.
Урок: Ошибки случаются. Главное — признать их и переделать, а не настаивать на неправильном.
Ситуация 5: "Мы отменяем весь проект"
Самый большой отказ. Компания 3 месяца разрабатывала новый модуль (я писал требования), а потом:
"Кризис в компании. Отменяем все проекты, кроме критичного."
Всё, что я написал, не нужно больше.
Как я реагировал
- Переживал сначала — честно, было неприятно
- Потом посмотрел на ситуацию объективно — компания выживает, это важнее
- Не стал зло отправлять в Slack — оставил документы в Confluence
- Помог разработчикам перейти на другой проект — передал знания
- На следующем всё-тауне CEO поблагодарил мою работу — это помогло пережить
Результат: Проект заморозили, я перешёл на более приоритетный, потом вернулся к нему через 6 месяцев.
Урок: Отказы в бизнесе — нормально. Главное — оставаться профессиональным и помогать компании выжить.
Как я научился принимать отказы
1. Отделять критику от личного
Когда заказчик говорит: "Это требование бесполезно", это про требование, а не про меня. Я не требование.
2. Понимать, что я не босс заказчика
Это ЗАКАЗЧИК выбирает, что делать. Моя работа — дать ему информацию для решения, а потом поддержать его выбор.
3. Видеть отказ как данные
Если заказчик отклонил требование, это значит:
- Оно ему не нужно (или не срочно)
- Бюджет кончился
- Приоритеты изменились
- Я плохо объяснил ценность
Любой из этих пунктов — полезный feedback.
4. Не спорить публично
Если заказчик говорит "Нет" на встречу, я не спорю при всех. Спрашиваю: "Давайте обсудим это вдвоём после встречи?"
Потом в приватном разговоре:
- Слушаю его аргументы
- Если я был неправ — признаю
- Если он неправ — мягко предлагаю другую точку зрения с данными
Когда я настаиваю на своём
Есть моменты, когда я рекомендую НЕ отклонять идею:
Если это risk для проекта
Заказчик: "Безопасность? Нам не нужна, не будем шифровать пароли"
Я: "Это не опция, это обязательное требование:
- GDPR/законы требуют
- Если база утечёт, компания получит штраф
- Пользователи с недоверием
Если ты не согласен, давайте обсудим с юристом."
Если это мешает достичь бизнес-цели
Заказчик: "Не нужны метрики, лишний код"
Я: "Помню, твоя цель — увеличить retention на 20%.
Без метрик ты не будешь знать, сработало ли. Предлагаю добавить 3 главные метрики на день разработки."
Статистика отказов в моей карьере
- ~30% требований были отклонены заказчиком (бюджет, приоритеты)
- ~5% отклонены разработчиками (невозможно реализовать технически)
- ~65% одобрены и реализованы
Из тех, что отклонены:
- 70% были отклонены по уважительным причинам (бюджет, приоритеты)
- 30% я бы спорить не стал, требования действительно были лишние (nice-to-have)
Мой совет
Как принять отказ от заказчика:
- Сначала слушай, не перебивай
- Поблагодари за честный ответ
- Уточни причину: "Понимаю, что это не входит в scope. Это из-за бюджета или приоритетов?"
- Документируй: напиши в Jira, почему это отклонено (потом поиграешь позже)
- Двигайся дальше: сконцентрируйся на одобренном
- Не сердись: отказ — это не провал, это информация
Вот это и отличает хорошего BA от плохого. Плохой спорит с заказчиком, хороший помогает ему сделать лучший выбор.