您如何跟踪您和您的团队日常工作？

我在努力跟踪自己和团队中每一个人每天的实际工作。每周检查完已完成的卡片后，我会得到一个全面的了解，并且站立式会有所帮助，但是我觉得我对团队的日常工作没有很好的处理能力。卡片将连续数天保持运行状态，而每天的站立状态不会有任何更新，而且某些工程师是我的团队中沟通能力最弱的。

我已经考虑过实施某种日常记录，每个人都可以填写（通过邮件列表或共享的Google文档），但这似乎很繁琐且手动。

监视GitHub的活动可以很好地完成工作，但每天发送多少封电子邮件可能会使您有些不知所措。我曾经考虑过要为其构建摘要系统，但没有时间可以节省时间。

您实施了哪些策略以保持团队日常工作的最高级，从而可以评估“进行中”任务的工作量？

我跟他们说话。

技术不能解决社会问题。你早上起立时间短。你昨天做了什么？你今天要做什么？有障碍吗？

如果听起来有些可疑（或我很好奇），我停下来问一个问题：“您昨天在XYZ上工作，结果如何？”。这迫使人们注意并真正知道发生了什么。它还可以使您在团队中保持领先地位（并注意并真正知道正在发生的事情）。这需要准时，并且要短（最多 10分钟）。其他任何事情和人们都不会“搁置”工作。他们将停下来等待站起来，然后花一些时间重新开始。无论如何，有些人会这样做，但这在很大程度上是不可避免的。

然后，我下午在每个人的办公桌旁停留。不是每个下午（尽管对于新朋友来说可能不是每个下午都多），不是在同一时间，而是大约在同一时间（所以这既是非正式的又是定期的）。“有什么问题吗？有障碍吗？”

当人们一对一时，您会经常遇到问题，您会感到惊讶。

如果人们没有问题，那就太好了；回去工作。如果他们整周都没有问题？问题。您没有足够地挑战他们，或者他们没有开放。询问XYZ（他们在站立状态中提到的）情况如何。让他们解释事情。

这不是微管理。你不是在告诉他们如何做他们的工作。你不是在照顾他们。您在那里可以消除他们日常生活中的障碍。您需要信息才能做到这一点。只要您不让您的团队参加会议，而让项目经理脱离他们的立方体，那么每天只有一个人来帮助您，不会让他们感到悲伤。但是所有这些交互都需要来自“我在这里为您提供帮助”的脉络。

我要做的另一件事是（非正式地）亲自检查变更集。然后，我可以看到人们签入的频率，他们的变更集有多大，与他们报告的内容相匹配，他们重做的频率，有多少个错误修正等等。将工作状态更改为“完成”几乎是没有意义的。看代码。看起来完成了吗？

注意：一个非常严重的问题是：您的团队有多大？超过7个人吗？当然，如果您的团队太大，您将无法跟踪发生的所有事情。

不要微管理您的开发人员！

高效的软件开发需要长时间的集中精力。期望它们产生恒定的输出是不现实的。如果您开始每天对其进行测量，它们将调整其工作结构，以便它们始终会产生一些可识别的工件，供您每天查看。这可能或可能不会对您的软件质量产生积极影响。几乎可以肯定，这会对开发人员的效率产生负面影响。

正如罗伯特·哈维（Robert Harvey）所建议的那样，请不要微观管理您的团队。为团队提供一些具有具体业务价值的优先任务，并让您的团队找出最佳方法来实现此业务价值。

如果团队提供了业务价值，那么您应该很高兴。他们如何确保交付所需的功能应该由他们决定。

然而：

卡将连续数天保持运行状态，而每日站立时不会更新

这可能表明该过程存在缺陷。

可能是团队没有真正发挥团队的作用，并且在遇到困难时没有介入帮助彼此。也可能是与企业的沟通。任务太大，因此很难确定需要什么。规格不清楚。

也可能根本没有真正的问题。也许团队只是用代表工作需要数天才能完成的主要工作的卡片很好地工作，也许团队可以很好地实现这一目标。

我认为将回顾作为表达您关注的平台是有效的。有时候，从外部获得观察是一件好事。

但是让团队弄清楚是否有问题，这是什么原因。准备接受可能您需要调整将任务交付给团队的方式。

请记住，日常站立是团队帮助他们组织工作的工具；它不是经理人员跟踪团队活动的工具。

“推送消息”而不是“拉消息”

开发人员通常会进入与您相关的以下状态之一：

1. Yaaay，我做了X！
2. 我正在研究X，但似乎需要花费较长时间...
3. 我陷入问题Y，正在研究它，但可能需要建议。
4. 我正在等待A，B和C，因此被阻止。

理想情况下，您希望获得有关这些状态的合理最新信息，而又不影响实际生产率。常量“我们到了吗？” 是适得其反的，但是可能您可以对状态2-4做一些有用的事情，因此您需要了解它们。

有效的是一种“推送消息传递”的文化，最好是一种自动化的方式。您可能不需要查看整个提交日志，但是可以创建一个“仪表盘”，在其中可以看到每个团队成员的最新提交或最新解决的故障单（针对错误或功能）。在其他情况下，您可以让他们通过此类更新主动向您发送电子邮件（希望它们比提交更罕见），或者去询问他们是否在任何仪表板上都看不到持续的进展-如果您有内部协议需要提出卡住的建议（如果事实证明它花费了80个小时而不是8个小时，则可能不需要某些功能），那么它们要么使您保持最新状态，要么就让您烦恼。

另外，您可以对整个团队进行每日报告，例如https://idonethis.com/的文化-这样可以确保其他人也都在同一页面上。

其他一些答案（以通讯为重点）的替代方法是，可以将便签卡上的任务分解成小块，然后您便可以更快地获得反馈。

使用较小的部件，团队感觉他们每天都在完成某些工作，这应该在站立时反映出来。

缺点是这些单独的卡可能会彼此非常依赖。能够彼此轻松交流的团队在这里会很有帮助，否则各个部分可能无法达到应有的结合。如果您需要先完成某些操作，则可能还需要保留一些卡。

话虽如此，人们仍然会陷于困境或发现一项任务比他们或您不时预期的挑战更具挑战性。这就是为什么在站立讨论中公开讨论问题仍然有帮助的原因，其他人可以在不判断遇到麻烦的人的情况下提供建议。

为了回答其他一些问题带来的微观管理问题：即使人们每天都会完成一些小任务，也需要从更广泛的角度看待已完成的工作，以了解每个人的实际工作量，而不是通过他们的日常成就来评价他们。

我之所以建议这样做是因为我是一个由8人组成的团队，该团队的沟通非常容易，人们之间也很容易接近。我们获得的任务从来都不会花费超过两天的时间。有时，这些任务是紧密相关的，我们需要就彼此各自的工作方式保持相互更新。我们每个人都有责任每两周向经理报告一次已完成的工作。

再次阅读问题后，我意识到您可能以团队成员而不是领导者的身份提出问题，因此您可能无法控制自己的任务。

1. 您可以建议您的领导者分手更多任务
2. 如果您的工作受阻或依赖于其他团队成员的工作，请随时与他们核对，并根据需要执行其他任务。

首先，您需要根据时间和技能来分析自己。如果您是具有一定实践经验的技术人员，则可能与您只是一个经理（对开发人员的实际工作没有很深的技术知识）的情况有所不同，他们只需要确保在截止日期之前。

两种情况的共同点是，您需要能够为您的团队提供便利，并产生您信任他们的感觉。您不是在评估他们的表现，而是在尝试变得富有同情心，并有助于使他们的体验变得有趣而轻松。

现在假设您只是我上面所说的经理，在这种情况下，即使某些开发人员确实面临与开发相关的严重问题，您也可能无法帮助他/他。实际的问题可能很耗时，并且也需要集中精力。进一步假设开发人员对工作确实很真诚，并花了全职（甚至额外的时间）来解决该问题，但不幸的是仍然无法解决问题。在这种情况下（当您甚至无法完全理解问题时），您会不断询问问题，每天甚至每天两次非正式地取得进展。结果将对开发人员造成极大的挫败和干扰。无论是用于收集日常进度的应用程序还是仅用于日常站立会议的应用程序，都可能令人沮丧。

另一方面，在保持所有其他因素不变的情况下，只需假设您具有强大的技术背景并且过去曾使用相同的技术即可。在这种情况下，进行日常工作或举行站立会议确实很有帮助。开发人员一定会相信您和您的专业知识，并且会乐于讨论他们面临的重大挑战。您将提供一些有用的建议，即使它们没有直接帮助，它们也会帮助您提供一些替代方法。

但是，在任何情况下，每日站立会议都必须使您感觉自己是团队成员，而不是主管/领导/经理。除非您的团队成员认为您与他们处于同一水平，否则他们将无法传达他们的疑虑/建议/问题/反馈等。
要考虑的另一点是在考虑使用一些自动进度跟踪软件或增加您的互动之前，您的团队规模以及管理团队的时间。您需要确保团队提出了任何问题，您都能够尽快解决它们。对于团队成员而言，主要的激励因素是他们的关注/建议/反馈未被重视或未被重视。知道每天的进度很重要，但是只有在您完全参与团队合作的情况下，才是重要的。如果您也参与一些副业，请不要尝试与团队进行更多互动。考虑一下您的团队的反应不堪重负，他们早于时间就提交任务，引起关注和疑问，但您无法及时提供反馈和审查的情况。在这种情况下

为各种配置创建并充分利用各种IM聊天室。有些可能很宽泛，例如@engineers，有些可能很具体，例如@newFeatureA

考虑使每日站起来包括对机上机票的审查。

使用支持协作的开放环境，并确保QE和主要产品所有者位于开发人员中间。您会偷听很多东西，并从周围的屏幕上看到一个想法。

正如罗伯特（Robert）所指出的，首先，不要将其视为微观管理（注意使用“被看见”，即不管您的实际意图如何）。

最终，我们跟踪随着时间的推移完成的工作，并从中了解我们的速度。由于人们会士气低落和/或离开，因此专注于日间进度会适得其反。

令我惊讶的是，这里还没有人提到在GitHub或BitBucket等系统中内置的“已关注”或“已加星标”存储库消息。

我们的技术利益相关者（项目负责人，开发和支持经理）都关注我们的问题，并提交有关其相关项目的最新历史记录。我们有一个小团队（15个FTE +承包商），但这似乎对我们有用

没有人可以衡量这些事情，但是除了PM的每周状态报告之外，它还可以每天查看项目的情况，以至少使每个人都知道正在处理哪些方面，因此没有人没有可见性。

它还有助于提高开发人员和承包商之间以及我们的业务联络人之间的透明度，这有助于每个人对自己的交付时间表负责。

与与特定存储库或整个组织相关的RSS feed结合使用时，我们能够限制电子邮件（在需要时），并通过RSS阅读器实时提供摘要数据并进行汇总。对于某些用户来说，这是Outlook，因此基本上是给他们的电子邮件，尽管略有不同，但是对于其他用户，他们使用功能强大的RSS客户端以及所需的所有其他过滤功能，以根据实际需要对其进行自定义。

最初，我们对电子邮件的数量也有类似的担忧，但是最终用户提出了RSS系统，而工程组织无需做很多事情，除了可以为不使用Outlook的客户提供建议。全年在多个办公室和时区为大约20-30 FTE +承包商服务。YMMV，显然。

这是一个非常微不足道的补充（并且不是特定于程序员的），但是我在最近的项目中使用Asana取得了成功。

要与现有的在线协作工具集成，别无所求。它围绕一个聊天室构建，但是它是Asana，GitHub和Bitbucket 等其他工具的极简主义中心。它使用API 预先构建和社区构建了这些“集成”的不错的集合，这些API当然允许您构建自己的API。