一个小需求引发的撕逼记

　　一、事件经过
　　目前在公司接手一个账户中心的产品，产品形式是预装到手机里的客户端，类似于小米的“我的小米”，此产品收集终端用户最基础的信息，为后续开展业务统计、对外合作等提供数据依据。
　　公司是上市公司，部门庞大，合作方也是大上市公司，双方勾搭对接的环节是这样的
　　业务业务
　　产品产品
　　研发研发
　　中间流程环节太多，每次邮件大票人马，最后干脆让研发直接对接。我方业务及领导对对方基本上是有求必应，发展至最后，到了对方业务人员直接让我方研发改代码的程度。
　　哥接手后，某日对方业务部门要求我方客户端直接给他们服务器传参数，我拒绝了，理由如下：
　　流程居然是：我方客户端海外AWS服务器服务系统A（上海）服务系统B（深圳）合作方客户端
　　客户端是直接面向用户的，修改要重新发版引导用户升级，这对用户是极大的干扰，且升级覆盖率也不高；
　　业务逻辑尽可能放服务端实现，客户端负责业务展示应尽量简单以适应业务变化；
　　就不要扔到客户端来做，要解耦，况且还是跟外部合作方的系统耦合，简直没有天理！
　　作为一只有原则的汪，底限是要坚持的，业务逻辑是会变更的，一旦开了口子，往后就是无尽的深渊，哥有理有节，不干！您请找我方业务转接到服务端去以为事情就此结束，接着了解到业务部门推不动中间环节的两个服务端部门，然后呢，层层邮件升级给各种叫大领导的生物，在一封转到我这只有一句“请客户端产品xxx务必尽力支持！”的回复后，哥的原则就像多年前坚守的节操一样，瞬间碎了真实憋屈这通常就是大公司里撕逼的常见方式，苦笑。
　　二、事件后果
　　业务部门抱怨产品部，就一个小需求都做不好；
　　研发同事极度苦闷，需求一时一个变，毫无规划，今天改了明天又反复；
　　产品狗也郁闷，被业务和研发两头夹着，里外不是人；
　　合作方也有抱怨，贵方效率这么挫，还要不要玩耍了？
　　三、原因分析
　　系统支撑缺乏规划，前期系统设计可扩展性差，导致各个子系统分散各地；
　　历史债，公司大了，部门割裂严重各自都是屁股决定脑袋，各种交接留下的烂摊子；
　　沟通问题，业务部门做事方式实在太粗糙粗暴，只管拉上级施压而不考虑为何实现困难，鸭梨下来产品研发也只能头痛医头脚痛医脚；
　　产品缺少定位无规划，一个需求是否要加上，什么时候加上，以怎样的形式加上，都需要用产品定位来衡量决定。定位混乱各部门就都想来插一脚加几个需求，于是乎系统最后臃肿不堪，七零八落再做减法就难了；
　　四、反思与改进
　　产品定位始终要明确
　　产品必须有一个明确的定位，不忘初心，也就是开发这产品时的需求出发点必须坚持。如果需求点已变，也要清楚变成了什么，然后才能围绕这一定位来构造产品。对于产品需求来说，定位不清，何以加为？产品定位，是衡量新需求的标尺。账户中心的产品定位应该是：账户中心一个用户信息平台，汇集用户各类信息为画像及数据挖掘服务，同时也是各项业务的入口。但也只是入口，不应跟具体业务耦合太高，更不应该直接参与具体业务实现。
　　沟通沟通沟通
　　如果有机会再处理一遍这次事件，我觉得步骤应该是这样的：
　　充分了解现状及问题所在，了解各方关注点；
　　确定方案，本次按应急处理，召集各相关人员包括施压的大领导们申明利害，后续把梳理产品流程，拉回到正常轨道来。
　　就这样！