软件需求管理只局限于软件工程范畴吗？——一个烂尾项目尾款回收案例的思考

近段时间公司在筹备CMMI 5级认证，主任评估师是一位我非常尊敬的是实战派资深人士，为国内很多大企业提供软件工程和管理咨询。应团队要求请老师做了一堂软件需求培训课，这是应老师需要，我分享的一个与需求有关的案例，同时也是从软件工程之外的角度对需求管理的重新思考。

项目情况

13年左右，公司业务重组，我接手了一个新部门，因此接手了一个已结束的烂尾项目，客户是国内一家著名的航空公司。

这是一个整包项目，客户提需求，我们交结果。因为需求变更过多，项目异常终止，留下未执行完的合同，项目成本未回收，处于亏损状态。

好在我方项目经理契约意识很强，每次有需求变更，无论客户的项目经理是否回复确认，都会给对方发邮件说明项目的变更情况，事后经统计的总体变更工作量达到60%。

处理方式

• 确定目标：

和上级领导请示，最低目标是回收成本。

• 客户谈判：

第一步，尝试性沟通：以充足的证据作为基础，先当面沟通，当面说的挺好，回复去努力推动，因为项目是异常终止，结果可以预见，后面就没回音了。

第二步，表明态度，穷追不舍：遇到这种情况，我先是表明有困难可以商量，没有回复我会一直骚扰你，还是没回复。

第三步，书面催款：进入下一阶段，发催款邮件，邮件一律抄送他的上级，还是没有得到解决。

第四步，法律恐吓：最后就是硬的一手，告知再得不到答复我们会发律师函。项目没做好可能也就是部门内知道，如果收到律师函，他的整个部门就在自己公司挂好了，坏事传千里，谁都不想名声在外，于是对方有了实质性响应。

经过半年多的拉锯，最后回款50多万，收回项目了成本。

事后思考

如果没有项目经理的有效证据，这笔款是否收得回来？

为什么需求变更超过60%才以项目终止的方式结束，中途及时沟通是不是会有项目成功的可能？或者其他更好的出口？

其他项目如何避免这样的风险出现？是把关键赌在项目经理一人身上，还是应该有个机制？怎样的机制能以最小的代价预防大部分风险？

组织对项目是如何管理的？项目汇报有没有个内容框架？如何识别和管理项目风险？日常和风险发生时，项目经理、客户经理/销售经理是否有配合，标准的最小行动计划是什么？

需求管理仅限于狭义的软件工程范畴，还是应该与组织的其他管理相协同？组织运营管理应如何与项目管理对接？

 

只有想不到，没有做不到，意识到问题就能解决，关键是有没有相关的意识。