1

Системный Анализ и Требования / Re: Согласование Вариантов использования (Use case): подводные камни и обходные пути

« : 11 Мая 2016, 15:32:58 »

А вы можете чисто для себя и своей команды разъяснить зачем вам понадобились юз-кейсы? Если объяснение будет убедительным, то и заказчик скорее всего поймёт.

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

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

Вы, в своей практике, проводите какое-нибудь "обучение" Заказчика, при условии, что это новый для вас Заказчик и Проект? Скажем так, чтобы настроить всех на одну волну?

2

Системный Анализ и Требования / Re: Согласование Вариантов использования (Use case): подводные камни и обходные пути

« : 10 Мая 2016, 12:38:09 »

Андрей, спасибо за развернутый ответ.
Попробуем поиграться с картинками.

А вы как-то разъясняете клиентам, что такое use case, почему в таком формате пишете требования? Или у них не возникает вопросов и "погружение" не нужно?
Кто-то привык видеть в требованиях описание "фич", а мы хотим как раз от этого отойти.

3

Системный Анализ и Требования / Согласование Вариантов использования (Use case): подводные камни и обходные пути

« : 06 Мая 2016, 17:56:45 »

Привет, коллеги!

Я пробежался по топикам форума, увидел, что многие пишут требования в виде Use case (ВИ). Поделитесь опытом, как вы согласуете их с Заказчиком? С какими проблемами при этом сталкиваетесь и как решаете?

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

Сейчас на одном из проектов начали использовать ВИ. Но заказчик не согласен с таким подходом и хочет чтобы требования были написаны в виде "пользовательской инструкции", т.е. текста с кучей картинок, на которых должны быть обведены кнопки, и поля в которые надо будет тыкать пользователям.
Аргументирует тем, что ВИ непонятны пользователям, т.к. не содержат описания интерфейса, и у пользователей не складывается в голове представление о том, как работать с будущей системой. При этом мы снабжаем ВИ ссылками на макеты формы.

4

Бизнес-анализ и Целеполагание / Re: Вопросы о бизнес-целях. Как правильно задавать и бороться с сопротивлением

« : 08 Февраля 2016, 13:08:21 »

Добрый день, коллеги 

Давайте, вернемся несколько назад. Мне кажется тут снова возник вопрос терминологии.
По Вигерсу, бизнес-требование - это высокоуровневая бизнес-цель организации или заказчиков системы.
Отсюда следует, что бизнес-цель и бизнес-требование это одно и то же.
В википедии, также говорится, что Бизнес-требования — определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).
И я придерживаюсь этого определения. Т.к. с этим можно работать.

Как я понял, на этом форуме у многих иной взгляд на бизнес-требования и бизнес-цели. То о чем говорили Денис, Леонид и товарищ Humbert больше похоже на личные интересы ЗЛ. Мне кажется, личные интересы и бизнес-требования - все же разные понятия. Иначе, я просто не понимаю как с этим работать. Я не совсем согласен с позицией Дениса о том, что у организации не может быть цели. Организация - по сути общество, объединенное общими целями и интересами. А иначе, в чем тогда заключается работа бизнес-аналитика, если бизнес-цели это личные цели отдельных дядь и тёть.

Так вот. Я же говорю, что часто приходят документы с описанием требуемой функциональности (красных и зеленых кнопок), но бизнес-требований в документах нет. Чтобы сделать свою работу качественно, моя задача - понять в чем же заключается бизнес-требования. Для этого надо задавать вопросы. Видимо, вопросы, которые были указаны в начале топика не самые удачные, т.к. люди сразу начинают думать не о том. А как же правильно задавать такие вопросы?

5

Бизнес-анализ и Целеполагание / Re: Вопросы о бизнес-целях. Как правильно задавать и бороться с сопротивлением

« : 05 Февраля 2016, 23:58:28 »

Похоже это вы пытаетесь решить за счет Ваших заказчиков личностные проблемы:)

Можете описать цепочку Ваших умозаключений, которые привели к такому выводу?

Аналитик работает по озвученным целям клиента.

Вот прям Браво! 

6

Бизнес-анализ и Целеполагание / Re: Вопросы о бизнес-целях. Как правильно задавать и бороться с сопротивлением

« : 05 Февраля 2016, 22:35:32 »

Да что с вами не так-то. Вы сами себя слышите?
У каждого есть свои личные цели от проекта. Меня они не интересуют. Я полагаю, что помимо личных целей могут быть (должны быть) какие-то бизнес-цели, какое-то адекватное обоснование, которое должно помочь понять что и как надо улучшить.
Вас послушать, так получается, сказали что нужна красная, круглая кнопка, вот и делай. И не спршавай почему.
Вам нравится ваша работа? Довольны результатом? Я не имею в виду ваши зарплаты,  бонусы  и т.д

7

Бизнес-анализ и Целеполагание / Re: Вопросы о бизнес-целях. Как правильно задавать и бороться с сопротивлением

« : 05 Февраля 2016, 17:00:59 »

Вам на каждом проекте так вот "глазки строят"?

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

8

Бизнес-анализ и Целеполагание / Re: Вопросы о бизнес-целях. Как правильно задавать и бороться с сопротивлением

« : 05 Февраля 2016, 13:56:54 »

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

9

Бизнес-анализ и Целеполагание / Вопросы о бизнес-целях. Как правильно задавать и бороться с сопротивлением

« : 05 Февраля 2016, 12:22:16 »

Привет, коллеги!
Работаю в интеграторе, и так получается, что здесь больше занимаются системным анализом, нежели бизнес-анализом.
Иногда занимаюсь пресейлами и готовлю оценку в части анализа и дизайна. Клиенты присылают для оценки такие документы как БТ, RFP, BRD или ФТ. Как правило (80-90% случаев), эти документы не содержат бизнес-требований и бизнес-целей(!), а описывают набор необходимой функциональности.
В результате примерно понятно, что должна уметь делать система, но совершенно непонятно для чего планируется внедрение системы.
Проблема в том, что вопросы типа "для чего внедряется система?", "какой эффект планируется получить в результате?", "какие цели и бэкграунд у проекта?" воспринимаются... не очень хорошо.
Во первых, такие вопросы стараются не пропустить клиентские аккаунт-менеджеры и продавцы, во-вторых, сами клиенты не всегда нормально реагируют на это. А мне кажется, что это главные вопросы которые надо разъяснить в начале проекта.
Может быть вы сталкивались с подобным? Как бороться с такой проблемой, может я неправильные вопросы задаю?