511

Идеи и мозговой штурм / Re: Тематические анекдоты

« : 06 Апреля 2008, 14:42:18 »

На самом деле это нормальный разговор с пользователем.

Автор говорил про ЗАПИСКУ от пользователя, а не про разговор. А в процессе РАЗГОВОРА с пользователем можно выяснить таки о чем это пользователь написал :-)

512

Примеры / Re: План управления требованиями

« : 04 Апреля 2008, 13:41:53 »

Линк я как-то приводил в форуме, куда я выложил презентуху. Можно ее просто оттуда скачать и выложить в архив. Вобщем если что -- свистите.

513

Работа / Re: где бы поднабраться опыта бизнес/системного аналитика?

« : 27 Марта 2008, 10:32:35 »

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

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

514

Варианты Использования (Use Case) / Re: Розенберг против Коберна

« : 26 Марта 2008, 10:41:43 »

Эд, не парься особо на тему кто из авторов методик прав. По поводу шаблонов Коберна, то не забываем что у него кроме fully dressed есть еще и casual вариант. Да и кто сказал что его шаблоны нельзя модифицировать под себя? Просто у Коберна юзкейсы достаточно удобные для практического использования. Мне НИЧТО не может помешать, если это добавляет ценности проекту, дополнить их макетами GUI. Но, ПЕРВИЧНЫМ будет таки UC с его целью пользователя и постоянным контекстом по достижению именно цели, а не концентрации на том, какую кнопку при этом нажать. Хотябы по тому, что как минимум название кнопки, да и сам дизайн GUI может еще 100 раз измениться в процессе проектирования и собственно разработки, и что, мне потом все в UC править, чтобы обеспечивать целостность? Да, у меня были проекты, когда UC будучи написаны выполняли свою роль на начальных этапах, и больше я их не поддерживал ... а разработка шла практически через прототипы, с очень короткими итерациями. И это тоже нормально. Саша правильно заметил -- каждому проекту своя методология. И если я вижу, что  в конкретном проекте UC не воспринимаются заказчиком и не добавляют ценности -- я от них отказываюсь в пользу других техник. Все зависит от проекта.

515

Работа / Re: Кто такой Product Manager?

« : 20 Марта 2008, 10:35:43 »

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

Аналитики пишут задания на разработку программистам, ВИ и т.д. Общаются только с конечными пользователями.
 
Мне, кстати, нравится такое построение команды ) если быть в роли Product Manager )
Менеджер проекта в этом случае часто отсутствует.

Хм, всегда думал что ТЗ это контейнер требований к ПО. Причем там вполне могут жить и фичи продукта. Кстати, IEEE 830 предлагает один из вариантов построения иерархии требований -- по фичам. А вот что такое "задание для программистов" я если честно не вполне понимаю. Я представляю что есть требования к ПО живущие как в одном так в нескольких документах. На их базе делается дизайн системы -- может быть выражен в виде UML моделей, ERD диаграммах и т.п. .... дизайн может быть архитектурным или детальным. Детальный может подаваться на вход разработчикам. Но дизайн -- это уже не совсем компетенция аналитика. Что же тогда та самая "постановка задачи", она же "задание для программистов"? Каково назначение и цель этого документа? Что в нем описывается?

516

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

« : 19 Марта 2008, 10:43:18 »

В литературе разброд и шатания. Да еше BABOK добваил энтропии :-). Переплетение бизнес-анализа и системного анализа (в контексте разработки ПО) происходит из-за ERPшников, у которых есть бизнес-процесс (которым занимается бизнес-аналитик) и есть, опа, техническое решение, которое автоматизирует этот БП. А консультант по SAP должен по-идее быть экспертом в предметке + уметь настраивать соответствующие модули. Требования как таковые им особо не нужны.
Лично я склонен использовать понятия RUP  для этого. Бизнес-анализ,  это все что связано с анализом именно бизнес-процессов. А бизнес-процессы могут быть и без использования ИТ как таковых. Анализ предметной области -- это по сути пляски вокруг domain model. Т.е. направленное уже больше в сторону разработки ПО активность, связанная с переводом понятий бизнеса на рельсы ООАП.

Хорошая мысль -- сделать обзорную статью на эту тему, в которой дать обзор методологий, стандартов в которых встречается понятие бизнес-анализа и бизнес-архитектуры (а это уже скорее ближе к EA и TOGAF/DoDAF/...) и про требования и системный анализ. После чего предложить собственное (комбинированное?) виденье того, что есть бизнес-анализ, а что есть требования и системный анализ.

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

517

Вакансии / Re: Вакансия: Ведущий бизнес-аналитик 70 000 -75 000 руб, Москва, м. Автозаводская

« : 17 Марта 2008, 20:50:28 »

Хотел бы я посмотреть на результат работы -- ИТ-стратегию ...

518

Сообщество Аналитиков / Re: [Встреча] Сообщества в скайпе 20.03.2008

« : 17 Марта 2008, 20:45:58 »

в 19-00 я аккурат с работы ухожу ... не получится у меня поучаствовать

519

ПО Аналитика / Re: Хороший обзор систем Change and Configuration Management

« : 09 Марта 2008, 23:14:09 »

мне нравятся комменты по Borland и Telelogic

520

Системный Анализ и Требования / Re: Семинар от Telelogic в Москве: Requirements-Driven Development

« : 09 Марта 2008, 23:11:55 »

В Excel не очень комфортно работать с многомерными данными, к тому же если нужно делать сортировки по ним, да и what-if анализ будет приводить каждый раз к пересчету на всем множестве данных. А графику рисовать -- для визуализации, тоже задачка.
С другой стороны -- при 10 фичах и 2-х параметрах (предполагаемые косты и бенефиты) можно и Excel не использовать, а на бумажке прикинуть ;-).
Есть еще один аспект .... думаю, что сегодня (позднее) напишу в блоге мысли на эту тему.

521

Системный Анализ и Требования / Re: Семинар от Telelogic в Москве: Requirements-Driven Development

« : 06 Марта 2008, 22:09:39 »

Хочу обратить внимание, что там рассматриваются именно фичи а не собственно требования. Т.е. мы делаем анализ именно фич продукта.

522

Системный Анализ и Требования / Re: Семинар от Telelogic в Москве: Requirements-Driven Development

« : 06 Марта 2008, 13:18:09 »

Побывал на семинаре. Был дан обзор по продуктам Телелоджик, их назначении и совместном использовании. Был рассказ про FocalPoint, как очень полезный инструмент для Product Managers -- рекомендую обратить на него внимание.
Общий вывод -- было бы здорово получать более детальную информацию по возможностям продуктов Телеложик, но как правило они это делают только в рамках проведения презентаций для конкретной компании, которая приглашает их для этого. Так, что если хотите узнать больше -- приглашайте их к себе в гости :-).

Кто-нить кроме меня ходил туда?

523

Для всех / Re: документ об обзоре и границах

« : 03 Марта 2008, 11:36:15 »

Посмотрел документ.
1. Думаю имеет смысл явно выделить раздел в котором указывать problem definitions. И имеет смысл либо делать это в виде  классической таблицы Проблема ... - затрагивает ... - Ее следствием является ... - Успешным решением будет ..., либо просто в виде списка где каждая проблема будет иметь свой ID.
2. У вас раздел называется "Бизнес-цели и критерии успеха". Цели обозначены, но звучат неубедительно -- т.к. нет тех самых критериев.  Для указанных вами целей стоит привести ожидаемые оценки -- как вы будете измерять улучшение качества обслуживания клиентов, насколько увеличиться скорость работы с заказами, насколько будет снижены затраты на ведение заказов. А за счет чего это будет достигнуто -- указать либо в разделе "Возможности бизнеса заказчика" либо прямо в problem definitions, при условии если проблемы и цели имеют четкую и прямую, а не опосредованную связь. Еще одно -- у целей тоже должны быть уникальные идентификаторы, я например использую BG1, BG2, ...
3. То же самое с рисками -- должны иметь идентификаторы, и кроме этого желательно их "оцифровать" и показать пути миграции с них, хотябы в общих чертах.
4. В функиях системы стоит "Взаимодействие с клиентом", если честно я не понимаю что имеется ввиду -- толи возможность клерка взаимодействовать с клиентом посредством системы (каким образом???), толи вы говорите что система не собственно софт, а система в ГОСТовском понимании, включающая персонал -- тогда это будет похоже на функцию системы в ГОСТовском смысле. А вообще, это слабо похоже на функции, а больше на преимущества, которые получают пользователи системы. И стоит этот раздел именовать как Features. А фичи не всегда есть функции. И если это именно фичи должны быть, то раздел следует назвать "Высокоуровневые возможности и свойства системы". И перечислять именно фичи системы, а не получаемые преимущества.
5. Предположения и завсисмости невнятно сформулированы. Нужно более четко их сформулировать и привести внятное описание что под этим имеется ввиду. Например, что это предположение или зависимость "Прайс фирмы на услуги и товары" Не понятно.

524

Системный Анализ и Требования / Семинар от Telelogic в Москве: Requirements-Driven Development

« : 27 Февраля 2008, 00:09:46 »

Собственно по этой ссылке http://www.telelogic.ru/company/events/index.cfm?showdetail=y&id=2488&eventtype=Seminar

525

Бизнес-анализ и Целеполагание / Re: Шаблон концепции системы автоматизации

« : 26 Февраля 2008, 22:45:11 »

Можно скачать еще тут http://www.mail333.com/download.php/?file=:Yury_Buluy_%28ReqClassification%29.pdf&host=bouloui.mail333.com/flashcard