一个小需求引发的撕逼记

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

sibiji

一、事件经过

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

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

  1. 业务<–>业务
  2. 产品<–>产品
  3. 研发<–>研发

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

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

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

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

二、事件后果

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

三、原因分析

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

四、反思与改进

产品定位始终要明确

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

沟通沟通沟通

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

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

就这样!

 

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

您的赞赏,是对我创作的最大鼓励。

评论( 1

登录后参与评论
  1. 一个产品定位和产品迭代模式都没搞清楚, 如何进行可持续性发展。。。走一步算一步,迟早留下烂摊子。

    回复
加载中