3

我不是在谈论你在大学里得到的那种,而是在为开发人员实施工作进度报告。

我组织开发团队的想法是令人鼓舞的,并且在某种程度上,需要定期更新进度,因为开发人员会报告他们在过去一小时或几个小时内做了什么以及任务花费了多长时间。下面我列出了我想到的一些专业人士

  • 让我回去看看我是否可能犯了一个错误,并在努力解决我创造的问题时让自己成为一个起点。
  • 让团队很好地了解他们是否参与了项目并定期更新
  • 对于未来的项目,能够回过头来查看某项任务花费了多长时间并创建准确的估计
  • 鼓励团队之间进行更多的沟通

我不希望看到它成为让开发人员喘不过气来的一种方式,而且我认为如果有人感到压力每小时提交更新,它很容易分散注意力。

  • 你有什么想法?
  • 优点和缺点。
  • 你有没有亲身经历过这种情况?它让你感觉如何?
4

12 回答 12

10

每小时都太频繁了。如此多的中断会降低生产力,并增加开发人员的挫败感。我建议研究一下 Scrum 方法,他们有一个“每日 Scrum”会议,每天早上你都会向团队更新你前一天的进度并计划当天的工作。它对我有用,它可能对你有用。

Scrum 还包括故事和任务卡的概念,您可以在其中估算时间,并最终回来看看您的估算距离有多远。这为您提供了一个“焦点因素”,您可以使用它来帮助提高未来估计的准确性。

查看Trenches中的这个 PDF Scrum 和 XP 以获得关于它的好读物。

于 2008-09-23T19:59:58.493 回答
4

通常,要求状态报告的频率超过每天一次会让您获得大量 Office Space TPS 报告评论。您在更多项目数据中看到的任何好处都会很快被士气低落和团队普遍萎靡不振所抵消。

尝试定期(可能每天)要求更新。不要要求正式的书面报告,这是你作为 PM 的工作,为你的老板提供这些报告。开发人员有开发工作要做。尽量不要让他们承担管理任务的负担。

于 2008-09-23T20:35:32.463 回答
3

这是项目经理无法理解他们的角色的又一个例子。Scrum 不是答案,也不是任何其他教义。在任何组织中,为了更好地支持或参与决策,您到底为什么需要每小时报告?你是工人鱼吗?他们是否有不超过 60 分钟的回忆,需要你通过“嘿,杰夫......它怎么样?”......完全令人筋疲力尽的思路杀手镊子驱动暂停“wazup patch22?.. . 我在 59 分钟前见过的那个人……”

如果你能非常详细地了解最后一次失误出了什么问题……你的下一个项目会发生完全相同的出轨吗?即使确实如此,您是否了解避免所有形式的滑动/错误/进展所需的机器人化?

成为人类……帮助人类,大声呼喊!没有奇迹般的数学结构方法可以实现高水平的生产力……只有启发式。阅读 The Mythical Man Month 和其他人......这不是关于糟糕的管理技术,而是关于事故,因为我们正在与人类打交道。

我做过的最好的和提高团队生产力的事情(当我“只是”一个 PM 时):让我的员工吃得好、睡得好、有规律的作息,并向他们提供“问我你最愚蠢的问题,我”我只会回答 IFFFF 我 10000% 肯定答案”。保护他们免受上面的压力,为他们解决下面的问题,确保他们知道你在那里是为了出气筒的职责。

于 2008-09-23T20:17:42.740 回答
2

我会避免一起使用状态报告,但如果您必须使用它们,请不要让它们比每周更频繁。优秀的开发者更像是艺术家而不是劳动者。他们以创造性的方式创作出伟大的作品,而不是像时钟一样规律地工作。如果您需要频繁的状态报告,他们会感到不必要的压力,这实际上会降低他们的快乐、缺乏创造力,并最终降低工作效率。

于 2008-09-23T20:19:21.393 回答
2

我们使用twitter.com进行团队更新。我要求我的团队在开始一项任务、完成一项任务以及完成一项任务并开始一项新任务时发推文。这边走:

  1. 我知道他们经常在做什么,我不需要闯入他们的办公室总是问,'你在做什么?
  2. 如果开发人员沉默太久,我可以去提供帮助。
  3. 开发人员可以轻松地寻求帮助,而无需打扰其他开发人员
  4. Twitter 中的字符限制确保更新很短,并且不需要大量时间来创建。

我们都将我们的帐户设置为私人帐户,以确保我们组之外的任何人都不会收到我们的推文。我们已经使用了两个月的大部分时间......它真的让我了解了我的人正在做的事情而不会打扰。

于 2008-09-24T20:24:49.953 回答
1

每隔几个小时报告一次进度报告是多余的。如果您正在使用源代码控制工作,您可以在跟踪签入和为开发人员设置标准以评论他们所做的任何提交/签入方面获得大量里程。通过这种方式,您不会纠缠他们(并导致非常昂贵的上下文切换),但您允许他们留在他们的流程中,同时仍然能够监控进度。

根据您的源代码控制的复杂程度,您可以将任务与提交/签入相关联,这是跟踪估计的额外粒度。

于 2008-09-23T20:14:11.283 回答
1

你想做两件事。

每日会议

你要做的就是问两个问题。

  1. 你昨天做了什么?
  2. 你今天打算做什么?

您很快就会确定开发人员是否正在取得进展,或者是否存在任何导致延迟的问题。试图更频繁地获取更新将被证明是矫枉过正,并且可能被视为微观管理。

每周进度报告

每周一次,花半小时整理一份简单的报告,涵盖以下内容

  • 成就
  • 假设
  • 依赖项
  • 问题
  • 决议

这样做不需要太多努力,它会让您很好地了解项目的跟踪方式。它在提供管理或客户以及正在发生的事情和需要解决的问题的概述方面也非常有效。

如需更全面的概述,请访问以下链接

干杯,马蒂

于 2008-11-16T01:06:22.577 回答
0

Scrum 方法很好地处理了这个问题。你每天都有简短的会议来报告进展和障碍。它可以让每个人都被赶上,而不会被细节所困扰。

于 2008-09-23T20:00:41.597 回答
0

查看 Scrum,它是一种敏捷方法,它定义了您想做的所有事情,并且对我们的团队(以及我读过的许多其他人)非常有用。

于 2008-09-23T20:01:04.713 回答
0

敏捷 scrum实际上执行了这一点。我们遵循 VSTS Scrum 方法和项目模板来跟踪所有任务/Bug 等,我们可以轻松地为时间报告设置一个字段(我们正在考虑尽快实施)这样最终的数据将对组织非常有用评估人们进行评估。如果他们缺乏一些专业知识,我们可以通过这种密切跟踪轻松发现这一点。但是这个实用性大吗?

于 2008-09-23T20:06:13.907 回答
0

如果可以的话,我会取消状态报告。虽然这听起来是个好主意,但它传达的信息是您正在尝试管理人员,而不是专注于完成工作的最佳方式。从我所见,当你描述一些需要完成的工作,然后给他们足够的空间,然后提供自己作为资源时,人们似乎工作得最好。我认为像每小时报告这样的事情对每个人来说都很难,包括你。

一个快速的早会(类似于 scrum)可能会有所帮助 - 如果有人挂断电话,很快就会变得很明显,因为他们每天都在说同样的话。它还让其他人有机会站出来提供帮助,如果您愿意,或者如果您有一个喜欢评论想法的老板,您可以随时私下记录。

于 2008-09-23T20:50:12.460 回答
0

领导团队的一切都是日程安排、动机、优先级和冲突管理。

我每周一早上都会召集我的团队,然后我们开始工作,聊聊他们的工作。

我们谈论我们在前一周完成的工作,以及我们期待在下一周完成的工作。

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

有一些东西。

我发现,除了以令人欣喜的成就清单开始新的一周之外,思考未来会怎样,以及等待着哪些令人敬畏的项目/成就也是令人振奋的。

我们在会议之外制定后勤工作。时间表、优先级是根据个人情况处理的。

这样的会议实际上产生了像Finisht.comTwenis.com这样的小事。这非常酷,与我一起工作的团队对编码感到非常兴奋,以至于我有时无法相信。

于 2008-09-27T18:07:36.380 回答