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

Хочется написать, что налаженная коммуникация это когда бизнес-заказчик не просто говорит: «Я хочу…» (табличку, выгрузку, дизайн, новую фичу), а дает контекст, в который вписана задача, сверяется по срокам и возможностям и желательно делает это вежливо. Но в реальности все сложнее.

Полгода назад один реально хороший заказчик позвал меня на встречу, чтобы подробно объяснить, зачем считать показатели из задачи. Обычно я это ценю. Но в этот раз проект был не мой, требовалось быстро сделать разовые расчеты и вернуться к более приоритетным делам. Погружение было излишним.

Поэтому бывают ситуации, когда задачу можно решить и без долгих объяснений. Бывают специалисты, которые хотят работать только с технической частью. Иногда на передачу контекста нет времени и надо «сделать по-быстрому». Про сроки тоже не всегда обязательно спрашивать: если задача типовая, уже есть опытное понимание, сколько она занимает. Даже излишняя вежливость не всегда к месту: иногда она воспринимается с подозрением.

И в то же время есть задачи, где без контекста никак. Там важно либо дать его до начала работы, либо дать его уже после, чтобы человек вписал задачу во внутреннюю «базу знаний». Чаще всего нужно уточнять ограничения и попросить вежливо. Простое «пожалуйста» и «спасибо», по опыту, ускоряет многие процессы.

Но мне кажется, налаженная коммуникация появляется там, где изначально совпадают ролевые ожидания. Например, продукт‑оунер даёт бизнес‑контекст только лиду разработки, а остальная команда получает технический контекст уже от лида. Про неожиданные ограничения сообщают, когда они возникают. Работа работается, и никто не перегружен лишней информацией.

Или наоборот: команда интересуется и переживает за продукт, а оунер/лид считает важным делиться контекстом и спрашивать мнение команды. Здесь уже предполагается больше горизонтальных обсуждений и всем ок.

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

А неуспешные продукты, в моем опыте, чаще всего рождались там, где: -Решения сверху навязывались в темах, которые требовали обсуждения и долгого сбора информации от разных участников -А там, где кому‑то одному можно было принять решение и запуститься, наоборот, происходили бесконечные совещания

И всё это случалось при попытках «правильного» соблюдения фреймворка.