我坚信他们是，而且我经常感到惊讶和失望，因为越来越多的组织没有实施职能规模衡量标准.

生产率是一个概念，从国家层面的政府一直到单个公司都得到了广泛的讨论。, 在生产商品或提供服务的所有行业. 出于本次讨论的目的, 我拿 生产率 指生产单位产出所消耗的资源量. 这里的关键是有一个输出可以被识别和计数以与所使用的资源进行比较.

公司高管和政府部门负责人定期要求他们的组织每年通过以下方式提高生产力：, 例如, 用相同水平的资源产生更多的产出，或者用更少的资源产生相同的产出. 他们还对自己的组织与其他同类公司的竞争对手相比的绩效感兴趣.

IT行业也不例外. 示例包括需要展示竞争力才能赢得业务的服务供应商, 内部 IT 部门需要证明他们正在利用分配的预算为企业提供更多服务，而首席财务官则需要确保外包交易将为企业带来真正的利益, 不仅仅是更便宜的劳动力价格.

在软件开发领域, 代码行数已被用作所产生输出的衡量标准，但随着现代开发技术和工具的出现，这在大多数现代环境中不再是有用的衡量标准.

更有用的技术是根据软件开发项目向客户提供的功能量来衡量其输出, 无论使用何种技术/平台/开发方法. 要做到这一点，需要一个标准化的, 识别和评估所交付的业务功能的可重复方法，从而得出所交付软件规模的数值.

在实施功能规模调整过程中吸取的一些重要经验教训是:

衡量你所做的事情然后改进

• 除非您有当前绩效的基线，否则无法管理改进计划. 我多次听到经理们说“我们希望通过以下方式提高生产力” 10% 每年”，但他们不知道当前的表现如何. 也, 你需要知道当前的表现是否良好, 一般或不好. 取决于你的立场, 如果你需要改进你可以理解, 如果是这样, 多少才是现实的. ISBSG 数据可以帮助您解决这个问题.

了解您的数据并采取行动.

• 测量没有什么价值，除非它被用来表明可以采取的改进措施. 因此，需要“因果分析”过程来了解导致每个项目绩效的属性/因素/事件.
• 谨防成本“三足凳”, 质量和进度. 它们都是相互依存的，不应孤立管理.

谨防数据滥用

• 我曾经听说过 2 高级管理人员使用工时/功能点吹嘘其 IT 部门的绩效. 他们来自不同行业的公司，业务差异很大，所以这样的比较几乎没有意义
• 存在过度简化的危险. 因为项目, 即使在相似的领域, 会产生不同的结果, 为了正确理解结果，除了平均值之外还需要一些基本的统计分析.

与努力的相关性

• 使用功能规模来衡量生产力或估计的前提是规模和工作量之间存在足够的相关性. 并非所有任务都需要与功能规模成正比, 因此可能需要从生产率计算中删除并单独处理

小时/FP 或美元/FP

有些人定义生产力努力/产出单位，而另一些人则更喜欢成本 / 输出单位. 每个指标都具有价值，因为劳动率与完成任务所需的小时数之间通常存在关系. 我建议同时使用.

我很想听听你的经历 (好和坏) 尤其是为什么您没有实施功能调整的原因. 请联系我： john.ogilvie@isbsg.org 如果你感兴趣.

 

关于作者

约翰·奥格维 (John Ogilvie) 是该公司的首席执行官 国际软件基准标准组.

 

博文代表作者个人观点
而并不一定与官方NESMA政策一致.