2 LastLegion86: Снимите шоры!
в приведенном Вами примере ни бухгалтерия, ни продавцы не видят и не могут знать какие и сколько полей в объекта накладная есть в БД!
еще одна подсказка: накладная для бухгалтерии и накладная для продавцов - суть разные представления одного и того же объекта.

Господа, да что же вцепились в этих бухгалтеров. Это всего лишь пример  приведенный выше.
Причем тут сколько полей есть у объекта в БД ? Бухгалтер знает, что в накладных его фирмы должно быть то-то и то-то. Он с ними всю жизнь работает. И ему плевать на нашу БД. То же самое с продавцом. Давайте абстрагируемся от того, почему так, а не иначе.
Я повторюсь - это абстрактная ситуация. Давайте примем за исходные что есть 1 накладная и вней по закону может быть одно число со стоимостью товара. Накладную формирует и проверяет правильность бухгалтер, и передает продавцу. А тот получает деньги и отдает товар. Так вот у бухгалтера в его бухгалтерской программе написана стоимость с без НДС (а внизу это подписано). Ему удобно что бы это число было на накладной (физическая бумажка), что бы "сравнить с компьютером" (компания маленькая все вручную ). А у продавца в кассовой программе, указывается стоимость с НДС и с учетом персональной скидки (фактические деньги которые ему отдали) и он хочет что бы на накладной была стоимость с НДС и со скидкой, что бы он проверял все ли ему заплатили, а не считал каждый раз. Доработать бухгалтерскую и кассовую сис - му нельзя (. Вот как в таком случае быть.

ПРИМЕР АБСТРАКТНЫЙ !

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

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

P.S. зря вы это затеяли :о)))) с абстрактным примером... получите абстрактные ответы на все случаи жизни кроме вашего...

Я написал что систему менять нельзя Так что не подходит !

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

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

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

---------------- обличительная часть выступления закончена :о)))

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

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

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

Конечно ничего хорошего не будет, ктож спорит. Нужно на более ранних этапах добиваться явного согласования ТЗ. Но, если уж не удалось никак, в качестве последнего рубежа обороны может и сработать ("Ну Вы же согласились...").

Я написал что систему менять нельзя Так что не подходит !

пардон, я ВООБЩЕ тогда НИЧЕГО НЕ ПОНИМАЮ. либо прекращайте абстракцию, либо закрывайте тему.

Народ, не похоже ли это уже на флуд??

2 Странник:

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

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

Народ, не похоже ли это уже на флуд??

согласен

Коллеги,

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

Я и пытаюсь выяснить как "правильно" договариваться и какие особенности здесь могут быть !?

правильно договариваться нужно как-то так:
 - Я предлагаю чтобы эту функциональность не включать в такой-то релиз системы. Вы согласны?

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

Я бы договаривался по-другому, поднимая вопрос до уровня бизнеса.
- Пользователю А необходимо для его работы получать иметь такую-то информацию.
- Пользователю Б необходимо для его работы получать иметь такую-то информацию.
Мы предлагаем, чтобы в следующем релизе системы пользователь А сможет увидеть эту информацию на таких-то интерфейсных и печатных формах, а пользователю Б придется пользоваться обращаться к дополнительным формам/пользоваться калькулятором, а если кейс начинается от печатной формы, то надо будет сначала найти электронный документ и уже в нем это увидеть. Обоснования такие-то, имеются такие-то другие варианты, которые, например, задержат срок релиза на столько-то. Можно пообещать, что в следующих релизах... Аналогично - если не видеть информацию, а делать действия: пользователь А работает нажатием одной кнопки, а пользователю Б надо нажать несколько.

То есть поднимаем вопрос от уровня реализации требований до уровня решения проблем пользователей. Пример с бухгалтерами на это тоже ложится, но это именно общие решения.

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

Дык зачем же молчать?..
Я обычно поступаю следующим образом: излагаю все возможные варианты с констатацией того, какие преимущества и недостатки у каждого. Принимается решение. Если риски проигрываются, вспоминаем пословицу "ты начальник - я дурак", собссно и все.
Я вообще не понимаю, из-за чего весь сыр-бор.
Ответственность аналитика ограничивается полнотой и достоверностью предоставленной информации - больше с него никто ничего спрашивать не будет.

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

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

Хороший способ, надо запомнить

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

Формально процессы заказа/поставки/разработки описаны в ГОСТ/ISO 12207 и внутри них - процессы совместного анализа и совместного решения проблем.
В RUP в описании дисциплины Requirements есть кое-какой формализм  (см. например активность Analyze the Problem и в ней Requirements Workshop - то самое собрание).
Еще есть советско-российская бюрократическая традиция совещаний с составлением протоколов разногласий (что формально описано - неи знаю, но точно можно найти образцы документов).
По идее должны быть аналоги в описаниях других процессов.