为什么软件需求沟通会这么难？

作为我公众号的第一篇文章，来和大家揭秘下互联网公司是怎样进行软件开发的。

有在互联网公司工作过的朋友大致都能理解，一个软件的需求，往往最开始是原始需求的对接和整理，接着需要进行软件需求评审，而后开小会确定各个开发岗位的开发任务，紧接着开发完成后的联调测试，最后才是这个软件功能的发布上线。

如果团队中有好的产品经理或好的开发，或许会让这个进程加速许多，但任何一方出了差池，那就是无限循环的撕逼和冷场。

在这里简单的以ToB公司描述个故事，以甲方强制增加需求：“实现用户成就体系”为例子说明。

正常首先收到需求的是产品经理，当产品经理收到“实现用户成就体系”这一需求的时候，他大概的想法是这样的：

“卧槽为什么要成就体系？特么谁想的这功能？要不要埋点？奇怪现在的用户量没必要先开启成就体系啊？完了完了这下前后端有的忙活了？我要不要创新下成就的体制和样式？算了算了我看一下别人怎么做的吧！哎又要被喷模仿了。没事没事先完成功能。嗯我要开始查资料了。

而后是开发部门收到这个需求的通知，先说下设计师的心理活动：

“哪个傻X想的成就体系？卧槽这得做多少动效？有没有原型？一定是产品经理想的功能！折磨死人了擦擦擦擦擦擦！这产品还需要成就？做了也白做啊感觉？哈哈哈不过想想程序员更苦逼心里还是好受一点点！不对等等产品来沟通的时候我要怼回去。

接着是前端开发工程师的心理活动：

“哪个傻X想的成就体系？这得写多少效果出来？我去数据都是有关联的！产品经理会不会埋点啊？这产品也要做成就体系？咋不上天？哈哈哈哈哈后端哥哥来开发半死！算了算了等需求吧。”

而后是后端开发工程师的心理活动：

“哪个傻X想的成就体系？这得掉多少头发啊！每个数据都要关联起来做个蛋蛋啊！产品经理要不要埋点啊？自己写还是接别人的平台啊？哈哈哈哈哈哈爆炸爆炸！这个服务器不知道受不受得了。算了算了等具体需求吧。”

最后是服务器开发和运维的心理活动：

“哪个傻X想的成就体系？带宽不够啊要爆炸啊！有没有服务器扩容的预算啊没预算做个蛋蛋啊！有没有并发的要求啊！卧槽没做负载啊！卧槽数据库要备份啊！怎么做不完的需求啊！能不能好好睡个觉陪陪女朋友啊！算了算了等具体需求吧。”

So...经历了一番前期的脑部思维后，正式开始：

产品：我画完整点吧！这样能更清楚，同时也少背点锅；

设计：哈哈哈我还是做做动效吧，不然开发会气死；

前端：坐等后端写接口...；

后端：坐等服务器宕机...；

运维：？？？？？？

终于这个功能上线了：

产品：哎实在不是我想要的，算了先这样吧。

设计：卧槽开发哥哥你要按照我的效果来做啊！

前端：呵，后端偷懒，我也偷懒。

后端：呵，我这么写真是太厉害了。

运维：阿弥陀佛服务器别炸别炸。

甲方：呵，就简简单单的一个成就的界面，随便抄一下就好了，做这么久，一定是偷懒了。

一天后出现了BUG，用户一登录就获取成就，APP假死：

产品：我说的你们要做啊别偷懒啊！

设计：不关我的事，开发的问题。

前端：（看了看BUG用例）不关我的事，我只写界面。

后端：（看了看BUG用例）不关我的事，服务器的问题。

运维：（看了看BUG用例）不关我的事，谁叫推广部门一下子拉这么多用户没和我们说。

甲方气炸，开会，会议现场：

产品：？？？

设计：？？？

前端：？？？

后端：？？？

运维：？？？

最终，获得解决方案：

产品经理背锅，进行整体流程梳理，并落实功能；设计去做另外的项目；前后端确认没问题后去做另外的项目；运维对服务器做动态带宽，并且能保证每次做活动或长期运行的时候不宕机。

最后的最后，甲方若有所思，坐在座位上，看着APP“成就体系”这个页面，怎么也想不通，就一个页面，为什么能搞成这样？

（完）