61

Идеи и мозговой штурм / Re: Методы оценки эффективности Аналитика

« : 16 Ноября 2009, 22:38:17 »

2Salar
Вы не могли бы изьясняться более конкретно - а то одни отсылы к толстым фолиантам, а конкретики не видно
1 "Бытует мнение, что создание, внедрение и использование различных шкал оценки персонала относится к "смертельным грехам менеджмента"." Тема так и не раскрыта
2 "Посмотрите у Деминга, кто в процентном отношении виноват в браке." Тема так и не раскрыта.

62

Идеи и мозговой штурм / Re: Методы оценки эффективности Аналитика

« : 16 Ноября 2009, 19:27:12 »

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

Огласите плз в какой бизнес-области работаете, делаете продукт или заказная разработка, методология разработки - используется ли agile-подходы, outsourcing или внутренняя разработка? Просто интересно в каком случае такой подход работает!!!!!!

Если применять подход дословно то это презумпция виновности аналитика))))

63

Идеи и мозговой штурм / Re: Методы оценки эффективности Аналитика

« : 16 Ноября 2009, 13:15:19 »

2Salar
а в двух словах можете сказать почему?

64

Идеи и мозговой штурм / Re: Методы оценки эффективности Аналитика

« : 16 Ноября 2009, 11:13:29 »

Kirillss, расскажите про свой опыт и то, как вы оцениваете эффективность.               

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

65

Идеи и мозговой штурм / Re: Методы оценки эффективности Аналитика

« : 16 Ноября 2009, 10:07:03 »

2Ontology Nazi
 Прежде чем повышать градус в обсуждении попытатесь понять собеседника...

На самом деле то что вы сказали про качество (его определение) относится к качеству УСЛУГИ. И, как мне кажется, не очень подходит для определения качества требований и, тем более, работы аналитика.
Никому ведь в голову не приходит оценивать качество кода через то насколько этот код соответсвует ожиданиям заказчика - оценивается продукт/решение целиком
Мне представляется что оценивать качество требований нужно через колво дефектов. Если затруднительно оценить колво дефектов через призму "много"/"мало" то важно хотя бы видеть что их колво падает...

Теперь еще одна проблема - "качество требований" != "качество аналитика". Точнее не всегда они тождественны. А тема всетаки про АНАЛИТИКА а не про требования!!!!

66

Идеи и мозговой штурм / Re: Методы оценки эффективности Аналитика

« : 16 Ноября 2009, 00:14:07 »

NB: Субъективные оценки важны и нужны, потому что качество — это соответствие ожиданиям ключевых ЗЛ, а ожидания всегда субъективны.

Качество -не есть соответствие чьим либо ожиданиям. Мне кажется, что качество аналитика - это
1 личные качества (ни за что не буду убирать из проекта человека если он не очень знает бизнес-область, но видно что у него глазки горят)
2 колво дефектов в требованиях (тут к сожалению ряд проблем - обнаруживать их(дефекты) иногда очень дорого и сложно или даже невозможно. А даже если их посчитали - то кто скажет много это или мало, ибо проекты неоднородны)
3 устойчивая тенденция к снижению колва дефектов (отсутствие эффекта пилы)

Короче вывод получается такой - что оценка аналитика (персоны, работника) есть действительно субьективная штука, только наверное не внешними (по отношению к проекту/процессу) личностями, а самой командой

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

Ни разу не согласен - например, одному попалась разработка справочников системы (относительно стабильной части) а другому - требования по новой (развивающейся) ветке бизнеса...
Кроме того, качество требований не равно тождественно качеству аналитика!!!!! Ведь они отчасти создаются и бизнесом (заказчиком)

67

Идеи и мозговой штурм / Re: Личностные качества аналитика(экстраверсия, интроверсия)

« : 12 Ноября 2009, 12:52:31 »

Очень хороший вопрос...
Думаю что никакой четкой методики по первому вопросу - нет. Должно быть желание человека и понимание про что это - аналитическая работа)))) Ну то есть хорошо бы прочитать Вигерса, SWEBOK, BABOK если речь идет об аналитике в IT
Во втором случае (аналитик обьявляет себя уже состоявшимся) - наверное стоит попросить тексты написанные им, попросить описать проекты, процедуры взаимодействия с другими ролями проекта.

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

Но мне кажется что сейчас работодатели в первую очередь интересуются опытом и знанием в той предметной области куда набирается аналитик

На SECR-2009 был доклад по похожей теме (несколько более общей, правда)
http://cee-secr.org/invited-talks/arkhipenkov/

68

Для всех / Re: Кто я?

« : 05 Ноября 2009, 13:07:23 »

Это каким образом?

В MSF сбор требований и контроль их выполнения лежит на роли Product Manager (по крайней мере в MSFv3) Далее из таблички все вытекает А Program Manager это если не изменяет память есть аналог Project Manager в нашей терминологии

69

Для всех / Re: Кто я?

« : 05 Ноября 2009, 12:40:55 »

Классификация вполне соответствует и моему пониманию. На тему совмещения должностей есть в MSF любопытная табличка Из нее в частности вытекает что совмещение аналитика и руководителя проекта(PM) нежелательно. Мой опыт (в данном случае горький!) подтверждает это.


PS Кстати вопрос. А какие есть противопоказания для совмещения ролей Аналитика и Архитектора? Ну конечно в проектах среднего размера

70

О Сайте и Форуме / Re: ДР сайта 2009 - подготовка

« : 03 Ноября 2009, 11:43:42 »

2bas
А примазаться к системщикам в Москве еще можно?

71

Реализация / Re: Задания разработчикам.

« : 30 Октября 2009, 11:14:40 »

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

Боюсь что менее общие слова можно сказать только зная конкритику:(

72

Примеры / Re: тестовый пример "типография"

« : 27 Октября 2009, 10:26:54 »

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

Относительно "понятности" или "чистоты" UML - если речь идет о user cases то важнее понятность если речь идет о генерации костяка кода по диаграммам то кончно от "чистоты" никуда не открутишься

73

Примеры / Re: тестовый пример "типография"

« : 26 Октября 2009, 22:22:20 »

Много букв - это утомительно. А ДВИ можно на стену повесить и любоваться. =) Станции и линии метрополитена тоже "зачем-то" рисуют схемой, хотя, можно было бы текстом...))

Там связи всего лишь двух типов - переместиться на поезде и пешком (пересадка) - никаких двусмысленностей не допускается. А тут какието пять ВИ вызывают вполне серьезную полемику и неоднозначность!!!! Именно в таких случаях текст работает... А теперь представьте себе что вариантов будет не пять а сто пять и разбираться в такой схеме/схемах да еще при наличии наследований и прочих "прелестей" UML будет очень проблематично и говорить об однозначном прочтении таких диаграмм скорее всего не придется

PS сорри за много букв

74

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

« : 26 Октября 2009, 21:52:33 »

если мотороллер не ваш, то откуда вы знаете что знает заказчик а что нет?

75

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

« : 26 Октября 2009, 00:34:02 »

2 div
Я настаиваю на том что требования по отчетам должны формироваться на этапе проектирования OLAP решения или DW (т.е. когда не то что данных в OLAP системе нет - еще самих систем то нет). Невозможно понять какие витрины, какие факты и по каким разрезам (т.е. какие кубики) строить если нет понимания требований к отчетам. Другое дело на каком уровне определять эти требования.
Детализировать описание отчетности до уровня полей на этапе подписания обязательств (тут я может Вас не понял) - в век Agile както вот странно!!!!

PS а вы отчетность на чем делаете? В смысле на какомто продукте или сами кодируете?