遇到不合理的业务需求，项目流程和走向不如愿，你是如何应对的？作者复盘了自己的这次项目，针对两个版本进行了分析，总结了相关经验和教训，希望对你有所启发。
大家在做项目的过程中会不会碰到以下问题？
- 业务总是提出不合理需求，产研部门苦不堪言；
- 业务人员总是不按照定好的流程操作系统，自己搞“野路子”，功能不是落地不下来，就是要按照他们的要求重新设计；
- 项目上线前信誓旦旦的承诺，上线后立刻又变了个样子，导致需求反复修补；
而正好最近，我也遇到了这些问题，但最后还是将项目成功上线，并顺利跑通。
虽然项目本身是需要增加公司内部的「订单审批」的功能，看起来并不大，但由于我司商品机制复杂、且牵涉到了底层订单模块，导致这个功能并不像市面上一般审批功能好做。
这个项目有两个大的版本，版本1上线时出现了诸多问题，版本2却十分丝滑地嵌入了业务流程。
为什么两个版本会出现如此大的差别，我在版本2的设计中究竟做对了什么？
我对这次项目复盘了一下，总结出了十分重要的经验分享给大家。
话不多说，让我们正式开始吧。（老规矩：加粗字能帮你快速阅读）
背景说明：我负责在线教育公司的自研系统，本次举例的功能是订单录入 审批的功能。
一、版本1-设计阶段这个需求最先开始于业务希望新增录入订单。
于是这个项目最一开始的版本，是先简单做了一个录入订单的功能。
它十分简单：销售人员在后台操作录入订单→订单生效，客户使用，就完成了。
不久之后需求发生了改变：除了录入，还需要新增审批功能，理由是财务需要风险控制。
我当时心想：哎呀，这还不简单吗？审批功能是市面上已经成熟的常见功能模块，并不是很难才对。
完成了初期的调研工作后，很快，我与相关部门进行了第一次会议，定下了本次项目目标：
顺着这两个目标，我开始了产品设计。
这个过程也并不复杂，我参考了市面上已有的审批功能设计，刷啦啦就完成了第一版的产品设计，简版示意图大概如下。
省略了一些环节，大家可以简单理解。
拿着初版，我们开始了第二次对齐会议。
问题从这里开始出现：
会议上业务人员提出特殊要求，出于各种业务原因，希望能让订单先生效，审批后置。简版示意图如下：
这个要求在我看来十分“不合理”：如果订单先生效，那审批只是摆设。本身审批就是为了控制风险，这么一来是为了什么？
经过协商，业务人员用充分的理由打败了我们：需要立刻使用订单的客户占比不少。
于是，我只能硬着头皮去设计这一个功能。很快我就发现了问题：这么设计会让损害客户体验。
简单地描述一下就是：我们存在关联商品。当某个商品订单被驳回后，连带着所有的关联商品都会出问题。客户则会在某一时刻看到自己的所有订单都无法使用。
这期间我觉得十分奇怪。拉起了第三次会议，但业务和财务人员仍然没有表示什么。认为如果有驳回的情况，客户体验感差也是没关系的。
销售主管表示：“保证大部分客户的体验才是最重要的。其他的少数客户我们会解释。”
回想起来，这句话给我埋了个深坑，我应该及时注意到指望销售压住客户，是不靠谱的。
财务人员没有对该需求表示异议，我仍然按照这个版本的设计正常推进了。
二、版本1 – 使用阶段很快，第一个版本如期上线了。
但上线后——问题爆发了。
首先是我们对功能预期使用出现了偏差——比起客户未打款，销售人员错误录入信息的情况更多。
原因是这条是新流程，此前我们从未试跑过，自然就没想到销售人员录入订单能这么不“走心”，有些销售竟然能把客户都写错。
其次是驳回订单的修改流程落地使用出现问题，体现在销售人员总是忘记要修改订单，一笔错误订单在客户端正常运行着，尽管财务一直催促，销售人员却屡屡先集中于开单工作，而将修改工作抛之脑后。
于是我们紧急上线了补充版本，为了跑通补充版本，又和各方需要配合的部门人员几番沟通，连续加班好几天，可谓是心力交瘁。
本来以为万事大吉了，没什么大问题，但销售侧却开始推翻自己在对齐会议上许下的承诺。
一天，销售人员小B找到我：“小里小里，这个你快帮我看看怎么回事呢？”
我回答：“是财务人员驳回了订单呀。”
小B大惊失色，表示驳回订单后，客户反应很大，情绪很糟糕，希望能将订单恢复给客户。
我表示，这是因为客户本身的问题没有打款，自然是不能恢复。
但小B继续说，客户人在海外，打款有时限，希望我们能通融一下。
我对此事感到不满：“可明明是他没打款吧？”
小B则解释说：“我们还是希望他能打款过来呀，总不能得罪他吧。现在大家都会上小红书写我们坏话了。我可得罪不起。”
至此我是明白了，之前完全是我天真了，销售怎么可能得罪客户呢？
经过几位大佬们的商讨，我们仍然同意了销售的“新诉求”，就这样运行了1年多的时间。
以下大概是这个流程的简版示意图：
经过这次的项目，我总结出了2点经验教训：
1. 流程未试跑，便直接接入系统
这次的项目是建设一条新流程，此前我们从未试跑过。所以真正系统上线后，出现了许多我们未能预料的情况。
所以当我们的项目是建设一条新流程时，最好让业务先在线下试跑，跑通后再上系统。试跑的方法，这里限于篇幅，我会另开文章说明。
如果业务没条件去试跑的话，那么系统在这时候的介入应该保持最小介入，简单开发，不能做太个性化的设计。
简单开发的思路，我会在下文继续跟大家详细分享。
2. 不能过分听信业务或任何其他部门给给予的保证
屁股是决定脑袋的：所有人都是根据他的指标去行动的。
销售的指标是营收，要去得罪客户其实是很困难的。也许他在跟你做保证的时候心是好的，自己也想往那个方向努力。但是当指标压力给下来时，未必如此好操作。
还有一个例证是管理层有时会承诺说自己会从哪一个环节中给予监督，帮助系统落地。但往往随着业务高峰期的到来，所有人都集中于冲业绩，“监督”这个事情慢慢变得无足轻重。
也许他认为监督很重要，但是时间精力已经不允许他完成监督工作。
所以对方给予了保证，我们应该都持怀疑态度，准备好一些备用方案。
三、版本2 – 设计阶段1年后，因为公司内部调整，这个功能再次出现问题。就新版的审批如何调整，我们半年前开始了各种“掰头”会议。
我强烈反对了继续使用「先生效，后审批」的流程，并举例说明这个流程中已经存在的种种问题和给客户体感造成的损害。
业务人员则一直强调立即生效的必要性，也拿出了数据证明。并且认为保证客户体感应该是产品需要考虑的问题。
这段时间陆陆续续拉了几次会议，我们一直达不到共同的结论。
最后事情迟迟没有推进，领导喊上了业务最大的负责人一起商讨。
业务总负责人则认同应该审批后再生效订单，可能是位置的原因，他也更愿意为公司利益考量。但属下反馈的问题他也不得不管。
最后在总负责人的协调下，我们采取了折中方案：
- 存在关联关系的商品，不允许先生效，必须等待财务审批通过。
- 简单商品的订单需要先对客户生效。
拿到会议结果的时候不由得喜从心中生，产品设计的时候多快了许多。
不过我们仍然面临着「简单商品的订单，需要先生效」的问题。
这次我也学会了不再埋头苦干，和其他团队伙伴、领导进行了一番商讨后，我们发现这个功能也许并不需要很复杂。
过去我们下意识地认为录入订单就是要生成正式商品（课程），让客户使用。
但是只要我们多开一个「临时商品」，只让客户使用，而不产生正式订单&商品的数据，整个开发量会小非常多。
最后我们确定了这个简单的实现方法，即把「生效」和「订单」两件事分开来。让功能自行闭环，与订单模块隔离开来，即使出问题了，也能减少影响面。
我们是如何得出这个解法、思路是什么，我会在「方法论提取」部分重点说明，大家可以继续往下看。
同时我也吸取之前的一些教训：功能流程太长、复杂导致的问题，在这一版设计中我都尽力规避，去做到「高内聚、低耦合」。
例如我将订单修改功能删除，仅保留录入订单功能。
如信息有误，则直接在录入时选择错误订单，便可由系统快速填充信息提交新审批，无需自己手动重新填写。
这个功能最后通过我的一番改造，从6个功能模块，简化为了3个功能模块：
最后上线后，只做了一场培训，线上意外的比我想象中更顺利的跑通了起来。
并且在培训环节中，我们改变了过往的培训流程。
过往的培训流程中，由产品向公司所有人宣导，所以不直接操作系统的管理层，往往当个”甩手掌柜“，遇到问题了就问我们，一线人员也是直接来问我们。
而一线人员的流动性较高，我们也每隔一段时间就需要回答同样的问题。
新的培训流程只跟管理层培训，由管理层下发到一线执行人员，他们的问题由管理层解答。
这种模式不仅让管理层能更清楚系统能做什么，而且一线人员学习时，因为由上司直接培训，效果也好了许多。
版本2的顺利上线和使用让我终于松了口气，回想起来，我在版本2中做对了这几点：
- 学会拆分问题，不将所有问题整合起来处理。就像订单生效和订单使用，未必是一回事。
- 产品设计时，一定要遵循「高内聚、低耦合」的原则。不仅开发起来更简单，对业务人员的使用也更方便，无需记忆太多的使用方法。
下面，我想根据上文提到的几点经验教训，给大家分享下这中间可复用的方法论。
1. 拔高一些角度看，为什么版本1各种问题，版本2却如此丝滑顺畅？
这里是我自己尝试从全局的角度思考这个项目，不一定对，欢迎大家和我一起交流。
1.1 公司战略上
做版本1时的公司战略，现在回想起来是做出比去年翻2倍的营收，那么当时公司的重心一定是营收。
而审批的需求，更多是出于风险控制，与营收无关。所以审批需求，它牵涉范围很广，需要各部门支持以外，却又得不到公司的战略支持。
意思就是实际落地时，其他部门人员觉得：我可以配合你，但你可别挡着我搞营收，压力可大呢。
做版本2时的公司战略，发生了重大改变。从营收，变为了重点控制成本、保证流程符合要求。
所以在版本2的需求会议上，很明显地感觉到财务部门的人说话都更有底气了。
总结起来，做版本2时，需求符合公司今年战略，所以推进起来更丝滑。
1.2 公司流程上
版本1时，公司未建立审批流程，所有的一切都是0-1。
版本2时，公司已经跑了1年多的审批流程，有些曲折，但终究是能跑通的。
所以这两点的差异，又导致了版本2注定比版本1好跑。而我在设计流程时，更是注意这一点，未增加新流程，而是把旧流程中不必要的细节剪裁掉，业务人员非常容易熟悉，不需要额外的学习、沟通成本。
1.3 公司文化上
这是一个非常有趣的视角，意思是窥探其他部门的做事风格。
从我这次项目中，可以感受到销售部门是非常担心得罪客户的，即使可能公司利益有损失，他们也不愿意得罪客户。
这和指标有关，也和他们长期以来的工作习惯有关。
和多几个销售沟通，发现他们都有一样的担忧。可以理解为，整个部门的风格是这样的。
所以如果事先窥探到这一点，就很容易理解为什么后来销售侧会推翻自己在会议中的保证。
方法论提取：
之前读《金钱博弈》时，得到了一个洞察：当项目进行到一定时间后，成和不成很可能已经不是谈判人员的问题了，是这背后势力的较量。
所以从这个角度去理解版本1为什么出问题，版本2为什么不出问题，就更容易明白一些。
在需要多个部门协作配合的项目中，如果没有公司战略支持，那么想要实行起来是十分困难的。
在开始一个项目前，可以先了解一下公司今年战略是什么，各个部门的规划又是怎么样的。
作为一个个体，我们要尽全力做好。
但是也要学会观察整个环境中，我们究竟受到哪些限制，这样才能更好地定位接下来该如何行动。
如果我能尽早的观察到这一点，可能后续的产品设计中，就会十分简单去设计，并且只重点做一个监控看板供财务部门分析订单数据。
这样既完成了项目目标，又避免了复杂设计带来的风险。
同时，我们也可以反向得出一个结论：花更多时间去做公司战略相关的项目。
不仅项目推进更顺畅，这些工作在年终总结、或晋升汇报里才能让我们更亮眼。
2. 面对拒无可拒的不合理需求，如何尽可能做的合理、可复用性强？
版本2中，虽然业务负责人松口退让了一步，但我们仍然需要完成简单商品的「先生效、后审批」。
面对一个不合理的需求，我们是如何得出「订单生效和订单使用拆分开」的结论的？这里给大家重点分享一下解题思路，那就是：「拆分问题的思想」。
首先这里的问题看上去是是否要做「先生效，后审批」的功能，其实隐藏着3个问题：
- 是否应该是先生效，后审批？
- 录入订单后，客户可以等待多久？它应该在多久内生效？
- 客户使用商品，与订单生效是必定划等号的吗？
第1个问题，按照市面上能够接触到的竞品来看，几乎所有的审批都是先审批，后生效。
先审批，后生效不仅开发流程简单，不易出问题以外，也能避免成本的隐性支出。
第2个问题，根据之前客户消费习惯数据来看，业务提出的观点去确实有道理。
第3个问题，与开发进行了一番讨论后，使用商品，并不一定等于订单生效。
这里带出了解题的第二个重要思路：「尽量不与重要模块耦合」。
订单生效后代表着订单数据生成、营收数据生成。但我们可以另外做一个「临时使用权限」，类似与给内部人员使用那种。
方法论提取：
- 遇到两边都是死胡同的问题，先将问题拆解开。不要将多个问题揉杂在一起。
- 拆解后，观察问题之间是否划等号？问题1=问题2吗？
- 如果不划等号，问题之间的平衡点在哪里？
- 最后设计时，尽量不与重要模块耦合设计。
这里我的平衡点是采用临时权限的功能来解决问题。
大家如果在工作中也遇到了类似的困难，可以采用这个方法去思考一下，说不定就有新的思路。
结束语最后给大家总结一下本篇文章的几个重要经验教训：
1. 面对不合理需求，产品应该怎么处理？
学会拆分问题，不将所有问题整合起来处理。
尽量将“不合理”需求设计“合理”。具体的方法论也写在了上面，希望对大家有帮助。
避免功能流程太长、复杂；遵循高内聚、低耦合的设计原理。
2. 业务人员总是不按照定好的流程操作系统，自己搞“野路子”
建设新流程时，谨慎在业务未试跑前，就增加系统接入。
如果有可能，应让业务先在线下试跑。如无法试跑，则保持系统的最小介入，简单开发MVP版本。
3. 项目上线前信誓旦旦的承诺，上线后立刻又变了个样子，导致需求反复修补
不能过分听信业务或任何其他部门给给予的保证。准备好自己备用方案。
最后学会从公司战略、部门规划的角度理解项目。为什么高层想做这个项目，他们会有多重视这个项目。同时也尽量多去做跟战略相关的项目，会让我们协调其他部门，推进项目都更顺利。
那么今天的分享就到这里，如果你觉得本篇文章不错，请帮我点个赞，给予我一些鼓励吧~
如果你对文章有任何疑问，也欢迎来找我一起交流。
本文由 @Thea小里 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
