Могут ли ежедневные отчеты снижать производительность разработчика? [закрыто]


18

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

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

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

  1. Нет необходимости следовать какому-либо определенному формату. Каждый формат принят.
  2. Даже если работа не выполнена, мы хотим услышать о прогрессе.
  3. Нет необходимости упоминать время, затрачиваемое на каждое задание.
  4. Следует отметить препятствия для развития и требования к координации.
  5. Не нужно зацикливаться на ежедневных отчетах. Это не так уж строго.

Как вы думаете, это может снизить их производительность? Были ли у вас ежедневные отчеты? Есть ли у вас какие-либо предложения для нас, чтобы мы могли быть уверены, что мы не занимаемся микроуправлением ?


20
Если ваши схватки занимают более 5-10 минут, вы делаете это неправильно. Встречи Scrum не место, чтобы исправить или обсудить. Все, что вы делаете, это говорите: что я сделал, что я делаю, и что блокирует меня. Это занимает 60 секунд и не должно быть стрессом вообще. Любые дальнейшие обсуждения должны происходить за пределами схватки.
Крис Эберле

3
Можете ли вы рассказать больше о том, какую выгоду вы получите (или надеетесь / ожидаете получить) от ежедневных отчетов?
Poolie

9
Я ненавижу пункт № 2: он не решает никаких проблем со стороны разработчика, только со стороны менеджера. Плюс это говорит о том, что босс не доверяет мне в моей работе. Я предпочитаю то, что говорит Крис: что я сделал, что я делаю, что блокирует меня.
Мувисиэль

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

2
Есть ли причина для общения с другими формами жизни на основе углерода, если исходный контроль интегрирован с системой отслеживания ошибок и CI-сервером?
Уайетт Барнетт

Ответы:


37

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

Какая ужасная идея.

Как вы думаете, это может снизить их производительность?

Да.

Почему? Устная презентация на встрече комбайнах писать и н людей «чтение» отчета в одной параллельную деятельность. Разговор плюс Слушание. Снова и покончено. На вопросы ответил сразу.

Написание отчета - пустая трата времени, потому что будут вопросы, и вам придется просматривать отчет с людьми, у которых (а) есть вопросы и (б) они действительно не читали.

Ежедневные отчеты не будут прочитаны. Они быстро переходят в шум внутри коробки.

«Нет необходимости быть одержимым ежедневными отчетами». В каком случае, почему они?

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

Да. Ежедневно вставайте. Это займет несколько минут, и все готово.

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


6
+1 «Если ваша ежедневная работа занимает больше, чем несколько (15?) Минут, вы делитесь слишком большим количеством деталей ...» на нашей еженедельной встрече (где мы связываемся с разработчиками, которые находятся в штате), мы действительно попытаться усилить этот тип правил. У нас были встречи, которые длились слишком долго, и так как мы планируем это до обеда, ... ну, вы поняли.
Джеймс Хоури

Самое длинное выступление, с которым я был связан, было 20 минут, и это было из-за наплыва людей. У нас была не только команда разработчиков, но и стажеры, кооперативы и один или два подрядчика. Не все всегда говорили, но если у многих людей были соответствующие обновления, это раздвигало границы. Через 20 минут внимание начало уменьшаться, и это стало предельным, пока цифры не уменьшились, и мы не вернулись к 15-минутным встречам. Как правило, 15 минут - хорошее время для съемок.
Томас Оуэнс

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

+1: «Я пишу отчет о кодировании». Микро-статус «Я предоставляю отчет о макро-статусе».
С.Лотт

11

Я делал это в прошлом, но утром, а не в конце дня. Как правило, заполнение заняло менее пяти минут, так что нет, я не вижу, как будет снижение производительности разработчика. Приятно было делать это по утрам, заставляя думать о том, что ты собираешься делать до конца дня.

Сказав это ...

Мы обнаружили, что это было больше, чем нет, это был не самый эффективный способ рассказать о том, что мы делали в предыдущий день и над чем мы собирались работать в этот день. Почему? Люди обычно их не читали. Это было запланированное задание Outlook, поэтому каждый отправлял их каждый день, но они либо были затушеваны, либо пропущены вообще (кроме как от руководства или руководства).

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


2
+1: «они были затушеваны». Я работал на клиентов, которые хотели получить ежедневный статус, но все же настаивали на встречах, чтобы обсудить это. Если мы все равно собирались на встречу, зачем сначала записывать все это?
S.Lott

@ S.Lott - возможно, потому что он записан в любом случае - в основном список дел, который многие люди будут использовать для отслеживания своего собственного прогресса. Учитывая, что (из вопроса) «нет необходимости следовать какому-либо определенному формату», я был бы более чем рад скопировать и вставить свой список дел с вычеркнутыми законченными элементами - я обычно делаю это каждый день, чтобы начать на следующий день список в любом случае. В моем устном отчете основное внимание будет уделено тому, что я помню и что, по моему мнению, должны услышать другие, - поэтому в нем будут пропущены некоторые вещи по сравнению с письменными, а также рассуждать о предстоящих проблемах, которые могут затронуть других людей.
Steve314

@ Steve314: «Мой устный доклад ...» Это благородное усилие, чтобы максимально использовать плохую ситуацию. Более фундаментально, однако, зачем дублировать? Если письменный отчет просто ни для чего не используется, почему люди об этом просят?
С.Лотт

@ S.Lott - если это ни для чего не используется, это правда. Но я много слышал о программистах, которые думают, что все хорошо, с большим количеством прогресса, в то время как менеджеры находятся в панике, потому что они ничего не слышали целую вечность и поэтому полагают, что люди молчат, пытаясь скрыть полное отсутствие прогресс или какое-то приближающееся бедствие. Пусть менеджеры увидят некоторые отмеченные пункты, и, возможно, этого можно избежать. Что касается дублирования, человеческое общение нуждается в избыточности - все вовлеченные в него люди.
Steve314

@ Steve314: «программисты думают, что все тикает хорошо ... в то время как менеджеры в панике». Не в этом дело. Письменный отчет, который просто приводит к встрече, чтобы обсудить прогресс, не был прочитан . Если это не было прочитано, зачем писать это? Вы можете приложить благородные усилия, чтобы исправить плохую ситуацию. Но письменный отчет, который ведет только к последующей встрече, является пустой тратой письменного отчета. Просто проведите следующую встречу. Просто проводите ежедневные встречи. Пока стоит. И покончим с этим.
С.Лотт

6

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

  1. Что было сделано накануне. Не все мелкие детали, но в целом.
    • Если вышеупомянутое не закончено, если нет, что нужно закончить и сколько времени это займет.
    • Если вышеупомянутое закончено, какова следующая задача, что требуется, и время, которое это займет.
  2. Блокаторы. Если вы работаете над Foo, который зависит от Bar, а Bar еще не закончен, это нужно прояснить.

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


+1: мы делаем то же самое. Не ежедневно, а еженедельно в понедельник на всю неделю (так, по-твоему, только на большем таймфрейме). Мы занимаемся этим не каждый день, потому что большинство сотрудников являются студентами и не посещают их каждый день, в большинстве случаев общение происходит также через мгновенные сообщения и т. П., Поэтому достаточно еженедельной встречи всей команды (около 10).
Femaref

6

IMO любой тип ежедневных встреч / отчетов снижает производительность, потому что, честно говоря, воняет микроуправлением. Да, я знаю о Scrum и тому подобном, и они не так уж и плохи, если они имеют короткие обновления статуса («Привет, как продвигается Project X?»), Но я твердо верю, что профессиональным разработчикам оскорбительно следить за нас на этом низком уровне; это похоже на использование расписаний, чтобы убедиться, что мы находимся в офисе 8 часов в день, или чтобы убедиться, что нет стен, чтобы вы могли следить за компьютерами людей, чтобы видеть, какие окна у них открыты в данный момент времени.

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


4

Моя команда занимается скрамом уже около года. До этого у нас было две встречи в неделю, во время которых каждый член команды сообщал о своей деятельности за предыдущие 2, 3 дня. Каждая встреча длилась от 30 минут до 1 часа. Если нам нужно было обмениваться информацией и координировать нашу работу, мы просто подходили к нашим коллегам и разговаривали с ними (что мы, конечно, все еще делаем).

Теперь, когда мы занимаемся скрамом, у нас часто создается впечатление, что одно собрание в день (даже если оно длится всего 15 минут) - это слишком много. Часто сообщения некоторых членов сводятся к: «Ничего нового со вчерашнего дня». У нас часто складывалось впечатление, что схема 2 встречи в неделю была более эффективной.

Другим недостатком является то, что ежедневное собрание является запланированным перерывом (см., Например , статью Пола Грэма , пункт 1. Избегайте отвлекающих факторов): поскольку вы знаете, что перерыв наступит, вы не собираетесь начинать что-либо сложное перед собранием (ежедневные собрания могут проходит от одного до полутора часов после начала работы).

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

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

ОБНОВИТЬ

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


2

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


1
Если вы не скажете точно, что вы имеете в виду под коротким ежедневным сообщением о статусе, по крайней мере, несколько человек будут часами беспокоиться о том, правильно ли они это делают.
Steve314

@ Steve314, лол правда, потенциально хороший способ проактивно определить следующий раунд гм сокращениями.
анонимный тип

2

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

мы не хотим терять хорошие части ежедневной схватки, как, например, возможность каждый день координировать действия разработчиков,

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

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

Множество хороших KPI (таких как время отклика сайта или количество критических ошибок) будут измеряться механически, и вам не нужно навязывать разработчикам затраты.


2

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

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

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


2

Отличная идея - настроить свои Agile-методы так, чтобы они подходили именно вам - спасибо за это.

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

Вот альтернативный подход: вместо использования этих методов «опроса», когда вы спрашиваете у каждого разработчика об их статусе, вы используете технику «толчка». Если разработчик не имеет ничего особенного, он не должен сообщать о любых проблемах и прогрессе по мере их возникновения. Поэтому, когда они завершают модуль, они должны отправить электронное письмо всей команде, которая закончила работу, что она находится в SCM, где можно найти документацию и краткое описание того, что это такое, как это работает и / или как использовать Это. Если у них возникнут проблемы, они должны написать команде команду с просьбой о совете, помощи или каких-либо советов. (да, как в старые времена, когда команды хорошо общались без микроуправления, которым мы страдаем сегодня)

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


2

Я также согласен с тем, что заменять ежедневные сообщения отчетом - плохая идея. Ежедневная стоянка - отличное место, чтобы озвучить идеи и проблемы. Это одна из причин, по которой мне нравятся старые добрые доски (которые мы используем вместе с Jira + Greenhopper). Доска - это место, где группа «суетится» и обменивается информацией, все есть, все видно, все двигаются и меняют стикеры, над которыми они работали, это также очень весело.


2

Не можете ли вы извлечь эту информацию из других ваших инструментов?

  • Над чем Вы сейчас работаете? Билеты, которые я назначил.
  • Каковы ваши успехи? Для билетов у меня больше, чем 1 день, смотрите комментарии в тикете или коммит сообщения ветки. Билеты у меня короче: возможно, сделано завтра (вы не делаете большие 5 + дневные билеты, да?)
  • Каков общий прогресс? посмотреть соотношение открытых / закрытых билетов
  • Что нужно организовать? билеты, которые вам вернули, с необходимыми отзывами о статусе , и все, что обсуждалось в IRC вашей команды, в Campfire Room, что угодно.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.