Изначально термин "адаптированный документ" возник в ответе Galogen'а:Здесь речь про то, что если "заказчик UML не понимает", то надо написать требования тем языком, который он понимает. Но мне в данном случае кажется, что порядок действий несколько перепутан. Опять же, сошлюсь на "буквари", требования изначально и должны излагаться на языке бизнеса. Именно так, чтобы их понял прежде всего заказчик. А дальше вы можете уже для проектной команды сделать отдельный документ, где перевести все требования на технический язык.

Каюсь, Михаил. Действительно вы правы. Контекст вопроса увел от истинного пути.

Однако есть вопрос, описать требования на языке заказчика, а какова степень детализации? Где та грань, за которой мы описываем требования уровня заказчика и не вносим требования уровня системы, на котором как раз актуальны разные схемы, нотации и прочее?

Насколько понятным путем текстовое структурированное описание бизнес-процесса в отличии от какой-то графической нотации?

Я просто примеряю ситуацию к руководству нашего вуза, т.е. достаточно консервативной аудитории топ-менеджеров со своими представлениями?

А я думал что адаптивный документ - это некая облегчённая интерпретация требований. Я был неправ.

Ваш документ должен быть в таком случае, но его полезность опять же сомнительна, надо будет его шлифовать на многих клиентах

ArtemyY, мне кажется, есть нечто забавное в том, что чтобы вовлечь Заказчика в разработку 1-го документа (проектного - ТЗ), вы хотите сначала нагрузить его вторым (процессным).

ArtemyY, вот давайте рассмотрим ситуацию.

Заказчик (З) - некто, кто желает пошить себе костюм.

Разработчик (П) - некто, кто шьет ему костюм.

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

Заказчик пришел к портному.

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

приходит срок примерки
П надевает на З костюм начинает его адаптировать по фигуре. З довольный уходит. П назначает срок изготовления
З приходит примеряет все отлично

Обычный процесс верно? З взаимодействует с человеком и он абсолютно не знает как ведется процесс, сколько человек готовит его костюм, как вообще шьется костюм

Представим другую ситуацию.

З приходит в мастерскую. З просят раздеться и встать в некую кабинку. Просят зажмурить глаза. Можно открыть.
Все мерка снята. С помощью программы для З демонстрируют его костюм на макете. З в сомнении, он слишком консервативен, но решает довериться.
З приходит через день его костюм готов без примерки - он его одевает и страшно доволен.

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

Денис "Майевтик",

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

Galogen,

Абсолютно не согласен. Не корректное сравнение. Цена ошибки не сопоставима!

Представляете если бы костюм шился тиражом 10000. Уже ближе к нашему случаю. Думаю Заказчику пришлось бы утверждать проект вплоть до выкроек + вникнуть в весь технологический процесс чтобы понять за что он платит что его ожидает, что его ждет.

Заказчик должен быть максимально привлечен в команду на этапе сбора требований.

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

А почему вы вообще думаете, что проблемы неэффективности КОММУНИКАЦИЙ с помощью ДОКУМЕНТА могут быть решены с помощью ДОКУМЕНТА же?

Абсолютно не согласен. Не корректное сравнение. Цена ошибки не сопоставима!

Конечно, Вы правы, ситуации не сравнимы.

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

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

Заказчик платит за результат,а не технологический цикл. Он потому и платит, что нафиг ему вникать во весь технологический цикл - он доверяет разработчику, ожидая от него профессионализма. Другое дело, что иногда заказчик ожидает от разработчика, того, чего ему от него не следует ожидать.

Да заказчик рискует деньгами, а разработчик рискует репутацией. Потом нужно понимать, что заказчик - это не один человек, а коллектив. Раньше при внедрении АСУП или АСУ, заказчик часто нанимал дляэтой цели субподрядчика - некий проектный институт, который и готовил сбалансированное техническое задание.

Современная практика как мне кажется, тоже вернется возможно к этому.

А почему вы вообще думаете, что проблемы неэффективности КОММУНИКАЦИЙ с помощью ДОКУМЕНТА могут быть решены с помощью ДОКУМЕНТА же?

А почему нет?

В общем, действительно, проблема не новая.
Заказчику не надо знать методологию. Заказчик должен четко знать, что от него требуется. Для этого в договор вы включаете все требования к заказчику, которые необходимо выполнить. И не надо его убеждать в важности или не важности этапа сбора требований, так как вы пишете, что ТЗ будет являться основанием приемки системы, по этому, что он подпишет, то и получит. Если заказчик адекватен и хочет резултат, он и сам будет заинтересован в четком изложении, понятном для нго, что же он получит. Если заказчику результат не нужен - вы его не получите никак.

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

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

Тот адаптивный документ, что был описан - это регламент внедрения или план проекта. Такой документ всегда можно написать и утвердить протоколом, как документ, регламентирующий действия в проекте.

Это не регламент!!! Это справочная информация

Это нормальная ситуация. Тогда пишите договора грамотно, чобы в азделе "Заказчик обязан" стояло все, что вам надо для успешного завершения проекта.
 
Похоже, теоретики предусмотрели все... Это выходит прототипный метод в условиях, когда заказчик об этом не осведомлен ;-) По нашему - каша из топора...
... Алиса знала, что если залпом выпить бутылочку с надписью Йад, то почти наверняка почувствуешь легкое недомогание... (с)
Отказ от каждой здравой идеи может и не убить проект, но все равно повлияет на результат.
Те проблемы, что у Вас описаны лечатся грамотной работой руководителя проекта. Если в этом месте в проекте провал - то у Вас стоит выбор: или методами работы в разведке тащить на себя рычаги руководителя проекта и тайком за них дергать или смириться и на своем месте сделать работу максимально качественно, прикрыться бумагой и вовремя отойти в сторону, когда громада, воздвигнутая на зыбком фундаменте, станет рушиться. А может, вы варите кашу из топора и все исправится на следующей итерации: заказчик пощупает первую версию и выкатит вполне разумный список требований на доработку или переделку...

Мне кажется Вы говорите об идеальном управлении проектом...
И потом, я надеюсь что с документом фундамент простоит гораздо дольше и каша будет наваристее

А почему нет?

Если коротко - потому что это абсурд. Только Мюнхгаузен мог вытащить сам себя из болота за волосы.

Лицо, ставящее подпись УТВЕРЖДАЮ со сторонв заказчика несет ответственность (гражданскую в суде, а иногда и уголовную) за свою часть обязательств по документу. По этому его задача (и в его власти) выпустить соответствующий приказ по своей организации, в котором будет четко прописано, как надо относиться к согласованию и кому.
Извиняюсь за резкость.. Для чтения в туалете.

Если этот документ смогут читать и в туалете, то значит я не зря потратил время.

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

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

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

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

Заказчик платит за результат,а не технологический цикл. Он потому и платит, что нафиг ему вникать во весь технологический цикл - он доверяет разработчику, ожидая от него профессионализма.

Риск получить не разговорчивого и неадекватного заказчика есть всегда. В результате и профессионал может завалить проект.
Вот именно, "Доверяет разработчику и ожидает от него проффесионализма". Заказчик часто себе говорит "ну если они об этом не спрашивают значит это не нужно - они ведь профессионалы". Аналитик может упустить некоторые моменты, упускает и будет упускать, какой бы он профессионал не был. Мы должны подготовить Заказчика к этому!
Т.е. Заказчик должен не только ожидать, но и котролировать разработку документа требований т.к. это требования являются детализацией его договоренности о разработке ПО или приложением к договору на разработку.

Другое дело, что иногда заказчик ожидает от разработчика, того, чего ему от него не следует ожидать.

Да заказчик рискует деньгами, а разработчик рискует репутацией. Потом нужно понимать, что заказчик - это не один человек, а коллектив. Раньше при внедрении АСУП или АСУ, заказчик часто нанимал дляэтой цели субподрядчика - некий проектный институт, который и готовил сбалансированное техническое задание.

Современная практика как мне кажется, тоже вернется возможно к этому.

Посылая документ требований Заказчику(или документ описание бизнес процессов) на согласование мы ставим перед собой задачу определить одинаково правильное видение процессов и разрабатываемой функциональноси. Для этого Заказчик должен вникнуть в каждую деталь документа. В ответ мы ждем от него замечаний комментарии которые помогут исправить документ и максимально привести его в соответствие с реалиями.

Заказчику все равно, что от него требуют, для него это дополнительная, лишняя работа. Максимум, что сделает, это прочтет, разбираться точно не будет. Поэтому, пишите документы на русском (чтобы понятно было не ИТшнику, а любому человеку), для наглядности можно рисовать формы, и небольшие диаграммы (как рисунки), не более, больше всего должно быть текста.
P.S. есть прием - чем больше написано, тем вероятнее, что читать не будут совсем. Подпишут так. Но при внедрении будут говорить, что кучу вещей надо переделывать.

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

Согласна, среди руководства много умных людей.