这篇文章通过一个具体的故事，揭示了产品需求价值评估的复杂性和实际操作中的困境。它讲述了一个业务部门对现有系统效率不满、提出改进需求，到产品经理如何评估这个需求的价值，再到需求实施后的实际效果与预期之间的差距。

业务部门觉得现有系统的录入合同信息功能就是“反人类”！

一个新合同要在ERP、财务系统、OA审批系统分别录入，录完合同然后再录入收款，假如合同的收款分为多次，那负责合同收款的小姑娘就要哭啦。因为合同收款是一线销售在跟进，收款到账是财务部进行核实，中间是小姑娘向销售人员要到收款信息后录入系统，工作流才能串联起来。但是，有些合同收款周期太长，销售忘了提供合同后续的收款信息（实际已打款），财务部就多了不少“无头账”，小姑娘就得拿着一笔笔银行转账，去ERP系统里找哪个合同收的款。因此，小姑娘经常加班到深夜9、10点，大好年华都奉献给了公司。

小姑娘很委屈，就找到部门主管诉苦。业务部门主管一听，觉得有道理，公司的系统是该好好改造一下了，这破系统，简直就是让人在给系统打工！于是，业务部门给IT部提了一个需求，要求合同信息不用录入3次。

产品经理小吴一听这需求，简单啊！做个系统间的数据同步不就好了嘛！

产品经理老吴会心一笑，别急！咱先来看看业务部门在3个系统的功能现况。

接着便发现：

1. 需要录入的合同信息主要为十几个合同字段，还有一些附件材料。
2. 在ERP是在项目签完纸质合同的时候录入合同，在OA审批是项目合同上报管理层的时候录入合同，在财务系统是项目第一次收到付款的时候录入合同。
3. 在OA审批时要填写的信息远不止合同信息，还有很多线下收集的材料、审批流字段。也就是说，如果做数据同步，只能把3次录入减到2次，并不能减到1次。
4. 更好的办法是将收集合同信息的录入工作转移到一线销售员工身上，因为销售员工上百名，分摊到每人不过0.5个合同，不会给他们造成很大的工作压力，并且销售跟进自己的合同更上心。
5. 需求的另一个块——“无头账”的解决方案，则同样将收集收款信息的工作转移到一线销售员工身上，从而释放小姑娘的工作压力。

这么一来，功能应该设计成：在APP新开发两个表单收集页面，在PC后台新开发一个管理页面。

老吴又找到小姑娘细聊，确认完她日常苦逼的工作之后。问她：每个合同要花多少时间处理？每个月大概有多少个合同？

小姑娘满眼真诚地说：“每个合同都要花掉她1小时录入，一个月大概有40个合同。假如合同分多次付款，则还要多花1个小时。”

老吴脑子里开始盘算：算她一个月大概50小时做这事，一年是600小时，折合下来差不多是3.4个月（720/22/8）。小姑娘的人力成本是10k/月，那么，这个需求的成本是34k。然后，IT部为此投入的产品、开发、UI、测试的人力成本算1人月吧，研发的人力成本是30k/月。需求的投产比是114%，虽然是正收益，可价值不是很大。

告别了小姑娘，老吴把分析结果给小吴讲了，小吴惊呼，这需求没多大价值嘛，一般需求的投产至少要到200%。给它放着，先做价值高的需求吧。

老吴又说：“你还是天真了，我们需求池的里的各个业务部提的需求，价值、投产真的有那么高吗？大家知道投产会影响需求优先级，于是业务部门报过来的需求价值往往高估，甚至水分十足。这小姑娘不谙世事，说的却是实际的。另外，这个业务部门领导平时在老板面前威望很重，要是拖着人家，人家到老板那边告我们的状，我们可要吃不了兜着走。”

小吴：“这可咋办？”

老吴：“这样，你私下里跟那个小姑娘说一声，告诉她正式提交需求给IT部门的时候，不要把价值评估的范围局限于她自己一人，把财务同事、销售人员花的时间，以及她和相干人频繁交接所花的时间都算进去。”

小吴：“高还是你高！不仅瞬间提升了需求价值，还TMD贼合理。”

小姑娘听了豁然开朗。不过，她还是很谨慎，把这事告诉了部门主管，主管一听，当机立断：“这必须得把价值提升上去啊！”内心嘀咕：我只管提升我们部门的工作效率。心里默默地夸奖老吴、小吴：这两个IT部的员工，很懂得做事嘛。

于是，小姑娘在正式需求单里把每个合同的耗时从1小时改为了3小时，一个月大概150小时，一年是1800小时，需求成本约合10万，投产比暴增至333%。需求优先级大大提高，顺利排上期。

一个月后，需求上线。

小姑娘却发现新功能上线后，并没有给她省下很多的时间，因为销售人员还是习惯性的把付款材料传给她，还有些销售抱怨要自己传资料很麻烦，不如之前线下的流程来的方便。小姑娘反而变成了一个辅导员，每天教销售人员如何填写合同信息、如何提交付款记录。

过了不久，公司企划部抽查IT部的工作成果，正好选中了这个“合同信息”的需求，于是，便去询问需求提出人——小姑娘——实际使用效果如何？以及“有没有为业务部门每个月节约150小时？”

小姑娘犹如被雷劈了一下——怎么还有检查啊！现在要暴露了，咋办咋办？一时之间不知如何开口，只好支支吾吾的说：“那个……确实有所帮助，那个…….实际节约的时长，我……我……再回去问下我们领导。”

慌慌张张的小姑娘跟领导说了检查的事，领导一听，眉头微微一皱：被抽到确实有点倒霉，但兵来将挡水来土淹，总能应付的。要是现在事实求是汇报使用现况的话，就会说我们部门虚报需求价值，估计IT部两位产品经理也要被批评需求管理不当——不行！我们把效果说的好一点，这样才能证明我们部门是认真做事、积极向上。

领导把小姑娘拉过来，跟她说：“你这么…这么…写，这样…这样…说，明白了吗？”

有过上次点拨的经验，小姑娘立马心领神会，回去“啪啪啪”敲键盘，给企划部回复到：合同信息需求不仅帮助业务部门员工节约了150小时/月的合同收录时间，相关员工还做了更多工作，尤其是辅导销售人员这一块，培养了我们的销售队伍线上化作业的能力，使我们整个销售流程更加合规、更高效。在此，非常感谢IT部的支持和相关产品经理的出谋划策，帮助业务部门降本增效。

企划部收到回复表示满意：业务部认可需求价值，并且逻辑也说的通。此外，因为“流程线上化”是当年公司创新主题，企划部还将该需求标记为“有价值案例”。

至此，这个需求的故事收获了一个各方“皆大欢喜”的结局。

可是，这个结局似乎也不尽如人意。需求价值虚报的，需求产出蒙混过关，小姑娘也没因需求省心多少，销售还在吐苦水。

这就是一个普通的关于需求价值的故事，或许，也是很多产品经理经历过的事儿。如果也曾感到无奈，这里有三条建议给到分享：

1. 做好需求调研、分析。业务夸大需求价值不可避免，产品经理收到需求时不可盲目轻信之，多思考，多去体验用户的场景、流程，从而避免被业务忽悠，做了低价值的需求。
2. 做好用户陪伴、追踪上线效果。新功能需要一个试用期和学习培训阶段，需求价值不能马上体现，保持耐心，比如过一个月再看需求效果，如果解决了主要问题解决了，那么需求基本没太大问题，还有些小问题一点点优化就好。假如主要问题没解决，那就说明这需求最初的分析判断有误。
3. 保持清醒的认知。有些时候有些需求价值不高，但也“必须做、必须上”，产品经理人轻言微，那就内心明白这个需求本质是什么就好，做好原型、文档等本职工作，其他的就让他随风去吧，别因此精神内耗。