Пятница – день отчётов

Привет!

Сегодня пятница. У меня пятница - день отчётов.

Я сейчас руковожу одновременно четырьмя “горячими” проектами. Под термином “горячие” я понимаю проекты, по которым ведётся очень активная деятельность, на которые направлены пристальные взоры начальства и заказчиков. По всем четырём проектам заказчики и начальство требуют от меня разного рода отчётность с разной периодичностью. По пятницам я всегда (ну… почти всегда) стараюсь выдавать заказчику отчёты в стандартной форме. Я верю в то, что периодическая отчётность является очень полезной практикой (даже если эти отчёты читает только менеджер со стороны заказчика) и вообще улучшает карму любого PM’а =)

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

Четвёртым проектом я управляю по классической методологии описанной в PMBOK – проект разбит на фазы, объём работ на каждую фазу зафиксирован, запросы на изменения (change requests) обрабатываются согласно ранее принятому регламенту, форма отчётности по утилизации ресурсов зафиксирована... На этом проекте заказчик не так активно вовлечён в процесс разработки продукта, поэтому количество информации в отчётах о прогрессе проекта должно быть больше, нежели в предыдущих трёх.

Сам отчёт состоит из двух частей – календарный план проекта (в формате MS Project) и собственно описание текущего статуса (в MS Word).

С календарным планом в MS Project все, в общем-то, понятно, а вот про описание статуса стоит поговорить.

Практика показывает, что чем меньше отчёт, тем выше вероятность того, что заказчик вообще будет его читать. Поэтому я умещаю все отчёты на одну страницу, при этом пишу всё предельно простым языком. Отчётность по освоенному объёму (earned value) – это очень здорово, но, если честно, я не встречал ещё заказчиков, которые требовали бы такой отчётности и понимали разницу, к примеру, между CPI и SPI. Освоенный объём можно и нужно использовать, но до заказчика лучше доносить фразу “Мы опережаем график работ на 10% от планируемого!!!”, чем “Вууухуу! На этой неделе SPI = 1.1!!!” =)

Сам лист отчёта я разбиваю на четыре части:

1. Шапка, в которой описано по какому проекту данный отчёт, кто его составил, когда, и за какой период.
   
2. Раздел “Прогресс проекта за отчётный период”, в котором обычными словами описываю, что именно произошло в проекте за отчётный период. В этом разделе я пишу только то, что может быть интересно и полезно заказчику и что он сможет понять. Т.е. фраза “Реализована страница, а так же соответствующий функционал, позволяющий пользователям входить в систему, используя свой логин и пароль” предпочтительнее, чем “Реализовали DAL и GUI для авторизации”.
   
3. Раздел “Текущие вопросы и проблемы. Способы их решения/предотвращения”. В данном разделе озвучиваются произошедшие риски, описываются их последствия, а так же озвучиваются наиболее актуальные угрозы и благоприятные возможности (threats and opportunities) и способы их предотвращения и усиления соответственно.
   
4. Раздел “Последующие шаги на следующий отчётный период” описывает планы на следующий отчётный период.

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

Всем удачного окончания рабочей недели!