需求又变了，要不要怼回去？

需求变更，让每一个技术人头疼的问题，应该以怎么样的态度来面对需求变更，是今天要讨论的话题。

 

为什么技术人讨厌需求变更？

一个典型的互联网产品项目的流程是：

（1）调研，产品经理设计需求；

（2）产品经理和技术进行需求评审；

（3）技术进行方案设计；

（4）技术进行编码实现；

（5）技术进行功能联调；

（6）技术进行提测，开始进行测试；

（7）若干轮测试与BUG修复，达到准上线状态；

（8）发布沙箱环境，进行最后一轮沙箱测试，达到准发布状态；

（9）将产品系统发布到线上；

 

不管使用敏捷看板，还是传统瀑布式项目管理方法，就单个项目来看，这流程是串行的。

画外音：如果够敏捷，产品、测试、研发等角色是流水线的。

 

可以看到，产品方案是在项目流程的最上游，产品方案确定后，技术同学会按照2-3-4...-7-8-9等步骤将产品发布上线。

 

试想，现在项目流程进行到了第x个步骤，产品经理突然说，产品方案要变化，这意味着什么呢？

这可能意味着一系列工作要推到重来：

（9）线上发布白干了，产品要回滚；

（8）沙箱发布白干了，沙箱要回滚；

（6-7）若干轮测试白干了；

（5）联调白干了；

（4）代码白写了；

（3）技术方案白设计了；

（2）需求要重新评审；

（3）技术方案重新设计；

（4）代码重新开发

（5）系统重新联调；

（6-7）重新提测，迭代测试；

（8）重新发布沙箱；

（9）重新发布线上；

 

产品经理们，尝试着体会一下技术们的心里感受，就知道为什么技术这么痛恨“需求变更”了。

 

看到这里，一定有产品经理嘀咕“有这么夸张么，只变了10%的需求，需要全部重来么，技术同学也太矫情了”。有必要全部重来么？能不能省去联调、提测、测试的几个环节？

很多人把产品设计比喻成建设高楼大厦，产品经理是大厦设计师，技术是工程师。大厦快建成了，设计师突然说，图纸要修改10%，工程师要不要重来？还是说省去几个环节？

 

那么，需求变更了，技术同学要不要怼回去？

 

在一家互联网公司，产品技术是很难分割的一个整体，他们虽有分工，各有侧重，但归根结底其最终目标是一致的：为达成公司业务目标共同努力。

 

为了这个共同的业务目标，产品经理的工作思路与逻辑应该是：

“在资源有限的情况下，做什么产品、工具、后台、运营活动，对业务目标的达成最有帮助，就最先做什么”。

 

然而，有些产品经理的工作思路与逻辑却是：

“想一出是一出，拍脑袋决策，凭直觉决策”：

• 登录这里改一下，能够提高转化率

• 详情页这里改一下，能够提高留存率

• 过节发个红包，能够拉新，能够提高活跃度

 

无穷多的需求上线后，无非是这几个结果：

• 产品成功了，哇，天才的构想

• 产品效果不好，嘘，技术们在忙着做后面的需求，也不会有人注意到

• 有人想起来要复盘，可以用“互联网产品，还不允许试错啦”搪塞过去

 

在“人人都是产品经理”的时代，有多少没有调研，没有分析，凭借直觉的产品经理，拍脑袋出来的需求，让一大帮技术专家为之操劳花好几月去实现。

画外音：这句话是对产品经理的侮辱，还是？产品经理的门槛很高，专业要求很高的。

 

不仅如此，项目半途，有多少需求是因为产品经理“之前没有想清楚”变更了需求，让“几百人日”的研发投入付之东流。

 

即使有些非常资深，非常厉害的产品经理，但人数一多，每个产品经理都想要业绩，在研发资源有限的情况下，为了争抢资源：

• 我这提了N个需求，总得排期一个吧

• 竞品有了这个功能，我们也必须有一个

• 老板说了，这个功能必须在节前上线

画外音：

（1）既然负责这个产品模块，必须提对应的需求呀；

（2）劣币驱逐良币；

一将无能，累死三军。

 

所以，这不是一个简单的“需求变更，要不要怼回去”的问题，甚至不是一个“需求提过来，要不要承接”的问题：

• 产品技术作为一个整体，共同为公司的业务目标服务

画外音：有些公司甚至有“技术不允许拒绝需求，不允许拒绝需求变更”的畸形文化。

• 产品作为技术侧的上游，需要系统性思考问题，而不是拍脑袋提需求

• 技术侧作为产品侧的下游，不能只是一味的接需求，要帮助他们想清楚，少为业务埋坑

 

技术侧能够如何帮助产品，让他们把需求提得更靠谱呢？

至少，“过节发个红包”这类需求评审时，多问这么一些问题：

• 哪些产品指标，和业务的最终目标相关

画外音，假设有：新客，转化，留存，下单等。

• 这些产品指标中，哪些是主要矛盾

画外音：假设是新客。

• 对于这个产品指标，做哪些事情可以改善

画外音：假设有12345五件事。

• 对于这五件事，哪件事投入产出比最高

画外音：假设真的是“过节发个红包”这个活动。

• 对于这个活动，活动方案有几种优缺点是什么，为什么最终选择了这一种，活动逻辑是怎么样的，活动效果有没有预估，有没有埋点，活动结果怎么评估...
  

画外音：啥？活动只有一种方案？

事先问的问题越多，讨论得越充分，需求就越靠谱，需求变更的几率就越小，埋坑的几率就越小。

 

总结：

• 产品技术作为一个整体，共同为公司的业务目标服务

• 产品经理要系统性思考问题

• 技术要帮助产品经理系统性思考问题

 

有技术的同学说，我天天在做需求，没时间想这些问题，没时间和产品经理讨论这些问题，怎么办？

你MB，你活该天天加班。

架构师之路-分享技术思路

推荐阅读：

《我不够聪明，但我就是不服》

《技术演讲，如何快速做到80分（值得收藏）！！！》

《离不开的微服务架构，脱不开的RPC细节（值得收藏）！！！》

《“搜索”的原理，架构，实现，实践细节（值得收藏）！！！》

兄弟姐妹们，你遇到过需求变更么？