• Формы отчетов

    Posted on October 30th, 2008 Александр Орлов 10 comments

    Ты уже записался на открытый тренинг проекта Happy PM? Еще нет? Не читай этот пост, иди и запишись!

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

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

    Никакого специального формата, только ответы на 3 вопроса: что сделал за неделю; какие есть проблемы, требующие моего внимания; что планируешь делать на следующей неделе – обычно не больше предложения на каждый вопрос.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

     

    10 responses to “Формы отчетов”

    1. Если есть знания, которыми можно поделиться, и которые будут полезны в будущем – то написать стоит. Лично я бы почитал. :)

    2. Мне встречалась и понравилась схема с Багзилой (или любым другим заменителем).

      1. На каждую задачу заводится баг (то есть Багзила содержит уже не только настоящие баги, но просто все работы в проекте)

      2. Баги можно связывать через зависимости типа blocks, depends, requires и т.п. => имеем простое и эффективное средство планирования. Например, заводим баг выпустить версию X, ей в зависисмость все работы, которые надо сделать, чтоб версию выпустить (можно выстроить дерево произвольной глубины). Чтобы закрыть баг, надо закрыть все его блокирующие => имеем простое средство для отслеживания статуса проекта (или достижения текущей цели)

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

      4. У каждой задачи грамотно прописываем summary и более развернутую постановку. Обязываем людей отмечать в баге статус, прогресс, детали и т.п. (кому что необходимо/нравится)

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

      Делается это все стандартными средствами, без всяких плясок с бубном и лишних телодвижений.

    3. 2 xls Ровно такая схема была в моем последнем Интеловском проекте. Там даже наваяли скриптов, которые рисовали всякие burn-down графики и складывали эти отчеты на вики.

      В принципе, оно неплохо работало, хотя поначалу вызывало сильное сопротивление инженеров. Ну, как обычно при внедрении чего-то нового и неизведанного. :)

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

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

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

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

      По-хорошему, надо было как-то все это разрулить. Но времени что-то не было, так и мучались. :)

    4. 2 bustor – ага, на этой неделе будет пост про Опс ревью. :)

    5. Забавная штука получается:

      Отчет Summary/Details – нужен для того, чтобы держать с людьми контакт.
      Отчет Done/Issues/Plans – нужен 1) для того, чтобы быть «в курсе», 2) для собирания месячных годовых отчетов начальству
      Отчет Почасовая раскладка деятельности – 1) отмазка от начальства 2) средство планирования

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

      Чем, позвольте спросить, занимается менеджер в свое основное рабочее время, если он «не в курсе» состояния проекта, задержек и проблем в нем? Почему исполнители, сосредоточенные на решении конкретных нетривиальных задач, должны тратить свое время на организацию своей же деятельности?

      Я работаю с небольшой командой и в тесной связке с заказчиком. Мы генерируем только отчеты о потраченном времени в основном для бухгалтерии. Все стороны, участвующие в проекте, постоянно и полностью «в курсе». Мы работаем максимально эффективно. И сохранить эту эффективность при увеличении масштабов, на мой взгляд, можно только с помощью автоматизации управленческих задач. Разработчики должны заниматься разработкой, а не писанием никому ненужных отмазок (даже если это занимает не более 10 минут в день). А менеджер должен иметь достаточный набор автоматически генерируемых отчетов, ясно представляющих картину состояния проекта.

      И Bugzilla не самый лучший инструмент для этого, хотя описанный опыт безусловно интересен. Есть ли у кого опыт работы с Dedicated PM инструментами?

    6. Алекс, стоп-стоп-стоп. :) Когда у вас плотная команда и вы работаете над одним проектом, сидите в одной комнате, где все и происходит, вы не контактируете с другими проектами в компании, то зачастую отчеты и не нужны. Однако иногда еще в работе встают вот какие вопросы и проблемы:
      – Команда может сидеть в разных городах, быть разнонациональной и разнокультурной (не все культуры так легко будут говорить о своих проблемах на скрам митингах). Да и скрам митинги не всегда сделаешь.
      – Другие проекты могут быть заинтересованы в том, что неожиданно сделали в вашем проекте (например, их может заинтересовать ваша тестовая сюита). Причем вы зачастую не можете заранее предугадать, что им это тоже будет интересно. В итоге, если не интересоваться деятельностью групп сбоку, вдруг окажется, что в двух группах написали одно и то же, вместо того, чтобы переиспользовать.

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

      Я никогда не автоматизировал, просто потому что не видел нормального инструмента, который бы в наших условиях был прост в обращении. А писать свой инструмент было неэффективно с точки зрения затраты/бенефиты. Я не очень вижу, на что конкретно тратить свое время в организации своей работы, если надо раз в неделю написать 10 строчек. :) По-любому эти строчки придется писать – в Аутлук ли, в отчетный ли инструмент.

    7. А не поменяем ли мы понятия, коллега?

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

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

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

      Я отдаю себе отчет в том, что моя позиция отдает критиканством. На самом деле, мне вполне знакомы и достаточно близки все те нюансы отчетов, которых здесь шла речь. Я имею опыт работы в распределенных командах и знаком с многими описанными процедурами. Однако в целом мне система корпоративной отчетности сильно не нравилась тогда (отчасти поэтому, я сейчас с маленькой командой и в тесном тандеме с интересным заказчиком). И признаться в комментариях коллег я не увидел ничего нового и интересного для себя. Все свелось к тому, что при помощи рутинной бюрократии можно облегчить жизнь менеджеру, осчастливить начальство, замылить глаза заказчикам, и немного иногда может быть решить какие-то действительно важные рабочие вопросы. Стоит ли тратить на это силы и время? Стоит ли писать 10 строчек, если они не несут в себе полезной и необходимой информации?

    8. Пардон! Первая фраза:

      А не поДменяем ли мы понятия, коллега?

      Поторопился :)

    9. Поменяем понятия – это еще лучше. :) На самом деле, думаю, не подменяем, просто говорим про разные вещи. Напишу отдельным постом.

    10. [...] постами так было, теперь вот про отчеты то же самое. В предыдущем посте про отчеты Алекс Арефьев поднял отличное обсуждение про [...]

    Leave a reply

    You must be logged in to post a comment.