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

×


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

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


Сообщения - bas

991
Круглый стол  "Какие нужны Аналитики?"
   
Когда: Чт, 19 Августа 2010 c 19:00 до 21:00

Практически в любой компании, которая занимается разработкой крупных ИТ проектов, есть человек, который собирает/анализирует/документирует/управляет требованиями. Роль Аналитика есть практически везде, но человек, который выполняет данную роль, может называться в каждой компании по разному.

На данном КС мы хотим понять:
1. Чем должен заниматься Аналитик?
2. Чем занимается Аналитик у вас в компании?
3. Кто такой Бизнес и Системный Аналитик? В чем различие?
4. Какие проблемы у вас есть с Аналитиками? И как их решать?
5. Как правильно разделить обязанности в компании?
6. Как Аналитик должен взаимодействовать с другими заинтересованными лицами?

Целевая аудитория:
Бизнес-аналитики.
Системные аналитики.
Менеджеры проектов.
Любой другой заинтересованный сотрудник любой ИТ-компании.

Также на КС устроим коллективный обмен визитками. Всем брать визитки обязательно, а у кого их нет, то рисовать на А4 :)

Ведущий КС: Заборов Михаил, Компания «Заказные ИнформСистемы»
Дата и время проведения: 19 августа 2010 года с 19:00 до 22:00
Место проведения: 01990, Москва, Архангельский переулок, 1/1/9, строение 1, офис 423. Компания «Заказные ИнформСистемы».

Просьба всем писать ФИО в профиле, чтобы можно было выписать пропуска, иначе Вы НЕ попадете на семинар.
При входе на семинар иметь с собой паспорт.

Участие условно бесплатное.
Чтобы участвовать в семинаре, нужно сделать одно из следующего:
1. Написать отзыв о предыдущем событии Сообщества Аналитиков в своем блоге (ссылку оставляйте здесь)
2. Прорекламировать КС и ресурс uml2.ru в своем блоге или другом публичном ресурсе(ссылку оставляйте здесь)
3. Сделать (договориться о) что-то полезное для сайта uml2.ru
http://www.uml2.ru/forum/index.php?topic=1643.0
4. Подготовиться к КС и активно в нем участвовать
5. Задать вопрос здесь на КС

Регистрация обязательна здесь.

992
Если проблем нет, то зачем развивать отдел? Для чего это нужно?
Нужно сначала с этим определиться.

993
Анатолий,

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

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

Откуда берутся потребности?! А как раз из проблем или неиспользуемых возможностей. Появилась проблема, я хочу от нее избавиться (потребность). Но заказчик скорее всего будет говорить именно о потребности, но нужно докопаться до корневой проблемы и уже потом найти пути ее решения.

995
Коллеги,

Я закончил формализацию модели компетенции Аналитика, котрую мы обсуждали на ЛАФ:
http://lib.uml2.ru/%D0%9A%D0%BE%D0%BC%D0%BF%D0%B5%D1%82%D0%B5%D0%BD%D1%86%D0%B8%D1%8F_%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%B0#.D0.A1.D0.BC._.D1.82.D0.B0.D0.BA.D0.B6.D0.B5

Прошу дополнять и корректировать.

996
Понятно, что ТЗ не полное, но направление правильное. Мне понравилось.

Только ДСостояний немного не верная. Если вы хотите показать, что в состояние Неактивен Дефект может перейти из любых состояний, то нужно использовать Compound States см. здесь:
http://www.sparxsystems.com/resources/uml2_tutorial/uml2_statediagram.html

998
Не за горами крупнейшее событие от Микрософт.

1000
Интересное забугорное исследование по использованию UML в организациях:
http://www.projectpragmatics.com/Home/resources-for-you-1/the-uml-survey-results-are-in

1001
Коллеги,  на Wiki (http://uml2.mytrac.ru) есть два пустых раздела:
* Знания и Навыки Аналитика?

* Обязанности Аналитика?
http://uml2.mytrac.ru уже не актуальна (нужно написать об этом) сейчас вся БЗ накапливается на lib.uml2.ru

На семинаре Лаф-2010 я представлял наши наработки в этой области, в частности, описание позиции аналитика (аналитика требований), список навыков и знаний, которыми он должен обладать и т.п. Весь матиериал является результатом компиляции наиболее разумных (с нашей точки зрения) положений книг и статей в этой области. Если вы сочтете это стоящим внимания, я готов предоставить эти материалы  
В новой БЗ есть раздел "Компетенция Аналитика":
http://lib.uml2.ru/%D0%91%D0%B0%D0%B7%D0%B0_%D0%B7%D0%BD%D0%B0%D0%BD%D0%B8%D0%B9_%D0%BF%D0%BE_%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7%D1%83
Его можно/нужно наполнять. Твои знания будут только кстати. Прочти вот этот пост плиз:
http://www.uml2.ru/forum/index.php?topic=202.msg22844#msg22844

1002
Вопрос как бы организационного плана. Вот написал кто-то статью, она будет как-нить предмодерироваться? А то выложить то можно, а потом начнутся жаркие споры. И вообще, как процесс добавления регламентриуется - захотел, добавил статью/раздел/элемент глоссария?
Как раз куратор и должен этим заниматься, если он сомневается, то привлекать экспертов в помощь из Сообщества.

1003
А зачем нам в принципе оставлять старую цель, если она достигнута? Почему мы можем захотеть это сделать?
Хорошо. Давай уйдем из медицины, где мы ничерта не смыслим, в область деятельности предприятия. Как правило при орг изменениях, разработки ПО  и т.д. на предприятии смотрятся текущие проблемы и их как раз решают (ставят целью решение этих проблем в начале). Кстати, не факт, что от решения данной проблемы будет лучше всему предприятию. Но мало кто задумывается о том, что если мы решим эту данную проблему, то что потом? Искать новые проблемы, опять ставить новую маленькую цель и бежать до нее? Т.е. я предлагаю смотреть всегда чуть шире, не в рамках текущих проблем, а в рамках стратегических целей.

1004
Саша, с какой целью ты открыл эту тему? У тебя какая-то проблема?
Цель была - спровоцировать дискуссию. У меня возникла мысль (можно сказать проблема): я всегда отталкивался от проблем и потом формулировал цель в контексте разработки ПО, но как-то перед сном я подумал, а верно ли это? Вот так и возник длинный тред :)

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