产品汪18：产品经理遇到的那些坑

不怕神一样的对手，就怕猪一样的队友。前几天写过一篇《那些年，产品遇到的开发神队友》，里面通过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年+开发经验呢？不知道这样的外包，怎样的产品经理才能驾驭的了？

经纬度查询

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

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

本文章收录于我的电子书 从零开始做产品：产品汪https://download.csdn.net/download/m1928/89094023