每日报告会降低开发人员的生产力吗？[关闭]

在另一个问题中，我问为什么开发人员可能不喜欢每天的混乱。我们与开发人员进行了交谈，我们决定暂时不举行每日Scrum（在我们的第一次尝试中尝试一下并定制化Scrum）。这是直接与开发人员进行协商的结果。

另一方面，我们不想失去日常工作的大部分内容，例如有机会每天与开发人员进行协调，或者像关键绩效指标那样观看工作进度，以便尽早采取行动。

作为每日混乱的替代方案，我们正在考虑要求开发人员提供以下条件的每日报告：

1. 无需遵循任何特定格式。每种格式均被接受。
2. 即使工作没有完成，我们也希望听到进展。
3. 无需提及在每个任务上花费的时间。
4. 应提及发展障碍和协调要求。
5. 无需沉迷于每日报告。没有那么严格。

您认为这会降低他们的生产率吗？您有任何日常报告经验吗？您对我们有什么建议，以便我们可以确定自己没有进行微观管理吗？

作为每日混乱的替代方案，我们正在考虑要求开发人员提供以下条件的每日报告：

多么可怕的主意。

您认为这会降低他们的生产率吗？

是。

为什么？会议上的口头陈述将写作和n个人“阅读”报告合并为一项同时进行的活动。说话加听力。一遍又一遍。问题立即得到回答。

撰写报告是浪费时间，因为会出现问题，您必须与（a）有问题而（b）并未真正阅读报告的人一起查看报告。

每日报告，不会阅读。它们迅速演变为箱内噪声。

“不必沉迷于每日报告”。在这种情况下，为什么要这么做？

您对我们有什么建议，以便我们可以确定自己没有进行微观管理吗？

是。每天站起来。只需几分钟，您就完成了。

如果您的日常站立时间超过几（15？）分钟，那么您共享的详细信息太多了，因此需要安排单独的会议以获取这些详细信息。每日站立很容易。经过2分钟的总结，其他所有内容可能都是细节，而不是整个团队的细节，需要将其推进到后续会议中。会议将转移到下一天的焦点。

我过去曾经做过这些，但在早晨而不是一天结束时已经做了。通常只需要不到五分钟的时间就可以完成，所以不，我看不到开发人员的生产力将如何下降。早上做这件事的好处是，它使您思考了一天余下的时间。

话虽如此 ...

我们发现，这不是很多时候了，这不是传达我们前一天所做的事情以及当天我们将要工作的最有效方法。为什么？人们通常不阅读它们。这是一项预定的Outlook任务，因此每个人每天都将其发送出去，但是要么被蒙蔽，要么就完全被遗漏了（除了潜在客户或管​​理层）。

我们发现，随着人们倾向于互相倾听，每天站立起来的价值更大。此外，如果有误解，那么它就会被冲走，比起回复日常状态电子邮件询问其他问题的人更容易发生误解。

坦白地说，允许任何人无限制地举报似乎离等式的自由派还有点距离。在我工作的地方，我们走了一圈，每个开发人员都提供以下内容：

1. 前一天做了什么。并非所有微小的细节，而是整体。
   • 如果以上未完成，则需要完成什么以及需要多长时间。
   • 如果以上步骤完成，则下一个任务是什么，需要什么，以及花费的时间。
2. 阻滞剂。如果您正在使用Foo（取决于Bar）并且Bar尚未完成，则需要弄清楚这一点。

建立供所有人遵循的通用架构可以使查看给定的报告变得容易。您可以轻松地设置一些方法，使每个人都可以获取包含每日报告的电子邮件，从而使任何人都可以了解正在发生的事情。

IMO的任何类型的日常会议/报告都会降低生产率，因为坦率地说，这会导致微观管理的恶臭。是的，我知道Scrum之类的东西，如果它们是简短的状态更新（“嘿，X项目怎么样？”），它们还算不错，但是我坚信这会侮辱专业开发人员保持关注我们处于如此低的水平；这类似于使用时间卡来确保我们每天8小时在办公室，或者确保没有墙壁，以便您可以窥视人们的计算机以查看他们在给定时间打开的窗户。

如果您必须密切关注每个人以确保他们正常工作，则意味着您不信任他们。如果您不信任他们，那么工作中的问题会比您担心的更大。

我的团队已经进行了大约一年的Scrum。在此之前，我们每周举行两次会议，在此期间，每个团队成员都报告了他/她在过去2、3天内的活动。每次会议持续30分钟到1小时。万一我们需要交换信息并协调我们的工作，我们只是过去去找我们的同事并与他们交谈（当然，我们仍然这样做）。

现在，我们正在做混乱工作，我们常常给人的印象是一天开会（即使只持续15分钟）也太多了。通常，一些成员的报告可以归结为：“自昨天以来没有新内容”。我们经常有一种印象，即每周2次会议的模式更为有效。

另一个缺点是，日常会议是计划中的中断 （请参阅Paul Graham的文章，第1点。避免分心）：由于您知道中断将要到来，因此您不会在会议之前开始任何困难的事情（每天会议可能会在一个人开始工作后的一到一个半小时内进行）。

最后但并非最不重要的一点是，尽管尽早提供反馈确实有好处（“哦，您正在研究这个问题，我们应该讨论它！”），但有时只有当您已经将想法整理好后，才开始进行讨论有时会更有效。 ，您有特定的问题，可以随时进行讨论了。取而代之的是，每日报告会迅速引起很多不必要的，无组织的头脑风暴。因此，请提防过早的反馈：它会使您感到困惑并使您放慢速度。

因此：在某些情况下，每日报告确实降低了我们的生产力。平均而言，我没有感觉到他们使我们的工作更加有效。

更新

几年前，我写了最初的答案，与此同时，我更换了团队。在我目前的团队中，我们按需进行日常会议，即当我们感觉需要短期状态更新时。因此，每天都有可能召开这样的会议，但是如果没有人要求，我们不会这样做。我们每周举行一次回顾会议。这基本上与我们以前在我的非敏捷团队中最初使用的方法非常相似：固定每周一次的会议，以及在本周剩余时间内举行的其他按需会议。

如果您真正想要的是粗糙的状态并记下任何障碍，最好的方法是要求他们提供简短的“每日状态电子邮件”。如果您过分强调它，或者列出了它应该/不应该包含的内容，那么至少您的一些开发人员将花更多的时间来设计它以满足要求。取而代之的是，索要一封简单的电子邮件。当一天中出现问题时，请说“哦，把它放在日后的电子邮件中”，如果您收到的日终电子邮件真的很长，请随便提一下“您不必每天都这么详细”。

明确任何会议或报告的目的非常有帮助，尤其是每个人每天都要进行的会议或报告。您说的原因是：

我们不想失去日常工作的一部分，例如有机会每天协调开发人员，

协调开发人员是什么意思？什么样的工作需要协调，开发人员和他们的经理在需要时不会临时协调吗？也许您可以通过某种方式确定需要协调的任务，并仅在那些情况下进行沟通？

或像关键绩效指标那样观看工作进度，以便及早采取行动。

许多好的KPI（例如站点响应时间或严重错误的数量）将可以通过机械方式进行测量，而您无需为此付出任何代价。

我不得不在工作场所以几种不同的格式进行每日报告。一般来说，我认为每日报告往往只会为管理人员增加价值，而不是为开发人员本身增加价值。尽管管理人员可以在短时间内了解每个项目的总体状态和每个员工的任务量，从而从每日报告中受益，但以我的经验，大多数开发人员都不会理会彼此的状态报告。

但是，好像不执行每日报告的格式，就使经理和其他开发人员都难以阅读和处理报告，从而加剧了开发人员时间浪费的问题。

如果您决定继续为开发人员提供每日报告，我是否建议使用内部Wiki而不是电子邮件报告？这样，您就不会在向每个人的收件箱发送垃圾邮件的同时保持每个人的日常状态记录。

定制您的敏捷方法以使其适合您是一个好主意-为此感到荣誉。

因此，我想说的是每天的报告并没有比每天的会议好得多，它仍然是“告诉我您在做什么”的方法，只是让每个人写下而不是说。

这是一种替代方法：不用在询问每个开发人员状态时使用这些“轮询”技术，而是使用“推送”技术。如果开发人员没有什么要报告的东西，而他们没有，则他们应该报告发生的所有问题和进展。因此，当他们完成一个模块时，他们应该通过电子邮件将所有已完成的模块，在SCM中的模块发送给所有团队，可以在其中找到文档以及其内容，工作原理和/或使用方法的简短摘要。它。如果他们有问题，则应向团队发送电子邮件，以寻求建议，帮助或任何提示。（是的，就像以前的团队在没有我们今天遭受的微观管理的情况下进行良好的沟通一样）

您会发现这更具生产力和建设性。您不会因为他们而得到毫无意义的报告，而且您会得到一个更有动力的团队，因为每个人都喜欢将他们的工作告知同行。

我也同意，用报告代替日常站立是一个坏主意。每天站起来是表达思想和问题的好地方。这是我喜欢旧式白板（我们与Jira + Greenhopper一起使用）的原因之一。白板是小组“闲聊”并共享信息的地方，所有内容都在其中，所有内容都可见，每个人都可以移动并更改其工作的粘性，这也很有趣。

不能从其他工具中提取此信息吗？

• 你目前在做什么？我分配的票。
• 你的进度如何？对于超过1天的票证，请参阅票证中的注释或提交分支机构的消息。我卖的票比较短：可能明天就做（您不买5天以上的大票，是吗？）
• 总体进展如何？见开/闭票率
• 需要组织什么？分配给您的票，需要状态反馈，以及团队IRC，篝火室中讨论的所有内容。

当您有更具体的问题要回答时，我会看到需要特定的报告，但如果没有这些问题，您的报告看起来就好像是目的本身。