А зачем для этого OpenApi? Есть куча более удобных методов договориться, которые ребята и используют. Ключевое - договориться.

Сверяются то в техдизйне, а не в реализации. Это обычно еще до описания api делается

Здесь бэкера дважды проверяют) Зачем?

В каком месте дважды?

> отправляет фронту на проверку
> потом я смотрю сверху

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

А не проще вместе сесть за одним столом?

Присоединяюсь к вопросу

А потом кто-то уже по результату опишет тех-задание

Дольше и требует синхронизации и выхода из потока. Иногда нужно и созвониться, но далеко не всегда.

Асинхронные взаимодействия обычно эффективнее в процессах

Я думал как раз теряется время на передачи тех-задания из рук в руки) Остальное +.

А если бойцы вместо севера на юг поплыли?

По опыту - не теряется. Если есть вопросы - то спишутся

Совсем не то сделали, что требовалось. Поняли так

я просто мимо проходил но
"в процессе решения выяснилось что" - это нужно минимизиовать всяческим образом, и выяснять детали до начала разработки - подозреваю что речь идет о новом функционале, значит нужно было на стадии технического дизайна фичи обговаривать решение, определять модели взаимодействия. Подозреваю что момент технического дизайна прошел не совсем корректно
"В результате на фронте и бэке несовместимые API" - это так же следует из первого пункта + описание тех контрактов по которым фронт и бэк будет взаимодействовать, даже если бы бекенд по каким-то причинам мог что-то упустить оно бы всплыло на этом этапе, когда фронт спросил бы а где вот этот эндпоинт, на что бэк бы округили глаза и спросил какой эндпоинт? ну и дальше уже оно бы появилось на уровне контракта и набора задач
"При этом все это сопровождалось диким колличеством обсуждений" - встреча должна приводить к результату, вопрос в качестве проведения встреч а не в их количестве - для этого тоже ряд практик есть, как плохих так и хороших. Но если встреча не приводит ни к чему - процесс проведения встреч вероятно не работает

недеюсь что если я где-то наврал, меня поправят

Вот потому я и приглядываю. Иногда и продакт смотрит, если сложный момент. Но так как код еще не писали, то переделать не сложно.

Спасибо, все по делу) Конечно все это рецепты, надо учиться системному мышлению)

Ну, много разных рецептов расширяют сознание, это тоже полезно.

Анатолий Левенчук - Системное мышление. Кто читал, с нее начинать стоит, или что порекомендуете другое?)