weekly/daily report

уважаемые менеджеры и тим-лидеры, в каком виде вы требуете от своих подчиненных $subj?
что туда должно включаться и что для вас особенно важно?
и еще вопрос: каким образом вы распределяете недельную активность? рассылка мейлов с конкретными задачами или просто показываете сотрудникам план?

Уважаемая N.K.

А почему Вы это спрашиваете?
Вам для диссертации или для журнальной статьи?

У нас формат репортов определяется требованиями заказчика во многом. Иногда достаточно репорта который генерируется системой трекинга задач - просто видно что по кому в каком статусе на данный момент - какие задачи окончены, какие в процессе, какие сдвинуты.

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

уважаемый Yury,
я спрашиваю потому что это интересно. мне для общего развития. и вообще хочется узнать как нормальные люди пишут репорты. работаю тестером два года. сначала на крупную компанию N**, теперь на компанию E**. Аутсорсинг, естественно. требования - разные. причем, как правило, заказчику репорт каждого отдельного сотрудника, им интересен командный отчет. только вот кажется у нас тест-лидер не может определиться в каком виде ему это надо :/ скоро у меня в отчете будет что-то типа
Time reporting: 20% - weekly report presentation creating

так вот, есть ли какие-то шаблоны или общепринятые нормы?
а зачем вам, собственно, знать зачем мне это надо? помочь можете, или так, чтобы разговор поддержать?

Case, то есть у вас каждый таск создается в таск-трекинговой системе? а всякие мелкие вещи как то: чтение документации по тулам, чтение новых спецификаций, расстановка меток в клиркейсе, трекинг трабл-репортов и прочие мелочи на которые тратится куча времени, это позволяет отслеживать?

и у нас кстати отчеты по команде составляет не менеджер... а у тим-лидеров 30% времени отведено на составление всяких таких бумажек

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

и у нас кстати отчеты по команде составляет не менеджер... а у тим-лидеров 30% времени отведено на составление всяких таких бумажек

Case, то есть у вас каждый таск создается в таск-трекинговой системе? а всякие мелкие вещи как то: чтение документации по тулам, чтение новых спецификаций, расстановка меток в клиркейсе, трекинг трабл-репортов и прочие мелочи на которые тратится куча времени, это позволяет отслеживать?

Нет конечно. От проекта зависит. Ежедневных репортов в текущем проекте не делаем - для картинки по состоянию проекта достаточно ежедневного оперативного трекинга задача/статус, а для получения общей картинки есть недельные статус-репорты, только в них не задачи уровня "читал документацию", а таски по проекту уровня "test case design for modul DTF-12" или "data set praparation for test cases TC-16 - TC-42", где соответсвующие TC-nn или DTF-12 это ссылки на issues в трекинг системе или указание на глоссарий/словарь проекта, откуда уже можно ити на пакеты документации, например.

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

Ну это может у вас так? А если не так, то поделитесь как у вас?

"Ответьте на вопрос зачем вам нужен отчет, и вы поймете, что в нем должно быть". (с) ...

В одной из фирм недельные отчеты применялись для расчета премий. И сразу понятно что в них должно быть. Был в отпуске / на учебе - проектный бонус не положен, участвовал в провальном проекте -....
Заметьте, этот отчет отвечал не на вопрос "в каком состоянии находится проект", а на вопрос "какую премию начислить работнику".

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

Для чего еще могут понадобиться отчеты
* Для расчета оплаты при повременке. Характерно для аутсорсинга или работы по договору. Отвечает на вопрос "сколько часов отработал". Потом умножаем на тарифную ставку и выставляем счет к оплате.
* Для определения "в каком состоянии находится проект". Для рядовых сотрудников смысла не имеет. Руководители групп должны подавать такой отчет вышестоящему начальству. Но еженедельная планерка все таки лучше отчета. Еще лучше отчет + планерка.

SALar очень верно заметил про цели, с которыми составляется отчет. Какая цель - такой и отчет.

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

По поводу "недельной активности" -- что за странная единица измерения времени? Почему именно недельная? Что, руководитель только по понедельникам на работе присутствует? Распределил -- и на покой. Я распределяю активность по мере необходимости. Не ждать же до следующего понедельника. Форма -- любая уместная в конкретной ситуации: через реквест-трекекер, по почте, устно, записка на клавиатуре, ...

В основном форма отчета зависит от менеджера и, действительно, от целей. Те отчеты, которые мы пишем риследуют цель контроля сотрудников и являются поводом настучать по голове при желании (придраться можно всегда, было бы желание). Формы разные, некоторые пишут в специальную БД. Я же пишу в эксель файле - одна закладка - один день, файл в неделю. Собственно форма не удобная когда приследуется цель подсчета времени на проэкт. Для таких целей как возможный вариант можно делать эксель таблицу "день" vs "задание". Так видно и проработка заданий и можноп осчитать время как на задание так и на проэкт за определенный период. Отчеты лежать в общей базе, так что доступ к ним есть у менеджеров и работающих всегда.
Особо не вникала, но, насколько я понимаю, для этих целей можноп риспособить ProjectManager, только надо пошурупать как :).

По поводу "недельной активности" -- что за странная единица измерения времени? Почему именно недельная? Что, руководитель только по понедельникам на работе присутствует? Распределил -- и на покой. Я распределяю активность по мере необходимости. Не ждать же до следующего понедельника.   Форма -- любая уместная в конкретной ситуации: через реквест-трекекер, по почте, устно, записка на клавиатуре, ...

активность "недельная" потому что у заказчиков такая единица измерения времени. мы уже привыкли жить "виками" ;) cейчас вот W49 :) естественно, и задания распределяются на неделю. конечно, в процессе выполнения они могут корректироваться и долгосрочное планирование тоже имеет место быть.

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

Я так понимаю, что вопрос медленно перетекает в такой: "В каком виде вы подаете отчеты заказчику". Конкретный ответ: "Тайна сия велика есть"

Обший ответ: Что тут думать? Какой хочет заказчик, такой и надо подавать. Мы в некоторых проектах не подаем промежуточных отчетов вообще, в некоторых отчеты ежемесячные, по выполненной работе (сдельные), в некоторых еженедельные (по активностям).

Для себя, чтобы отслеживать ход проекта, как я уже сказал, я просто веду дневник, в который записываю то, что мне кажется существенным. Сразу записываю. И слежу за выполнением работ постоянно. Поэтому нет необходимости подавать мне отчет в конце недели -- я и так в курсе всех работ. И если происходит сбой в графике -- тоже узнаю об этом сразу, а не в следующий понедельник. Если очень жесткий график и много активностей, так что не удается все одновременно держать в голове, дополнительно делаю трекинг в MS Project. А по отчетам невозможно проанализировать ход проекта, как-то они не годятся для этого. (Впрочем, может быть я просто не знаю, как правильно их готовить...)

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

ИМХО абсолютно верно. Хороший менеджер всегда должен знать ответ на вопрос, чем занят сейчас тот или иной подчиненный. Причем вне зависимости от того, требуют ли от него отчетности или нет.
В идеале, в таких небольших командах менеджеру достаточно часа-двух в неделю чтобы распределить обязанности подчиненных и составить для высшего начальства кое-какой репорт либо прогноз на следующую неделю. Это, конечно, при условии более-менее планируемого будущего.

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

ИМХО абсолютно верно. Хороший менеджер всегда должен знать ответ на вопрос, чем занят сейчас тот или иной подчиненный. Причем вне зависимости от того, требуют ли от него отчетности или нет.
В идеале, в таких небольших командах менеджеру достаточно часа-двух в неделю чтобы распределить обязанности подчиненных и составить для высшего начальства кое-какой репорт либо прогноз на следующую неделю. Это, конечно, при условии более-менее планируемого будущего.

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

Но если речь идет об аутосорсинговой компании, где группа тестирования из 10 человек может заниматься 4-6 проектами, то никакой менеджер не уследит за всеми. Естественно, ему нужно организовывать контрольные точки, что бы синхронизировать свое представление о текущем состоянии проектов с реальным.

Вот здесь и возникает проблема отчетности.

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

Или ещё веселее если специалистов 4, а проектов 10 :)
Я видел "простынку" - сводный отчёт за полгода, где у одного бизнес-аналитика было 56 проектов.

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

1. Количество выполненных тест-кейсов с указанием - passed, failed, passed with a bug - в формате excel;
2. Количество ошибок ( кратким описанием):
- новых
- исправленных и проверенных (verified)
- закрытых
- переоткрытых (reopen)
3. Общие выводы - типа "считаю, что такая-то функциональность довольно стабильна. Рекомендую обратить внимание на такую-то ошибку, она блокирует работу всего приложения"
4. Планы на завтрашний день.
Сейчас эти отчеты пишет каждый тестировщик по отдельности - так захотел заказчик. Но, думаю, будет полезнее, если будет один отчет по группе QA.
Создание такого отчета при нормальной системе багтрекинга (нас устраивает bugzilla) у меня занимает минут 10 в конце рабочего дня.

Еженедельные отчеты, как верно заметили раньше, у нас используются для начисления зарплаты и премии. Поэтому особенно подробно их никто не пишет, только время указываем и общее направление деятельности. Генерируется через систему time tracker-а, исходя из ежедневных записей.

У нас примерно тоже самое, что и у Лены:
1. Сколько успел сделать за неделю, из заявленного на предыдущей неделе.
2. Планы на следующую неделю, если товарищ в курсе.
3. Возникшие проблемы по ходу работы.

Результаты использовались при планировании дальнейших задач.