Форум Сообщества Аналитиков

Дисциплины => Системный Анализ и Требования => Тема начата: Oleg Voronov от 04 Октября 2010, 23:32:17

Название: Противоречивость требований
Отправлено: Oleg Voronov от 04 Октября 2010, 23:32:17
Что делать если требования от двух независимых stakeholder противоречат друг другу и придти к консенсусу не выходит ? Кому отдать предпочтение и на чем основываться ?
Название: Re: Противоречивость требований
Отправлено: maksiq от 05 Октября 2010, 00:44:29
В общем, по обстановке. И зависит от уровня противоречий. В одних случаях можно реализовать оба требования. Из нашей практики - все представители заказчика видели деление товара по товарным группам, только по-разному - в результате в систему заложили несколько классификаций - но только тогда, когда они сами осознали, что не договорятся (потому что сначала все они настаивали на одной классификации). В принципе, это оптимальный вариант - придумать такое решение, при котором все пожелания оказываются выполненными. И убедить заказчиков, что пожелания учтены. А что за ситуация?
Название: Re: Противоречивость требований
Отправлено: Oleg Voronov от 05 Октября 2010, 09:11:25
Это больше теоретический вопрос. Ну вот например директор говорит, что бы все цены были в НДС, а глав бух говорит что лучше без. (Я понимаю что можно реализовать и то и то, но давай те представим что это невозможно). Или например служба безопасности говорит что система должны запускаться только с определенных станций, а главный инженер требует мобильный доступ с любого девайса ?
Название: Re: Противоречивость требований
Отправлено: StUtk от 05 Октября 2010, 09:39:08
Невозможно, наверное, сделать систему, которая бы удовлетворила абсолютно всех. Чьи-то требования приоритетнее остальных, а что важнее желание главбуха или директора - определять тому, кто главнее по регламенту или иным установившимся "правилам", или каким-нить внутренним договорённостям. Так же с безопасностью. Может я где-то заблуждаюсь?
Название: Re: Противоречивость требований
Отправлено: Oleg Voronov от 05 Октября 2010, 09:44:02
Понятно что всем не угодишь.
Вот я и хочу понять как самые приоритеты устанавливать. И на каком этапе это делается ?  В какой момент и как нужно проставлять приоритеты для требований ?
Название: Re: Противоречивость требований
Отправлено: bas от 05 Октября 2010, 09:46:11
О, это мой любимы вопрос на собеседовании :)

Можно предложить следующее:
1. Запереть экспертов в одной комнате и выпустить только после договоренности, объяснив, что реализовать то и то невозможно, т.к. требования противоречат друг другу
2. По каждому направлению нужно выделить ЛПР и глобального ЛПР на старте проекта, чтобы можно было ему эскалировать проблему.
3. Изучить нормативные документы, регламенты, в которых м.б. четко сказано как.
4. Обратиться к мировому опыту, best practice.
Название: Re: Противоречивость требований
Отправлено: Oleg Voronov от 05 Октября 2010, 09:49:24
А нет ли каких либо формализованных методов в рамках тех или иных методологий?
Название: Re: Противоречивость требований
Отправлено: bas от 05 Октября 2010, 09:52:07
Методология говорит - что делать, но не как
Название: Re: Противоречивость требований
Отправлено: bas от 05 Октября 2010, 09:53:59
А чем Вам не понравились предложенные методы?
Первые два мои пункта можно четко формализовать в договоре.
Название: Re: Противоречивость требований
Отправлено: Oleg Voronov от 05 Октября 2010, 09:58:01
Да нет, методы хорошие, просто я думал может есть что-то в PMBOOK или каком - нибудь RUP
Название: Re: Противоречивость требований
Отправлено: Oleg Voronov от 05 Октября 2010, 09:58:22
А вообще  спасибо за ответы.
Название: Re: Противоречивость требований
Отправлено: Водолей от 05 Октября 2010, 10:34:07
IMHO если что-то подобного рода в PMBOK или в RUP и есть, то это легко выявляется их чтением :о))
Результат, впрочем, bas написал...
Название: Re: Противоречивость требований
Отправлено: maksiq от 06 Октября 2010, 00:27:19
Вообще вопрос решения противоречий упирается в приемку системы. Кто будет принимать - тот и отвечает за способ реализации. Если с ним договориться о любой формальной методике решения - можно по ней работать. Если не договориться, то никакие ссылки на стандарты не помогут. Если вернуться к приведенным примерам, то цены с НДС и без НДС - надо делать оба, благо это можно и это - реальные требования. Бывают и менее реальные - когда менеджеры хотят скидку в 1/3 от всего, а бухи - цену и НДС (!) на единицу товара в целых копейках. И все это надо напечатать в одной накладной - тогда договариваешься с обоими и объясняешь, что тупого решения - нет (а они - не верят), и иногда будут получаться кривоватые документы. Это как раз противоречие реальное, когда обоим надо обеспечить бизнес-процесс и есть объективные требования. А с безопасностью - там другие заморочки, обычно бизнесу надо, чтобы процесс шел, а безопаснику - чтобы он виноват не был. И придумываешь (иногда вместе с ним), как это "не виноват" - обосновать соответствием системы нормативам. Обычно получается. И все это (оба случая) - работа аналитика.
Название: Re: Противоречивость требований
Отправлено: Oleg Voronov от 06 Октября 2010, 09:29:03
В общем как во всех областях - только договариваться :).
Название: Re: Противоречивость требований
Отправлено: kas от 06 Октября 2010, 10:21:20
 я даже догадываюсь, куда вы на собеседование собрались)
Название: Re: Противоречивость требований
Отправлено: Oleg Voronov от 06 Октября 2010, 10:27:53
Тут в соседней ветке меня еще вчера раскрыли :)
Название: Re: Противоречивость требований
Отправлено: ida - брэнд с 14-летней историей от 06 Октября 2010, 12:21:46
Что делать если требования от двух независимых stakeholder противоречат друг другу и придти к консенсусу не выходит ? Кому отдать предпочтение и на чем основываться ?
Предпочтение отдавайте тому, кто принимает решения. Как он скажет - так и делайте.
Если такого человека нет - проект безнадежный.

Анализ анализом, а ответственность за результат, как правило, несут не те, кто предлагает варианты - а те, кто осуществляет выбор. Так что вам в принципе должно быть все равно, какой вариант пойдет в дело.
Название: Re: Противоречивость требований
Отправлено: Oleg Voronov от 06 Октября 2010, 12:39:27
Но ведь хочется добиться максимальной удовлетворенности пользователя. А если лицо принимающее решение далеко от области в которой противоречия. Например есть конфликт двух бухгалтеров, а лицо принимающее решение - технический директор. Он не всегда сможет выбрать максимально хороший вариант.
Название: Re: Противоречивость требований
Отправлено: Galogen от 06 Октября 2010, 14:39:57
Такая ситуация очень типична. И права ida, проблему эскалируют тому, кто платит за систему, кто имеет право принимать конечное решение и решается часто административными ресурсами
Название: Re: Противоречивость требований
Отправлено: ida - брэнд с 14-летней историей от 07 Октября 2010, 11:00:04
Например есть конфликт двух бухгалтеров, а лицо принимающее решение - технический директор. Он не всегда сможет выбрать максимально хороший вариант.
а. техдиректора ***т конфликт двух бухгалтеров?.. они на него работают, а не наоборот
б. ваши интересы, как аналитика, на чьей стороне? ваша задача предоставить развернутую информацию по имеющимся вариантам и обосновать каждый (преимущества, риски и т.п.) если бы ваша задача была принимать решения - были бы вы тех.директором, а не аналитиком
Название: Re: Противоречивость требований
Отправлено: Oleg Voronov от 07 Октября 2010, 12:19:16
Я говорю о ситуации когда главное ЛПР - тех директор. А конфликт у бухгалтеров.

Моя задача как аналитика в первую очередь добиться максимальной удовлетворенности пользователя в рамках оговоренного бюджета.
Название: Re: Противоречивость требований
Отправлено: ida - брэнд с 14-летней историей от 07 Октября 2010, 12:51:44
Моя задача как аналитика в первую очередь добиться максимальной удовлетворенности пользователя в рамках оговоренного бюджета.
Зарплату вам платит тоже пользователь?... (я не имею в виду ситуацию, когда пользователь является бухгалтером вашего работодателя)
Название: Re: Противоречивость требований
Отправлено: Oleg Voronov от 07 Октября 2010, 13:56:01
НУ как раз зарплату мне косвенно платит пользователь. Будет он доволен - будут заказы - будет бабло. Моему непосредственно руководству вообще пофиг на спор бухгалтеров заказчика. Ему важно, что проект был успешно реализован.

+ ЛПР тоже на стороне заказчика зачастую, и оно тоже не платит мне з\п
Название: Re: Противоречивость требований
Отправлено: Galogen от 07 Октября 2010, 17:24:59
НУ как раз зарплату мне косвенно платит пользователь. Будет он доволен - будут заказы - будет бабло. Моему непосредственно руководству вообще пофиг на спор бухгалтеров заказчика. Ему важно, что проект был успешно реализован.
Так в этом и дело. Если конфликт двух пользователей создает проблему успешности проекта, т.е. уперлись рогами и никто уступать не хочет, а вы не в состоянии реализовать одновременно их противоречия, Ваша прямая задача правильно описать проблему, показать как она препятствует успешности проекта и создает риск не для бухгалтера, а именно для этого самого техдиректора. Если он поймет это, то все решится сразу. Не поймет - ну наверное совет послать их куда подальше :)
Название: Re: Противоречивость требований
Отправлено: Странник от 08 Октября 2010, 03:25:01
Я говорю о ситуации когда главное ЛПР - тех директор. А конфликт у бухгалтеров.
Моя задача как аналитика в первую очередь добиться максимальной удовлетворенности пользователя в рамках оговоренного бюджета.

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

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

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

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

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

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

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

P.S. кстати, а что же будет делать аналитик (обеспечивший молчаливое "согласие") на стадии сдачи, когда риск реализуется и проблема всплывет на более высоком уровне критичности? заявление об уходе писать?
Название: Re: Противоречивость требований
Отправлено: maksiq от 08 Октября 2010, 10:54:00
Кстати, о бухгалтерах, и не только о них. По моему практическому опыту, очень часто конфликт возникает потому, что каждый из пользователей рассказывает не задачу в бизнес-терминах, подлежащую решению, а свое представление о решении этой задачи. Делает это из совершенно благих побуждений - не грузить аналитика семантикой бизнеса. А когда дожмешь и вникнешь в предметную область, вполне может оказаться. что предлагаются именно два решения одной проблемы, и надо обсудить плюсы и минусы, выбрать. А может оказаться, что проблемы - разные, и решать надо обе. Наконец, часты ситуации, когда решения от заказчика реально решением не являются - он же не IT-проектировщик, учел только простые ситуации и т.п. В общем, надо уходить от требований в бизнес-область, понимать там проблемы и вместе искать решения.
Название: Re: Противоречивость требований
Отправлено: Oleg Voronov от 08 Октября 2010, 11:24:43
Кстати, о бухгалтерах, и не только о них. По моему практическому опыту, очень часто конфликт возникает потому, что каждый из пользователей рассказывает не задачу в бизнес-терминах, подлежащую решению, а свое представление о решении этой задачи. Делает это из совершенно благих побуждений - не грузить аналитика семантикой бизнеса. А когда дожмешь и вникнешь в предметную область, вполне может оказаться. что предлагаются именно два решения одной проблемы, и надо обсудить плюсы и минусы, выбрать. А может оказаться, что проблемы - разные, и решать надо обе. Наконец, часты ситуации, когда решения от заказчика реально решением не являются - он же не IT-проектировщик, учел только простые ситуации и т.п. В общем, надо уходить от требований в бизнес-область, понимать там проблемы и вместе искать решения.

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

Речь идет немного не о том. Имеется ввиду ситуация как например описанная выше. Бухгалтерия требует в накладных указывать сумму с НДС, а продавцы сумму без НДС и с вычетом скидки клиенту. А поле на накладной только одно.
Название: Re: Противоречивость требований
Отправлено: Водолей от 08 Октября 2010, 11:29:57
2 LastLegion86: Снимите шоры!
в приведенном Вами примере ни бухгалтерия, ни продавцы не видят и не могут знать какие и сколько полей в объекта накладная есть в БД!
еще одна подсказка: накладная для бухгалтерии и накладная для продавцов - суть разные представления одного и того же объекта.
Название: Re: Противоречивость требований
Отправлено: maksiq от 08 Октября 2010, 11:41:05
2 LastLegion86. Аналитики действительно работу по проектированию обычно делают лучше пользователей. Но - тут есть разные люди у заказчиков. Некоторым нравится заниматься проектированием систем, поиском решений - они отвлекаются от скучной рутины. И именно они часто становятся ответственным за проект со стороны заказчика. Ну и выдают не бизнес-прболему, а такие "полу-решения". Дальше с этим разбираешься. В нашей практике как-то так, хотя, естественно, может быть и иначе.

А в накладной (ТОРГ-12) надо печатать то, что положено по нормативам, это же официально определенная форма. Иначе придет налоговая, после чего многие окажутся без работы. Приоритет - за бухгалтерами (или директором), поскольку отвечать и проходить проверки - им. А вот Счет официально определенной формой не является. И тут бухгалтерам может быть интересно одно, чтобы сверять со своей бухгалтерией, а менеджерам - другое, чтобы видеть управленческие данные. И тут надо увеличивать число колонок. Кстати, в накладной дополнительные колонки тоже можно вводить (не запрещено), но лучше не надо - чтобы при проверках не возникало вопросов. Правда при всем этом, задача убеждения менеджеров в обоснованности идей бухгалтеров часто ложится именно на аналитика :)
Название: Re: Противоречивость требований
Отправлено: Oleg Voronov от 08 Октября 2010, 11:53:27
2 LastLegion86: Снимите шоры!
в приведенном Вами примере ни бухгалтерия, ни продавцы не видят и не могут знать какие и сколько полей в объекта накладная есть в БД!
еще одна подсказка: накладная для бухгалтерии и накладная для продавцов - суть разные представления одного и того же объекта.

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

ПРИМЕР АБСТРАКТНЫЙ !
Название: Re: Противоречивость требований
Отправлено: Водолей от 08 Октября 2010, 12:06:40
совсем переходя в абстрактную плоскость - нужно изменить процесс продажи, например, чтобы не бухгалтер выписывал накладную, а получал ее от того же продавца :о)))

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

P.S. зря вы это затеяли :о)))) с абстрактным примером... получите абстрактные ответы на все случаи жизни кроме вашего...
Название: Re: Противоречивость требований
Отправлено: Oleg Voronov от 08 Октября 2010, 14:17:02
Я написал что систему менять нельзя :) Так что не подходит !
Название: Re: Противоречивость требований
Отправлено: Странник от 08 Октября 2010, 16:02:20
Не могу не выступить с обличением :о)))
2 Странник:
Смею Вас уверить, что задача аналитика, как и всех остальных членов команды разработчиков, совсем иная, нежели декларируете Вы.
Т.к. все они (или по крайней мере большинство из них) являются исполнителями, то они должны грамотно выполнить свою профессиональную работу в рамках установленных для этого условий (например, без превышения временного бюджета или финансового).
Потенциальная прибыльность не должна заботить исполнителя вообще! Неважно из каких источников: инвестиции владельца, оплата по контракту клиентом, государственное финансирование и т.п. - будет оплачена его работа, главное чтобы была оплачена исходя их его затрат, квалификации/компетенции, полученного результата... И только!

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

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

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


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

P.S. кстати, а что же будет делать аналитик (обеспечивший молчаливое "согласие") на стадии сдачи, когда риск реализуется и проблема всплывет на более высоком уровне критичности? заявление об уходе писать?
Конечно ничего хорошего не будет, ктож спорит. Нужно на более ранних этапах добиваться явного согласования ТЗ. Но, если уж не удалось никак, в качестве последнего рубежа обороны может и сработать ("Ну Вы же согласились...").
Название: Re: Противоречивость требований
Отправлено: Водолей от 08 Октября 2010, 16:29:41
Цитата: LastLegion86
Я написал что систему менять нельзя :) Так что не подходит !

пардон, я ВООБЩЕ тогда НИЧЕГО НЕ ПОНИМАЮ. либо прекращайте абстракцию, либо закрывайте тему.
Название: Re: Противоречивость требований
Отправлено: bas от 08 Октября 2010, 16:32:15
Народ, не похоже ли это уже на флуд??
Название: Re: Противоречивость требований
Отправлено: Водолей от 08 Октября 2010, 16:36:10
2 Странник:

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

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

согласен
Название: Re: Противоречивость требований
Отправлено: Oleg Voronov от 08 Октября 2010, 17:04:56
Коллеги,

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

Я и пытаюсь выяснить как "правильно" договариваться и какие особенности здесь могут быть !?
Название: Re: Противоречивость требований
Отправлено: Водолей от 08 Октября 2010, 18:27:50
правильно договариваться нужно как-то так:
 - Я предлагаю чтобы эту функциональность не включать в такой-то релиз системы. Вы согласны?

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

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

Название: Re: Противоречивость требований
Отправлено: ida - брэнд с 14-летней историей от 11 Октября 2010, 13:56:52
P.S. кстати, а что же будет делать аналитик (обеспечивший молчаливое "согласие") на стадии сдачи, когда риск реализуется и проблема всплывет на более высоком уровне критичности? заявление об уходе писать?
Дык зачем же молчать?..
Я обычно поступаю следующим образом: излагаю все возможные варианты с констатацией того, какие преимущества и недостатки у каждого. Принимается решение. Если риски проигрываются, вспоминаем пословицу "ты начальник - я дурак", собссно и все.
Я вообще не понимаю, из-за чего весь сыр-бор.
Ответственность аналитика ограничивается полнотой и достоверностью предоставленной информации - больше с него никто ничего спрашивать не будет.
Название: Re: Противоречивость требований
Отправлено: Oleg Voronov от 11 Октября 2010, 14:01:07
Я пытаюсь выяснить если какие - то формализованные методы решения подобных противоречий. Судя по ответам решение одно - усадить всех за стол, все рассказать и заставить договориться.
Название: Re: Противоречивость требований
Отправлено: Странник от 12 Октября 2010, 08:58:02
.....
Я обычно поступаю следующим образом: излагаю все возможные варианты с констатацией того, какие преимущества и недостатки у каждого. Принимается решение. Если риски проигрываются, вспоминаем пословицу "ты начальник - я дурак", собссно и все.
....
Хороший способ, надо запомнить :)
Название: Re: Противоречивость требований
Отправлено: Странник от 12 Октября 2010, 09:25:44
Я пытаюсь выяснить если какие - то формализованные методы решения подобных противоречий. Судя по ответам решение одно - усадить всех за стол, все рассказать и заставить договориться.
Формально процессы заказа/поставки/разработки описаны в ГОСТ/ISO 12207 и внутри них - процессы совместного анализа и совместного решения проблем.
В RUP в описании дисциплины Requirements есть кое-какой формализм  (см. например активность Analyze the Problem и в ней Requirements Workshop - то самое собрание).
Еще есть советско-российская бюрократическая традиция совещаний с составлением протоколов разногласий (что формально описано - неи знаю, но точно можно найти образцы документов).
По идее должны быть аналоги в описаниях других процессов.

Название: Re: Противоречивость требований
Отправлено: Oleg Voronov от 12 Октября 2010, 10:04:30
В целом понятно, спасибо!
Название: Re: Противоречивость требований
Отправлено: ida - брэнд с 14-летней историей от 12 Октября 2010, 11:11:29
Я пытаюсь выяснить если какие - то формализованные методы решения подобных противоречий. Судя по ответам решение одно - усадить всех за стол, все рассказать и заставить договориться.
Это единственный способ, что ж тут неочевидного - мы все люди, и люди принимают решения, а не формальные методы.
Формально вы можете приоретизировать требования, посчитать эффективность - но решать, как поступить, все равно будет человек. И какой смысл в вашей работе, если этот человек не захочет вас слушать?
Переговоры это и есть единственный способ быть услышанным.

Вообще в последнее очень странно читать форум и слушать коллег, потому что с какого-то момента, похоже, люди перестают понимать, что любые инструменты работают в определенных границах, и границы эти задает тот, кто их применяет, и через это не перепрыгнуть, хоть какой супер-крутой метод придумай. Возьмите любое направление хотя бы в работе с требованиями и убедитесь. Но как только доходит до человека - так у нас столбняк и никто не понимает, как с ним работать. Всем бы надо какое-то волшебное ПО, чтобы само как-то без нас все сделало.
Учите психологию! Все инструментальные средства уже достигли потолка в своем развитии, для дальнейшего повышения эффективности надо развивать собственные мозги (а точнее - некие социальные навыки).
Название: Re: Противоречивость требований
Отправлено: Oleg Voronov от 12 Октября 2010, 12:10:29
ida - здесь речь не идет о каком-то ПО или других инструментах. Речь идет о методах, а они вполне применимы и в общении. Метод утюга и паяльника отлично позволяет эффективно узнавать пароли у пользователей. :) Кто говорил о том что человек не хочет кого-то слушать?

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

Никто не говорил, что не понимает как работать с заказчиком, если бы это было так, многие были бы без работы. :) Да и ПО волшебное тоже никто не просит.
Название: Re: Противоречивость требований
Отправлено: Водолей от 12 Октября 2010, 12:22:31
IMHO всё-таки Вы не слышите, что Вам говорят, и гнёте свою линию.
нет правильных вопросов, нет и правильной последовательности! нет и всё! всё строго индивидуально.
а чтобы говорить со знанием дела - нужно быть специалистом. однако ни вы, ни я, ни кто-то еще из нас ИТишников не может лучше заказчика знать его предметную область, его проблемы и потребности/хотелки. хорошо знать может, но лучше - вряд ли (иначе б работал на его месте). вот и нужно этого "хорошо" достигать + коммуникативные навыки.
так что единственный способ - грамотно говорить с заказчиком на его языке (как в той рекламе).
Название: Re: Противоречивость требований
Отправлено: Oleg Voronov от 12 Октября 2010, 12:29:32
Господа, да нет у меня никакой своей линии, если бы была, я бы у вас не спрашивал.
Это вы думаете что нет вопросов и последовательностей и т.д. Некоторые наши коллеги считают иначе.
Естественно что все строго индивидуально, но для других же процессов есть какие то шаблоны, которые потом дотачиваются под конкретный проект и заказчика. Никто не говорит о том что нужно учить заказчика, прочитайте первые посты. Вопрос стоял - предпочтения кого и как выбирать при возникновении противоречий, а не о том что нужно внедрять что то на свое усмотрение.
Название: Re: Противоречивость требований
Отправлено: Водолей от 12 Октября 2010, 12:58:29
ответ короткий - stakeholder'ов. тех, кто что-то получает / теряет от внедрения, кого (чью сферу ответственности затрагивает система)
как? искать. изучать процессы, взаимоотношения в организации заказчика, просто внимательно смотреть по сторонам, слушать и слышать разговоры, вроде бы не относящиеся к делу, узнавать о событиях в организации, делать выводы из реакций на ваши (и кого-то еще) действия.
психология тут поможет.
Название: Re: Противоречивость требований
Отправлено: Странник от 12 Октября 2010, 15:25:56
А вот тут я уже, извините, упустил смысл продолжения спора. Если правильно понял, вопрос был о формализованных рекомендациях, которые описаны в стандартах и формальных описаниях процессов типа RUP. Да, они там есть, но в конечном счете сводятся все к тому же - собрать заинтересованных лиц в одной комнате и попытаться привести к согласию:
To conduct a requirements workshop, means to gather all stakeholders together for an intensive, focused period.
Есть еще советы по подготовке и ведению совещения, ничего особо сверъестественного.
А вот рекомендаций, какими словами убеждать участников, и что делать в случае провала там нет.
Название: Re: Противоречивость требований
Отправлено: Oleg Voronov от 12 Октября 2010, 15:29:42
На самом деле, довольно много предложиk bas - в начале обсуждения. Но все спасибо за предложенные варианты.
Из всего вышесказанного можно сделать вывод. Что при возникновении спорных ситуаций, надо собрать всех вместе, обьяснить им варианты, выслушать их мнения и заставить принять решение того кто платит :)
Название: Re: Противоречивость требований
Отправлено: Водолей от 12 Октября 2010, 17:16:23
лучше не "при", а "до". договариваться лучше "на берегу", а не "в тонущей лодке" (ну или не в тонущей, а "идущей полным ходом")
Название: Re: Противоречивость требований
Отправлено: ida - брэнд с 14-летней историей от 13 Октября 2010, 10:23:44
Вы уже по-моему на следующий цикл пошли :)
Название: Re: Противоречивость требований
Отправлено: Oleg Voronov от 13 Октября 2010, 14:29:16
Главное вовремя остановится. :)