业务频繁的改需求，怎么破？

说起改需求，我想绝大多数的产品经理都对这种行为恨之入骨，想必你也是一样的感觉。

但是，我们却又无能为力。

毕竟，这就是常态，需求哪有不改的？业务哪有不变的？流程哪有不调整的？

最近，我们公司有个新的项目上线了，虽然最终的结果是完成了交付，但是在这个过程中我们就被业务部门折腾的够呛。

一.折腾的项目

先来说说这个项目折腾到什么程度吧。

01.主业务流程不确定

这个项目，最初定的上线时间是3月中旬，但是他们在1月份和我们对接的时候，甚至连主要的业务流程都还没有定好。

就是在这种不确定的情况下，他们的负责人还一直和我们强调，这个项目非常重要，公司非常重视，一定要在3月份上线。

面对这样的情况，我们也和对方明确表示过，如果连主流程都不能确定，是没法保证系统能够用的。

可能是听到我们说这样的话，对方负责人怕万一项目延期的主要责任在他身上，于是他就临时想了一个大概的流程。

具体细节就不说了，大致流程就是：先买票-再联系教练-再预约课程-到预约时间来签到-上课-结束。

而且他还十分强调，里面的每一步都必须要，而且不能跳过，也就是环环相扣。

于是我们就按这个方式进行开发，大约是在2月初的时候，让他们进行内测。

经过他们的测试之后，对方负责人说不行，这个流程太复杂了，要改。

改成：买票的时候可以直接约课，也可以不用教练，也可以不用签到，到约定时间来上课就可以。

然后我们按照这个思路，又调整了一版。大约是2月中旬的时候，让他们内测。

然后，对方负责人还是觉得不行，说还是太复杂了，还要改。

改成：只买票，剩下的教练、约课、签到，通通都不要。

这还只是其中一个流程的改动，类似还有很多其他的流程，也都是改来改去，反复的折腾。

02.项目内部各种勾心斗角

在这个项目的对接过程中，前前后后我们一共接触过3类人，都是不同的岗位，然后他们对同一个流程又有不同的看法。

最开始我们接触的是销售团队。

他们并不关心核心的业务流程到底要怎么走，他们关心的就是如何能够让用户快速的把钱给付了。

对于他们来说，用户钱付了，他们才能拿业绩。至于后续的服务问题，不是他们关心的点。

所以在刚开始的时候，他们让我们做的都是些无关痛痒的功能，比如添加企微发优惠券、在线沟通生成付款链接等等，目的都是为了促进成交。

后来我们又接触到了服务部门。

他们不关心用户怎么收钱，他们关心的是用户付钱后，到现场来的服务过程。

比如他们关心怎么查用户的付款记录，怎么快捷的帮用户约课，怎么方便的让用户可以上课等等。

如果他们两个部门，都是各自关心各自的事情，那还好说。但问题就是，他们还特别喜欢管对方的事情。而且他们两个部门属于同级部门，谁也不听谁的。

所以就会导致，相同的业务，不同的需求，甚至有时候是矛盾的需求。

比如针对用户到现场来付钱的场景，销售部门的想法是先收钱，剩下的再说。服务部门的想法是，付钱+约课一起做掉，减少后续操作的流程。

大家都是站在自己的立场考虑问题，提出的想法也都是对自己最有利的。

03.时间紧任务重

从1月份的接触，到3月份的上线，其实留给我们的时间也就仅仅2个月而已。

这2个月，要做哪些东西呢：1个小程序、1个PC后台、1套硬件闸机。

不仅如此，我们团队的人员本来就很紧张，每块都只有1个人能做，而且还不是全职的，大家手上都还有其他的事情要做。

然后这个项目，又是公司今年重点打造的全新项目。可以说，公司的所有业务重心都聚焦在这个项目上。

于是从高层到执行层，都沉浸在一种紧张的氛围中。

可越是在这种时候，也就是越容易发生变化的。

领导催，业务催，大家都在盯着。你先干着吧，有点进度好汇报，这也确认那也确认，哪有那么多时间呢。

这也是大部分人的常态，用战术的勤奋去掩盖战略的懒惰，到最后的结果就是，干活干得累死，但是要结果没结果，要业绩没业绩。

以上，就是这个项目的基本情况，可谓是折腾至极。

二.为什么会导致这样的情况？

这个项目虽然最终是上线了，但是其中的折腾和教训，到现在我还是记忆犹新，我想可以从下面几个方面来说明下为什么会导致这个项目如此频繁的变更。

01.没有对接到关键干系人

我认为这是最主要的原因，我们没有接触到对方的核心人物，这也就意味着，我们部门所接到的内容，都是别人传达过来的二手需求。

二手需求也就算了，他们自己对需求的意见还经常不统一，这也就导致了需求的割裂甚至是冲突。

最开始的时候，他们来的是所谓的硬件负责人，这个人应该是没有互联网经验的，之前都是从事硬件安装的工作，在这次接触中，他提出了一些他的想法。

第二次接触的时候，主要是他们的销售业务部门，之前的经验也都是偏向线下业务的，在这次沟通中，他们又提出了一些他们的想法。

第三次接触的时候，主要是他们的服务部门，接触下来，发现他们之前也都是没有相关经验的，在这次交流中，他们又提出了一些他们的想法。

这几次接触，他们老大都没有出面。他们老大是直接将一线的工作人员拉过来，与我们直接沟通。

当然，按照我的了解，他们自己内部是没有达成共识的。比如销售部门和服务部门，他们2个部门的需求经常就是冲突的。然后他们老大也不拍板，谁声音大一些，就听谁的。

到最后，向我们提需求的基本就是他们老大了，可能是他们也觉得之前那样的方式不太好吧。当然了，他们老大的需求和他们之前的需求肯定也是不一样的，所以又是一顿改。

如果我们从一开始就对接的是他们的老大，这样的情况是不是就能避免了呢。

当然，你会有疑问，为什么他们这样折腾，你们还愿意做呢？

这就是下面第二个原因了。

02.研发部门的弱势

部门在公司中的定位，取决于公司高层对这个部门的看法，和这个部门的名字无关。

有些公司，研发部门是核心，话语权很大。但是有些公司，研发部门只是辅助部门，没有话语权。我们公司，就是后者。

我们公司在最开始是没有研发部门的，都是业务部门在主导。到公司发展到一定的规模后，公司觉得有必要进行系统化的管理了，才成立的我们部门。

所以我们部门在公司的定位就是为业务部门进行服务的，这也就从基因里决定了，我们部门在与其他部门的对接中只能处于弱势地位。这是公司骨子里带的，没有办法改变。

就拿这个项目来举例吧，他们的对接人，就认为他们的需求我们都应该要做出来，不能影响他们的业务。业务变是常态，做不出来就是你们研发部门的失职。

他们这样的想法有错吗？其实没错，因为公司一直以来就是这样的情况。

所以，在他们那里，就没有所谓的折腾一说，一切都是为了业务，一切都是为了发展。

不仅如此，我们部门老大自己也没觉得这样有什么问题，反正业务说啥就是啥，说改就改。有时候有那么一点小坚持，被对方一说也就放弃了。

既然业务部门这样认为，我们部门自己也是这样的定位，那需求频繁的改，当然就会是常态。

03.业务确实调整的快

最后的一点，那就是业务调整和变化的确实是快。快到我们功能还没有做好，他们就调整了。

但是，我们又不能不做，这就是两难的处境。

这个项目的周期拉的非常的长，跨度达到了2年。所以，在最开始的时候，他们是没有找我们的。直到今年年初，项目的内容定的八九不离十的时候，他们才开始与我们进行接洽。

但就是在这样的情况下，最后的几个月，业务还是在频繁的调整。

最初的时候，他们老大和我们部门其实是商量过的，大致意思是说很多东西都不确定，开发的任务其实可以缓一缓的。但是这时候，公司高层发话了，他们觉得有些东西是要提前准备的，如果所有东西都等到最后才做，时间肯定是来不及的。

所以就是，研发跟着业务跑，一遍一遍的试错和调整。

从开始的接触到最终的上线，主流程大概就改了3、4遍。每更新一次，就让他们去实地模拟和体验，有问题就改，有不通顺的就调。

就这样在反反复复的状态下，目前总算是到了试运行。但是我相信，接下来，还会有一系列调整在等着我们。

以上的3点原因，能大致解释这个项目折腾的原因，每个点其实都不是孤立的，环环相扣才导致整体的局面。

三.如何避免？

面对业务需求频繁变更的情况，我们研发团队能够怎么做呢？

01.改变自己的心态

这一点真的不是阿Q心态，而是做产品人该有的自觉。

需求变，是常有的事，只要习惯了这个设定，自己就能够坦然处之。

市场在变，业务在变，自然而然的就是需求也在变。

那些所谓的以不变应万变，都是在前期无尽的折磨和折腾之后，才能总结出来的一套不那么普世的方法论。

所以，前期那些经历，产品人是逃不掉的。

在产品主导型的公司里，这样的需求调整，可能没有那么频繁。毕竟话语权在自己手里，掌控的度也比较好拿捏。

但是在业务部门型的公司里，产品的话语权就小了，自己所能掌控的也就很少。

比如上面提到的我们公司的新业务，业务方说他们的流程已经调整了，我们产品部难道可以说我们不改？我们产品部难道可以说之前的需求不是这样的，我们不做？

这是不可能的对吧，业务在前的公司，产品只是辅助。

再退一万步说，如果哪一天业务没有新需求了，那产品还有存在的价值吗？

所以，平常心看待一切，认清部门的位置，明确自己的定位。

02.改变开发的思路

既然我们已经知道业务部门的需求会频繁的调整，那么我们自己的开发思路和方法，是不是要调整一下？

如果还是按照传统的预测型来，显然是不符合现状的。

所谓的预测型，就是：需求调研 → 需求分析 → 方案设计 → 产品开发 → 产品测试 → 产品验收 → 产品上线。

这套方法很好，只是不那么灵活，只是不能适应快速调整的业务。因为有可能你还在做方案设计呢，他们的需求又变了。

换个思路，换个方法，也许就没有那么纠结了。

我们公司也在尝试，就是你业务说要改成这样，好的没问题，我先按你说的，最快速的给你做一版出来，但是功能可能不是很完善，只能保证基本流程能跑通。

如果你们觉得这样的流程没有问题，那接下来，我们就把里面的内容完善完善，让他变得不仅能用，而且好用。

如果你们觉得这样的流程有问题，那也好办，我们根据你们的业务来调整，反正上个版本也只是基础流程，调整起来也方便。

这就是我们目前正在做的思路，也就是所谓的敏捷开发，这也是目前很多公司开发都采用的流程，主要是为了应对快速变化和调整。

既然不能改变，那就努力去适应和调整。

03.让业务深度参与

业务变更需求，一部分原因确实是实际的情况发生了变化，不得不改变。但是还有一种可能，那就是业务变更的代价太低，对他们来说没有任何成本，变就变了，反正也不是我开发的。

如果让业务深度参与到每次的研发过程中呢？当然，肯定不是让他们开发，而是让他们频繁的确认。

比如在准备开发前，将流程图梳理清楚，然后找他们进行反复的确认和沟通，让他们通过流程图来演示业务实际的场景。

比如在开发测试的过程中，让他们全程参与，让他们能够在测试的过程中实际体验最终预期的效果。

比如在产品发布上线前，让他们再次确认，确保最终所要交付的产品就是他们想要的，避免上线了说不是想要的效果。

只有这样，让他们深度的参与到产品开发的整个流程里，他们才会认真对待自己的每次想法。

同时，大部分人对自己投入很多精力的事务都是有种复杂的感情的，不到万不得已，一般不会随便推翻自己辛辛苦苦琢磨出来的东西的。

这也就是说，投入的越多，越害怕失去，对业务来说，也是同样的道理。

一些想说的话

产品经理的需求大部分都是来自一线的业务，因为他们离前线最近。

但是无休无止的变更，也会消磨产品经理的耐心和任性。

接受变化，但是不随意瞎改，这其中的度，产品经理需要拿捏。

- - - end - - -