136

Системный Анализ и Требования / Re: Противоречивость требований

« : 08 Октября 2010, 11:53:27 »

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

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

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

137

Системный Анализ и Требования / Re: Противоречивость требований

« : 08 Октября 2010, 11:24:43 »

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

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

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

138

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 08 Октября 2010, 11:16:59 »

Резюмируя обсуждение, принципиальных вопросов, от которых зависят ваши действия два:
1) Вписался ли проект ли в сроки и бюджет? Если да, то функционал - это бонус, и в сопровождение тоже впишется.
2) Считает ли Вы дополнительный функционал настолько ценным, что отдавать без денег - жалко?
После ответа на эти вопросы действия достаточно определены, и в обсуждении варианты звучали.

1. Сопровождение "левых" фич - это в любом случае дополнительные расходы ресурсов.
2. Вопрос не в его ценности, а в рисках попасть на доп расходы по его поддержки и доработки.

139

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 08 Октября 2010, 11:12:09 »

На самом деле таких ситуаций может быть огромное количество. Первое, что приходит на ум:

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

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

140

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 08 Октября 2010, 10:26:32 »

На самом деле, я себе вообще слабо представляю подобную ситуацию.

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

141

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 08 Октября 2010, 09:26:49 »

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

142

Системный Анализ и Требования / Re: Противоречивость требований

« : 07 Октября 2010, 13:56:01 »

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

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

143

Системный Анализ и Требования / Re: Противоречивость требований

« : 07 Октября 2010, 12:19:16 »

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

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

144

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 06 Октября 2010, 14:14:50 »

Кстати, а у кого - нибудь были в практике подобные случаи ?

145

Системный Анализ и Требования / Re: Противоречивость требований

« : 06 Октября 2010, 12:39:27 »

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

146

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 06 Октября 2010, 11:43:50 »

Я вот это и пытаюсь узнать.

Я никогда не сталкивался с подобным.

Мое мнение что ТЗ актуализировать не получится. Как объяснить заказчику, что мы ему что-то "левое" впихнули?

+ По идеи, ТЗ уже давно согласованно и подписано, и как его менять непонятно. Опять же тот или иной функционал должен покрывать задокументированную нужду заказчика\пользователя, а в данном случае заказчик\пользователь никак ее не озвучивает и не факт, что ему оно понравится и уж точно он не готов сразу за это платить.

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

147

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 06 Октября 2010, 11:09:26 »

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

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

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

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

Вот насчет багов проблема, есть баг - негатив ложится на всю систему целиком и не скажешь что "Неиспользуйте вы это не заказывали". Либо убирать, либо исключать.

148

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 06 Октября 2010, 10:45:23 »

Не обязательно. Даже если эта заказная разработка, то рано или поздно наступает момент когда тот или иной продукт требует доработки. Внедрение новой версии так сказать. И тогда идет описание того, что нужно изменить и как.  Например нужно изменение модуля номер 1 и номер 5. И вполне вероятна ситуация когда незапланированный функционал пришелся "по вкусу" заказчику в процессе использования всего продукта и у заказчика есть пожелания по его изменению доработки. И тогда подобные изменения доработки можно делать уже за денежку.

149

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 06 Октября 2010, 10:32:24 »

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

150

Системный Анализ и Требования / Re: Противоречивость требований

« : 06 Октября 2010, 10:27:53 »

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