Как выглядит идеальный отчет о состоянии?

Question

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

Я хочу учиться:

• выполненных предметов и сколько времени было потрачено на каждый
• Возникли проблемы и сколько времени было потрачено на каждую
• Элементы, которые будут обрабатываться следующим, их оценки (в человеко-часах) и их целевые даты
• Вопросы, которые у них есть на работе

Я ищу формат, который предоставит эту информацию, пока:

• Быстро для разработчиков, чтобы завершить (5-10 минут, не задумываясь)
• Мне легко читать и быстро просматривать
• Един для каждого разработчика

Что бы вы предложили?

Answer 1

Вы, вероятно, не хотите слышать это, но вот это все равно -

Я оказался в такой ситуации по обе стороны от пульта и пришел к выводу, что такие сводные отчеты о состоянии - пустая трата времени для вас и разработчиков. И вот почему:

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

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

на стороне разработчика - «быстрый пятиминутный статус» [я ненавижу эту фразу, пять минут не быстрые!] Прерывает поток разработчика, вызывая потерю пятнадцати минут (или более) производительности (joel даже писал об этом я думаю). Но даже если это действительно всего пять минут, если у вас есть дюжина разработчиков, вы тратите пять человеко-часов в неделю на администрирование (и это, вероятно, больше похоже на 20)

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

но вот реальная проблема: такого рода отчетность и свертка могут указывать на реактивное управление, а не на активное управление. Другими словами, не имеет значения, какая методология используется - scrum, xp, гибкая, рациональная, водопадная, доморощенная или что-то еще - если проект правильно спланирован и выполнен, тогда вы уже должны знать, что каждый делает , потому что это было запланировано заранее. И не имеет значения, было ли это запланировано в то утро или шесть месяцев назад.

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

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

о, и ответить буквально на ваш вопрос: в идеальном отчете о состоянии написано "в соответствии с планом проекта", и ничего более; -)

Answer 2

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

У меня нет ссылки на образцы, но вот некоторые черновики:

10/02/2008 - Product A daily status

<Burndown chart>

Team member A
Last 24: feature A
Next 24: feature A unit tests

Team member B
Last 24: bug jail
Next 24: feature B

Team member C
Last 24: feature C
Next 24: feature C
Blocked on: Dependency D - still waiting on the redist from team D

10/02/2008 - Product A weekly status

<Burndown chart>

**Feature A** - Green
[note: red/yellow/green represents status; use background color as well for better visualisation]
On track

**Feature B** - Yellow
[note: red/yellow/green represents status; use background color as well for better visualisation]
Slipping a day due to bug jail
Mitigation: will load balance unit tests on team member A

**Feature C** - Red
[note: red/yellow/green represents status; use background color as well for better visualisation]
Feature is blocked on external dependency from team D. No ETA on unblock.
Mitigation: consider cutting the feature for this sprint

**Milestone schedule:**
Planning complete - 9/15 (two weeks of planning)
Code complete - 10/15 (four weeks of coding)
RC - 10/30 (two weeks stabilization and testing)

Answer 3

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

Есть несколько вариантов для достижения этой цели, но все они рискуют сделать процесс более сложным и длительным. Некоторые из них могут быть:

Онлайн-форма с разделами для каждой или многолистовой электронной таблицы, где каждый лист является разделом.

Все это требует некоторых усилий для их создания. Вам нужна единообразие для какой-то цели? например для автоматизации сводных отчетов.

Альтернативой этому может быть использование какого-либо инструмента управления проектами, который подрядчики заполняли во время работы, и о котором вы могли бы сообщить в любое время. Я бы порекомендовал Thoughtworks Studio Mingle, но он опирается на agile-подобный процесс.

Answer 4

Похоже, вы хотите проводить экстремальное программирование на встречах.

http://www.extremeprogramming.org/rules/standupmeeting.html

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

Answer 5

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

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

Кажется, ваш список "Я хочу учиться" является отличной отправной точкой для создания шаблона. Только вы будете знать, что для вас идеальный формат.