Статьи

Рекомендации в виде размышлений о методах контроля работы аналитика на ранних этапах выполнения проекта и оценке качества работы аналитика.

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

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

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

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

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

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

ПМы, которые думают, что они хорошо разбираются в работе аналитика, или не доверяют своим подчиненным, делают полную проверку документа – т.е. читают его от начала и до конца. Это, несомненно, метод, хотя не очень быстрый и не единственный.

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

Второй объективный фактор контроля хода работы – это анализ покрытия. Этот метод работает только в случае, если:

1. на входе в начале проекта вы получили от заказчика требования (или другой подобный документ)

2. импортировали исходный документ в систему управления требованиями

3. отдельно от исходного документа начали разработку вашей версии детальных требований/спецификации в той же системе

4. проставляете связи от требований в вашем документе к требованиям в исходном документе

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

Дальше уже можно проверять собственно сам документ целиком. Для приблизительной оценки готовности документа и качества работы аналитика можно считать ошибки и замечания, сделанные в процессе проверки. А можно использовать атрибуты – например, в системе управления требованиями добавить новый атрибут и назвать его «статус проверки». В ходе проверки заполнять этот статус для каждого требования, и после проверки смотреть, какой процент требований в документе не прошел проверку, а какой нет. Такие статусные атрибуты можно также добавить для согласований с заказчиком, разработчиками и тестировщиками.

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

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