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

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - ichy

Страницы: « 1 2 3 4 5 6 7 8 9 »
16
Одна из задач BABOK - "Поддержка требований для повторного использования".
При разборе этой задачи в BABOK Study Group разгорелась горячая дискуссия:

1. Нужно ли тратить дополнительное время и силы для приведения в порядок требований перед их «консервацией», для повторного использования в будущем? И кто это будет делать?
2. Может ли аналитик самостоятельно провести качественную ревизию своих же требований? И кто должен «мотивировать» другого аналитика помогать?
3. Правильно ли, вообще, повторно использовать требования?

И еще:
- Кто может оценить степень важности такой работы?
- Окупится ли потраченное время?
- Кто должен контролировать, чтобы данная работа выполнялась?

Основные умозаключения здесь - http://just-analyze-it.com/?p=103

А какие у вас мысли?

17
Обсуждение статей / Re: BABOK для Золушки
« : 28 Сентября 2011, 14:37:20 »
Так я же и говорю, что не стоит воспринимать задачи ВАВОК, как перечень шагов, которые должен выполнить наш аналитик.
Если это делает заказчик - замечательно, значит на его стороне будет человек, который, возможно, называться будет совсем не аналитик, но должен будет выполнить эти задачи. Чтобы мы, для выполнения своих задач, смогли получить на вход бизнес цели, рамки решения и пр.

Если говорить об анализе рынка, нигде же не написано, что мы должны влезть внутрь 3-4-х организаций (конечно же, и никто не пустит, и слишком дорого). Но определить, что же этим организациям (или частным лицам) нужно, какие у них проблемы и как мы эти проблемы можем решить, перед тем, как садиться что-то делать, просто необходимо.
Потому ВАВОК и предлагает для каждой задачи перечень техник, которые мы можем использовать по ситуации.
Например, (раз мы уж говорим об Анализе предприятия) задача "Определение бизнес целей", ее техники (или методы решения):
- Benchmarking
- Brainstorming
- Business Rules Analysis
- Focus Groups
- Functional Decomposition
- Root Cause Analysis
Есть доступ к предприятию, отлично, проанализировали его бизнес правила или побрейнстормили с руководством по поводу целей. Нету - тоже не беда, собрали фокус группу или провели бенчмаркинг.

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

И еще, мы как-то зацепили Анализ предприятия, но это только одна область знаний из шести, есть ведь еще:
Планирование и мониторинг
Выявление
Управление требованиями и коммуникация
Анализ требований
Оценка решения

Они-то точно актуальны для большинства аналитиков.

18
Да, могла пропустить, лучше еще раз
или в скайп: aelirena

19
Да мы, собственно, не спим - милости просим!

20
Обсуждение статей / Re: BABOK для Золушки
« : 26 Сентября 2011, 21:43:57 »
Как вы думаете, для какого контекста больше всего подходит идеология BABOK — внутренней разработки и внедрения, заказной разработки, продуктовой разработки или системной интеграции? Для каких контекстов не подходит вообще?
Мне думается, что BABOK прежде всего применим в inhouse. Частично — в системной интеграции. В заказной разработке мало и в продуктовой совсем неприменим.

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

Я, если честно, этого не почувствовала. Мне, как раз, кажется, что они даже слишком в общем попытались дать картину - на все случаи жизни.

Скажем, область знаний "Анализ предприятия", а в ней у нас: определение бизнес-целей, поиск проблем, выбор оптимального решения, оценка, что будет более выгодным (может, дешевле вообще не решать проблему) и т.п. - задачи, вроде, заказчика (в заказной разработке делать будем не мы, а при разработке продукта какой может быть заказчик?).
Но, во-первых, заказчики бывают разные (некоторым, перед тем, как решать какую-то проблему, нужно сначала найти и объяснить, что проблема-то у них не в этом),
во-вторых, есть же еще замечательные аналитики - внешние консультанты, хлеб которых именно в том, чтобы проанализировать, найти проблемы, предложить решения, и почему они не могут привлекаться к заказной разработке?,
а, в-третьих, даже при разработке того же коробочного продукта, желательно предварительно побрейнстормить, а какие цели у бизнеса, которому мы будем это предлагать, а какие у них проблемы, а может этому бизнесу будет дешевле игнорировать эти проблемы, чем покупать наше решение.

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

И еще про продуктовую разработку, во многих задачах ВАВОК среди техник предлагается Бенчмаркинг, который, по-моему, ни для чего так не эффективен, как именно для разработки продукта.

21
Обсуждение статей / Re: BABOK для Золушки
« : 26 Сентября 2011, 18:39:33 »
Нет, ни в коем случае не решила, что хватит!

Сейчас есть записанных и выложенных:
Введение в ВАВОК
Планирование и мониторинг бизнес анализа
   Введение
   Задача 1.1 Выбор подхода к бизнес анализу
   Задача 1.2 Анализ заинтересованных лиц

Если все эти записи получили, то все нормально, больше пока ничего и не было. Знаю, очень виновата, но 24 часа в сутках - это катастрофически мало! Буду стараться исправляться!

И жду конструктивную критику, может, есть что улучшать!

22
Если совсем прагматично:
Для отдельных личностей - первыми в стране получить красивую международную бумажку (членство дает скидку на сертификацию, для Украины: при 40 долларах членства, скидка на экзамен 100)
Для отдельных личностей в чаптере - стать первыми в стране тренерами, организовать сертификацию, перевод трудов и т.п., что потенциально может приносить доход, особенно, если тема с ИИБА будет набирать обороты

23
Могу присоединиться к этому славному списоку? Я, правда, еще только начала, но очень надеюсь, что у меня хорошо пойдет и что и в моем блоге можно будет прочесть что-то интересненькое

http://just-analyze-it.com/ Крючкова Ира, инженерия требований, коммуникации, управление знаниями

24
Да, очень хочется организовать трансляцию!
С кем лучше обсудить технические моменты использования http://yatv.ru/uml2?

25
Еще и от себя хочу всех пригласить к нам в Киев!
Иры, Саша, Гриша и все все все, всех вместе и каждого по отдельности будем очень рады видеть!

26
Спасибо, конечно... Но:
Почему меня?
Почему сейчас?
И
ромка всех благ тебе

кто такой Ромка?

27
Обучение / Re: Analyze IT - Выпуск 3
« : 18 Октября 2010, 13:09:16 »
УРА!

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

29
Вы имеете в виду, что журнал можно получить синтетически из других таблиц, тогда можно констатировать факт, а история вся затрется. Журнал для того и ведется, чтобы можно было отследить историю движения бланков с момента оприходования до момента списания

Именно об этом я и говорю.
Куда может пропасть история, если у вас будут храниться все факты движения (ну или изменения статуса)? Т.е. понятно, что "на складе" куда приходили бланки, их через некоторое время не будет, но документы о приходе их туда и расходе оттуда никуда же не денутся...

30
В вашем случае, если я все правильно понимаю, журнал операций может быть просто отчетной формой, которая, по идее, не должна очень беспокоить разработчиков и размер которой будет проблемой только Заказчика, который хочет видеть этот журнал именно в таком виде

Страницы: « 1 2 3 4 5 6 7 8 9 »