目前,我的公司利用敏捷作为其开发主体。我的老板找我来确定一些方法来确定项目经理在特定项目上所做的工作量。老实说,我真的想不出任何万无一失的方法。
我想最好的问题是我们如何评估项目经理每天的忙碌程度?
目前,我的公司利用敏捷作为其开发主体。我的老板找我来确定一些方法来确定项目经理在特定项目上所做的工作量。老实说,我真的想不出任何万无一失的方法。
我想最好的问题是我们如何评估项目经理每天的忙碌程度?
请记住,您能想出的任何指标都极有可能被人玩弄。
[ 我是否会获得指向 Joel On Software 的主题链接的徽章?:)]
话虽如此,您可以尝试以下方法的联合:
开发者反馈!!!(例如,一个好的 PM 的反馈是“我遇到了 X、Y 和 Z 的问题,他让它们消失了”)。不太适合衡量 PM 的“忙碌”程度,但确实适合衡量他/她的效率。
项目计划的数量和额定清晰度(容易玩弄)
项目计划的变化率(容易被玩弄)
会议数量/会议时间(容易玩弄)
项目的成功率(及时性与交付功能的百分比与客户满意度)。不容易玩弄,而是魔鬼自己的工作,以使跨项目的这一点正常化。
时间表将在某种意义上衡量工作量(你可以看到他们的一天是如何分解的等等),但我认为不是你想要的意义上的。
最终,我不相信在这个意义上对项目经理有一个有用的指标,但我认为这不是问题。
我认为最终你应该衡量项目的成功而不是“忙碌”。毕竟,如果项目经理交付了成功的项目,你为什么要关心他们有多忙呢?
一位 PM 可能会花半天时间整理一份包含 20 个风险的风险日志和缓解计划,另一位可能会花费 2 天时间整理一份只有 5 个风险的项目,但这些数字中没有一个比代码行更有用的指标。关键不是你花了多长时间,你发现了多少风险,你的缓解计划有多大,而是你是否真的成功地管理了项目的风险。
您最好了解项目经理的职责,即按时交付项目、按预算和客户满意度(我将其用作质量而不是缺陷的最终衡量标准)。
毕竟,你衡量 CEO 有多“忙”吗?还是他只是根据公司的利润来判断?
去做这个:
时间——真正可以玩弄它的唯一方法是大量填充估计和计划,这可以通过审查计划和估计并让所有相关方(开发人员、PM、客户)同意它们来最小化。另一方面是总理必须同意该计划,而不是将实施日期强加给他或她。您可能希望根据整体实施或每个里程碑来衡量这一点。
预算 - 可衡量但可玩。对于大多数开发项目,她的关键是开发人员提供诚实的时间表,确保做到这一点的最佳方法是让 PM 是 PM,而不是他们的直线经理。这样一来,如果开发人员被迫填写时间表以降低预算,他们就有了与他们角力的人(例如技术总监)。再次,PM 应该同意预算,期望他交付他告诉你不合理的东西是不合理的。
客户满意度 - 难以衡量,因此我建议您保持简单,并与客户经理进行直接的项目后审查,并在沟通、交付和其他重要事项方面打出 10 分。这是主观的,但最终客户满意度也是如此。
但很大程度上取决于公司文化。对于某些组织而言,关键是计费时间,而其他开发人员的满意度将是其中的一部分。
我试图了解为什么您被要求估算项目经理在项目上所做的工作量。充其量只是对经验法则的要求,否则表明您的老板只是不知道运行项目的第一件事。即使项目看起来非常相似,项目也总会有一些独特之处:
项目上的每一个条件都可能改变项目经理的工作量,所以它总是一个主观的评估。
我建议您使用与开发人员相同的 Burn Down 和 Level of Effort。PM 在敏捷环境中的任务有点不同(而且从一个商店到另一个商店都不同),但是 PM 应该能够提供任务列表等。我的想法是积极的,并将其视为您的老板确定的方法PM 有多少可用性。
大多数项目经理将责任等同于地位,因此有闲置能力的项目经理很可能自愿承担新的责任,因为这符合他/她自己的最大利益。除了最实用的组织之外,在所有组织中,为了那种英勇的外表,明显超负荷通常会更好。
稍微降低项目经理的负荷更有可能符合组织的最佳利益,以便在出现问题时有一些可用的备用容量。在任何情况下,项目经理都可能选择以某种建设性的方式运用他/她的空闲能力。过度的政治活动或其他非建设性活动是一个很好的指标,表明某人可以更有建设性地部署。即使在敏捷项目中,整个项目周期的工作量也往往是不平衡的——例如,交付通常是一项管理密集型活动——持续承受重负荷的人可能有太多事情要做,并且可能忽略或隐藏一个严重的问题。
如果下一级管理层定期进行项目审查,关注上报了多少问题,项目报告是否与小道消息相关,并对每个项目经理的工作量预测做一些基本的估计,那么组织应该能够运行一个相当有效的系统。
管理者往往是政治和心理动物。任何不考虑这一点的方法都是无视现实的,因此解决这个问题的好方法可能更多地基于观察到的行为而不是硬数字。
对不起,如果我是纯粹主义者,但标签和问题需要敏捷。什么是敏捷项目经理?您可能正在尝试评估产品所有者或 Scrum Master 正在完成的工作?
无论如何,这两个角色都执行了几项难以衡量的任务,因此您的老板可能看错了。
例如,Scrum Master 是"The person responsible for supporting the development team, clearing organizational roadblocks, and keeping the agile process consistent"
. 基本上是教练和促进者。通过协商或说服遵循 Scrum 实践来阻止由更高级别的管理造成的破坏性请求或干扰是 Scrum 主管常用的技能之一。其中一些软技能很难用“工作”来衡量,因为它们不涉及在计算机上工作或生成报告。
我认为你的老板最能从中受益的指标更多地与团队的效率以及如何描述 Scrum Master 以促进他的队友的工作有关。DVK 有一个非常有效的观点,您创建的指标可以“玩弄”,因此如果您的项目正在取得进展并且您的团队很开心并且作为一个团队工作,那么最好相信您的经理很忙。