Как относишься к взаимодействию с заказчиком без посредников

# Взаимодействие с заказчиком без посредников

Прямое общение с заказчиком - это обоюдоострый меч. Если его правильно использовать, получится лучше понять требования и создать лучший продукт. Если нет - возникнут конфликты и путаница в процессе.

Моя позиция

Я положительно отношусь к взаимодействию с заказчиком, но с условиями и границами:

✅ Что я поддерживаю

1. Быстрое уточнение требований

Прямой контакт экономит время:
- Нет телефонной игры "испорченный телефон"
- Сразу видно что нужно заказчику
- Можно показать прототип и получить мгновенный feedback

Пример:
Я: "Верно я понимаю - фильтр должен работать по 3 критериям?"
Заказчик: "Да, но также по цене в диапазоне"
Проблема выявлена за 5 минут, а не через неделю на demo

2. Понимание бизнес-контекста

Общение с заказчиком помогает понять:
- Почему нужна именно эта функция
- Какие боли она решает
- Какие граничные случаи важны
- Что действительно критично

Это делает разработку умнее и быстрее

3. Раннее выявление проблем

Если я вижу что требование нереализуемо или нецелесообразно:
- Лучше сказать это прямому заказчику
- Чем разработать неправильно
- Или потом переделывать

Пример:
"Вы хотите получать результаты за 0.1 сек с 10 млн записей?
 Это невозможно с текущей БД. Давайте рассмотрим альтернативы:..."

4. Построение доверия

Прямое общение показывает:
- Я ответственен за результат
- Я понимаю проблему
- Я сам могу объяснить процесс

❌ Что я не поддерживаю

1. Обход процесса / PM роли

❌ НЕПРАВИЛЬНО:
Заказчик: "Давайте сразу переделаем feature X в Y"
Я: "Окей, делаю сейчас"

✅ ПРАВИЛЬНО:
Я: "Хорошая идея. Давайте обсудим с PM/lead,
       как это влияет на план спринта и другие задачи"

Причина:
- Без планирования получится chaos
- Другие разработчики не будут знать о изменениях
- Потеряется context для команды

2. Scope creep

❌ НЕПРАВИЛЬНО:
Заказчик: "Пока разрабатываешь, добавь еще..."
Я: "Окей"
[Потом 100 мелких фич, сроки сорваны]

✅ ПРАВИЛЬНО:
Я: "Интересная идея, но сейчас у меня задача X.
     Давайте это добавим в следующий спринт с оценкой"

3. Выступление от имени команды

❌ НЕПРАВИЛЬНО:
Заказчик спрашивает сроки
Я: "Мы сделаем за неделю"
[Потом коллеги узнают что их вовлекли в обещание]

✅ ПРАВИЛЬНО:
Я: "Я дам оценку для нашей команды и свяжусь с вами"
[Согласую с коллегами, потом даю честный ответ]

Правила эффективного общения

1. Проясни структуру общения

Перед началом работы:
"Есть ли расписанный процесс как вы общаетесь с разработчиками?
- Есть ли PM/product manager?
- Кто приоритизирует задачи?
- Я общаюсь напрямую с вами или через PM?"

Это избежит путаницы позже

2. Документируй договоренности

После каждого обсуждения:
- Отправь письмо с выводами
- Ссылка на created/updated issue
- Согласование с PM если нужно
- "Верно я понимаю что...?"

Значит потом все помнят то же самое

3. Установи часы/каналы общения

✅ ХОРОШЕЕ РЕШЕНИЕ:
"Я доступен для вопросов:
- Пятница 14:00-15:00 для встреч
- Slack для срочных вопросов
- Email для документированного общения"

Тогда твоя фокусировка не страдает

4. Говори честно о сложностях

❌ НЕПРАВИЛЬНО:
Заказчик: "Это просто, да?"
Я (улыбаясь): "Конечно"
[Потом 3 недели отсутствия в chat]

✅ ПРАВИЛЬНО:
"Технически это возможно, но требует:
- Переписать часть архитектуры БД
- Оптимизировать запросы
- Примерно 3-4 дня работы

Исторически такие задачи часто имеют неожиданные сложности.
Можно ли выделить буфер времени?"

5. Знай когда сказать "нет"

Примеры когда нужно отказать:

1. Требование идет в разрез с архитектурой
   "Это затронет 50 мест в коде, создаст technical debt"

2. Сроки нереалистичны
   "Лучше неделя и качество, чем 2 дня и баги"

3. Это не входит в текущую область ответственности
   "Это должен решить QA/DevOps/PM"

4. Это требует согласования с командой
   "Мне нужно обсудить с архитектором, это влияет на..."

Граница ответственности

Что я РЕШАЮ САМОСТОЯТЕЛЬНО:
- Как технически реализовать требование
- Какие подходы есть (и их плюсы/минусы)
- Сроки на основе сложности
- Вопросы по уточнению требования

Что обсуждаю с PM/lead:
- Новые требования (меняют план)
- Приоритизация (что сначала)
- Конфликты интересов
- Масштабные изменения
- Предложения оптимизации (если заказчик согласен)

Что сообщаю заказчику:
- Статус текущей работы
- Готов ли результат
- Есть ли вопросы по требованиям
- Предложения по улучшению (через PM)

Пример хорошего взаимодействия

День 1:
Заказчик: "Нужна функция экспорта в PDF"
Я: "Интересно. Какие данные экспортировать? С какой страницы?"
[Уточнение в чате, PM видит conversation]

День 2:
Я на PM: "Заказчик хочет PDF экспорт. По моей оценке - 3 дня.
          Как это влияет на план?"
PM: "ОК, добавляю в спринт"

День 3-5:
[Разработка]

День 5:
Я заказчику: "Функция готова, вот тестовый link"
Заказчик: "Отлично! Но можно ли добавить логотип?"
Я: "Да, это просто. Пришли логотип и готово"

День 6:
[Финально готово]

Все довольны потому что:
- Требования были ясны
- Сроки соблюдены
- Честное общение
- Структурированный процесс

Когда прямое общение NOT рекомендуется

❌ Избегай прямого общения если:
- Заказчик очень "вспыльчив" (всё через посредника)
- Много мелких вопросов в день (договори office hours)
- Требования нестабильные (нужен PM как буфер)
- Ты не уверен в своем техническом решении
  (сначала обсуди с lead)

Итоговая позиция

✅ Прямое общение - ДА, но с условиями:
✅ Должна быть структура (PM, процесс)
✅ Честность о сложностях
✅ Документирование договоренностей
✅ Знание границ ответственности
✅ Готовность сказать "нет"

✅ Результат: быстрее, качественнее, заказчик доволен

Вывод: я профессионал, а не исполнитель. Могу говорить с заказчиком как равный партнер, но в рамках процесса и добросовестно.