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

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

Доброго времени суток) Прочитав ветку, пришел к выводу, что требуемое решение не было найдено. А ведь тема то поднята правильно, я лично, как аналитик/архитектор ежедневно сталкиваюсь с проблемой написания руководства программисту. И УВЕРЕН, что у  многих аналогичные проблемы. Фраза "Дай мне детальную постановку" становится гимном программистов. А что значит детальная постановка? На взгляд программистов - 95% от описания всей задачи. Здесь немного остановлюсь: даже не столько интересуют различные схемы (юзкейсы и т.д.), прототипы (хотя очень действенно), а просто описание ВСЕГО, вплоть до запросов и условий ЕСЛИ/ТО/ИНАЧЕ. Запросы используются для описания различных математических формул, соседствующих с использованием БД, поэтому используется описание - вплоть до "возьми первую запись из выборки" (ДРУГОГО ВАРИАНТА Я НИГДЕ НАЙТИ НЕ МОГУ). Один раз решил написать прямо запросом, а не русским текстом - потом пришлось сопоставлять то, что программист счел неэффективным. Второе - ЕСЛИ/ТО/ИНАЧЕ: тоже задействованы различные математические модели, которые НИКТО НЕ ЗНАЕТ КАК ОПИСАТЬ в виде привязки мат. модель-БД. Вот и отстается писать детальный документ. ИМХО - проще (и уже сам предлагаю руководству) писать самому код, и абсолютно без разницы какой-то выигрышь во времени (если он еще будет после многочасовых споров на тему "Ты не написал в постановке...а ты сам понять то не можешь?") и теория о том, что "Невозможно все знать" (хотя все задачи под мое ИМХО ставить скорее всего нельзя). Основано на реальных событиях и средней сложности проектах
Коллеги, прошу прокомментировать и дать разумный совет, если я что-то непраавильно вижу

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

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

а вообще правильный ответ, по-моему: постановка процесса разработки и построение разработки на основе компонентов (надеюсь, вам как архитектору не нужно объяснять о необходимости правильной компонентной архитектуры)

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

Для начала ответьте для себя, что такое "кодирование программы", что для этого нужно, что будет результатом и т.п. в Ваших конкретных условиях.
Конкретный документ извне получить вряд ли получится - очень уж много разных типов программ существует: от системного ПО (грубо говоря, драйверов и антивирусов) до прикладного (базы данных, сайты и еще уйма всего).
В каждом случае есть свои особенности. В каждой группе разработки - конкретные люди со своими навыками и тараканами в голове. Поэтому Ваши документы будут зависеть преимущественно от Ваших конкретных условий.

Фраза "Дай мне детальную постановку" становится гимном программистов...

 просто описание ВСЕГО, вплоть до запросов и условий ЕСЛИ/ТО/ИНАЧЕ. Запросы используются для описания различных математических формул, соседствующих с использованием БД, поэтому используется описание - вплоть до "возьми первую запись из выборки" (ДРУГОГО ВАРИАНТА Я НИГДЕ НАЙТИ НЕ МОГУ). Один раз решил написать прямо запросом, а не русским текстом

Это не программист.
Лет 30 назад была профессия связанная с пробивкой перфокарт. Сидели тетки и переводили написанные алгоритмы в язык дырок на листе картона. То, что вы описываете - примерно из этой же области. Кодер - видимо будет подходящим названием.

А какой документ нужен? В каждой компании свои правила. Кому то действительно нужен почти код, кто -то оскорбляется, видя запрос. Везде люди строят свою коммуникацию.

Коллеги, прошу прокомментировать и дать разумный совет, если я что-то непраавильно вижу

Мой опыт (7 лет в анализе, 4 компании разной крупности и профиля, больше 20 проектов, ТЗ не считала) говорит о том, что, когда человек не хочет что-то делать, он найдет этому любые оправдания - в т.ч. и нечеткость поставленной задачи. А программисты - они люди сначала, а потом уже - программисты.

Поэтому, когда меня начинают динамить, я задаю себе простой вопрос - почему этот человек не хочет сейчас делать эту задачу? Если причина лежит в психологической плоскости, а так бывает в 80% случаев, я работаю в этой плоскости. Если причина в технической плоскости, выясняем, чего не хватает для решения этой задачи, и даем ему это.

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

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

Вот видите  - и вам тоже трудно.
А вы возьмите на себя ответственность, напишите такой документ хотя бы для своей компании, добейтесь его соблюдения - и вам станет легко

надо наверно было сразу написать)):разговор веду про прикладное ПО, не коробочное решение.
Абсолютно согласен, что в каждой компании своя история развития и, исходя из этого, свои схемы. Тогда задам вопрос так: как вы думаете, какая должна быть ОПТИМАЛЬНАЯ детализация при работе для "все что до программирования"/программирование программы (желательно с примерами)? (как то сложно написал
По поводу опыта работы: 2 года в аналитике и прекрасно понимаю, что психологическая ответственность периодически ставит перед командой ряд заслонок. Однако лично я в работе всю ответственность забираю на себя (естественно, если пишу задание на кодирование с ужасающей детализацией), поэтому вопросов к программисту в 99% случаев никаких.
По описанию документа - есть такая задумка, поэтому я и вытаюсь взять добрый совет/пример у своих более опытных коллег (у всех вас).

...Однако лично я в работе всю ответственность забираю на себя (естественно, если пишу задание на кодирование с ужасающей детализацией), поэтому вопросов к программисту в 99% случаев никаких...

а кому вопросы, если не угадал, либо прошло изменение требований?

а кому вопросы, если не угадал, либо прошло изменение требований?

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

Тогда задам вопрос так: как вы думаете, какая должна быть ОПТИМАЛЬНАЯ детализация при работе для "все что до программирования"/программирование программы (желательно с примерами)? (как то сложно написал
По поводу опыта работы: 2 года в аналитике и прекрасно понимаю, что психологическая ответственность периодически ставит перед командой ряд заслонок. Однако лично я в работе всю ответственность забираю на себя (естественно, если пишу задание на кодирование с ужасающей детализацией), поэтому вопросов к программисту в 99% случаев никаких

Еще раз: оптимальная стратегия - адаптивная, нет никаких священных писаний, которыми надо руководствоваться - каждый работает, исходя из собственного опыта и здравого смысла. А главное - зачем эти священные писания?... Вы же сами себя таким образом загоняете в выдуманные границы.

Что такое адаптивная стратегия - взять и спросить конкретного исполнителя - слушай, Вася, а какая степень детализации тебе нужна для решения этой задачи? А вот этой? А вон той?

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

Из моего опыта: детализация не нужна. Аналитик описывает требования, но не реализацию.

взять и спросить конкретного исполнителя - слушай, Вася, а какая степень детализации тебе нужна для решения этой задачи? А вот этой? А вон той?

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

Я тоже так думала еще 5 лет назад
А теперь думаю - эххх, молодешшшшь!!

Хотя, все зависит от контекста - какая компания, какие проекты, какие заказчики..