PrepBro
← Назад к вопросам

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

2.0 Middle🔥 111 комментариев
#Soft Skills и личные качества#Работа со стейкхолдерами

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI26 мар. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

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

Я пережил много отклонений идей. Не все мои предложения были удачны, и это нормально. Вот конкретные примеры, что я из них выучился.

Пример 1: Я предложил переписать всю архитектуру (и мне сказали "нет")

Ситуация

Работал в проекте e-commerce на монолитной архитектуре. Код был сложный, новые фичи добавлялись с трудом.

Я предложил: "Давайте переходим на микросервисы! Это будет:

  • Масштабируемость
  • Независимая разработка команд
  • Легче добавлять новые фичи"

Представил архитектурную диаграмму, план переехда на 6 месяцев, бюджет $200K.

Почему сказали "нет"

CEO:

  • "Монолит работает, клиенты платят"
  • "$200K — это 20% нашей выручки"
  • "6 месяцев — это слишком долго, потеряем время"
  • "Риск: что-то сломаем во время миграции"

CTO:

  • "Не ясно, что будет лучше"
  • "Микросервисы — это добавляет сложность (разделённые БД, сетевые вызовы)"
  • "Сейчас нам хватает монолита"

Как я реагировал

❌ НЕПРАВИЛЬНО: "Вы консервативны, не понимаете современные подходы"

✅ ПРАВИЛЬНО: Я:

  1. Признал их точку зрения: "Вы правы, это рисковано"
  2. Предложил компромисс: "А что если сначала сделаем небольшой эксперимент? API Gateway + один микросервис вместо монолита. За месяц, бюджет $20K, low risk."
  3. Согласился на отложение: "Если это подтвердит, что микросервисы работают, мы сделаем full migration в Q3."
  4. Собрал данные: спросил у 3 компаний, которые перешли на микросервисы, какие были трудности

Результат

Эксперимент: мы вывели Payment Service в отдельный микросервис. Был сложный, но работало.

После этого CEO согласился на фазовый переход:

  • Фаза 1: Orders Service
  • Фаза 2: Products Service
  • И т.д. по одному

Это растянулось на 18 месяцев (вместо 6), но был low-risk и по мере разработки мы учились.

Чему я научился

  • Не предлагай big bang changes
  • Проверь гипотезу маленьким экспериментом
  • Слушай опасения, не спорь с ними

Пример 2: Я предложил отменить фичу (и мне сказали "её нельзя отменять")

Ситуация

В одном проекте был requirement: "Пользователи могут удалять свои комментарии без ограничений."

Одна из фич была: "Если пользователь удалил комментарий, все ответы на него тоже удаляются."

Я заметил: это создаёт проблему. Пользователь пишет комментарий, получает 10 ответов, потом решает удалить комментарий → исчезают 10 других комментариев.

Я предложил: "Давайте не удалять комментарий полностью. Показывать: '[Comment deleted]' вместо исходного текста, но ответы остаются."

Почему сказали "нет"

Product Manager:

  • "Пользователи просили полное удаление"
  • "GDPR требует полного удаления (right to be forgotten)"
  • "Это уже на production, не можем менять"

Как я реагировал

❌ НЕПРАВИЛЬНО: "GDPR не требует удалять ответы других людей!"

✅ ПРАВИЛЬНО: Я:

  1. Спросил у юриста: проверил, правда ли GDPR требует полное удаление
  2. Юрист сказал: "Нет, GDPR требует удалить личные данные. Ответы других людей — это их личные данные, не данные автора."
  3. Показал PM исследование: как другие платформы (Reddit, Medium) это решают
  4. Предложил компромисс: "Добавим опцию: 'Delete with responses' и 'Delete only my text'."

Результат

PM согласился на компромисс. Добавили опцию для пользователей.

После этого:

  • 70% выбирают "Delete only text"
  • 30% выбирают "Delete with responses"
  • Никто не жалуется

Чему я научился

  • Не вернёшь одобренную идею просто так
  • Нужны данные и примеры, не просто мнение
  • Компромисс часто работает лучше, чем полный отказ

Пример 3: Я предложил фичу, которая "никому не нужна" (и я был неправ)

Ситуация

Рабочий в SaaS для управления проектами. Я предложил: "Давайте добавим 'темное меню' (dark mode). Много пользователей просят."

CEO:

  • "Это ни на что не повлияет. Никто не платит больше за dark mode."
  • "Сосредоточимся на功能, которая приносит revenue."

CTO:

  • "Это добавляет сложность: нужно хранить предпочтение юзера, тестировать оба варианта."
  • "Мне это не нужно."

Как я реагировал

❌ НЕПРАВИЛЬНО: "Вы консервативны, moderna ПО всегда имеет dark mode!"

✅ ПРАВИЛЬНО: Я:

  1. Согласился: "Может, я ошибаюсь. Давайте проверим."
  2. Сделал небольшой опрос пользователей (выслал email, спросил про preferences)
  3. Результат: 8% пользователей просили dark mode, но это не был приоритет
  4. Предложил отложить: "Это не критично сейчас. Когда будет свободное время разработчиков, можем добавить."

Результат

Prioritize другие фичи (которые приносили revenue). Dark mode добавили через полгода, когда был свободный sprint для улучшений.

Пользователи были рады, но это не изменило бизнес-метрики.

Чему я научился

  • Мое мнение !== мнение пользователей
  • Проверяй гипотезы, не полагайся на интуицию
  • Nice-to-have может подождать

Пример 4: Я предложил решение, которое было технически невозможно

Ситуация

Проект: мобильное приложение для доставки. Я предложил: "Давайте добавим real-time трекинг курьера на карте. Обновление каждую секунду."

CEO обрадовался: "Отлично! Это повысит trust."

CTO:

  • "Это невозможно"
  • "GPS обновления каждую секунду → батарея истощится за 2 часа"
  • "Real-time обновления на 10,000 пользователей → потребуется WebSocket инфраструктура, очень дорого"

Как я реагировал

❌ НЕПРАВИЛЬНО: "Ты технически неправ, это возможно!"

✅ ПРАВИЛЬНО: Я:

  1. Спросил CTO: "А что возможно?"
  2. CTO: "Мы можем обновлять каждые 30 секунд. Это даст хороший баланс: батарея OK, сеть OK, UX OK."
  3. Согласился: "30 секунд подойдёт. Это лучше, чем вообще не обновлять."

Результат

Реализовали: обновление каждые 30 секунд. Пользователи видят примерную позицию курьера, этого достаточно.

Потребляемость батареи: нормальная, пользователи не жалуются.

Чему я научился

  • Я не инженер, я не знаю, что технически возможно
  • Нужно слушать CTO, а не предлагать "так должно быть"
  • Компромисс часто лучше, чем ideal solution

Пример 5: Я предложил фичу "для будущего", которая не нужна сейчас

Ситуация

На планировании I предложил: "Давайте построим систему управления версиями документов. Потом нам это понадобится."

PM:

  • "Нам это нужно сейчас? Нет."
  • "Это 'золотой предмет' — nice-to-have, не critical."
  • "Давайте сосредоточимся на том, что нужно СЕЙЧАС."

Как я реагировал

❌ НЕПРАВИЛЬНО: "Лучше сделать сейчас, потом будет поздно! Это будет architekturally困难!"

✅ ПРАВИЛЬНО: Я:

  1. Спросил себя: "Когда нам это ДЕЙСТВИТЕЛЬНО понадобится?"
  2. Ответ: "Может быть, через год. Может быть, никогда."
  3. Согласился: "Вы правы, сосредоточимся на критичном."
  4. Позже: когда понадобилось, мы добавили версионирование (потребовало 1 спринт)

Чему я научился

  • YAGNI: You Aren't Gonna Need It
  • Лучше добавить потом, чем сейчас впустую
  • Архитектура может быть гибкой для расширения

Как я использую опыт отклонений

1. Я слушаю критику

Когда идею отклоняют, я спрашиваю "почему?" Часто скрывается хорошая причина.

2. Я не защищаю идею агрессивно

Это не моя идея, это идея для проекта. Если она не подходит — отпускаю.

3. Я собираю данные перед предложением

Не "я думаю, что нужно это", а "я опросил 30 пользователей, 60% просили это".

4. Я предлагаю малые эксперименты

Вместо "давайте переделаем всё", я предлагаю "давайте проверим на 10% пользователей".

5. Я иду к нужному человеку

Для технических идей — сначала CTO. Для бизнес-идей — сначала PM. Для архитектуры — CTO.

Вывод

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

  • Я предлагаю идеи (это хорошо)
  • Я сталкиваюсь с реальностью (бюджет, технология, приоритеты)
  • Я учусь на отказах
  • Я становлюсь лучше в предложении идей

Самые успешные BA — это те, кто много предложили идей, много из них отклонили, но научились делать это правильно.