大厂也Bug,产品经理这么干,漂亮!

1 评论 3064 浏览 15 收藏 18 分钟

对程序员来说,最怕的就是出现bug,这也是产品经理和程序员争吵的最大原因。但很多程序员不愿意调整或者改变,这种情况下,产品经理怎么做?这篇文章,作者给出了范本。

01 bug的产生

99.99%做开发的都会被问到或者被吐槽到:“你的程序怎么又出bug了!”

而此时只有开发自己明白:“老子犯的是高级错误”。

但他又会觉得不好意思理直气壮说出来。

最后只能在心中回荡着海子的诗句:“你们一再嘲笑,须知,他跌倒在高于你们的上方。”

这种心理是有道理的。因为代码的复杂度和产生bug的概率是成正比的,并且具有「边际效用递减」的效果。

这就意味着,做更多的验证带来的收益会越来越小。

所以测试的责任重大。

我带团队时候对测试说:你们要有底气,你们就是正义女神:一手天平,一手执剑,蒙着眼睛保持内心的公正。

那么怎么从根源降低bug?

表面看,bug出自程序员之手。但是这件事完整的步骤分为3步,就像盖房子一样,你一看就看出猫腻:

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

我们再来仔细看看这三步:第一步,“与产品经理讨论并确定功能”主要是沟通,靠“看”和“理解”。沟通是相互的,这锅只让程序员背的话的确太委屈了点。

除非你说产品经理的PRD毫无破绽。

接下来更具体点,来看一个小小例子:

PRD中我们说update,但是实际上开发是采用的删除后insert。这时候,产品经理会发现这条数据看起来是更新了,但是“创建时间”也变了。所以要防范,你起码需要约定一下“更新时间”和“创建时间”的,避免开发的实现手法跑偏。

第二步,开发看prd,背后思考的是“将每个单独的元件抽象出来”,这主要是一个人抽象能力的体现。

抽象是“透过现象看到本质”的能力。随着你对相关信息的掌握越多,这个能力会越强,但永远不会真正达到100%。

所以,当开发具备的信息没那么多的时候,是不是就抽象的不是那么合理?

不合理虽然不会直接产生bug,但是会更容易产生bug。

——这就是为什么需求背景、场景穷举那么重要。因为“背景”意味着“扩展和兼容”,穷举以为这“逻辑和判断”。

精通一项能力的背后都是踩着无数的bug过来的。要么在来这个公司之前已经踩过了,要么在这个公司里踩。因此,有经验的薪资也比后者高。学费教的不一样。

在这个层面上,产品和开发是需要共同成长的。途径就是复盘,每一次事故,都要做到“四不放过”,其中一条就是干系人得到成长。

期待不要掉进同一个坑里两次。

换一角度,如果过分苛求没有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

曾经有开发调侃说:不能把代码写太完美,不然没事做的时候就被开除了。

然而多虑了。从经验来看,中后台产品的需求是层出不穷的。

一个后端系统使用一年之后,需求就像河水,冲刷着产品经理不得不做调整。

在产品的生命周期中,只要业务还在,减本增效的需求就在。系统就不会走到淘汰地步,只能是升级。

每当我们通过抽象用户故事、找出角色、事件,输出用例图、状态机的时候,新的业务也在同步滋生。

况且一个功能本身,往往只是形成了业务的小场景的闭环,是需求持续迭代。

持续迭代的具体原因举例:

  • 不确定性:需要继续观察积累用户偏好。缺少用户行为数据的支撑依据,
  • 分步完成:工期较长,以增量方式迭代;
  • 方案没想好:没设计出来。
  • 过度状态:用户业务方式或场景不成熟
  • 思路局限:没考虑到。
  • 集需求:集中起来一起搞个大动作。
  • 资源局限性:人员或硬件资源局限。
  • 其他:略。

于是纵向、横向都要继续。“随波逐流”亦或是“推波助澜”,大量的需求源源不断。

而产品经理想要独立自主地优化架构、统一功能等,在时间和资源都被挤占变少。

曾经有公司的解决办法,是加强需求的过来口径。大致做法是:

  • 凡是没有收益的需求,一律不做,除非技术总监拍板的(甩锅);
  • 有收益的需求,按收益大小排序,每周只做前5个。
  • 成立项目组,进行收益较大的需求的抽离和独立完成。

其实本质上就是抽出一部分资源,进行自主优化,统筹规划和重构。

重构的好处是利在千秋,但是重构的压力来自琐碎需求的羁绊。

当资源、时间、质量三者汇聚的时候,想办法为高性价比项目争取资源,决策就显得尤其要紧。

为此,可将需求分为五类,分别对应不同的决策态度。

04 铁打的需求,流水的策略

这五类需求,是笔者对B端或泛后台产品需求的一个定性划分:浅薄需求、噱头需求、踢球需求、过剩需求、建设性需求。

1. 用户的浅薄需求

这类需求,不经大脑,不考虑系统的兼容性和业务兼容性的。

比如:电商场景中,要求:若价格为0,则果断给予下架;价格变为非0,果断自动上架。

这种强制是存在风向的,并且库存为0也有曝光对需求场景;非零也有下架的场景。二者不等同。

这种情况下实际是“概念偷换”的错谬,无库存=下架。

对这类需求,产品可以持保留态度,持续观望,收集更多用户的深层次数据反馈。但不能轻举妄动。

2. 老板的噱头需求

这种很好理解,很多公司其实都是这么玩没的。

比如:看到友商(竞争对手)有的功能,我们要有;友商无的,我们也要有。这样可以吹。

或者是强行“组合创新”:一个做医药电商的,你让他做直播带货,且不说是否合规,你能想象药师在店里当着店长的面做网红吗?

这种情况下实际是“感觉谬误”。理论上,产品经理需要拿数据,试图说服上级,但是实际操作可能有局限性。

所以产品经理能做的就是慢点做,保留资源。找机会慢慢把意见渗透到高层。试图止损。

3. 隔壁的踢球需求

在多组织的团队中,这种踢来踢去丢需求的情况相当普遍。

比如,对医药商品,配置一段免责声明,展示在商城。

那么让商品后台在商品维度加字段并传给前端,看似从后端到前端,且商品维度的,似乎没错。但是没必要的。

因为,这是共性字段,商品维度几乎不需要维护,也没有操作差异性。

这类需求,产品经理需要从分工、系统职能、收益考虑,将事情客观表述出来,完成博弈。

4. 客服的过剩需求

这类需求,往往是客服传达来自用户的需求。通常目的很明确,但是对功能设计进行了干涉,可能影响产品的分析。

比如,客服传达某O2O用户的需求:要在商品的实际销售价旁边,展示线下零售价格。

产品:然后呢?

客服:对比到差异,则修改线上价?

产品:怎么修改?

客服:在线下零售价的基础上按公式计算,比如上涨1%,得出线上零售价,然后逐个编辑。

产品:是否可以理解为,目的是让线上价格,按自己期望的卖,不取线下零售价?

客服:

产品:那么为什么不在根源处理呢:创建一组用于线上销售的价格,直接引用不就可以了吗?

这类问题,一定是要挖掘到用户的场景的,从用户的场景下寻求同理心,不受制于现有功能的设定。

只有这样才能不受局限,找到用户的初心。以解决问题为标准。

5. 产品的建设需求

所谓建设性需求,可能是每个产品经理心中都有的夙愿。前提是,产品经理的脑子是正常的。

比如:自主优化产品模型,拆分微服务,界面统一等,统筹规划和重构的类的内容。

若前四类需求过多,将会挤压产品的建设性需求。

产品经理能够腾出手来做一些真正正确的事情,往往能对全局带来增益。

05 小结

面对开发的困境、代码的劣质、用户的迷雾、资源的协搭等,都需要产品经理统筹策略,指路明灯。

多走一步,把渗透的交界处,融合到PRD中!

需要了解开发的动向、意见,代码的质量漏洞、需求的来源、价值,紧迫性,老板的意图,市场的玩法等等,都装进产品经理的思维生态中

恰如产品有体系,产业有生态,产品经理的世界,也是全生态化的。而不是点对点的甩手角色。

就像苏杰说的,产品经理要像“芸香科”水果一样,PRD也要支持多重兼容和任意杂交。

专栏作家

产品参赵,公众号:产品参赵,人人都是产品经理专栏作家,2019年年度作者。《后端产品经理宝典》作者,药学硕士转行互联网产品多年;熟悉跨境电商业务,医药领域;擅长大型后台体系,社交APP。

本文原创发布于人人都是产品经理,未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 写的太好了,非常贴近我的工作哈哈哈

    来自台湾 回复