Тут в соседней ветке меня еще вчера раскрыли

Что делать если требования от двух независимых stakeholder противоречат друг другу и придти к консенсусу не выходит ? Кому отдать предпочтение и на чем основываться ?

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

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

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

Такая ситуация очень типична. И права ida, проблему эскалируют тому, кто платит за систему, кто имеет право принимать конечное решение и решается часто административными ресурсами

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

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

Я говорю о ситуации когда главное ЛПР - тех директор. А конфликт у бухгалтеров.

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

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

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

НУ как раз зарплату мне косвенно платит пользователь. Будет он доволен - будут заказы - будет бабло. Моему непосредственно руководству вообще пофиг на спор бухгалтеров заказчика. Ему важно, что проект был успешно реализован.

+ ЛПР тоже на стороне заказчика зачастую, и оно тоже не платит мне з\п

НУ как раз зарплату мне косвенно платит пользователь. Будет он доволен - будут заказы - будет бабло. Моему непосредственно руководству вообще пофиг на спор бухгалтеров заказчика. Ему важно, что проект был успешно реализован.

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

Я говорю о ситуации когда главное ЛПР - тех директор. А конфликт у бухгалтеров.
Моя задача как аналитика в первую очередь добиться максимальной удовлетворенности пользователя в рамках оговоренного бюджета.

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

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

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

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

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

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

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

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

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

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

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

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

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

2 LastLegion86. Аналитики действительно работу по проектированию обычно делают лучше пользователей. Но - тут есть разные люди у заказчиков. Некоторым нравится заниматься проектированием систем, поиском решений - они отвлекаются от скучной рутины. И именно они часто становятся ответственным за проект со стороны заказчика. Ну и выдают не бизнес-прболему, а такие "полу-решения". Дальше с этим разбираешься. В нашей практике как-то так, хотя, естественно, может быть и иначе.

А в накладной (ТОРГ-12) надо печатать то, что положено по нормативам, это же официально определенная форма. Иначе придет налоговая, после чего многие окажутся без работы. Приоритет - за бухгалтерами (или директором), поскольку отвечать и проходить проверки - им. А вот Счет официально определенной формой не является. И тут бухгалтерам может быть интересно одно, чтобы сверять со своей бухгалтерией, а менеджерам - другое, чтобы видеть управленческие данные. И тут надо увеличивать число колонок. Кстати, в накладной дополнительные колонки тоже можно вводить (не запрещено), но лучше не надо - чтобы при проверках не возникало вопросов. Правда при всем этом, задача убеждения менеджеров в обоснованности идей бухгалтеров часто ложится именно на аналитика