+ телефоны служб мосгаза, пожарных и скорой  на холодильнике

ну вот, в общем случае разработчик таким "мужем" и является, так как не знает всей последовательности операций в процессе между входом и выходом. Но вот спустя n итераций при работе с одним и тем же процессом, уже можно ограничиться только конечными и/или начальными требованиями, так как "муж" станет опытным в "варке борща".

Всем привет) Кто-нибудь работал с GrafQL? Как ощущения? Описание методов сильно отличается от Rest?

Вооот!

И это еще тут почти ничего нет про правую часть, после производства — зачем вообще борщ, что с транспортировкой, хранением, потреблением, утилизацией

вот так традиционно исполнитель получает постановку без понимания, зачем)

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

в моём опыте исполнителю чаще всего и не особенно интересно было, зачем

контекста действительно не хватает. я при выборе вариантов исходил из представления, что исполнитель не знает, что такое борщ, но умеет пользоваться библиотеками "нарезать овощи" и "вскипятить воду"

Так тут же аналитики, надо ширше смотреть. Но если аналитик системный, за него бизнес мог подумать и дергать зачем и почему на каждую задачу чревато.

Зависит от исполнителя и контекста.
Если бы мне пришла такая задача, то я в первую очередь попрошу рецепт и состав, т.к. у меня нет опыта приготовления борща и мне нужны подробные инструкции как его приготовить.
От контекста стало бы понятно что ещё нужно уточнить. Если жена/девушка просит приготовить для дома, это одно, если нужно для мероприятия, то другое.

Ну в этом случае у него будет продукт "нарезанные овощи в кипящей воде"

похоже, я и сам пока недостаточно погружен в предметную область ))

так-то оно так, но не менее полезна система каскадного контроля, когда каждый следующий сотрудник осуществляет некоторый контроль действий предыдущего. Так мне не раз удавалось отлавливать ошибки в задаче на стадии аналитики, ещё до входа задачи в стадию реализации, вероятно из-за того, что аналитики и разработчики смотрят на вещи под разными углами, да и эффект "свежего глаза" не стоит сбрасывать со счетов. Кстати, если к прочтению аналитики подключался тестировщик и кто-нибудь с техподдержки и/или внедренцев - было ещё круче. Но конечно такое лучше делать на крупных задачах.

Понятие рецеп еще прекрасно включает в себя технологию, состав, и определение потребительских свойств, и объем на выходе и параметры на входе. Тут видимо разные понятия участники опроса и Денис вкладывают в термин "рецепт"

Ну тут можно накопать сколько угодно. Например если задача сварить борщ шла после 10ка задач нарезать салат и заварить чай - нечего тут каскадировать, делай борщ))

В другую сторону можно досмотреться до того друг за другом что бухгалтерия будет дизайн макеты согласовывать

агась, да вот только всплывёт потом, что клиент ожидал рецепт по классическому (в его понимании) рецепту, где картошку и мясо режут крупными кусками, а не как в салат 0,5х0,5 см кубиками - в результате на сдаче получается "упс! " нежданчик :). Клиент кричит и топает ножками.

И если уж ещё накопать то в задаче нет не только контекста варки борща, но и контекста получателя задачи