PM项目案例：产品功能不适用，甲乙双方如何平息纷争

今天，我们邀请了希赛创造营的小伙伴们出谋划策，通过剖析具体问题进而提出解决方案，让大家在实际工作中可以有所参考。

本期案例

项目类别：IT

岗位：项目经理

案例背景：

需求调研和打合都是跟甲方领导进行的，已顺利通过签字确认，开发完成，到达培训验收节点。

遇到的问题：

培训过程中，实际使用者反馈功能不适用，不支持验收结项，甲方坚持先修改后验收，乙方希望先验收后修改。

待解决的问题：

对于客户方，领导签字确认但实际使用者不适用问题如何处理?对于验收节点，甲乙方协调不一致的，如何处理?

主治医师

01昵称：闻道有先后

1、首先要确认使用者反馈需要修改的部分，是否属于已签核确认的工作范围内。如果是，那没说的，乖乖修改符合要求，一起校核验收即可。

2、如果使用者反馈的功能超出既定的工作范围，可分几步走：

①团队内部紧急评估，要完成这份额外的工作，需要新增的成本是多少。如果新增成本不多，内部协商一致后，可向上级反馈，是否同意免费修改。

②如果新增的成本过多，可向上级反馈这件事，请上级出面与甲方领导沟通协商，得到进一步的确认后再行动。

③如果领导同意免费修改，团队可和实际使用者协商，要求实际使用者出具份变更请求(可告知其是免费改)，以最快的速度跑完变更流程后，即可着手修改，静待校核验收。

④如果确认使用者反馈的实际功能超出既定的范围，且上级与甲方沟通失效。团队需要整理下手上的资料，和甲方约定个时间召开会议，需要邀请甲方签核的领导和自己的上级共同出席，共同协商来解决这个问题。最终目的都是要求甲方出具变更请求，以此请求为据来修改额外的需求。

⑤会上要商议确定好各自的需求和时间节点，签字确认;会后及时发送会议记录给甲方和团队内部。然后依照既定的节奏来开展工作，直至完成验收，达到节点目标。

02昵称：米奇

其实这是一个项目需求管理应该自上而下还是自下而上的分歧。个人判断在项目进行过程中应该就已经遇到过高层级需求和底层需求不符的情况了，只是当时这位项目经理考虑高层级需求优先度较高，有点忽视了基础使用者的需求了。

其实在本次案例中，最好的处理时机是在确认高层级需求的同时将需求分发到底层使用者知晓，或在收集需求的时候同时兼顾底层使用者意见。次好机会是在研发过程中收集使用者意见并反馈给高层领导。但考虑到目前开发工作已经完成，建议可以从以下几个方面入手。

正常版:

1、与甲方领导沟通，根据项目合同及需求沟通确认书与甲方领导进行协商，说明根据合同及需求确认情况，目前项目已属于完成阶段，恳请甲方领导进行付款流程并提交承诺书。后期将收集并分析实际使用者的需求，并将需求完善，进行升级或增量。但此刻需要领导支持，针对使用者进行高层推进。

2、与实际使用人员进行沟通，说明本次需求样本采用高层级需求，并得到领导肯定，让其认可系统基本满足使用需求，其中不适用部分为少数，并且收集其使用需求，承诺在某时间段内完成更新或修改。

激进版：

召集甲方领导及甲方使用人员代表一起开需求沟通会，会上讲明需求来源及需求原因，并说明如需针对使用者提出的问题进行二次开发，需要追加成本约XXX，并请甲方领导批示。此时需要坚持超出预算部分需要追加资金。大致两至三次会议后甲方领导就会强力推进验收了。

总结：

其实项目按照高层级需求去实现的，最终验收应该也抓住高层级领导来处理。只要甲方领导同意强推，那么剩下的问题就非常好解决。但是强推的话需要和甲方领导有较好的业务关系，否则可能会做不了长期业务了。为了避免出现类似的问题，建议还是从需求初期就避免此类问题，或采用敏捷而非瀑布形式进行开发。

#我有话说#

@2022朱：

观题目前存在几个问题：譬如相关方识别不到位;范围确认不到位(需求确认的目的未达成);项目监控过程未进行确认;验收前未进行试运行。

通过问题找解决办法：首先项目初期相关方识别要细化，需求调研要包含到所有的相关方的期望，其次验收标准验收范围需要明确，达到什么目标才能进行验收等等。

其次项目进行过程中，产品要多方面进行确认，所有相关方都要包含在内确保满足相关方的期望，最后产品在验收前进行试运行，出具试运行报告不符合项进行修改。最后，达到使用验收规定的标准后提交验收申请。

@错了别怪我：

可以看下实际使用者不适用的程度，如果是部分使用场景没有覆盖到，基础业务流可以流转的情况，那么建议梳理出现有功能模块结合业务场景的使用帮助，没有覆盖到的情况看领导是卖人情给他做还是另外再签合同补充开发;如果整个系统无法保证正常的业务流程和业务逻辑，那改造的代价估计大于重做。

这个时候再去了解其他相关方的实际需求场景，还比较容易让对方误会：

①这个纰漏就是我们问题，现在补漏;

②我们调研好了排除万难就能做;

最好还是领导之间先确认说情况，工具人们再进行下一步的动作。

@一碗钞票：

1、首先，相关方识别和沟通没有到位。需求调研，需要包括所有人相关方，本次案例没有把运营或者用户包含在内。领导实操少，实际使用还是用户或者运营人员清楚产品的实用性;

2、需求清单、需求验收标准需要在项目合同中确定清楚，这个就是避免对方扯皮，交付后不承认;

3、培训验收节点前，可推出测试版先行邀请用户或者运营人员使用，提前收集意见;

4、制定培训文档和操作手册，培训演示操作手册，让使用者按照文档操作。

问题处理办法：

①实际使用者不适用问题，收集需求，按照优先级排期，该加钱的加钱;

②领导签字确定，该甩锅的甩锅;

③验收节点提前沟通。

@SU：

案例中一共两个问题：

第一个问题，领导签字代表甲方正式确认乙方开发有效，按照契约精神，乙方开发所付出的成本、人力都得到甲方验收。而甲方实际使用者认为不适用的情况，是甲方内部上下沟通的问题，如果甲方需更改，双方可协商走新开发项目流程，甲方与乙方重新确定开发内容及成本等。

第二个问题，实际是第一个问题的延续，第一个问题解决了，第二个问题就解决了。如果是乙方开发技术问题，乙方当然需要修改;如果是甲方认为适用性的问题，而乙方是按合同开发的，则甲方先修改再验收属于违反合同。可以使用协商、ADR，最好不要走到司法层面。

最后，解决问题的最好方式是双方都通过协商，各让一步，甲方不能让乙方自己承担重新开发或修改的成本。

@七月：

前期的沟通过程很明确，需求签字确认。现在的问题是，在交付时，实际使用人员认为系统使用不好用，希望按照使用者的反馈进行功能修改。

1、按照签字确认的功能需求进行对标确认，要求客户验收签字;

2、同步收集使用者的修改建议，评估改动开发量以及实现可能性，或是对于某些建议可以使用现有功能进行弥补;

3、将用户已确认的功能和需要修改的以及优化项进行梳理，商务介入谈判，首先确认开发是按照需求进行的，通过对需求项的分析，确认是优化项还是新增功能，对于必须要整改的内容，协商签署补充协议，结束原协议的开发进程，签字验收;

4、对于功能模糊的地方，对开发量进行分析，避免不必要的小功能扯皮，将原合同的约定内容尽可能的快速收尾。