大厂也Bug,产品经理这么干漂亮!(附资料)-技术圈

第 216 篇原创
公众号发送 1 ，抽50本电子书

在我所有的程序错误中，80%是语法错误，剩下20%里，80%是简单的逻辑错误，在剩下4%里，80%是指针错误，只有余下的0.8%才是困难的问题。

—— Marc Donner

本文4.6千字原创，文末附资料

目录如下：

01 bug的产生 02 开发：你去看，知名大厂的代码也烂 03 别把我的需求搞出bug 04 铁打的需求，流水的策略

bug的产生

99.99%做开发的都会被问到或者被吐槽到：“你的程序怎么又出bug了！” 而此时只有开发自己明白：“ 老子犯的是高级错误 ”。但他又会觉得不好意思理直气壮说出来。最后只能在心中回荡着海子的诗句：“ 你们一再嘲笑，须知，他跌倒在高于你们的上方。” 这种心理是有道理的。因为代码的复杂度和产生bug的概率是成正比的，并且具有「 边际效用递减 」的效果。

这就意味着，做更多的验证带来的收益会越来越小。所以测试的责任重大。我带团队时候对测试说:你们要有底气，你们就是正义女神：一手天平，一手执剑，蒙着眼睛保持内心的公正。

那么怎么从根源降低bug？ 表面看，bug出自程序员之手。但是这件事完整的步骤分为3步，就像盖房子一样，你一看就看出猫腻:

与产品经理讨论并确定功能（确定一个房子可以实现的设计图纸）
将每个单独的元件抽象出来（确定施工方案）
将相关的元件实现并进行组合，完成建设（带上材料开始施工）

我们再来仔细看看这三步：

第一步，“与产品经理讨论并确定功能”主要是沟通，靠“看”和“理解”。

沟通是相互的，这锅只让程序员背的话的确太委屈了点。除非你说产品经理的PRD毫无破绽。接下来更具体点，来看一个小小例子：

PRD中我们说update，但是实际上开发是采用的删除后insert。这时候，产品经理会发现这条数据看起来是更新了，但是“创建时间”也变了。

所以要防范，你起码需要约定一下“更新时间”和“创建时间”的，避免开发的实现手法跑偏。

第二步，开发看prd，背后思考的是“将每个单独的元件抽象出来”，这主要是一个人抽象能力的体现。抽象是“ 透过现象看到本质 ”的能力。随着你对相关信息的掌握越多，这个能力会越强，但永远不会真正达到100%。所以，当开发具备的信息没那么多的时候，是不是就抽象的不是那么合理？不合理虽然不会直接产生bug，但是会更容易产生bug。 —— 这就是为什么需求背景、场景穷举那么重要。因为“背景”意味着“扩展和兼容”，穷举以为这“逻辑和判断”。 精通一项能力的背后都是踩着无数的bug过来的。要么在来这个公司之前已经踩过了，要么在这个公司里踩 。

因此，有经验的薪资也比后者高。学费教的不一样。在这个层面上，产品和开发是需要共同成长的。途径就是复盘，每一次事故，都要做到“ 四不放过 ”，其中一条就是干系人得到成长。（参考历史文章： 10个跨界方法论：启发互联网项目（含案例）） 期待不要掉进同一个坑里两次。 换一角度，如果过分苛求没有bug，等于是在扼杀每个人成长的机会，并且在透支未来的可能性。人会变得非常保守、不敢尝试新事物。 第三步，“将相关的元件实现并进行组合，完成建设”

这就是实际的coding过程，而coding是一个主观的，完全由人主观掌控的事情。这就是为什么需要技术研讨，专家论证。

因为连杀猪有人都是从屁股先下刀子的，同样代码的实现手法，不同老师教出来不同语言，加上后期自身修为不同，也不见得都能找到最佳实践路径。

比如下面视频中的三类开发：

02 开发：你去看， 知名大厂的代码也烂
上月，公司招聘了两个P6的后端开发。这个级别在团队里相当“大熊猫”了。然而一周后，俩人相继离开：嫌原代码太乱。随后，一个去了阿里，一个去了腾讯。过一阵子再聊天，去腾讯的那个说： 腾讯的代码也没好到哪里 ，巴拉巴拉。虽然他这么说，但我们觉得那边的代码还是质量高些，就像国外的月亮。
✍
这个故事，抛开平台优劣之外，还显示一个常态： 铁打的代码，流水的开发，谁家的后厨都一样 。即使ORCAL这样的公司，也出现程序员吐槽：“ 我永远不会再为 Oracle 工作了！ ”

一位昵称“oraguy”的程序员对Oracle数据库代码的吐槽。大意是：
Oracle 数据库12.2版有近 2500 万行C代码。无法在不破坏成千上万个现有测试的情况下更改单行代码。
好几代程序员在有限的期限内编写了这些代码，其中充斥着大量的垃圾代码。非常复杂的逻辑、内存管理、上下文切换等，这些都用数千个flag连接起来。整个代码充斥着神秘的宏命令，甚至可能需要一两天才能真正理解某个宏命令的作用。
有时你需要理顺20个不同flag的值和效果来预测代码在不同情况下的行为方式，有时多达数百个flag！
这个产品仍然存活仍然可用的唯一原因是数百万次的测试！

结尾是：开发一个小功能需要6个月到1年的时间（如果是添加一种新的身份验证模式，比如支持 AD 身份验证，可能需要2年）。

后端开发内心的共识是：和一坨翔代码共处的要领就是 “千万别深挖” 。说不定把哪里挖塌了把你埋了。扔一坨代码到翔山上，达到自己目的，能跑就行了。后面的开发都是在上面修修补补，最终就导致整体代码惨不忍睹。纵向，一个公司如此，横向，其他公司也相似。走进一个后端代码森林，就开启一场惊悚的适应之旅。曾有开发如是说：

1、入职3个月内，喷，这么大的系统，上亿pv的系统居然这么做的，这么做的，我提出那么做，那么做，你们都不鸟我，推翻我，哎你们都是傻逼。
2、入职半年，咦，好像他们说的有道理啊，如果按我那么做，就会出现那些问题，那些问题。。。
3、入职一年，哦，只能这么做，这么做，你一个新来的，知道个屁啊，还那么做那么做。
4、入职两年，噢，这么做，这么做有好处，有坏处，可以在此基础上那么做那么做。

存在都是有道理的，所以要懂得后端开发的深沉，不是装出来的！
✍

后端开发的这种深沉的内核，配以抽烟或嚼槟榔的外延，同时也会影响着产品经理。当小鲜肉产品经理还在炫耀酷炫交互、辩论用户体验、说道人性灵感的时候，后端产品经理在思考的是：兼容、业务、逻辑、架构、性能…… 罗振宇说的：“少废话，只要一个界面和全世界交流，没有机会解释”。说的完全正确，但是往往是就不适合后端产品的生态。默默的，后端产品经理和技术走的较近，心灵互动的频调也较协调。双方一起发现漏洞，规避风险，这份默契油然而生。产品经理对代码不能左右。为了团队不掉坑里、少做返工，避免整个产品或者团队翻船，就只能在需求的来源上做改善。

03 别把我的需求搞出bug
曾经有开发调侃说：不能把代码写太完美，不然没事做的时候就被开除了。然而多虑了。从经验来看，中后台产品的需求是层出不穷的。一个后端系统使用一年之后，需求就像河水，冲刷着产品经理不得不做调整。在产品的生命周期中，只要业务还在，减本增效的需求就在。系统就不会走到淘汰地步，只能是升级。

每当我们通过抽象用户故事、找出角色、事件，输出用例图、状态机的时候，新的业务也在同步滋生。况且一个功能本身，往往只是形成了业务的小场景的闭环，是需求持续迭代。持续迭代的具体原因举例：（1）不确定性：需要继续观察积累用户偏好。缺少用户行为数据的支撑依据，（2）分步完成：工期较长，以增量方式迭代；（3）方案没想好：没设计出来。（4）过度状态：用户业务方式或场景不成熟（5）思路局限：没考虑到。（6）集需求：集中起来一起搞个大动作。（7）资源局限性：人员或硬件资源局限。（8）其他：略。于是纵向、横向都要继续。“随波逐流”亦或是“推波助澜”，大量的需求源源不断。 ✍
而产品经理想要独立自主地优化架构、统一功能等，在时间和资源都被挤占变少。曾经有公司的解决办法，是加强需求的过来口径。大致做法是：（1）凡是没有收益的需求，一律不做，除非技术总监拍板的（甩锅）；（2）有收益的需求，按收益大小排序，每周只做前5个。（3）成立项目组，进行收益较大的需求的抽离和独立完成。其实本质上就是抽出一部分资源，进行自主优化，统筹规划和重构。重构的好处是利在千秋，但是重构的压力来自琐碎需求的羁绊。当资源、时间、质量三者汇聚的时候，想办法为高性价比项目争取资源，决策就显得尤其要紧。为此，可将需求分为五类，分别对应不同的决策态度。

04 铁打的需求，流水的策略
这五类需求，是笔者对B端或泛后台产品需求的一个定性划分：浅薄需求、噱头需求、踢球需求、过剩需求、建设性需求。 ▐ 1、用户的浅薄需求 这类需求，不经大脑，不考虑系统的兼容性和业务兼容性的。比如：电商场景中，要求：若价格为0，则果断给予下架；价格变为非0，果断自动上架。这种强制是存在风向的，并且库存为0也有曝光对需求场景；非零也有下架的场景。二者不等同。这种情况下实际是“概念偷换”的错谬，无库存=下架。对这类需求，产品可以持保留态度，持续观望，收集更多用户的深层次数据反馈。但不能轻举妄动。
▐ 2、老板的噱头需求 这种很好理解，很多公司其实都是这么玩没的。比如：看到友商（竞争对手）有的功能，我们要有；友商无的，我们也要有。这样可以吹。或者是强行“组合创新”：一个做医药电商的，你让他做直播带货，且不说是否合规，你能想象药师在店里当着店长的面做网红吗？这种情况下实际是“感觉谬误”。理论上，产品经理需要拿数据，试图说服上级，但是实际操作可能有局限性。所以产品经理能做的就是慢点做，保留资源。找机会慢慢把意见渗透到高层。试图止损。
▐ 3、隔壁的踢球需求 在多组织的团队中，这种踢来踢去丢需求的情况相当普遍。比如，对医药商品，配置一段免责声明，展示在商城。那么让商品后台在商品维度加字段并传给前端，看似从后端到前端，且商品维度的，似乎没错。但是没必要的。因为，这是共性字段，商品维度几乎不需要维护，也没有操作差异性。这类需求，产品经理需要从分工、系统职能、收益考虑，将事情客观表述出来，完成博弈。
▐ 4、客服的过剩需求 这类需求，往往是客服传达来自用户的需求。通常目的很明确，但是对功能设计进行了干涉，可能影响产品的分析。比如，客服传达某O2O用户的需求：要在商品的实际销售价旁边，展示线下零售价格。

产品： 然后呢？ 客服： 对比到差异，则修改线上价？ 产品： 怎么修改？ 客服： 在线下零售价的基础上按公式计算，比如上涨1%，得出线上零售价，然后逐个编辑。 产品： 是否可以理解为，目的是让线上价格，按自己期望的卖，不取线下零售价？ 客服： 是 产品： 那么为什么不在根源处理呢：创建一组用于线上销售的价格，直接引用不就可以了吗？

这类问题，一定是要挖掘到用户的场景的，从用户的场景下寻求同理心，不受制于现有功能的设定。只有这样才能不受局限，找到用户的初心。以解决问题为标准。
▐ 5、产品的建设需求 所谓建设性需求，可能是每个产品经理心中都有的夙愿。前提是，产品经理的脑子是正常的。比如：自主优化产品模型，拆分微服务，界面统一等，统筹规划和重构的类的内容。若前四类需求过多，将会挤压产品的建设性需求。产品经理能够腾出手来做一些真正正确的事情，往往能对全局带来增益。

05 小结
面对开发的困境、代码的劣质、用户的迷雾、资源的协搭等，都需要产品经理统筹策略，指路明灯。多走一步，把渗透的交界处，融合到PRD中！需要了解开发的动向、意见，代码的质量漏洞、需求的来源、价值，紧迫性，老板的意图，市场的玩法等等，都装进产品经理的思维生态中。恰如产品有体系，产业有生态，产品经理的世界，也是全生态化的。而不是点对点的甩手角色。就像苏杰说的，产品经理要像“芸香科”水果一样，PRD也要支持多重兼容和任意杂交。

END