Польза для меня: долгосрочная - когда писались годовые ревью на сотрудников, я мог быстро вспомнить, кто чем когда занимался; еженедельная - сравнение сделанного с запланированным на прошлой неделе позволяло проверять на вшивость, если у меня были еженедельные 1-on-1, то я знал о чем говорить, а если 1-on-1 были реже, то я знал, когда надо встретиться раньше, если есть проблемы.

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

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

Если ты на отчеты не реагируешь - люди перестают их писать (или пишут - «все идет по плану»). Но это, как и в сборе любой информации -если ты с ней ничего не делаешь, то лучше и не собирай.

Впрочем, последний абзац верен не всегда. Принцип неопределенности иногда действует. Сам факт измерения (сбора информации) иногда оказывает (дисциплинирующее) воздействие. Джерри Вайнберг рассказывал байку про какого-то известного босса (совершенно не помню про кого, но для красного словца скажу, что это был Генри Форд). Когда в каком-то цехе дела пошли неважно, он стал приходить по утрам в цех и писать на доске какое-то число: сегодня - 207, завтра - 212, послезавтра 205 - никому ничего не объясняя. Народ понял, что его «меряют», и стал лучше работать. Важно понимать, что такие понты работают недолго. Вариант с требованием ежедневных отчетов у отдельного нерадивого работника может встряхнуть его только очень краткосрочно, и даже в этом случае надо эти отчеты читать.

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

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

Так какими же бывают отчеты по форме? В моей практике встречались такие:.

1.

Summary/Details. Обычно применялось для месячных отчетов. Человек очень детально пишет в деталях, что он делал и сделал за месяц. Озаглавливает это сочинение «Details», выделяет в нем ключевые вещи. После чего пишет коротенькое «Summary» вверху отчета, которое в несколько строк дает обобщение его деятельности.

Это очень удобно. Читаешь Summary, получаешь тем самым общее представление. Проглядываешь Details на предмет выделенного. Если что-то заинтересовало в Details - начинаешь вчитываться.

Иногда некоторые товарищи добавляли третью секцию в самый низ отчета. Что-то типа Interesting/Личное. Где писали об интересном, что с ними случилось, или с чем они столкнулись за месяц. Хороший способ, чтобы держать с людьми такой, контакт. У каждого человека появляется ощущение, что он тебя знает. И он может к тебе запросто обратиться по какому-нибудь вопросу. Ну и всегда будет про что при встрече поговорить. ©.

2.

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

Из таких планов очень удобно собирать месячные отчеты, ежели они нужны начальству. И список подвигов для ежегодного ревью -без таких отчетов за год все из головы просто вылетит.

3.

Почасовая раскладка деятельности (time sheet). В моей практике делалась дважды. В одном случае для заказчика. Надо было идти в какую-то тулзовину и прописывать там, сколько часов ты проработал над проектом каждый день. Надо ли говорить, что все работали ровно 40 часов в неделю? ©.

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

Первый случай был 100%центной профанацией. Второй принес некоторую пользу, потому что потом при планировании мы знали, сколько времени у нас, в среднем, уходит на болезни. Сколько - на тренинги. Сколько - на чтение почты. И пр., и пр.

С точки зрения читаемости было двояко. Отчет своей группы я еще мог окинуть взором и понять, что и кто делал. Но когда пытался читать скомпилированный отчет всего проекта (это было пять команд) - это уже было без шансов. ©.

В общем, как отмазка от начальства и средство планирования -очень хорошо. Как источник информации - плохо.

4. Отчеты из автоматических инструментов. В моей практике применялось периодически для каких-нибудь специфических нужд. Типа - кто там сколько багов нашел за месяц (или за весь проект). Кто там больше багов пофиксил. Кто больше всех поверифицировал. Кто нашел больше всех высокоприоритетных багов. Ну и т.д.

Инструменты обычные - системы учета дефектов (Bugzilla, JIRA), средства контроля версий (CVS, SVN, SCCS).

На такие отчеты я обычно смотрел в конце проекта. И иногда по ним виделись некоторые тенденции, по которым я делал потом правильные (или преждевременные ©) выводы.

Регулярную отчетность по тулам я не собирал. Потому что и так старался читать каждый новый выставленный баг, и комментарий к каждой заливке в пространство. © Вот это, кстати, отнимает время, но позволяет выявить немало косяков as soon, как говорится, as possible.

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