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

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

Второй случай - меню справа/слева. Заказчик ни с того ни с сего (как потом оправдывается перед ПМом аналитик) решает, что меню должно быть не слева, а справа. Но, как говорил Воланд, ни с того ни с сего ничего на свете не происходит. Конечно же, принять решение о том, что меню должно быть справа, заказчика сподвигли совершенно объективные обстоятельства, не выявленные аналитиком первоначально. В данном случае ("я тут полазила по сайтам и хочу...") - тенденция моды на дизайн сайтов.
Я совершенно уверен, что все так называемые "неожиданные изменения хотелок" заказчика на самом деле неожиданны только для аналитиков, квалификация и опыт которых недостаточны для данной работы. Конечно, в случае сложных и новых систем просто в природе может не существовать достаточно квалифицированного аналитика, чтобы все требования выявить с первой итерации. Но тенденция именно такая - чем лучше аналитик, тем меньше "неожиданных" изменений возникнет.

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

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

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

P.S. Возможно термин "целостное решение" примирит оппонентов

Лично мне больше импонирует оценивать эффективность сотрудника по связке:

Поставленная цель - Достигнутый результат.

Но такой подход не менее субъективен, чем обсуждаемые выше, и также оставляет открытыми очень и очень много вопросов, включая:

• правильную постановку целей;
• трудозатраты, потраченные на достижение цели;
• различия между целями при сравнении эффективности нескольких сотрудников;
• и т.п.

Ведь по сути, в большинстве случаев важен именно результат.

По поводу запросов на изменение...
А как вам такой случай - заказчик пустил аналитиков только на один из своих объектов, с мотивацией - у нас бизнес процесс единый и этот объект лучший. На все наши доводы, что дайте нам хотя бы сделать экспресс анализ нескольких объектов для получения сравнительной оценки только отмахнулся.
Что имеем в итоге - по закону подлости это оказался единственный объект, в котором отсутствовал важный элемент бизнеса. В итоге получили серьезную проблему и МНОГО запросов на изменение. Но аналитик не виноват...
Если уж судить работу аналитика по количеству запросов на изменение, то надо брать каждый (запрос) и анализировать его природу. Трудоемкая работа.

По поводу запросов на изменение...
А как вам такой случай - заказчик пустил аналитиков только на один из своих объектов, с мотивацией - у нас бизнес процесс единый и этот объект лучший. На все наши доводы, что дайте нам хотя бы сделать экспресс анализ нескольких объектов для получения сравнительной оценки только отмахнулся.
Что имеем в итоге - по закону подлости это оказался единственный объект, в котором отсутствовал важный элемент бизнеса. В итоге получили серьезную проблему и МНОГО запросов на изменение. Но аналитик не виноват...
Если уж судить работу аналитика по количеству запросов на изменение, то надо брать каждый (запрос) и анализировать его природу. Трудоемкая работа.

В данном случае это не проблема аналитика, а тупость заказчика. Если при обсждении ТЗ он не заметил того что там отсутствует выжный аспект бизнеса.
А по поводу оценки эффективности, то я выше писал о том что заявки на доработку диференцируются. Анализируются их причины. По поводу трудоесмкости, я бы не сказал что это трудно. В любом случае когда возникает какая либо задача(запрос на доработку), то явно или неявно задается вопрос: "А почему заказчик это хочет, зачем оно ему и почему не сделано раньше?". Поэтому это как бы побочный результат от основного процесса. Плюч ко всему необезательно переводить данный показатель в числовые значения. Его можно использовать для получения обшей картины работы аналитика/ов.

А как вам такой случай - заказчик пустил аналитиков только на один из своих объектов...
Что имеем в итоге - по закону подлости это оказался единственный объект, в котором отсутствовал важный элемент бизнеса. В итоге получили серьезную проблему и МНОГО запросов на изменение.

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

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

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

Ну не все так просто и очевидно именно по этому примеру - ТЗ и договор подписывались после того, как проект был реализован на 90%. Это называется "пролезть через черный вход", когда один из топов решает автоматизировать что-то и в рамках своей компетенции "помогает" потенциальному исполнителю создать ПО, а потом склоняет остальных топов к покупке "готовой" системы. Ну это так... Если кому интересно...
Если по теме.
Наверно, можно оценить эффективность аналитика по количеству запросов на изменение, вот только анализ этих самых запросов должен быть очень качественным.
LastLegion86, а можно пару уточняющих вопросов - т.е. вы анализируете каждый запрос на изменение и типизируете (дифференцируете) его. Кто участвует в этом процессе (РП, нач. отдела аналитики, ведущий разработчик, архитектор или...).

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

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

При работе по найму первым, что я делала, получив отчет заказчика о тестировании очередной версии - разбрасывала замечания в три кучки (какие именно, писала выше).
Если пользоваться моим примером, то некоторое представление об эффективности даст соотношение размеров кучек.

Не нашлись описания про кучки ((
Если не сложно, можно ссылку или повторное описание? А то не понятно, как соотношение количества замечаний разных типов друг к другу могут помочь в определении эффективности...

А как вам такой случай - заказчик пустил аналитиков только на один из своих объектов, с мотивацией - у нас бизнес процесс единый и этот объект лучший.

А это, как нам Гриша пояснил на конференции ReqLabs, - "Персональные риски аналитика" . Спасибо ему, хороший был доклад!

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

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

У нас релизная схема работы. То есть все изменения вводятся поэтапно. То есть, если заказчик (тут имеется ввиду сотрудник нашей фирмы который инициирует доработку, например начальник отдела закупок) хочет что - либо доработать в ИС он пишет заявку. Заявка рассматривается на предмет критичности для бизнеса. И если она кретична (какой то явный баг мешающий функционоровать бизнесу) то она сразу берется в работу (такой хот фикс), если заявка некритична (например изменилось законодательство и бухгалтерия должна перейти на другую форму отчетности к 2011 году), то такие заявки собираются и раз в 2 месяца происходит их обсуждение, в котором принимают участие заявители, начальник отдела сис. анализа, тим лид програмеров, некотороые аналитики. Там каждая заявка рассматривается, оговариваются сроки реализации (то есть этот или следующий релиз, или вообще через 2 релиза и т.д.), назначаются ответственные лица ( у нас нет PM в явном виде, часть их фукнций берет на себя аналитик, а часть заявитель. Аналитик контролирует сроки и со всеми договаривается, заказчик занимается финансовыми вопросами. ) и решается ряд других вопросов. В результате подобного обсуждения становится понятно в чем причина заявки. Вобщем как-то так .

2LastLegion86

Ага процесс становится понятнее....
Некоторые замечание/мысли
1 Какова средняя трудоемкость доработки (если не секрет конечно) в человеко-месяцах например.
2 Оценка колва запросов на изменение по Вашей методологии будет скорее характеризовать тройку (персонал автоматизируемого подразделения,аналитик,автоматизируемый бизнес). Кстати а аналитики могут участвовать в автоматизации разных бизнес подразделений или в основном "сидят" в "своем" бизнесе?
3 Для такой методы оценки должна быть хорошо отлажена трассируемость требования-фича-релиз-баг. Ну то есть если у вас эта прослеживаемость есть то большой комплимент вашему IT!!
4 Какие последствия (финансовые,организационные) у Вашей оценки аналитика?

kirillss

1. Средняя труоемкость порядка 4 - 6 человекомесяцев.
2. Конкретно аналитика характеризует определенная часть от заявок на доработку. Аналитик участвует в автоматизации разных бизнес-подразделений.
3.  Не совсем понимаю что значит 'Для такой методы оценки должна быть хорошо отлажена трассируемость требования-фича-релиз-баг'. Поясните плиз.
4. Последствия. Наверно как и везде. Изменение в показателях KPI и как следствие этого уменьшение или увелечение размера примиальных. Других прецедентов пока не было.

kirillss
3.  Не совсем понимаю что значит 'Для такой методы оценки должна быть хорошо отлажена трассируемость требования-фича-релиз-баг'. Поясните плиз.

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

kirillss
Тогда у нас действительно хорошо отлажена трассируемость. Хотя как показывает практика, баги всплывают довольно быстро ( в следующим или через 1 релизе). Плюс существует четкая привязка аналитика к тому или иному проекту.

IMHO проблема в том, что качество требований зависит не только от системного аналитика, но и ещё от множества людей и факторов. И выделить влияние на него системного аналитика трудно, хотя и наверняка возможно.

В целом согласен, но IMHO часто будут важные исключения, к-рые нужно учитывать. Ну например:

1.   Оценка требований продукт-менеджером и менеджером проекта относительно общего качества и эффективности продукта на рынке после разработки продукта.

Для менеджера продукта - системные требования отвратительные: в них не вошла и половина того "турбулентного потока сознания", который он выплеснул на системного аналитика. Ну и что, что это потому что архитектор с ведущим разработчиком сказали, что реализовать невозможно.
Для менеджера проекта требования - отвратительные, т.к. чтобы их реализовать, придётся работать много и напряжённо, и риски большие: проект можно не сдать в срок, а можно и вообще не сдать. Ну и что, что именно это нужно Заказчику.

2.   Отзывы ключевых клиентов о реализации процесса управления требованиями
3.   Показатели удовлетворенности клиентов

Для ключевого клиента требования отвратительные: его "хотелки" не будут реализованы сейчас же, как он хотел! Клиент этим не удовлетворён, ну и что, что он сменил "элитную" поддержку на самую дешёвую, и хочет сделать из АСУ склада систему SCADA. Да к тому же он же написал "сделайте, чтобы мне было хорошо, нажимаешь кнопку и ага!", чего уж непонятного, а этот глупый системный аналитик зачем-то расспрашивает...

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

План не соблюли! Хотели сделать за неделю 20 UC на 15 страниц, а пришлось 3 месяца делать 1500 требований и UC на 2000 страниц. Ну и что, что оказалось, что это - естественная сложность предметной области, помноженная на то, что решили делать подробное ТЗ для аутсорсеров...

5.   Контроль расползания требований, связанный с пропущенными требованиями и просачиванием "неформальных" требований в проект

Требования "расползлись", разработчики всеми правдами и неправдами добились того, что в SRS прошло их представление о том, что нужно Заказчикам. Ну и что, что именно благодаря этому продукт имел оглушительный успех.

По сумме 5 оценок имеем 0 из 10. При успешном продукте. Увольняем?