一个小需求引发的撕逼记

一、事件经过

目前在公司接手一个账户中心的产品，产品形式是预装到手机里的客户端，类似于小米的“我的小米”，此产品收集终端用户最基础的信息，为后续开展业务统计、对外合作等提供数据依据。

公司是上市公司，部门庞大，合作方也是大上市公司，双方勾搭对接的环节是这样的

业务<-->业务产品<-->产品研发<-->研发

中间流程环节太多，每次邮件大票人马，干脆让研发直接对接。我方业务及领导对对方基本上是有求必应，发展至，到了对方业务人员直接让我方研发改代码的程度。

哥接手后，某日对方业务部门要求我方客户端直接给他们服务器传参数，我拒绝了，理由如下

流程居然是我方客户端-->海外AWS服务器-->服务系统A（上海）-->服务系统B（深圳）-->合作方客户端客户端是直接面向用户的，修改要重新发版引导用户升级，这对用户是极大的干扰，且升级覆盖率也不高；业务逻辑尽可能放服务端实现，客户端负责业务展示应尽量简单以适应业务变化；就不要扔到客户端来做，要解耦，况且还是跟外部合作方的系统耦合，简直没有天理！

作为一只有原则的汪，底限是要坚持的，业务逻辑是会变更的，一旦开了口子，往后就是无尽的深渊，哥有理有节，不干！您请找我方业务转接到服务端去~ 以为事情就此结束，接着了解到业务部门推不动中间环节的两个服务端部门，然后呢，层层邮件升级给各种叫大领导的生物，在一封转到我这只有一句“请客户端产品xxx务必尽力支持！”的回复后，哥的原则就像多年前坚守的节操一样，瞬间碎了……真实憋屈……这通常就是大公司里撕逼的常见方式，苦笑。

二、事件后果

业务部门抱怨产品部，就一个小需求都做不好；研发同事极度苦闷，需求一时一个变，毫无规划，今天改了明天又反复；产品狗也郁闷，被业务和研发两头夹着，里外不是人；合作方也有抱怨，贵方效率这么挫，还要不要玩耍了？

三、原因分析

系统支撑缺乏规划，前期系统设计可扩展性差，导致各个子系统分散各地；历史债，公司大了，部门割裂严重各自都是屁股决定脑袋，各种交接留下的烂摊子；沟通问题，业务部门做事方式实在太粗糙粗暴，只管拉上级施压而不考虑为何实现困难，鸭梨下来产品研发也只能头痛医头脚痛医脚；产品缺少定位无规划，一个需求是否要加上，什么时候加上，以怎样的形式加上，都需要用产品定位来衡量决定。定位混乱各部门就都想来插一脚加几个需求，于是乎系统臃肿不堪，七零八落再做减法就难了；

四、反思与改进

产品定位始终要明确

产品必须有一个明确的定位，不忘初心，也就是开发这产品时的需求出发点必须坚持。如果需求点已变，也要清楚变成了什么，然后才能围绕这一定位来构造产品。对于产品需求来说，定位不清，何以加为？产品定位，是衡量新需求的标尺。账户中心的产品定位应该是账户中心一个用户信息平台，汇集用户各类信息为画像及数据挖掘服务，也是各项业务的入口。但也只是入口，不应跟具体业务耦合太高，更不应该直接参与具体业务实现。

沟通沟通沟通

如果有机会再处理一遍这次事件，我觉得步骤应该是这样的

充分了解现状及问题所在，了解各方关注点；确定方案，本次按应急处理，召集各相关人员包括施压的大领导们申明利害，后续把梳理产品流程，拉回到正常轨道来。

就这样！

本文由 @浅沙 原创投稿，并经人人都是产品经理编辑。未经许可，禁止网络推广网站推广转载。