我不是在谈论我们上大学的那种方式，而是在为开发人员在Job上实现进度报告。

我组织开发团队的想法令人鼓舞，并且在一定程度上要求定期更新进度，因为开发人员将报告他们在过去一小时或者几小时内所做的工作以及完成任务的时间。下面我列出了一些我想到的专业人士

• 让我回头看看我是否犯了一个错误，并为解决我创建的问题提供了一个起点。
• 使团队对他们参与项目和定期更新有很好的了解
• 对于将来的项目，具有回溯并查看某项任务花费了多长时间并创建准确的估算值的能力
• 鼓励团队之间进行更多的交流

我不希望发生这种情况，因为它成为一种让开发人员喘不过气来的方法，而且我认为，如果一个人每小时都感到压力，则很容易分心。

• 你有什么想法
• 优点和缺点。
• 我们是否曾经亲身经历过这第一手？感觉如何？

解决方案

每小时都太频繁了。如此多的中断会降低生产率，并增加开发人员的挫败感。我建议研究一下Scrum方法，他们每天举行一次"每日Scrum"会议，在此会议上，我们可以向团队更新前一天的进度以及当天的计划工作。它对我来说效果很好，可能对我们也有用。

Scrum还包括故事和任务卡的概念，我们可以在其中估计时间，最后回来查看估计值有多远。这为我们提供了一个"重点因素"，可用于帮助提高未来估算的准确性。

查看Trenches的PDF Scrum和XP，以获得有关它的良好阅读。

Scrum方法可以很好地解决这一问题。我们每天都有简短的会议来报告进度和障碍。它使每个人都可以被赶上，而不会被细节所困扰。

查找Scrum，这是一种灵活的方法，它定义了我们想做的所有事情，并且对我们的团队(以及我所阅读的许多其他文章)都非常有效。

敏捷scrum实际上可以强制执行此操作。我们正在遵循VSTS Scrum方法论和项目模板来跟踪所有Task / Bug等，并且我们可以轻松地为时间报告设置一个字段(我们打算尽快实施)，以便最终数据对组织如此有用。评估人民进行评估。如果他们缺乏专业知识，我们可以通过这种紧密跟踪轻松地找到答案。但这实用性大吗？

每隔几个小时的进度报告就显得过分了。如果我们使用的是源代码管理，则可以从跟踪签到信息和为开发人员设置标准以对他们所做的任何提交/签到发表评论中获得很多收益。这样，我们无需标记它们(并且不会引起非常昂贵的上下文切换)，但可以让它们停留在它们的流程中，同时仍然能够监视进度。

根据源代码管理的复杂程度，我们可以将任务与提交/签入相关联，这是用于跟踪估算值的添加粒度。

这是项目经理无法理解其角色的又一个示例。 Scrum既不是答案，也不是任何其他学说。
为什么我们实际上在任何组织中为了获得更好的支持或者作为决策的一部分，都需要每小时报告一次？你是工人鱼吗？他们是否有不超过60分钟的回忆时间，是否需要我们通过"嘿杰夫...怎么回事？" ...来思考？我59分钟前见过的..."

而且，如果我们了解到无穷无尽的细节，那么上一张单据出了什么问题……下一个项目会发生完全相同的出轨吗？
即使这样做，我们是否了解避免各种形式的滑动/错误/进程所需的机械化？

做人...要帮助人，因为他们大声喊叫！没有任何奇迹般的数学结构化方法可以实现高水平的生产力……只是启发式方法。
阅读Mythical Man Month和其他文章...与其说是管理技巧不佳，不如说是事故，还因为我们是在与人打交道。

我所做的最好的和提高团队生产力的事情(当我"只是"一个PM时)：保持我的员工饱餐，睡个好，有规律的时间表，并向他们提供"我问你最愚蠢的问题，我是只会回答IFFFF，我对答案有10000％的肯定"。使他们免受上述压力的影响，为他们解决以下问题，并确保他们知道我们在这里做沙袋工作。

我会避免所有状态报告，但是如果我们必须使用它们，请使它们的频率不超过每周一次。优秀的开发商更像艺术家而不是工人。他们以创造性的冲动创造出出色的作品，而不是按时完成工作。如果我们需要频繁的状态报告，他们会感到不必要的压力，这实际上会使他们不快乐，缺乏创造力，并最终降低了工作效率。

通常，要求状态报告的频率超过每天一次，这将使我们获得大量的Office Space TPS报告注释。士气低落和团队一般不适，我们将在更多项目数据中看到的任何好处将很快被抵消。

尝试定期(也许每天)请求更新。不要索要正式的书面报告，这是我们作为PM来为老板准备的报告的工作。开发人员有开发工作要做。尽量不要让他们负担管理任务。

如果可以的话，我将不提供状态报告。尽管这听起来像是一个好主意，但它传达的信息是我们正在尝试管理人员，而不是专注于完成工作的最佳方法。从我所看到的，当我们描述一些需要完成的工作，然后给他们足够的空间，然后提供自己作为资源时，人们似乎工作得最好。我认为每小时报告之类的内容对包括我们在内的每个人都很难。

如果有人挂了电话，快速晨会(类似于scrum)会有所帮助，因为他们每天都在说同样的话，所以很快就会变得明显。它还使其他人有机会加紧并提供帮助，我们可以随时私下记下我们是否愿意或者是否有喜欢点评的老板。

我们使用twitter.com进行团队更新。我要求我的团队在任务开始，任务中期以及完成任务并开始新任务时发推文。这条路：

• 我知道他们经常要做什么，而我不必闯入他们的办公室，而总是问："我们在做什么？"
• 如果开发人员沉默了太长时间，我可以提供帮助。
• 开发人员可以轻松寻求帮助，而无需与其他开发人员进行接洽
• Twitter中的字符数限制可确保更新时间短，并且不需要花费很多时间来创建。

我们所有人都将帐户设置为私人帐户，以确保我们团队之外的任何人都不会收到我们的推文。我们已经使用它至少两个月了……它确实向我敞开了我的家伙在不被干扰的情况下所做的事情。

领导团队的所有工作都是日程安排，动机，优先级和冲突管理。

在每周一开始工作前，我都会让我的团队聚在一起，讨论他们的工作。

我们谈论上一周取得的成就，以及我们期待下一周完成的一切。

最重要的是，我们每个人都提出我们所做的(通常与代码相关的)工作，这些工作在某种程度上确实令人兴奋。一段刚刚起作用的代码；用于新应用的创意的餐巾纸草图；可以丰富团队其他成员的新技术；

总有东西。

我发现，除了以令人欣慰的成就清单开始新的一周外，思考未来的前景以及期待的杰出项目/成就也令人振奋。

我们在会议之外进行后勤工作。进度表，优先级将根据个人情况进行处理。

此类会议实际上已经证明了Finisht.com和Twenis.com之类的小事情。这非常酷，与我一起工作的团队对编码感到非常兴奋，以至于我有时不敢相信。

我们想做两件事。

日常会议

我们只想问两个问题。

• 你昨天做了什么？
• 你今天打算做什么？

我们将很快确定开发人员是否正在取得进展，或者是否存在引起延迟的任何问题。试图更定期地获取更新将被证明是过大的，并且可能被视为微观管理。

每周进度报告

每周一次，请花费半小时来整理一份简单的报告，其中涉及以下内容

• 成就成就
• 假设条件
• 相依性
• 问题
• 决议案

这样做不需要太多的努力，它将使我们对项目的跟踪方式有很好的了解。它在提供管理人员或者客户以及正在发生的事情和需要解决的问题的概述方面也非常有效。

有关更全面的概述，请访问以下链接

• 日常会议
• 进度报告

干杯，
马蒂