Что такое правильная отчетность?

Очень часто заказчик или менеджмент разного уровня жалуются на то, что им непонятен статус проекта. Вроде бы много информации есть, а все равно непонятно. Не говоря уже об известной байке что «90% времени работа сделана на 90%». Или же на выдачу отчетности уходит много времени с «ковырянием» каждый раз в письмах, тайм и баг трекерах. Предлагаю рассмотреть вопрос — что же такое правильная отчетность. Постарался сгруппировать по категориям, не претендую на истину, несколько соображений.

Отчетность соответствует форме сотрудничества.

  • В проекте с контрактом Fixed Price больше интересует успеваемость в срок, расход бюджета по проекту в целом, запросы на изменения. Соответственно, заказчика не должны волновать вопросы типа: кто и сколько часов работает, кто что делает. Главное – результаты, оговоренные в контракте.
  • При долговременном сотрудничестве по развитию и поддержке какого-либо продукта обычно есть выделенная команда. Здесь уже больше интересуют параметры качества и своевременности поддержки, кто на что способен, кто что делает. А вопрос обработки запросов на изменения скорее всего отсутствует, так же как и в меньшей мере интересует бюджет, а сроки относятся только к конкретным задачам.

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

Отчетность помогает принимать решения

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

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

Инструментарий настроен

Теперь обратимся к практической стороне. Откуда берутся данные для отчетов? Все относительно просто — львиная доля данных должна находиться в системах тайм, таск, баг трекинга. Как они туда попадают? Тоже несложно – при правильной декомпозиции работ и при хорошо настроенном workflow статусов и ответственностей данные попадают в эти системы как бы сами собой.

Давайте посмотрим на примерах:

  • Наличие полей плановых и фактических трудозатрат позволяет судить о точности оценок, скорости работ, а также опосредованно о разнице планового и фактического бюджета
  • Наличие поля «Defect Origin» (Происхождение дефекта) позволяет приписать каждый дефект к виду работ, т.е. из-за чего дефект произошел. Что в свою очередь несложным запросом позволяет сказать с каким видом работ наибольшие проблемы, т.е. что нужно улучшать в первую очередь
  • Наличие градации дефектов по уровням серьезности плюс временнАя статистика обнаружения и устранения дефектов позволяет оценить так называемую «сходимость дефектов». Если графики обнаружения и устранения дефектов сходятся, то можно оценить когда же мы закончим устранять дефекты, если расходятся, то, вероятно, нужно переосмыслить состав команды, архитектуру, процессы работы и т.п.
  • Совсем уж высший пилотаж (но не настолько сложный, как может показаться), если в видах работ присутствуют такие как, например, инспекция требований, исправление дефектов в требованиях, инспекция кода, исправление дефектов в коде. Тогда можно вносить временнЫе характеристики – плановое и фактическое время, и регистрировать дефекты. Обычно дефекты в спецификациях и коде нигде не регистрируются для последующей оценки, а зря. Ведь с точки зрения качества проекта все равно где есть дефект и все равно кто его нашел.
  • Путем несложной настройки workflow и вносимых данных можно оценивать скорость и качество поддержки. ВременнЫе характеристики – по timestamp, качество – по количеству раз, которое один тот же запрос на поддержку был открыт (переоткрыт). Чем меньший % переоткрытых, тем лучше.
  • Можно раскрыть большую и интересную тему стоимости качества, т.е. сколько трудозатрат уходит на собственно говоря производство продукта, стоимость качества и стоимость плохого качества (устранения дефектов).

Список можно продолжить. Главное изначально понять какие данные могут быть потенциально нужны и настроить инструментарий соответствующим образом. Как внесение данных, так и получение данных. Чем больше автоматизации – тем лучше.

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

Tags: , , , , ,

Comments are closed.