Как ответить
Коммуникация с байингом была выстроена через единую точку входа — продакт-менеджера, который работал на стыке команды разработки и отдела закупок. Я как разработчик напрямую с байерами не общался, вся предметная область шла через продакта. Но были исключения — когда байеру требовалась техническая консультация по интеграции с нашим API.
Основной канал — еженедельный синк в 30 минут, где продакт собирал от байеров приоритеты и проблемы, а мы — технические ограничения и сроки. Критические вопросы решались в чате (Slack), где байеры писали напрямую в канал команды. Там работало правило: если вопрос не решается за 5 минут — заводится задача в Jira с тегом buying.
Была проблема: байеры часто путали баги и фичи. Например, говорили «не работает фильтр», хотя на самом деле фильтр не поддерживал их сценарий — такую задачу надо было вести как доработку. Чтобы снизить шум, мы добавили в форму обращения чекбокс «это баг или хотелка?» и привязали к ней шаблон описания. Это сократило количество переоткрытых задач на 30% за квартал.
Ещё один кейс: байеры запрашивали фичу «загрузить прайс-лист Excel», а в реальности им нужна была автоматическая синхронизация с их ERP. Мы потратили две недели на прототип, который никто не использовал. После этого ввели правило: перед стартом разработки продакт готовит спецификацию в формате user story и проводит её ревью с байером — буквально читает ему вслух. Это выявило несоответствие ожиданий в 40% случаев.
Что касается SLA: баги уровня «упал прод» фиксились за 2 часа, запросы на доработки попадали в бэклог и оценивались на следующем планировании. Критические для байинга задачи (например, срыв поставки из-за ошибки в системе) мы брали вне очереди — для этого был отдельный канал в Slack с алертами.