生命不息,折腾不止!

Viva La Vida

[转]不懂产品的研发,不是好 CTO

from: https://mp.weixin.qq.com/s/HpVCTJAmt-TH9M8y8K75lw

什么是产品?

产品是指能够供给市场,被人们使用和消费,并能满足人们某种需求的任何东西,包括有形的物品、无形的服务、组织、观念或它们的组合。

比如,手机满足人们通讯需求,是有形的硬件产品;微信满足人们社交需求,是无形的软件产品;家政服务满足人们清洁需求,是无形的服务产品……

其实,简单来说,产品就是能满足人们某种需求的东西。

什么是好产品?

从以下三组图片中,选择你认为好的产品。

第一组,相信大家都会选择小米遥控器。因为相比传统的遥控器,小米遥控器设计简洁,按键功能一目了然,不用看说明书就知道如何使用。

第二组,每个人的选择都不一样。对于普通用户来说,美图秀秀是个好产品,好用、容易上手,而 PS 完全不知道从何下手。但对于专业设计师来说,美图秀秀就是个渣渣,根本满足不了工作需求。

第三组,大家可能没怎么接触过,通过这两款产品可以实时查询公交的位置,还有几分钟到达相应的站点。仅凭一个界面,有些人会觉得车来了是好产品,因为界面干净、整洁、交互也特别好,而上海公交查询体验特别差。但事实上,我把车来了这个 App 卸载了,却一直在使用上海公交查询,因为它提供的数据非常准确。对我来说,这两个产品都算不上是好产品。

所以,好的产品必须同时具有以下三点:

  • 有用
  • 能用
  • 好用

人人都是产品经理?伪命题!

每次看到这句话我就特别想翻白眼,甚至想学罗胖来一句,我呸!

这是大家眼中的产品经理:

你是想卖一辈子糖水,还是跟着我们改变世界

在每个产品经理内心深处都有一个改变世界的梦想。

在父母眼中,产品经理就是公司的核心,不可或缺。

在研发眼中,产品经理就是一个打杂小妹,随叫随到。

在设计眼中,产品经理就是山顶洞人,完全没有审美眼光。

逻辑不如研发,文案不如运营,审美不如设计,视野不如老板。

为什么需要产品经理?

存在即是合理。

老板表示需要一个背锅的:遇到不好用的 App,大家第一反应都是什么 SB 功能,SB 产品经理,但是从来没有人骂 SB 老板;用户吐槽产品很难用,设计可以说这锅我不背,产品经理设计的流程就是这样的;项目进度延迟,研发可以说这锅我不背,产品经理需求变更频繁……

任何人都可以甩锅,唯独产品经理不可以,任何与产品相关的锅产品经理都要背,这些都是产品经理的责任,不可推卸。

研发、设计表示需要一个打杂的:缺文案,产品经理帮你写;缺数据,产品经理帮你整理;需求开发好了,产品经理还要帮忙验收测试……

市场、用户表示需要一个翻译:例如,如何向用户解释什么是 2G、3G、4G 网络。如果直接告诉用户 2G 是数字网络、3G 是高速 IP 数据网络、4G 是全 IP 数据网络,用户肯定一脸懵逼:什么鬼?但如果告诉用户 2G 可以看文字、3G 可以看图片、4G 可以看小电影,用户立马就明白了。

怎样才能成为产品经理?

在大部分人眼里,只要会吐槽就可以做产品经理。

吐槽吐的专业,可以成为评论家;吐槽吐的幽默,可以成为段子手;吐槽吐的群情激奋,可以成为意见领袖;但发现问题仅仅只是产品经理工作中的一小部分。一个优秀的产品经理,必须会分析并解决问题。

我们来看一下产品经理的关键词:

是不是有种产品经理从入门到放弃的感觉?其实,将这些关键词整理一下,可以分成以下几个维度:

1.人

实现一个产品功能,产品经理需要全程跟进,在这个过程中,就免不了在多个部门之间沟通协调。

例如,老板想要增加某个功能,那么产品经理首先需要和老板沟通,了解增加该功能的原因,然后简单评估一下需求的优先级,并给出一个合理的解决方案。找设计沟通UI设计及交互逻辑;拿着做好的设计稿找到研发,确定开发计划及上线时间;功能上线后,向市场、客服部门的同事做培训,推广产品功能;产品功能推向市场后,收集用户反馈,处理用户遇到的问题;功能稳定后,采集数据,分析数据,持续运营产品;最后,还需要向老板及相关部门汇报产品数据,复盘总结。

2.能力

在图中列出的产品经理相关能力中,最核心的能力是学习能力、独立思考、沟通协调能力。这里的沟通能力,并不是指性格开朗、热情大方、幽默风趣这些一般人理解的沟通能力,而是把细节说清楚,专业。把细节描述清楚,没有歧义,双方能达成共识;工作态度专业认真,不过于情绪化。而协调指的是协调所有可用资源,让事情朝着你想要的方向前进。

3.工具&方法&输出

工具、方法、输出都是手段,不是目的。学以致用才是学习的目的,学了不会用等于白学。

而在实际工作中,光会这些还不够,必须把所有这些都揉碎、重组、融入到工作的每个细节中。

左边是大家看到的路径,右边是产品经理考虑的路径。

左边是大家看到的需求,右边是产品经理面对的需求。

左边是大家的工作流程,右边是产品经理的工作流程。

以杏仁医生App药品登记需求为例,下图是用户和研发看到的。

而实际上,下图是我考虑的内容。

看到这里,你还认为产品经理门槛很低吗?人人都是产品经理吗?

产品经理不生产需求,只是需求的搬运工

介绍完产品经理,我们要介绍产品的另一个关键词:需求。产品经理不生产需求,只是需求的搬运工。有人可能要说反对意见,乔布斯不就生产了需求吗?其实乔布斯也没有生产需求。

需求就像煤矿一样,有的随意散落在地表,大家都能看见;可绝大部分有价值的需求就像埋在地底下的煤矿一样,需要专业的人员去挖掘,去采集,去清洗。而产品经理就是这个挖煤的矿工,优秀的产品经理能挖掘到人性最深层的需求。

按照马斯洛需求层次理论,饿了么满足了用户的生理需求,在家也能吃上全国各地的饭菜;支付宝满足了用户的安全需求,给用户提供了资金安全保障;微信满足了用户的社交需求,让用户低成本的与朋友、亲人、同事交流;知乎满足了用户的尊重需求,让用户展示自己出众的知识技能,得到大家的赞赏;得到满足了用户自我实现需求,营造一种充实感,让用户感觉自己每天都在进步……

需求需要符合这四个条件:

  • 特定的人
  • 特定的情况下
  • 特定的问题
  • 可以被解决

概括下来就两个字:场景

之前有同事提出,杏仁医生 App 中的药品登记模块需要增加一个批量登记的功能。咋一看是不是很合理?但仔细一想,什么场景下医生会需要批量登记呢?

事实上,并没有这样的场景。医生开药的场景大部分都是先搜索药品,如果没有搜索到合适的药品,就顺手登记一下。医生并不会用小本本记下缺哪些药品,然后批量登记。因此,批量登记功能是一个伪需求。

把问题放到一个具体的场景中可以过滤掉非常多的伪需求、不合理的需求。

需求从哪里来?

1.公司外部

公司外部的需求主要来自用户、合作伙伴、竞争对手。用户经常抱怨某个功能不好用,用户反馈其实就是需求;合作伙伴在和我们合作的过程中,肯定会产生一些新的想法,这些也是需求;竞争对手推出了一些好用的功能抢走了很多用户,为了抢夺市场,也会产生需求。

2.公司内部

公司内部的需求主要来自公司战略、产品规划、内部人员。每年公司都会制定公司一整年的战略计划,产品总监会根据这些战略制定每个季度的产品规划,产品经理再将这些产品规划分解成多个产品功能。在产品迭代的过程中,老板、市场、运营会提各种各样的需求,研发、产品经理也会从技术、产品层面提出需求。

怎么定优先级?

1.刚性

指这个需求是否迫切,实现了这个需求,是不是能立马解决困扰用户很久的问题。

2.广度&频率

广度指这个需求会影响多少用户,多少核心用户。频率指用户使用这个功能的频率。

3.替代方案

指解决这个需求,是否有替代方案。

按照以上原则,规划电商模块功能。第一个版本必须要实现商品展示、商品详情、购物车、下单结算、支付功能,因为这是用户购买过程中最核心的功能。而售后退款相关流程可以放到后续版本,因为在初期售后退款功能并不是很迫切,只影响部分用户,且存在替代方案——人工处理的方式。当用户规模达到一定程度后,再做相关功能的开发。

满足需求的方法?

相信大家都去海底捞吃过火锅,每次去总是人满为患,假设你是海底捞的店长,你怎么解决海底捞排队的问题?满足用户快速吃饭的需求。

1.改变现状

我们能想到最直接的办法,就是扩大门店,增加更多的桌子和服务员。但性价比很低,一是扩张需要成本,需要额外负担装修成本、服务员工资;二是在非吃饭高峰期造成资源浪费,大面积的区域没有使用,部分服务员无事可做。

2.降低期望

在海底捞排队取号时,通常服务员都会告诉你前面还有多少桌,并告诉你大概的排队时间。但这个预估的排队时间通常都比实际等待时间要长一倍到两倍,虽然会吓跑一部分顾客,但留下来排队的顾客体验会好很多。本来以为要排 1 个小时,实际上只排了半个小时,内心会有小小的惊喜:海底捞效率还挺高的。

3.转移需求

现在海底捞的做法就是在排队区域准备一些小零食、水果和小游戏,让顾客一边吃东西玩游戏,一边排队。一方面通过零食和小游戏分散顾客的注意力,缓解顾客排队等候的暴躁情绪;另一方面通过零食和小游戏将大部分顾客牢牢的锁在海底捞,提高订单转化率。

研发与产品的爱恨情仇,本是同根生相煎何太急

经常会在网上看到程序员吐槽产品经理的各种段子、漫画和文章,平时工作中也遇到不少。分析下来,矛盾的根源在于:

  • 频繁变更需求
  • 低估研发成本
  • 需求变更没有通知到位

产品经理防“群殴”指南

需求频繁变更,其实说明产品经理在分析需求时缺乏思考,没有多想几个为什么。

不要用战术上的勤奋掩饰战略上的懒惰。

经常有朋友问我:做产品经理和做研发有什么区别?

最大的区别在于研发 80% 的时间用于执行,而产品 80% 的时间用于思考和沟通。

1.考虑未来三个月内的扩展性

在做一些比较大的功能模块时,不能只考虑第一个版本的规划,还需要考虑未来两到三个版本的功能。可以将版本规划提前告知研发团队,让他们了解未来产品要做成什么样子,哪些功能必须要做,哪些功能可能要优化。这样研发同学就可以提前做相关技术调研,规划技术架构,提高代码的可扩展性。

2.考虑常见的特殊情况

最常见的情况,调后台接口,展示列表数据。此时就要考虑很多种特殊情况:

  1. 没有网络
  2. 网络条件不好
  3. WiFi网络环境和非WiFi网络环境
  4. 没有数据
  5. 少量数据
  6. 大量数据

再比如,电商业务中最常见的订单,需要梳理整个过程中的状态,并画出各个状态之间的转化示意图。只有把所有状态都列清楚,才能确认逻辑是否完善,让研发能更好的实现订单流程。

3.不要想满足所有人的需求

相信大家也知道夫妻骑驴的故事,在这个故事中,无论这对夫妻采用何种方案,总会有批评的声音。

做产品也是同样的道理。比如,针对患教资料是否显示原创医生的个人信息。部分医生认为应该显示,理由一:这是医生花费大量时间和精力编写的文章,要尊重医生的知识产权;理由二:通过分享患教资料扩大知名度,让更多的陌生患者添加自己;另一部分医生却强烈要求隐藏原创医生的个人信息,这部分医生认为自己分享了其他医生写的患教资料,相当于向自己的患者介绍其他医生,为其他医生做推广。

无论是否显示原创医生的个人信息,总会有部分医生不满。你不可能满足所有用户的需求,在这种情况,坚持做自己认为对的事情就好。

4.MVP( Minimal Viable Product 最小可行性产品)

产品迭代路径应该按照 MVP 原则,先向用户提供能用的产品,再根据用户需求,逐步提供更好用的产品。而不是一上来,就规划一个非常完美的方案,然后花上好几个月甚至一两年来实现,说不定等你实现所谓“完美”的产品,用户需求早已发生翻天覆地的变化。

5.适当了解一些技术,适当看一些技术文档

在做患者端小程序前,先查看小程序接口文档,了解以下问题:

  1. 小程序能实现是否支持语音、视频、扫一扫功能
  2. 小程序和公众号如何相互跳转
  3. 小程序通知下发机制
  4. 如何配置 webview 业务域名
  5. webview 组件如何实现微信支付

这样才能规划小程序做哪些功能;如何实现小程序和公众号之间相互引流;如何通知用户;遇到非业务域名如何处理;如何在 webview 中调用小程序微信支付。

之前听过一句玩笑话。

产品经理懂技术等于流氓会武功?

流氓会武功的话,对付一般的小警察还是很有优势的;但如果流氓因为自己会武功,而无法无天,自以为是;等遇到狙击手的时候,直接一枪就被放到了好吗。

同样的道理,产品经理不能仗着自己懂一点技术,就对研发同学指手画脚。懂技术是为了排除需求中的隐患,更好的和研发沟通,提升工作效率。了解一些基础技术架构即可,不要沉迷于技术实现,否则,就是本末倒置。

6.重视文档更新

这个不解释。

研发防“入坑”指南

每次版本总结,总是会有研发表示被产品经理“坑”惨了:需求变更太频繁,需求不靠谱,需求解读错误,需求不明确……除去市场、产品本身存在的问题,大部分问题其实是沟通问题。

1.正确看待需求变更

一提到需求变更,一些研发会皱着眉头改代码,心里 mmp ,怎么又 TM 改需求啊;一些研发会让产品经理签字画押,作为日后打脸的呈堂证供;还有一些研发会直接拒绝,要改你来改啊,老子就不改……但事实上,业务稍微复杂一点的产品都会有需求变更,要求产品没有需求变更,相当于要求研发写的代码没有 bug 。我相信没有一个研发敢摸着良心保证自己的代码没有一个 bug 。

从另一个角度思考,需求变更其实是一件好事。正因为有需求变更,才能体现研发的价值:如果没有需求变更,80% 的程序员都要失业了。正因为有需求变更,研发的工作更具有挑战:如何设计更合理的架构,覆盖更多的业务场景,支持更复杂的业务流程。

2.先考虑需求是不是合理,是不是有更好的解决方案

看到这里,有部分研发同学认为,我为什么要考虑这些,这是产品经理的工作,不是研发的工作。这的确不是研发的工作,但实现这些需求却是研发的工作。为了避免自己被“坑”,如果有更好的解决方案,完全可以提出来,和产品经理一起讨论。

也许你们会讨论出一套性价比更高的方案:一方面满足产品需求,一方面减少自身的开发工作量。也许你们讨论过程中发现遗漏了某个分支的处理流程:一方面发现了产品设计的漏洞,一方面减少了 bug 数量提高代码质量。

3.有疑问,有困难一定要尽早提出,不要自己一个人默默的解决

例如,某个功能实现起来有技术难度,此时,研发和产品经理可以沟通讨论出更好的方案;某个模块功能太多研发时间太长,此时,产品经理可以根据实际项目情况,砍掉部分优先级低的需求,或者申请适当延长研发周期。千万不要自己一个人死扛,默默的处理遇到的所有问题,最终产品验收时,发现偏离了产品需求,吃力不讨好。

在每个版本开发前,产品经理都会先和各组研发 leader 进行小范围的需求评审,之后和后台研发同事进行第二轮需求评审,最后和所有相关研发同事进行最终需求评审。在这个过程中,产品经理逐步完善产品设计。前期沟通的越清楚,后期沟通的成本就越小,产品需求变更的情况也越少。

4.产品经理做的不好的地方,可以当面指出

在产品研发的过程中,产品经理接触最多的就是研发,听到最多的就是研发同事对产品经理的吐槽与抱怨。吐槽需求不靠谱,吐槽产品原型有漏洞,吐槽产品经理低估研发成本……吐槽产品经理也成为研发日常工作的一部分,我也相信这些槽点三天三夜也吐不完。

面对这些吐槽与抱怨,任何一个有职业素养的产品经理都会认真的听取意见。毕竟产品经理的部分工作就是收集用户建议、跟踪用户反馈、持续提高用户体验,而研发其实是产品经理最重要的用户。

没有什么事情,是一顿火锅解决不了的。如果有,那就两顿!

相信大家都知道瞎子和跛子的故事:一个瞎子和一个跛子,被困在火场中,眼看着要被烧死了,瞎子背起跛子,跛子指路,终于从大火中死里逃生。

如果说创业就像在火场中逃生,九死一生。那么产品经理就是一个跛子,能看见前进的方向,但没有行动能力;研发是一个瞎子,有行动能力,但看不见前进的方向;如果研发和产品经理之间相互猜忌,埋怨,最终可能是死路一条。只有两者相互信任,才有可能活着走出火场。

最后,希望研发同学和产品经理能够相互信任、和谐沟通,一起愉快的玩耍。

点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注