Оценка эффективности работы аналитика – зачем и как

Тема получилась мало кому интересная, но я ее все-таки закончу.

Начало было тут: Оценка эффективности работы аналитика – предпосылки
Продолжение тут: Оценка эффективности работы аналитика – а чем он занимается и чего можно померить?

Прежде чем продать что-нибудь ненужное, надо сперва купить что-нибудь ненужное. Иными словами прежде, чем впаривать менеджменту или команде какие-то процедуры мониторинга аналитики, надо понять – а есть ли в этом необходимость.

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

  • аналитик много и безрезультатно общается с Заказчиком;
  • аналитик на вопросы о срыве сроков завершения работ рассказывает о неадекватности Заказчика;
  • ведущие специалисты (девелопер и тестер) готовы постичь результаты аналитики, но у них это не получается;
  • Заказчик динамит аналитика с согласованием результатов работы;
  • Заказчик не доволен результатами аналитики. Ну и / или ведущие специалисты не довольны результатами аналитики;
  • сделано много безрезультатных заходов согласовать результаты аналитики.

Если решение контролировать аналитику принято, то наиболее правильный вектор движения, который я могу порекомендовать выглядит следующим образом:

  1. До начала работ необходимо определить две простые базовые метрики: максимально допустимое количество итераций по результатам внутреннего согласования и максимально допустимое количество итераций по результатам согласования с Заказчиком. По первой нормальным значением является 2, по второй – 3. Далее нужно просто следить, чтобы эти цифры не были превышены.
  2. Необходимо аналитика обязать вести список вопросов и с какой-то периодичностью (скажем, каждый день или раз в два дня) снимать с этого списка общее количество вопросов и количество открытых вопросов. Имея такую информацию с зависимостью от времени, можно получить некоторый график сходимости, из которого будет понятно, успевает ли аналитик закончить работу к обозначенному сроку.
  3. Если в списке вопросов ввести небольшую классификацию из трех пунктов (вопросы аналитика, вопросы от лидов, вопросы от Заказчика), то можно будет наблюдать отношение между количеством вопросов, которые у аналитика возникли по ходу работы к количеству вопросов (замечаний, понятие вопроса надо смотреть ширше – issue), возникших у согласующих товарищей. Уверен, что спустя некоторое время в результате наблюдения можно будет выявить некоторое пороговое значение этого отношения, превышение которого будет семафорить о плохом качестве первоначальной аналитики.
  4. Интересно понаблюдать за отношением трудоемкости первоначальной аналитики к трудоемкости ее доработки по результатам согласования. По этой инициативе тоже уверен, что спустя некоторое время можно будет выявить некоторое критическое отношение.

Друзья, я понимаю что все это выглядит жутко банально, но поделитесь пожалуйста своим опытом – как все-таки контролировать ход аналитических работ?

Комментарии

  1. Сергей,

    Интересно пишите.
    Чтобы подискутировать, приглашаю делать репост наиболее интересных постов в Блоге Аналитиков:
    http://blogs.uml2.ru

    Если не сложно, то напишите плиз мне, чтобы была возможность пообщаться:
    http://baikin.moikrug.ru/

    Спасибо.

    ОтветитьУдалить
  2. "максимально допустимое количество итераций по результатам внутреннего согласования и максимально допустимое количество итераций по результатам согласования с Заказчиком" - не работает. Это индикатор надвигающегося факапа, но не более того.
    "вести список вопросов" - я так и делаю, причем вопросы туда может добавлять вся команда. Аналитики ненавидят этот маленький файл, потому что все на виду, но зато потом говорят спасибо за это же свойство.
    "Если в списке вопросов ввести небольшую классификацию из трех пунктов" - очень громоздко, имхо. Я веду два списка: один - вопросы к заказчику, второй - вопросы от команды. А классификация только мешает.
    "Интересно понаблюдать за отношением трудоемкости первоначальной аналитики к трудоемкости ее доработки по результатам согласования" - по идее у тебя громадный опыт уже накопился на эту тему?

    ОтветитьУдалить
  3. Гриш, так речь ведь и идет о метриках. А метрики - не более, чем индикаторы чего-то. По поводу списка вопросов - я тоже его всегда вел.

    Но мне не допирало в голову его вывернуть в график и сходимость посмотреть. Попробуй - классная вещь :) (если еще не пробовал ;) ).

    Вопросы надо, мне кажется, делить не "Заказчику" и "От команды" а "аналитику" и "от аналитика". Тогда можно будет понять, как успешно аналитик работает. А если все это еще по временной шкале резвернуть... :)

    По последней позиции у меня получается отношение где-то 4 : 1. Уверен, у тебя примерно такое-же. Мы-то одного поля ягода :)

    ОтветитьУдалить

Отправить комментарий

Популярные сообщения из этого блога

Карта компетенции аналитика

Драйв

Оценка эффективности работы руководителя проектов