授人以鱼不如授人以渔,要鱼还是渔?

前言

授人以鱼不如授人以渔,见什么人说什么话,道理都很简单,怎么去实践并真正的认知,这才是最难的!

作为一个技术出身的产品,每当公司的一些同事问我一些产品上的使用问题或者是一些疑惑的时候,我都会跟他们解释的多一些,例如:

同事A:“这个功能是不能是能实现上线一个班级并购买”

我:“这个确实可以上线,但是你要注意这个东西需要你设置一下,还有这个东西你要注意它是需要在别的地方设置一下然后才可以完美的上线的……”

经过我一顿的巴拉巴拉的之后,对方直接给我一个白眼并怒问:“我就是想知道是不是这个东西这样设置就能上线,你给我解释那么多干嘛?”我瞬间懵逼,我给你解释这么多是为了让你不搞错,结果你还怪我。但是看了看同事满脸不高兴的脸,行吧!这波我认栽,我的是傻逼。

以上这种情况很常见,但是也很让我苦恼,因为确实他问的是一个问题,但是我给他回答的东西是这个问题可能会出现的意外以及解决办法;但是对于大多数人来说,我问的是问题1,结果你给我的答案除了答案1外还有答案1全家桶,搞得我都不知道真正的答案到底是什么,你这不是缺心眼吗?

额,以上这种“买一送一”的操作,站在我的角度来说,我是为了你好,让你不出错,让你后续遇到问题的时候可以知道什么原理,知道怎么去解决。

但是站在他们问问题的角度来看,我问了这个问题,我就是想知道这个问题的答案是多少,但是你给我的答案除了我要的答案外,还附赠了一堆全家桶,plus给我,让我不能准确的筛选这个答案到底是什么了。你说你是不是给我添乱呢?

这个我是亲身有感受的,为了方便理解我再举一个简单的例子,譬如说我大学的时候,经常做一些电脑手机的小生意,自然也有一些人问我一些关于电脑方便的知识和问题。然后找我推荐买什么电脑,跟我巴拉巴拉一大堆,我给她们(妹子居多)解释了一大堆后,她们说:“我听不懂,你直接给我推荐吧!”好的,我给她们推荐了,电脑到手之后,问题又来了:
“哎,我的电脑怎么开机没有系统,直接就是黑屏啊,这个电脑是不是有问题?”
“我的电脑怎么是win10的,不是自带win7吗?怎么系统只有一个盘,我怎么分盘啊?”
“这个电脑怎么没有送鼠标啊,我看别人的都有鼠标啊?”
……
以上等等问题,其实在购买之前的时候我都应该给他们解释清楚的,但是很多时候她们对太多的信息并没有兴趣和精力去筛选,所以他们要的就是直截了当的答案,例如“这个电脑适合我”,“这个电脑很不错”,“这个电脑用起来就很爽了”,然后你之后对她们进行一堆的巴拉巴拉都是废话,她们反而会觉得你这个人很烦。但是电脑到了之后,问题会接踵而至,所以你在这个时候给她们解决问题的时候,如果现实和她们理解的期待有很大的偏差,那么这个时候妹子们基本上是不开心,如果偏差不大,然后尽快解决问题,结果应该还不算太糟。

以上例子虽然有点不太准确,但是告诉我们的结论就是:对什么人要说什么话!

我很喜欢的一个观念就是“授人以鱼不如授人以渔”,鱼总是会吃完的,但是自己学会了解决问题的根本,以后遇到问题就不会一直等着别人帮我,拯救我了。这也是为什么很多时候写代码的时候,很多前辈都会说,“基础需要打好”,“有事没事多去看看源码,看看底层的代码,这样自己才会更加深刻的认知和理解这个程序”。

直到我产品生涯过了几个月后我才很深刻的理解这个问题,很多时候老板问你,这个功能什么时候能实现,怎么实现好。这个时候老板需要的回复是:一个大概的时间,一个粗略的概览,他需要知道你的进度和你的工作内容大概是什么。但是如果你劈头盖脸就跟老板说:这个东西很难做,这个东西要用到XXX技术,这个特别难实现,然后我们决定用YYY技术,然后通过OOO原理,巧妙地借助ZZZ,来解决这个问题……

这个时候老板基本上已经绿着脸不耐烦的送你一张飞机票或者翻车票了,滚!

这也是血淋淋的教训,对老板不需要BB那么多原理,你只要说:恩,一周后能解决,这个方案很不错,到时候解决了我给你看看,这个没问题,可以做,还行。
就算你做不出来,你也不要说那么多原理和困难,除非他是很认真的追问你细节的问题,否则你就说:做不了,这个问题暂时解决不了,下次我们再讨论下,这个需求可以改一下,我有一个更好的建议……

问题回到我们的标题,更多的时候我的生活中遇到的问题是:我扮演的基本上是一个长辈的身份,很多小学弟小学妹什么的或者一些朋友经常问我一些问题,请教一些事情;以前的时候真的特别喜欢跟他们解释一大堆原理或者是基础的东西,直到慢慢地我去思考作为一个产品经理如何说话,如果沟通,如何表达的时候,才发现其实之前的自己确实有点点中二。技术性质的问题,其实并非人人都喜欢听,喜欢的人自然会深追,但是不喜欢的人往往会因为太多的技术细节而感觉不舒服。

例如有人问我“怎么学习git”,“github入门感觉很难”,“github是什么”,如果只是简单问我,需要一个答案的,我基本上就很简略的通俗易懂的告诉他;如果是问一些怎么学习,或者怎么深入了解的问题,我基本上会告诉他,你先去看,有问题不知道的时候再问我;因为开始就给别人灌输太多的知识细节会让一个人很容易陷入学习的死角,然后兜兜转转地在纠结怎么解决问题。

由此,关于很入门类的技术类的书本或者教程,判断它写得是不是很好,其实我觉得只要看他是不是有以下几个关键点就好:

  • 简单地概述这个技术的原理或者是用途

  • 恰当地举例子,触类旁通式地讲解复杂问题

  • 每每结尾必有总结与归纳

  • 中心思想不偏移,总能圆的回来

举个例子,我之前看一些TCP/IP或者是HTTP协议的内容,很多人一来就说这个是专门针对初学者,没学过的人也能看得懂的教程。然后上来就说TCP/IP用到了什么原理,然后一堆的参数丢上来,一堆的图片各种层级架构丢上来,然后干巴巴的介绍完各种层级的用途与原理,然后就结束了。新生哎,初学者哎,你这样的教程别人真的看得懂吗?

入木三分,深入浅出,通俗易懂的教程,真的很难写,写得了好教程的人真的太少了。

产品角度来说:你无权选择用户,只有用户选择你,你的教程不能让用户满意,那么问题就是出现在你的身上。2333……我也很无奈啊,我能怎么办!

最后,很多人说“只要会吐槽的都可以做产品经理”,现在的产品经理门槛确实很低,但是我相信“人人都是产品经理”,但是真不是“人人都可以做产品经理”。 一颗有趣的灵魂,不是靠说出来的;一个独特的大脑,也不是评价出来的。产品之路还有很长,愿大家都可以走的更远,让我见识一些更有趣的灵魂和独特的大脑。

--本文到此结束感谢您的阅读--
随缘打赏,佛系产品
0%