Ошибку мог допустить раработчик - тестировщики ее пропустили - а пнут аналитика.

доработка функционала - как-то на ошибку не тянет.
Я автора понял так - что доработка - это ещё внезапное желание заказчика, или когда заказчик говорит: ну блин, я же не про это говорил.

Да никак они у нас не используются!
Сам не знаю как их применять нужно по правильному - не дорос еще.
Я их делал исключительно для себя.

Управление рисками по модели риск-оптимувов не хотите попробовать?
Блин. И сослаться то не на кого, кроме своей статьи  и своего же семинара...

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

Круто. Посмотрите у Деминга, кто в процентном отношении виноват в браке. Результат вас неприятно удивит.

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

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

А какая разница в какой области?

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

.. параметр "количество запросов на изменение" ..бесполезен для отслеживания эффективности работы аналитика..

+100

Не забывайте что работа аналитика - не только и не столько сбор требований. Основная работа - на мой взгляд - построение МОДЕЛИ проектируемой системы. А все что до сих пор пришлось услышать касалось ИСКЛЮЧИТЕЛЬНО сбора требований.

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

Всего Деминга здесь, конечно, не пересказать, но несколько цитат для затравки привести можно.

Кто отвечает за качество? Ответ: высшее руководство. Качество продукции компании не может быть выше уровня, который был определён наверху.

Ранжирование — это фарс. Производительность труда на самом деле зависит большей частью от системы, в которой работает человек, а не от него самого.

Убеждение в том, что, если проблему нельзя измерить, то её невозможно решить, — это очень дорогостоящий миф.

По моему опыту, большинство проблем и возможностей улучшить ситуацию соотносятся примерно так: 94% приходится на систему (ответственность руководства) и 6% — на особенные причины.

Ошибку мог допустить раработчик - тестировщики ее пропустили - а пнут аналитика.

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

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

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

Я занимаюсь поддержкой и развитием внутреннего решения поддержки бизнеса ( CRM + ERP + шлюз для обмена с системами бухгалтерского и склодского учета). Работаем по системе "релизов" ( я к сожелению не знаю к каой методологии можно это отнести ) Из оутсорсинга есть несколько интернет проектов которые обмениваются данными с нашей системой.

Вот и программист - прочитает по-русски, а поймет "так". Потом "так" сделает.

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

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

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

1. По поводу неправильного понимания программистом. У нас существует практика проверки того что написал программист аналитиком ( то есть насколько написанный функционал соответствует изначально задуманному аналитиком).
2. Речь идет не о всех запросах на изменение, а о тех случаях когда запрос поражден некорректой работой разработанного функционала ( с точки зрения логики, а не реализации), либо когда разработаннный функционал не решает поставленной проблемы ( или решает ее некорректно). Опять же, если проблема изменилась после или в течении реализации, то это не считается ошибкой.
3. По поводу стрельбы из ружья, я бы не был так категоричен. Может быть это и не самый достоверный показатель, но лучьше чем ничего.

2Salar
Вы не могли бы изьясняться более конкретно - а то одни отсылы к толстым фолиантам, а конкретики не видно

Простите, а как вы собираетесь стать профессионалом, не читая толстых фолиантов? Конкретно Деминга и Голдрата читать нужно.

2 "Посмотрите у Деминга, кто в процентном отношении виноват в браке." Тема так и не раскрыта.

На это Григорий ответил. Мне остается только добавить, что Деминг неоднократно пересматривал свою оценку, все время увеличивая долю ответственности руководства за брак.
Игра "Красные бусы" - это модель иллюстрирующая это.

1 "Бытует мнение, что создание, внедрение и использование различных шкал оценки персонала относится к "смертельным грехам менеджмента"." Тема так и не раскрыта

СМЕРТЕЛЬНЫЕ БОЛЕЗНИ
...

3. СИСТЕМЫ АТТЕСТАЦИИ И РАНЖИРОВАНИЯ ПЕРСОНАЛА

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

"Управление по Целям" — зло того же порядка; "управление на основе страха" было бы более подходящим его названием. Результаты подобной практики следующие:

Развивается "близорукое" мышление, взращивается соперничество, интриганство и страхи, уничтожается перспективное планирование, разрушается дух команды; Одни люди испытывают чувство горечи, другие — отчаяние, некоторые работники переживают депрессию, из-за которой они неработоспособны в течение недель после получения оценки своей деятельности, причем они не в состоянии понять, в чем их вина. Эти методы несправедливы, т. к. они приписывают людям в группах такие различия, которые могут быть полностью обусловлены системой, в которой работает группа. (см. главу 30).

Может все таки найти книгу и прочитать?

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

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

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

В предыдущем обсуждении я нигде не говорил о багах произведенных программистами. В моем понимании запрос на изменение это определенная доработка функционала не связанная с ошибками в реализации (изменения в логике работы). А ошибка реализации, это баг ИМХО. 

Причем тут программерская логика? Да и не писал я нигде о том что я что то там думал о способах мышления других.

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

Простите, а как вы собираетесь стать профессионалом, не читая толстых фолиантов? Конкретно Деминга и Голдрата читать нужно.

Сергей, т.е. ты полагаешь, что без прочтения этих авторов ну никуда? И специалист не специалист?

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

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

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

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

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