Команды продукта и разработчики часто сталкиваются с трудностями из-за различных интерпретаций приоритетов, ограничений и метрик успеха, а не из-за несогласий с конечной целью. Это трение встречается во многих организациях, что приводит к восприятию сопротивления или постоянных изменений. Решения включают в себя содействие общему пониманию, ясности решений и взаимной ответственности, а не просто добавление больше встреч или инструментов.Ключевые сбои происходят, когда у команд разные метрики успеха, такие как фокус менеджеров продукта на бизнес-результаты и фокус разработчиков на техническую стабильность. Требования часто передаются слишком поздно, а инженеры привлекаются только после того, как были сделаны значительные предположения. Чрезмерные передачи в псевдо-каскадном подходе также порождают недоразумения и переделку.Чтобы улучшить сотрудничество, инженеры должны быть вовлечены на ранней стадии определения проблемы, представляя проблемы клиентов, а не предопределенные решения. Совместные сессии по открытию с ключевыми заинтересованными сторонами помогают выявить предположения до начала разработки. Создание общих метрик успеха, таких как принятие клиентов и время до получения ценности, поощряет совместное решение проблем.Общение должно отдавать приоритет качеству над количеством, заменяя обширные документы обсуждениями и поддерживая журналы решений, чтобы сохранить контекст. Сокращение ненужных статусных встреч и фокус на асинхронных обновлениях, где это возможно, также полезно. Ясные границы собственности, при которых команды продукта владеют проблемами клиентов, а инженерия владеет технической реализацией, а также разделяют ответственность за результаты, являются важными.Отличные партнерства между продуктом и инженерией выравниваются вокруг влияния на клиента, задавая вопрос, что создает наибольшую ценность для пользователя. Предоставление инженерам обратной связи клиентов и аналитики дает необходимый контекст для принятия решений. Организации часто ошибочно рассматривают сотрудничество как проблему мягких навыков, слишком сильно полагаются на agile-церемонии или неправильно измеряют производительность.Инициативы по сотрудничеству терпят неудачу, когда поведение руководства не меняется, стимулы остаются несоответствующими или доверие игнорируется. Практическая основа включает в себя совместное открытие, совместное планирование, непрерывную коммуникацию при доставке и обзор результатов. В конечном итоге, сильное сотрудничество возникает из общего контекста, целей, стимулов и ответственности, рассматривая его как бизнес-возможность, а не просто как задачу коммуникации.