软件项目成败与工作量评估(原创)

在前一篇文章《中国软件企业九死一生之水土不服》中，我着重批判了中国大多数软件企业的急功近利行为。而这一次，我想表达的观点是：对于软件行业，我们确实能力还有很大不足，对软件的工作量缺乏评估能力就是其一。

先给大家讲一个业内流传很广的无奈故事，“六拍”项目：老板拍脑袋，想需求，定工期，此为一拍；老板拍项目经理肩膀，语重心长，委以重任，此为二拍；项目经理踌躇满志，拍胸脯以示信心，此为三拍；工期将尽，项目完成无望，老板发火拍桌子，此为四拍；项目经理满肚委屈，“项目问题多多，我拼死拼活还得受你这个”，拍屁股走人，此为五拍；老板落下这么一个烂摊子，直拍大腿，后悔不已，“早知如此，何必当初”，此为六拍。

六拍中的一拍（老板拍脑袋，想需求，定工期）是其它各拍的先行官，也为其它各拍早早埋下了隐患。那么，难道领导不知道“拍脑袋”的危害，不懂得尊重软件的客户规律？我想说，“不是的”。领导之所以拍脑袋，是因为，无论是通过他的能力，还是在项目经理的帮助下，他都没法比较准确地评估出软件的工作量。

众所周知，软件行业是一个脑力密集型劳动，我国的软件行业还是处于一个比较初级的阶段，还没有很多历史数据的积累。在这种情况下，评估软件的工作量，确实感觉无处下手。软件规模评估方法很多，但行之有效且被我们熟练掌握的并不多。

在此，分析几种常用的工作量评估方法：一、通过功能点对软件规模进行评估。此种方法是我们实际工作中常常祭出的法宝，有着大量的追随者，但由于其原始定义比较抽象，实际工作量与功能点之间的函数关系并不明显，常常还受制于技术选择。比如说，对于统计当前使用系统的用户数这一要求来说，采用B/S方式就很直接，而传统的C/S似乎就得费些功夫，两者的工作量明显不同。又比如，C/S中弹出一个模态窗体是很简单的事，但对于B/S好像也得多想想（声明：本人对B/S了解有限，两个例子可能都有不当之处）。二，常用的评估方法还有类比法和专家法。由于历史数据的不丰富，类比法和专家法也很难奏效，更何况很多的企业也缺少使用这种评估方法的经验和数据。无类可比，没有专家。综上，就不难理解领导为什么要拍脑袋了。

一直以来，我对工作量的度量单位都心存疑惑。比如说，人月这个单位。很明显，12人月让人很难理解。是解析成12个人干一个月，还是解析成1个人干12个月，又或者是3个人干4个月呢？这三者是绝对不同的。可能是我理解有错，关于这个问题，谁有不同的想法，欢迎与我交流。

那么，缺乏很多经验和历史数据的我们，应该怎么对工作量进行评估呢。我的观点就是充分细化。对于功能点，我们评估不准，我们就可以多花点儿时间，对功能点进行初步快速的设计，对分解出来的较小实现进行评估，估计最大值，最小值，以及最可能值，考虑一定的其他因素调节系数，这样，就会相对好很多。

对我个人而言，我坚持做产品，不做项目，对于客户提出来的建议，我都会很慎重地考虑再考虑，才会决定在下一版本中的行动方案。这样做，是本着对客户及产品负责任的态度，保证产品的专业性和方向性；另一方面，也是防止对变化失去控制，造成成本及利润的不可控。宁可错失这个客户，也不能饮鸩止渴，今天拿了订单，明天吐出利润，后天搭上本钱，你怎么看呢？