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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

产品:我画完整点吧!这样能更清楚,同时也少背点锅;

设计:哈哈哈我还是做做动效吧,不然开发会气死;

前端:坐等后端写接口...;

后端:坐等服务器宕机...;

运维:??????

终于这个功能上线了:

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

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

前端:呵,后端偷懒,我也偷懒。

后端:呵,我这么写真是太厉害了。

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

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

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

产品:我说的你们要做啊别偷懒啊!

设计:不关我的事,开发的问题。

前端:(看了看BUG用例)不关我的事,我只写界面。

后端:(看了看BUG用例)不关我的事,服务器的问题。

运维:(看了看BUG用例)不关我的事,谁叫推广部门一下子拉这么多用户没和我们说。

甲方气炸,开会,会议现场:

产品:???

设计:???

前端:???

后端:???

运维:???

最终,获得解决方案:

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

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

(完)

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181213G1IGNX00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码关注腾讯云开发者

领取腾讯云代金券