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

Продолжение…
Начало темы тут: Оценка эффективности работы аналитика - предпосылки

Если кому-то придет в голову спросить аналитика, чем он занимается. то он получит отличную возможность нарваться на долгий рассказ про процессы as is и to be, сценарии использования, требования, логические модели данных, прототипы пользовательских интерфейсов, шаблоны отчетов, алгоритмы конвертации чего-нибудь в кого-нибудь и т.п.

Но ведь это всего лишь перечисление артефактов, над которыми работает аналитик! – воскликнешь ты и будешь совершенно прав. И это не те знания, которые помогут нам понять, как оценить эффективность работы аналитика и по возможности научиться управлять аналитикой не только по планам, но и по фактам.

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

• уточнении бизнес-требований и определении границ (в широком смысле слова) ожидаемого решения;
  
• выработке идеи автоматизации, выраженной в виде предложений to be;
  
• детализации требований до уровня, достаточного для начала девелопмента.

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

Получается так, что заход за исходной информацией аналитик осуществляет в четырех конкретных случаях:

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

Три последних позиции делают аналитику итеративным процессом.

Попытка графически изобразить вышесказанное обернулась вот таким рисунком:

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

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

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

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

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

Осталось только рассказать, как это можно использовать. И это будет сделано ну прямо в ближайшие дни :)