61

Обучение / Критерии профессионального роста аналитика

« : 26 Сентября 2007, 19:26:40 »

Хотелось бы послушать мнение уважаемого сообщества, как можно понять, что аналитик профессионально вырос? Что сейчас он "аналитит" гораздо лучше, чем, например, год назад? По каким критериям, м.б. метрикам, это можно было бы понять, на ваш взгляд?

Другая сторона вопроса - если такие критерии можно сформулировать, можно ли их установить в качестве ориентира для роста аналитиков?

62

Системный Анализ и Требования / Проверка качества требований в проекте

« : 26 Сентября 2007, 18:32:53 »

Коллеги, вопрос к сообществу состоит в следующем:
Какими методами проверки качества требований вы пользуетесь на практике?

Теоретические вопросы качества требований вполне хорошо изложены в литературе, в т.ч. краткая выжимка по теме качества есть и на данном сайте: http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=341.0

Однако теория - теорией, а что в жизни? Вот приходит некий аналитик и говорит: "Я провел обследование заказчика и написал ТЗ". Как вы на практике решаете вопрос, как понять, это хорошее ТЗ или не очень?

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

Или, может, еще что-то используете?

63

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

« : 20 Сентября 2007, 16:54:44 »

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

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

Насчет адаптивного документа - я не писал, что "он не нужен". Но, честно говоря, я не до конца понимаю, что за документ вы хотите написать.
Изначально термин "адаптированный документ" возник в ответе Galogen'а:

Теперь насчет представления документа заказчику в виде UML, eEPC, IDEF0 и т.п. Да, конечно, заказчик совсем не обязан понимать все это, потому он должен требовать описания втакой форме, которую он понимает! Если это не возможно или обременительно )за предоставления адаптированного документа разработчик может потребовать некоторую сумму сверху), заказчик может воспользоваться услугами независимого эксперта или иметь в штате достаточно грамотного в этой области человека. Вне всякого сомнения заказчику совершенно не имеет смысла знать как разрабатывается ПО.

Здесь речь про то, что если "заказчик UML не понимает", то надо написать требования тем языком, который он понимает. Но мне в данном случае кажется, что порядок действий несколько перепутан. Опять же, сошлюсь на "буквари", требования изначально и должны излагаться на языке бизнеса. Именно так, чтобы их понял прежде всего заказчик. А дальше вы можете уже для проектной команды сделать отдельный документ, где перевести все требования на технический язык.

Вы же говорите о документе, в котором:

... планирую кратко описать этапность проектирования ПО, выделить этап сбора требований и дать понять важность этапа, на сколько важна детальность описания, к чему ведут ошибки описания, описать что Заказчик не получит Систему вовремя если не достаточно подробно он его изучит и согласует.

Это не документ с требованиями, это некий организационный документ. Я бы сказал, что-то типа Устава проекта. Если вы его напишете и согласуете с Заказчиком, вреда не будет. Если же вы сможете заставить его еще и выполнять те процедуры, которые вы там пропишете - можете смело ставить себе памятник при жизни, набирать Учеников и писать книгу "Как заставить заказчика исполнять регламент проекта". 

В-общем, пишите, да обрящете. Либо ваш документ заработает, либо вы приобретете ценный жизненный опыт

64

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

« : 20 Сентября 2007, 16:39:26 »

У нас так и есть, каждую категорию представляет лицо из отдела ИТ. Вот только этот человек не всегда может грамотно разъяснить и объяснить несмотря на то что он из ИТ.

Мы у себя такую ситуацию идентифицируем как один из стандартных рисков при выявлении требований. "Лицо из отдела ИТ" не может выступать представителем какой-либо категории пользователей, за исключением категории "пользователи отдела ИТ". Потребности конечных пользователей должен выражать в проекте конечный пользователь, а не ИТ-шник. Тут ситуация сложная. Сотрудники отделов ИТ заказчика - это наши союзники - им, в итоге, внедрять и поддерживать то, что мы сделаем. Поэтому дружить с ними надо однозначно. Но то, что они не могут представлять интересы "бизнеса" - это, по-моему, очевидно. Достаточно посадить рядом человека из бизнеса и ИТ-шника, который думает, что он понимает потребности бизнеса, и попросить ИТ-шника рассказать своими словами, как устроен бизнес. В 90% случаев человек из бизнеса через пол-минуты начинает нервничать и встревать со словами "да нет же, все совсем не так"... Это типовая ситуация; смотрим это кино у каждого первого заказчика. Привлекайте ИТ-шников как экспертов. Но не как представителей категорий пользователей

65

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

« : 19 Сентября 2007, 22:24:24 »

Иногда нет возможности сесть с каждым согласующим и разъяснить ему все особенности разработки документа требований. Когда согласующих 1-2, то да это оптимальнее, но когда 4-8 то думаю уже разумнее создать именно "адаптивный документ". В моем случае на всем нашем проекте в данный момент с нами взаимодействует порядка 40-60 человек из бизнеса(при этом есть "текучка" в данном круге, ~5% в месяц). Ко всем не подойдешь... 

40-60 согласующих - это какой-то страшный перебор. Надо поставить перед руководством проекта со стороны заказчика жесткое требование сократить число согласующих до разумного. На практике, я бы сказал, что при наличии примерно 7-10 согласующих лиц у заказчика приходится вводить внутри команды отдельную проектную роль - "согласующий", и на 100% специальный выделенный человек будет ходить по этим согласующим у заказчика, и с ними общаться. Иначе что-то согласовать в разумные сроки нереально. Причем это от типа заказчика (гос / не гос), по-моему, мало зависит.

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

Ну, это я попытался дополнить высказывания "аксакалов форума", с которыми в этой ветке полностью согласен.

66

Бизнес-анализ и Целеполагание / Re: Модель потребностей в малых проектах по созданию публичных веб-систем

« : 19 Сентября 2007, 21:43:17 »

В условиях малого бюджета я бы подумал в двух направлениях.

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

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

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

67

Работа / Re: Литература по специальности

« : 24 Августа 2007, 15:48:33 »

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

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

Сразу встречный вопрос: а какая у Вас цель? Спасти мир или найти нормального аналитика?

Ну, нормального аналитика мы, понятное дело, найдем. Ну, или найдем "просто аналитика", а потом сделаем из него "нормального". Это не очень интересно обсуждать.

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

68

Работа / Re: Литература по специальности

« : 23 Августа 2007, 13:38:41 »

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

69

Работа / Re: Литература по специальности

« : 22 Августа 2007, 20:41:45 »

доминирующая гипотеза названа - UML, IDEF, ARIS? А почему? По тому, что в тексте вакансий это и требуется, не так ли?

Я подумал, может, мы такие странные, хотим управления требованиями, а все хотят UML, IDEF, ARIS.
Не поленился полезть на hh.ru, отобрал вакансии "аналитиков", стал открывать те из них, которые по сути подходят под понимание системного аналитика или бизнес-аналитика (не "менеджер интернет-проектов"). Хотел посчитать, в каком навскидку проценте вакансий хотят "UML, IDEF, ARIS", а в каком пишут про требования. Что вы думаете?!
5 вакансий мне хватило. Счет 5:0 в пользу требований. Ни одного упоминания "UML, IDEF, ARIS"! Но в каждой из пяти вакансий хотят "постановку требований" или "анализ требований" или даже "знание методологии требований". Можно, конечно, провести эксперимент в более строгих условиях, но мне при такой качественной картине все понятно.

Так что, извините, неправда ваша. Работодатель нынче хочет требований от аналитиков, а не только UML...

70

Работа / Re: Литература по специальности

« : 22 Августа 2007, 20:32:51 »

Хочу еще раз отметить: доминирующая гипотеза названа - UML, IDEF, ARIS? А почему? По тому, что в тексте вакансий это и требуется, не так ли?

Что-то я сильно сомневаюсь, что кандидаты так трепетно относятся к тексту вакансии. Сомневаюсь и в том, что по UML, IDEF и ARIS они читают книжки (думаю, что так же довольствуются институтскими лекциями или, в лучшем случае, курсами).

Уточнил насчет своей вакансии. Слов "UML", "IDEF" и "ARIS" там нет. А слова про современные методики управления требованиями есть.

Но гипотезу про то, что аналитики читают книжки по "аналитическим" технологиям, проверю. Буду теперь про это спрашивать. Спустя какое-то время предоставлю уважаемой аудитории статистику. Интересно же.

71

Работа / Re: Литература по специальности

« : 22 Августа 2007, 13:04:58 »

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

А какие еще есть гипотезы, что такое "системный анализ в IT сейчас"?

72

Работа / Re: Литература по специальности

« : 22 Августа 2007, 11:10:35 »

Насчет отсутствия Леффингуэлла в электронных магазинах...
Чтобы не рекламировать всякие подозрительные сайты, я вот так тут напишу:
http://www.yandex.ru/yandsearch?text=%EB%E5%F4%F4%E8%ED%E3%F3%FD%EB%EB+%EA%ED%E8%E3%E0+%E2+%FD%EB%E5%EA%F2%F0%EE%ED%ED%EE%EC+%E2%E8%E4%E5
Ну и найти и скачать заняло у меня меньше 10 минут...

73

Работа / Re: Литература по специальности

« : 22 Августа 2007, 10:59:42 »

Ну, и некоторые частные ответы

Давайте рассмотрим 2 случая - вы про какой?

Да, в общем, про оба. Особенной разницы на практике не заметил.

Ну а то, что программисты в основном имеют завышенную самооценку - это уже классика.

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

Преподаватель так и говорит - не читайте никаких книг, моих лекций достаточно. Я за вас все прочитал, понял, выделил. Мои лекции - это квинтэссенция!

Вот где собака порылась! Если серьезно, я согласен с тем, что на психологическом уровне это лучшее объяснение тенденции. Чтобы не очень ругать "нерадивых студентов", скажу за себя, грешного. Читать толстые книжки - нужно много времени. А его нету. Работа, семья, другие дела; ну в отпуске что-то почитаешь, ну, мучительно, по 10 страниц в день, что-то перед сном. Все равно "глотать" книжки не получается. А лекции (в бизнесе - сиречь, курсы, семинары) - как удобно, придешь, в уши тебе все разжеванное вложат, 2 часа - и свободен.

А по системному анализу, бизнес-анализу - ничего. Леффингуэлла нет и в электронных магазинах. Это понятно, кто хочет - тот найдет.

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

74

Работа / Re: Литература по специальности

« : 22 Августа 2007, 10:46:14 »

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

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

75

Работа / Почему аналитики не читают литературу по специальности?

« : 21 Августа 2007, 18:14:34 »

Собеседуя массу кандидатов на позицию аналитика, обратил внимание, что мало кто из кандидатов изучал какую-либо литературу по специальности (бизнес-анализ, системный анализ). Ориентировочная оценка - не более 10-20% приходящих. Собственно, вопрос: почему так?

Собирается, допустим, программист устроиться на новую работу: узнает из вакансии, что на новой работе нужно знание, предположим, C#. Даже если человек в данный момент не знает C#, большинство делают вполне очевидную вещь: идут в магазин, покупают книжку по данной технологии и начинают ее изучать, ну, хотя бы чтобы термины понимать. Почему у аналитиков все по-другому, и вопрос о профессиональной литературе вызывает глухое недоумение (типа "а вы на Луну летали?" - "нет, а зачем...")

P.S. Обратил внимание, на самом деле, не я, а наш рекрутер, который взял у меня книжку Леффингуэлла и пошел читать, "чтобы разговаривать с кандидатами на одном языке". Учитывая вышеописанное, ну-ну...