自软件开发项目诞生以来，软件项目的规模和工作量估算一直是软件行业的痛点。业界曾尝试过多种估算方法，但均未能很好地解决这一问题。功能点估算方法的出现，为软件项目估算提供了一个相对客观的解决方案。经过多年的实践，该方法已获得业界的肯定，并被纳入国家标准。然而，在实际应用过程中，仍需关注一些具体问题，若处理不当，将严重影响功能点估算方法的正确性和准确性。本文结合笔者在软件造价评估工作中的实践经验，就功能点估算的常见问题进行解析，并给出相应的应对方案。
功能点是由国际功能点用户团体组织（IFPUG）提出的一种软件规模度量的方法。目前国内应用最广泛的为NESMA方法，它首先计算出软件的规模（即功能点数），然后通过规模进行后续的工作量、工期估算。该方法具有两个鲜明的特点：一是依据用户需求估算，对于估算人员来说，简单易用。基于此特点，可以在项目早期就开展估算工作；二是客观性，与开发语言、产品设计、开发风格等技术特性无关。正是因为这两个特点，功能点估算方法解决了软件项目估算工作中估算时间不确定、技术细节影响估算等多个难点，在实践应用过程中获得了业界的肯定。
近年来，功能点估算方法在我国的推广力度逐步加大。但在实际工作中，由于对方法的内涵和精髓理解不够深入，在方法落地实施过程中也容易发生一些问题。这些问题产生的原因多种多样，笔者分析其根本原因，主要有以下三点：
一、将功能点和工作量等同
在一些较为看重考核的组织中，容易出现此问题。常见的软件项目考核指标，如产品规模、工作量、生产率等，都与功能点数密切相关。功能点数是影响工作量估算的一个重要因素，但并非唯一因素。一些项目经理常常将这两个概念混淆。在实际估算工作中，一边进行功能点估算，一边就在计算开发需要多少时间。当开发时间不够时，为了保证生产率考核指标的达标，就在功能点上想办法。这种为了增加本项目的工作量，人为多估功能点的做法，将严重影响功能点估算方法运用的正确性。
二、未依据业务需求或功能进行估算
功能点估算方法是对软件规模（即软件大小）的一种度量，而软件如何是由业务需求来描述和确定的。由于估算工作通常由项目组在计划阶段完成，很多时候，项目组估算人员都是开发人员，这些开发技术高手容易将技术实现细节带入到估算工作中，由此会产生不少问题。例如，在一个系统模块中按软件前后台分别进行估算；对存放在不同数据库表的同一内部逻辑文件进行拆分；对技术实现中的临时文件进行拆分等。这些问题产生的原因都是考虑了技术实现，而没有以业务需求为基础进行估算。笔者在项目实践中，通过加强业务需求分析的培训，提高了估算人员对业务需求的理解能力，有效减少了此类问题的发生。
三、按功能中的步骤进行拆分
功能点估算方法对功能的拆分有着明确的要求，但在实际估算工作中，估算人员往往没有按要求进行拆分。常见表现有：业务描述了某个业务步骤发生了变化，估算人员就直接按业务步骤进行了估算，这样不符合功能点估算方法的要求，而且还会导致相关估算的严重不足。此外，还有直接按技术方案对完整业务流程进行拆分并进行估算的情况，也属于此类问题。
针对上述问题，可以从以下三点来应对：
一、提高项目管理水平，合理应对估算和评价要求
软件规模（功能点）、工作量和研发效率这三个数据是密切相关的，随意变动其中任何一项，都会对其他项产生影响。在组织级项目管理工作中，建议将功能点有关的指标不纳入到组织级的强制考核中，以此来充分发挥功能点估算方法的优势，更加准确完整地进行功能点估算。在此基础上，帮助项目经理制订合理的项目研发计划。针对项目的考核可以从组织外围视角来进行考虑，避免组织内部管理带来的内耗。
二、重视业务需求的后续分析和完善工作
业务需求质量也是业界的难点和痛点之一。在笔者的实践工作中，碰到的业务需求质量参差不齐，总体来说业务需求的编写水平在逐步提高，但也会看到，由于各种原因，业务需求的清晰度和完整度还有很大的提升空间。在业务需求还有所欠缺的时候，项目组应该充分发挥业务和技术融合的强项，深入分析和挖掘潜在的业务需求，尤其是业务关联需求和非功能性需求等隐含需求，将潜在开发工作量用业务需求及对应功能点的形式表现出来。
三、严格按功能点估算方法进行功能点估算
功能点估算方法对如何拆分、如何计算都有非常明确的要求，但在具体实践中，仍然会碰到各种各样的问题。针对不同情况，编制明确的指南来指导估算人员进行估算并经过三级审核。这里需要强调的一点是，估算指导的稳定性很重要。正确性不足，但都用一个方法估算，可以进行统一调整；如果方法老是变来变去，后期就难以处理了。声明：本文著作权及所有权均归北京中基数联科技有限公司所有。任何形式的转载或引用，均需清晰标注文章来源。
