其实做产品的，每月也总会有那么几天：有一根弦总是紧绷着的，那就是版本发布，贴个图让大家感受下。
版本发布的那一天，互联网人的朋友圈纷纷变成了：烧香拜佛，转发锦鲤求好运。为什么，怕出问题！需求太复杂、判断状态太多、系统耦合太严重，不到真正的生产环境验证，不能完全放心。
产品出问题，真的是太常见了！
不断要处理客户投诉：为什么订单取消了我的优惠券不能用？还触不及防地收到老板群里发出的挑战：怎么这个产品不能买了？
案例不胜枚举，产品经理每天处理各种问题把自己搞得焦头烂额、精疲力尽。紧接着，马上又要准备新的需求评审了，草草几笔，匆忙评审，被开发各种挑战。长此以往，恶性循环。
产品为啥总是容易出问题？到底有没有好的解决办法？答案是肯定的。今天，笔者来分享下，最近的思考。
01
你需要一张产品设计红灯地图
交通规则中，看到红灯，我们应该停下来，否则容易发生交通事故。在产品设计流程里，同样适用。一个产品/功能从0到1，是一个标准化的旅程，需求调研、需求撰写、需求开发等等，如下图。红灯地图，它是一一匹配的，它能告诉我们的是：这个路口下，会有什么红灯是千万不能闯的，否则会出问题的。
如图所示，每个节点下，都会有很多红灯。我们要做的就是不断丰富我们的红灯地图，确保每一个关键节点都能高效稳健。
02
如果产品设计没有红绿灯，那世界将混乱不堪
任何事物的诞生，并非凭空想象的，都会经历一个演变过程的。我们先来看看交通规则里的红绿灯。
19世纪中叶英国及其他欧洲发达国家，马车的使用已经是非常普及了。但因为没有很好的交通指挥工具，道路非常容易堵塞，而且交通事故频频发生。英国铁路信号工程师J.P.Knight从女性着装颜色区分：红（已婚）、绿（未婚）得到灵感，从而设计出红绿煤气灯罩。自此，交通拥堵和事故问题得到极大改善。
在产品设计的流水线中，产品经理设计的产品/功能非常之多，如果我们没有基本的红灯判断逻辑，那么会怎么样呢？
1、优惠券设计：没有考虑领取上限逻辑，被羊毛党连夜薅完，导致公司产生资金损失
2、账户功能迁移：没有把历史的数据回溯，用户查看到的资金数据不正确，导致公司品牌声誉受损
设计的时候，没发现红灯，产品上线之后，问题不断，只能不断打补丁，这是很多产品设计遇到的通病。
03
最需警惕的4大红灯
结合笔者过往的经验：根据出现频次的多少，排出产品设计最容易出问题的4大红灯：兼容性、逻辑漏洞、无埋点、砍需求，看到这4大红灯，可千万别闯。
兼容性
兼容性一般需要注意三种的类型：接口兼容、数据兼容、终端兼容。出现的场景一般是：新增功能或者代替旧系统。
1）接口兼容
一般情况是有依赖关系的接口，b接口依赖a接口，当a接口字段发生改动，就需要盘点下游的b1、b2、b3接口，会不会因为a接口的改动而受到影响，这种不仅是研发同学要特别注意，产品同学也有多加留意。
2）数据兼容
出现数据问题会两种场景：数据展示不出来、数据展示错误。其中背后的原因，可能有两种：
1是：数据库结构发生了变更，如：电商商品数据库中由spu变成sku，很多字段要新增；
2是：数据传输字段定义不一致，如要求传的是字符串，但是传过来的浮点数等。
3）终端兼容
一个页面，会放到App、小程序、H5，如果改动页面，需要兼容多个终端的情况。跳转有没有问题、页面有没有适配。
业务逻辑漏洞
跟钱打交道的产品，需要高度重视。如优惠券、抽奖、积分、抢兑、支付等等产品。需要充分考虑极限情况下的兜底逻辑。比如优惠券，对单人的发放限制、系统的发放限制、极限情况的熔断触发逻辑。
无埋点
页面没有埋点，这个虽不会影响客户，但很重要。当要分析页面漏斗情况、分析活动各渠道来源情况时，发现没有做数据埋点，这个场景出现时很容易被老板挑战。
砍需求
砍需求本身不是问题，会产生问题的是，需求被砍了之后，后续没有继续跟进优化，放一个半成品的功能在生产上，在这种情况下，当业务方理解和功能实现程度不一致的时候，就很容易出现生产问题。
04
建立个人的产品设计红灯地图
做产品的同学都知道，产品是需要不断迭代优化。其实对于产品经理也是一样，也是要通过一次次教训、踩坑，积累自己的经验和教训。基于此，红灯地图，就是产品经理成长最好的迭代手册。
我们不妨来试着列一下，从产品设计流程，拆解每一个关键节点，并深入归纳总结具体的红灯事项，示例如下：
红灯地图表，仅仅是展示一种思维和做事的方法，并不一定适合每一个人，需要产品经理自己结合具体的实战经验，去发现，去归纳，最后总结形成自己的工作指导手册。
以上就是本次要分享的内容，简单总结下：
本文的重点是：为避免产品少出现问题，我们需要在产品设计的过程中，培养红灯思维，找出各节点容易犯错的事项，填充到红灯地图表中，不断迭代，最终完成个人知识体系的建立。
送大家一句话：凡事预则立，不预则废。
好了，本周的分享到这里，如果你觉得有所收获，欢迎把文章分享给你的朋友。
Comments