• Снова про отчеты: кто и зачем их читает

    Posted on November 13th, 2008 Александр Орлов No comments

    HPM Reality Show: открытый тренинг проекта Happy PM, 12-15 декабря 2008, С-Петербург

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

    Отчеты можно разбить на два вида:

    • Индивидуальные – их пишет каждый сотрудник про себя.
    • Групповые (или проектные) – их пишет менеджер команды (проекта).

    Для чего нужны отчеты? Тут все просто – чтобы их кто-то читал. :)

    1. Индивидуальные отчеты. Кто может захотеть прочесть индивидуальные отчеты? Тут тоже все просто:

    Заказчик – чтобы посмотреть, за что он платит деньги при почасовой оплате. Если почасовой оплаты нет, и проект большой, то индивидуальные отчеты каждого сотрудника заказчику, скорее всего, не нужны. Заказчику интересно будет почитать групповой отчет о статусе проекта.

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

    Если же проект не требует большой координации (хей, гайз, такое тоже бывает :) ), то отчеты в формате Done/Planned/Issues являются аналогом устных отчетов на Scrum митингах – структура-то та же.

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

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

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

    Автоматические системы. Казалось бы, можно всю эту информацию по задачам и времени их выполнения хранить в автоматических инструментах – Алекс тут абсолютно прав. Если это сделано – отлично! Если есть место, где любой человек может получить срез проекта и посмотреть, кто, что и когда делал – это супергут! А то вдруг менеджеру, не приведи Господь, кирпич упадет на темечко – откуда тогда брать информацию? :)

    Ну, правда, перед тем, как использовать мега-систему учета заданий, ее надо будет внедрить, преодолеть сопротивление сотрудников и пр., и пр. И главное, им все равно придется что-то туда писать. :) Про тот же статус, время, проблемы и пр. Мне это всегда казалось не стоящим того, поэтому пользовался привычным Аутлуком.

    Более того, если в каком-то задании происходит что-то сложное, то в автоматическом отчете будет видно только то, что Вася почему-то тратит на это задание все больше и больше времени. Чтобы понять, что происходит, надо будет лезть в описание задания и читать, какие там артефакты Вася оставил. Если у Васи хромает системное изложение мыслей, или он про свои проблемы в автоматическую систему не пишет, то заказчик потом будет сильно удивляться и задавать вопросы. Менеджеру легче – он, скорее всего, будет в курсе, т.к. поймает Васю и все у него выяснит.

    Куда отчитывать Impact? Есть еще один тонкий момент. В случае формальный аттестаций при написании Performance review или сочинения сотрудника на тему “как я провел год, и почему мне надо повысить зарплату” отчета от автоматического инструмента будет недостаточно. Инструмент покажет что? – Какие задания выполнены, и сколько на них потрачено времени.

    Однако, ключевым в performance документах является impact того, что сотрудник сделал. То есть не то, сколько часов он отработал, не то, сколько строк кода он написал, а влияние его работы на проект. Если сотрудник придумал скрипт, который сэкномил два человека-года работы, то он большой молодец! Даже если на придумывание скрипта он потратил 10 минут, и еще два часа его писал.

    Я не видел ни одной автоматической системы учета заданий, где как-то учитывался бы impact. И слабо представляю себе, как это можно адекватно сделать. Поэтому, мое мнение, при любой автоматической системе учета заданий, сочинение про impact писать придется по-любому. Хорошая новость в том, что придется это делать, скорее всего, не чаще пары раз в год. :)

    2. Групповые отчеты. Кто может захотеть прочесть отчет от группы/проекта?

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

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

    Менеджеры соседних команд/проектов – правильные менеджеры часто интересуются тем, что происходит сбоку, с тем чтобы: а) можно было что-то перенять, б) можно было предложить что-то что есть у них, и тем самым и пользу принести, и засветиться.

    Устроит ли их мега-статистика из 100 пунктов по тому, кто сколько часов на что потратил в вашем проекте? Нет – они просто не будут это читать – по той же причине, что и большой начальник.

    Для групповых отчетов мне видится идеальной форма Summary/Details. Поскольку пишет ее менеджер, пишет нечасто, то на команду нагрузки не ложится. А менеджеру полезно попрактиковаться в эпистолярном жанре. :)

    Резюмируя:

    • Отчеты Done/Planned/Issues – иногда заменяют статус апдейт митинги. Но чаще реально не нужны.
    • Автоматические системы отчетности и учета заданий и времени – отлично, если есть на примете адекватный инструмент.
    • Некоторых stakeholder’ов отчет от автоматической системы не устроит. Им очень поможет литературный отчет в виде Summary/Details.

    Leave a reply

    You must be logged in to post a comment.