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

×


Какие существуют показатели работы аналитика(Прочитано 52758 раз)
Доброе время суток!
Вопрос: Какие существуют показатели хорошей работы аналитика?Если конечно этот вопрос уместен.

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

И как тогда измерять работу аналитика?



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



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



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

т.е. получается тестировщикам будет выгодно, чтобы в системе было больше ненайденных багов до передачи ее в эксплуатацию.
Должно быть наоборот: тестировщикам должно быть выгодно, чтобы в переданной пользователям системе было МЕНЬШЕ багов. Поэтому их акцент должен быть направлен на усиленное тестирование системы ДО передачи ее в эксплуатацию.

Почитайте про "черную команду" у ДеМарко и Листера.
Лью воду...



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



т.е. получается тестировщикам будет выгодно, чтобы в системе было больше ненайденных багов до передачи ее в эксплуатацию.
Должно быть наоборот: тестировщикам должно быть выгодно, чтобы в переданной пользователям системе было МЕНЬШЕ багов. Поэтому их акцент должен быть направлен на усиленное тестирование системы ДО передачи ее в эксплуатацию.

Почитайте про "черную команду" у ДеМарко и Листера.

Так и я об єтом же. Чем меньше багов, которые найдет конечный пользователь, тем качественней поработали тестировщики. Конечно количество найденных багов ДО передачи в эксплуатацию - это показательно, но такой показатель не объективен и становится неадекватным, если конечные пользователи найдут ПОСЛЕ передачи в эксплуатацию еще больше или хотя бы парочку.
Успех - не окончателен, поражение - не фатально, мужество продолжать - вот, что имеет значение.



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



Как будете мерить?

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

Мерить на глазок :-)



для PM:
абсол. - бюджет проектов, выполненных без задержек по срокам и с необходимым качеством
относит. - соотношение бюджетов проектов, выполненных с опозданием, с неадекватным качеством, по отношению к бюджету качественных проектов без опозданий
Лью воду...



У нас принято мерить качество работы аналитика и качество самого аналитика по отзывам людей с которыми он контачит в процессе работы - как со стороны исполнителя так и со стороны заказчика. Если эти мнения более менее совпадают то это и есть качество работы аналитика,  если нет то начинают копать - почему... ну в общем некоторый процесс



у меня какое-то дежа вю. покопайтесь, тут уже была такая тема.



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



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

У нас принято мерить качество работы аналитика и качество самого аналитика по отзывам людей с которыми он контачит в процессе работы - как со стороны исполнителя так и со стороны заказчика. Если эти мнения более менее совпадают то это и есть качество работы аналитика,  если нет то начинают копать - почему... ну в общем некоторый процесс

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

Вот например у музыкантов все просто: лажа это когда человек поет и играет мимо нот. Она очевидна и ее можно услышать даже невооруженным ухом, хотя и не всем. Если нет нот, это называется импровизация - в ИТ это по-моему называется XP, или Agile :)

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

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

А вот удовлетворенность заказчика - фактор во многом мистический. Ее в попугаях не измеришь. Так что наверное лучше все-таки сосредоточиться на более формальных критериях :)



у меня какое-то дежа вю. покопайтесь, тут уже была такая тема.
Да.Тема поднималась тут http://www.uml2.ru/forum/index.php?topic=1824.0




А вот интересно что.
А каков минимальный порог?
Сколько минимально должен найти ошибок в месяц тестировщик? 1 , 2 или 100?
Сколько должен аналитик написать ТЗ в месяц?
Каково должно быть соотношение довольных и недовольных клиентов?Принцип 20/80?Или 50 на 50?





 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19