那些年,产品遇到的猪队友

96
作者 詹仕波
2016.12.03 00:50* 字数 2621

不怕神一样的对手,就怕猪一样的队友。前几天写过一篇《那些年,产品遇到的开发神队友 》,里面通过3个案例阐述了神队友对于产品设计来说是多么赏心悦目的一件事。本文我将会结合我经历和听闻的事情,说说那些年,我们遇到的猪队友。

案例1:订单号引发的血案

朋友C君和其它几位程序猿一起开发完成了某个游戏平台的在线支付系统,订单号规则和长度由于时间久远记不太清了,但给我留下深刻印象的是:他做的订单列表没有显示订单时间,数据库里面也没有记录该字段,无奈之下只能去数据库查时间戳,然后根据时间戳反查出来订单时间。(这个例子我在《订单号怎样生成才能好用又好看,难倒了20多位产品经理》里面说过)

再说下另外一个游戏公司发生的真实事件。程序猿D君是位3年+经验的PHP攻城狮,在做在线支付系统的时候通过“时间+4位流水号+2位随机数”的方式来生成订单号,但不知道出于什么原因,他在时间格式里面每隔几位会插入一位大写字母,例如2016年12月2日12时34分提交的订单,他会这样来标记2016N1202U1234Y,加上流水号和随机数后的订单号大致就是2016N1202U1234Y876512这样的。当我知道后,下巴差点没掉下来。

事后我详细打听并了解了C君和D君做订单支付时候的情况,结果是没有任何产品和运营或者其他同事给他们提过任何要求(需求),他们完全是按照自己的想法或者经验来这样设计的。

订单号怎样生成才能好用又好看,难倒了20多位产品经理》这篇文章的评论以及对应知乎网的评论 中,有读者不赞同给订单号赋予太多太复杂的业务意义,其实我的观点里面也很明确的说过:结合实际的业务情况加一些标记。但订单号的基本原则“唯一、纯数字、尽可能短”这3条我觉得还是有必要遵循的。

据我了解的情况,这2家公司当时以及可预见的1年内日平均订单量不会超过一千笔,完全没有必要搞那么长的订单号。至于C君为什么没有订单时间,据他本人说是为了系统安全,但我至今还是不明白订单时间跟安全性有多少关联。

案例2:产品开发运营和设计都不背的锅

早些年做网页游戏时的一个案例。大家都知道网页游戏是直接通过游戏官网的特定按钮进入游戏的(如下图所示的“开始游戏”),但如果这个页面加载很慢呢?是不是会增加玩家的等待时间,影响玩家的游戏体验,严重点的甚至会导致玩家放弃游戏?


360旗下网页游戏

当时我们通过监控平台某款刚上线刚开服的游戏,各项指标都很差,最后各种排除原因,结果却让人啼笑皆非:游戏官网酷炫的大背景图+轮播广告+Banner整个加起来有将近20余兆,再加上各种页面JS、获取服务器列表、获取排行榜列表等等,整个页面加载完成需要30秒到1分钟的样子,而网页游戏本来就是“快餐消费”,玩家哪有那么大的耐心等你加载完?

这种情况直接影响到了转化率相关指标和游戏的收入,基本上可以确定为“事故”无疑,即然是事故势必就要追究责任,但追究责任的时候陷入了困境,这个责任究竟是谁造成的?是制作这些广告的设计么?是图片未经压缩处理、未经检查便上传这些图片的运营么?是开发CMS后台没有做图片大小限制、没有给图片上CDN加速、做前端页面时只顾特效不顾性能,狂堆JS的程序么?亦或者是我这个事先毫不知情无辜的平台产品经理么?

最后仔细分析了下,除了网页设计师之外视乎大家都有责任:设计在完成广告制作后连PSD一起发给了运营,但广告图片有文字需要修改,运营人员便直接在PSD上进行了修改,遗憾的是输出JPG图片的时候忘了控制大小,导致单张图片有将近两三兆的样子。当然,开发人员在CMS上没有做图片大小的限定,没有给图片及大文件上CDN,产品人员也有责任,没有制定网站的性能标准。

经此一役,我们便制定了严格的网站性能标准:单张图片大小不能超过50K,所有图片全部上CDN,整个首页加载内容不超过5M,加载平均时间不超过5秒。同时也让我长了记性:之后写产品需求文档的时候,只要涉及到图片的地方都会设定大小和尺寸。

案例3:外包项目遇上不靠谱程序猿

去年我帮朋友完成了一款O2O产品的APP用户端、APP商家端和WEB管理后台高保真原型图(商家版和官方版2个版本,商家版只录入和查看商品/服务信息,官方版具备所有功能),然后朋友将项目外包给了一位具有十余年开发经验的程序猿,后期我因为更新我的新书《在线教育这三年 》就没有太过关注这件事情,直到2个月后我朋友跟我吐槽,我才意识到:原来10余年开发经验的程序猿也不见得靠谱。

当时朋友把APP的安装包拿给我安装,我简单的体验了之后便发现了几个重大的问题:UI巨丑无比,没有丁点的美感可言;交互方面安卓版和iOS完全一致,有很多完全违背了UI设计规范和操作惯例;功能方面基本上没办法走完正常的流程,异常情况就更不必说。后来无意间我又发现,这个APP完全就是用他们之前开发的另外一款B2C电商APP改过来的,怪不得看上去用起来都那么别扭。

这还不是最严重的,最严重的是:开发自作主张地将商家端和用户端合二为一了,前端登陆时通过账号来辨别是商家还是用户。如果是二合一也还罢了,关键是他把WEB管理后台商家版也做到了APP里面,这样商家没办法通过WEB端发布并管理商品(试想下淘宝卖家通过APP来新增和编辑商品是怎样的一种体验,好有画面感),WEB管理后台则压根没有,开发美其名曰:官方也可以视为一个商家,只不过权限比较大,可以看到所有的用户、商家、商品/服务以及订单数据等等。

最后经过朋友与外包开发人员多次沟通协商,开发终于把WEB管理后台官方版的给加上了。没错,你可能猜对了,这个后台也是拿其它后台改的。但与此同时又爆发了几个新的问题:商家的地址信息通过WEB管理后台录入后,在APP上通过地理位置定位后进行查找筛选时显示的商家距离基本都超过500KM,要解决这个问题的方法很奇葩:通过在线地图经纬度查询 查出地址的经度和纬度(见下图),然后填在后台两个不知所谓的参数项里面即可。

如果只是这一个问题也还罢了,关键WEB管理后台官方版只能修改商家商品/服务的部分信息,价格和部分敏感信息只能登陆APP商家端修改,而产品运营早期商家的数据基本都是官方帮忙录入填写的,然后问题就来了:WEB管理后台只能查到商家的登陆用户名,不知道密码,这个时候,肿么办?

只要思想不滑坡,方法总比困难多。开发总能想到解决方案,于是超级万能密码诞生了,这个超级万能密码友相当于一把万能钥匙,所有商家的登陆用户名+这个密码都能登陆。听到这,我已经吐了一口老血。

说好的就差一个程序员呢?说好的10年+开发经验呢?不知道这样的外包,怎样的产品经理才能驾驭的了?

经纬度查询

开发神队友,可遇不可求;开发猪队友,我就呵呵了。不过话说回来,遇到猪队友虽然闹心,虽然可能会背锅,但同时也能让我们涨经验值,避免踩坑。

换句话说:遇到猪队友并不完全是坏事。

产品设计