Отчеты о проделанной работе

Каждый час слишком частый. Такое большое количество перерывов снизит продуктивность и усугубит разочарование разработчиков. Я бы посоветовал изучить методологию Scrum, у них каждое утро проводится «ежедневная схватка», на которой вы информируете команду о своем прогрессе за предыдущий день и о запланированной работе на текущий день. У меня это сработало, может сработать и у вас.

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

Прочтите этот PDF-файл Скрам и опыт из окопов, чтобы хорошо его прочитать.

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

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

Гибкая схватка фактически обеспечивает это. Мы следуем методологии VSTS Scrum и шаблону проекта для отслеживания всех задач / ошибок и т. д., И мы можем легко установить поле для отчета о времени (которое мы планируем реализовать в ближайшее время), чтобы окончательные данные были настолько полезны для организации, чтобы оценивает людей для оценки. Если им не хватает опыта, мы можем легко это выяснить с помощью этого тщательного отслеживания. Но практичность этого большой ?

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

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

Это еще один пример, когда руководители проектов не понимают своей роли. Скрам - это не ответ и не какая-либо другая доктрина. Зачем вам в любой организации, чтобы лучше поддерживать или участвовать в принятии решения, нужны почасовые отчеты? вы рабочие рыбы? У них не более 60 минут воспоминаний, требующих, чтобы вы троллили «эй, Джефф ... как дела?» ... совершенно изматывающая цепочка мыслей, пауза, управляемая щипцами-убийцами »wazup patcouch22? .. . кого я видел 59 минут назад ... "

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

Будьте людьми ... помогайте людям, за то, что громко кричите! не существует чудесных математически структурированных способов достижения высокого уровня производительности ... только эвристика. Прочтите «Мифический месяц человека» и другие ... он не столько о плохих методах управления, сколько о несчастных случаях и о том, что мы имеем дело с людьми.

Лучшее, что я делал, повышая продуктивность команды (когда я «всего лишь» PM): держал своих сотрудников сытыми, хорошо выспавшимися, придерживаясь регулярных графиков, и предлагал им мое «задайте мне свой самый глупый вопрос, я» Отвечаю только IFFFF Я на 10000% уверен в ответе ». Защитите их от давления сверху, решите за них проблемы, указанные ниже, убедитесь, что они знают, что вы здесь для боксерской службы.

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

Обычно, если вы запрашиваете отчеты о состоянии чаще, чем один раз в день, вы получаете много комментариев к отчету Office Space TPS Report. Любая выгода, которую вы увидите в большем количестве данных по проекту, быстро перевешивается низким моральным духом и общим недомоганием команды.

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

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

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

Мы используем twitter.com для обновлений команды. Я прошу мою команду твитнуть, когда они начинают задачу, в середине выполнения задачи, а также когда они завершают задачу и начинают новую. Сюда:

1. Я довольно часто знаю, чем они занимаются, и мне не нужно врываться в их офис и всегда спрашивать: «Над чем вы работаете?»
2. Если разработчик слишком долго молчит, я могу пойти и предложить помощь.
3. Разработчики могут легко попросить о помощи, не вмешиваясь в другого разработчика.
4. Ограничение количества символов в Twitter гарантирует, что обновления будут короткими и не потребуют много времени на создание.

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

Все, что касается руководства командой, - это планирование, мотивация, расстановка приоритетов и управление конфликтами.

Я собираю свою команду каждый понедельник утром, прежде чем мы приступим к работе, чтобы обсудить их работу.

Мы говорим о том, чего мы достигли на прошлой неделе, и о том, чего мы с нетерпением ждем на следующей неделе.

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

Есть что-то всегда.

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

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

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

Вы хотите сделать две вещи.

Ежедневные встречи

Все, что вам нужно, это задать два вопроса.

1. Что ты делал вчера?
2. Что ты собираешься сегодня делать?

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

Еженедельные отчеты о проделанной работе

Раз в неделю выделяйте полчаса, чтобы составить простой отчет, охватывающий следующие

• Достижения
• Предположения
• Зависимости
• Проблемы
• Резолюции

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

Для более полного обзора перейдите по следующим ссылкам

• Ежедневные встречи
• Отчеты о проделанной работе

Ваше здоровье, Марти