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.