读《给产品经理讲技术》后有感
我认为产品经理是要懂技术的。至于什么程度,当然越多越好。最底线就是不影响与开发人员交流。一起基本的开发词语要了解。了解技术的目的就是提搞工作效率,与沟通效率。达到目的即可。程度不可规定。如果开发都是你的亲朋好友,技术方面可以什么都不用了解啊。
下面是我看这本书的读书笔记,感觉很基础一共约8k 字有兴趣的可以看看
本书由陈宇、巩晓波、高杨、杨俊勇、关磊5位腾讯开发高级工程师人员撰写。书中介绍说这是一本专为非技术背景的互联网行业从业者和想了解互联网技术的人员量身定制,并希望能本书成为非技术背景产品经理步入互联网技术世界的敲门砖。它是希望产品经理能懂开发技术上一些基本的概念,这样就使大家在沟通之前,能有一些基本的共识,以提高效率。2019年由人人都是产品经理与起点学院联合出品。全书共28万余字,书中提到用白话和通俗易懂的例子解释工作中常见的技术原理是本书一大特色,读者不需要任何技术基础。在书的前页还有一张大而全的彩色技术图谱。
作为纯纯小白的我读完给我的感觉更像是一本小字典,大部分是一些技术上的名词解释,当然比百度上的解释要更通俗易懂一些,或者说更系统一些。不过很多就是内容就是在解释这个名词是什么,这个技术大都时候都是应用哪些地方,一些比较难懂名词还是看不懂,需要自己查B站之类的视频看看会更理解一点。视频的方式更能容易的理解内容。最后一章还是有些思考的。产品懂技术知识是很重要的,而怎么用这些知识更为重要。如何只是为了在与程序员“PK”中更能压制博弈对方,那还不如不去了解那些东西。别要用学到的皮毛去挑战别人的饭碗,你永远Battle不过专业的人。即使你是从技术岗转过来的,在Battle中也要适可为止,你懂你明白可是人家是靠这是拿工资的,有一百种维护自己的支持自己的有利条件。把技术的知识用在完善自己工作能力上是最重要的,预估工作量、准确的找到技术负责人、风险把控等上。最最重要的是减少与技术人员的沟通矛盾、和沟通成本。这才是产品懂技术的目的。
从技术人员的角度提炼出产品人员应该了解的知识和高效沟通方式。
一、Wed前端。
RD(程序开发)包括前端开发与后端开发。那首先要知道什么是前端,前端在我的理解就是在界面所有的能看到的内容以及按钮交互操作都是前端,换句话说与用户有直接关系的就是前端。与之相反后端是不与用户产生直接关系的,它是负责产品的业务逻辑、数据相关以及性能和安全的问题。为什么要知道前端与后端的区别呢?因为一个项目的开发不是一个人俩个人就可以完成的,是需要多人协作开发,如果不能明确这个BUG是谁造成的,容易提交给错误的开发人员,会大大降低BUG的解决效率以及沟通成本,在文中作者做为来发人员说到他常常会出于对产品负责的态度把产品人员反映的问题先接下来然后在转接给相应的人员,我认为这种间接传递问题是不提倡的,有时候反而会加剧很大的解决成本。另外,如果团队规模较大,或者由各地的项目组拼凑而成,势必会增加沟通成本。虽然说有QA(测试)岗位在处理这些。毕竟产品是要负责整个项目的跟进与沟通的,这些基本的区别肯定要知道的。在前端技术中涉及到的主要名词有:HTML、CSS、JavaScript、DOM、URL、HTTP、Chrome。还有许多名词解释。
HTML:是超文本标记语言。可以说是一套编辑规则,以盖房子类比,必须定义这个房子有多长、多宽。每一块面积如何规划,例如哪里是卫生间、哪里是饭厅、哪里是卧室。将这些定义好,网页也就有了最基本的样子。总之,HTML就是用来布局网页中的每一 个元素的。它是W3C的结构层。相当于只有206块骨头的女朋友。
CSS:是级联样式表。CSS中的“样式”就是指外观。还以盖房为例,定义好了各个空间,房子也盖起来了,但还要装修,例如给客厅贴壁纸、给卧室铺地板。 CSS就是起装修作用的,要和HTML一起配合使用。它是W3C的表现层。相当于女朋友有血又有肉了。如果血肉分配合理的话还会是个绝世佳人。
JavaScript:是一种脚本语言。房子已经装修好,贴上了墙纸,铺上了地板,桌子、板凳、沙发都已经摆好,一切都很完美。可是,因为生活总是在变化,有时要买些新家具,或者把茶换几个位置,这时移动、添加、减少物件就只能靠JavaScript实现。想想一天里你家里的大大小小的东西动了多少次。它是W3C的行为层。也是最难的,最复杂的层次。相当于女朋友可以随意移动,还可以发出声音。这不就完美了。
W3C:当前互联网上的任何一个网页都是由它们三个构建起来的也就是所谓的W3C,虽然简单,但不可不知。前端就像学医一样,里面的内容浩如烟海,变化无穷,不要以为懂了一些,前端开发人员说的什么都要质疑下。
HTML5:是HTML规范的最新版本,一系列用来制作Web内容的相关技术的总称。
服务器:这个谁都知道。也可以看做中转站。现在的技术离不开服务器。在客服端输入,然后传到服务器,服务器做出处理后再传递给客户。
HTTP:是浏览器与服务器之间信息传递的一种公用的传递协议。如果HTTP中规定0是你,1是好。如果你在浏览器中输入你好,传递出去的就是01。到服务器中再翻译出你好再传递出去。
HTTPS:就是更高级的、更安全的协议。所有人都知道01是你好,那可还行了,于是他们各种又设置了自己的密码譬如908代表你8665代表好。而且这个密码只有他们自己人知道不外泄。这样别人即使截获了9088665也不知道是什么意思,还是信息还是安全的。
Chrome: 它和IE、火狐等都是浏览器都是浏览器应该不用多说。这里面有些冷知识感觉挺有意思的。这种东西现在知乎百度一搜就能搜到就不说了。
URL:URL统一资源标识符。用定位的方式标识就是URL,如果用命名的方式标识就是URN。举例;假如打王者你想用李白,用URL法就是点刺客第二排第三个英雄我可以命名为http;//http://www.ck23.com代表李白。用URN法就是在搜索中打李白就可以了我可命名为http;//http://www.libai.com就好了。看起来或者更为简单,但是由于这种方法需要强大的解析器。所以现在多数都在用URL的方法。
DOM:文档对象模型(DOM)是Web前端里最基础、最常用的一个模型。例如,一个网页其实就是一个 HTML文件(就好比还在孕妇肚子里的婴儿它也是一个人只是能做的事情太少了),经过浏览器的解析, 最终呈现在用户面前。HTML语言是由很多标签组成的,这些标签有管开始的叫开始标签<head>还有管下一级的标签<body>。标签就像使用说明一样告诉你一步干啥第二步干啥。就像做菜一样第一步起锅烧油,第二步放菜,具体多大火多少油什么样的菜还是由自己来决定的。把每个标签 抽象成代码里的对象,按照这种层次分明的结构组织,这就是DOM
DOM树:就是很多个标签按照一定的规范排列着像一个树一样。
强烈推荐B站搜索尚硅谷Web前端初学者零基础入门视频。用诙谐幽默的语言讲解前端系统的知识。
二、客户端技术
客户端是指开发面向客户的程序,分很多平台,比如Window安卓,苹果,还有游戏客户端也算一类。文中指出Android与IOS 差别,Android会私自的唤醒应用。同时也介绍的客户端实现推送的方式。总结起来,APP和后台的连接方式有两种,一种叫pull,也叫轮询,就是定期地不断向后台请求,缺点是耗电,费流量,不环保;另一种叫 push,APP 和后台一直维持了一条通信通道,不定期地发送心跳包,也能携带信息。缺点是要维持一条长连接通道,这条通道如果不用 一些特殊手段保持连通性,很容易受系统或其他安全软件的影响而断开。同时也介绍了美颜APP的原理以及听歌识曲的基本原理。这些都是可以在网上都是可以查到的。在客户端技术的的最后一小节介绍了应用的生命周期。下图为一个 Android 应用的例子。
可以将图中的Activity简单地理解为呈现给用户的应用界面。可以看到这里有8种状态在按照一定的顺序进行切换,上半部分属于创建,下半部分属于消亡,但是整个过程并不是完全不走回头路消亡路径上的一些状态,也可以在一些条件下转换成创建路径上的状态。产品人员解了应用的生命周期后,再去使用应用时,就可以判断出程序设计的优劣,偶尔还能提一些建设性的意见。
三、开发技术
“空指针”是什么。顾名思义就是指向空的指针。但是“空”是一种极度抽象的概念,管理员立一块箭头牌子,总得把它指向某个具体的地址。既然没法指向真正的“空”,那就在内存中模拟出一个地址来代表“空”。具体指向没有明确的统一规定,不同的系统可以指向不同的地址,不过一般情况下,会指向0地址,访问它是非法的。大部分空指针的Bug是隐藏在代码的茫茫大海中的。不过,因为改起来很简单,程序员可喜欢改空指针的 Bug了,可是简单修复了空指针后会引发哪些后续问题,很多程序员就不会去考虑了。
“越界”是什么。发生数组越界的原因很简单,假设一 个列表中只有10个元素,但是某个函数偏偏要取列表的第11个元素,就会产生“数组越界”。程序员要存储的数字超过了他选用的数据类型所能表示的最大范围时,就会发生数据范围越界。
“起名”有多难。程序设 计里最难的两件事,一件是保证缓存一致性,另一件就是命名。编程五分钟,命名俩小时。在命名的时候,什么是Manager、Controller,什么又是Interface, 需要程序员通盘考虑。如果命名不当,后期维护的成本是很高的。
耦合与解耦。“解耦”和“耦合”是对立的,产生了耦合才需要解耦。耦合是代码结构设计中产生的问题。当公司需要开发一个应用时,往往会将应用中的 各个功能分配给不同的程序员,但各个功能在联动时会直接互相调用对方提供的方法,这就是耦合的温床。解耦就是把耦合的东西在拆分出来,并且不影响原先的结构,解耦是每一个程序员非常反感的事情。
“Bug”有些不能改。不是所有的Bug都是可以改的,世界上没有Bug的代码是不存在的,有些Bug开发是知道的不过修改这个可能会引起更多的Bug所以没有人想去冒这个风险。
“编不过”是什么。程序员说的“编”就是编译器在进 行翻译,“编不过”就是编译器在翻译的过程中发现有单词和语法不符合规范,向程序员提出警告:必须按照规范来,否则不予通过。这和 Bug 还不一样,Bug是编包成功后,在使用的时候出现的,但是这种在编译 阶段出现的错误,必须解决了才能继续。那为什么会一更新就“编不 过”呢?大多是因为一些不负责任的程序员没有好好检查自己的代码就提交到代码管理库中去了。“挂了”是什么。经常会有用户反馈程序用着用着就强行退出,也就是常说的应用程序崩溃,俗称“挂了”。一般说某程序不稳定,就是说该应用容易“挂”。产生原因有俩种,其一,都是程序员的错。程序员写出的代码就是应用程序的“行为清单”,应用程序运行的每一步都一丝不苟地按照程序员的指示进行。其二,操作系统不靠谱。所有的软件都是有Bug的。像操作系统这种极其复杂的软件更加无法幸免。所有的应用软件都依托于操作系统提供的基础能力运行。如果操作系统本身不稳定,就会对应用程序的运行造成影响。
“重构”是什么。重构就是在保留现有功能的基础上,重新梳理软件中的代码结构,让原本杂乱无章的代码重新具有可读性、结构性和扩展性,增加软件的开发效率,优化程序的性能。重构的范围可大可小,大到涉及整个产品的各个模块,小到一个函数。在软件开发过程中,每一款软件一开始都是经过精心设计的,具有良好的结构。但随着需求不断变更,之前的结构开始慢慢变得不适应, 就像隔壁老王的房子,本来是为平房设计的承重系统,后来娶媳妇想改装房子。现在的房子要承受二层楼和阳台的重量,这种变化可能是当初的设计者始料未及的。为了快速完成需求,开发者可能会使用一些违背当前软件架构的方式实现功能,久而久之,这种“另类”的代码越来越多,导致软件之前的结构已经淹没在 了这些杂乱无章的逻辑中,使得整个软件没有清晰的脉络,严重降低了代码的可读性和可维护性,一点小小的修改都会造成不可预知的 Bug 产生。在这种情况下进行大规模的需求开发,后果可能是灾难性的。
四名词解释
抽象、封装、类、实例和对象。这几个词可以用一句话串联为:对事物进行“抽象”,从而封装 为“类”,由“类”可以生成“实例”或“对象”。 抽象 是面向对象思维方式最基础的逻辑和思维,是封装的前提,是对一系列拥有共同属性或行为的描述。喝水、喝酒、喝西北风,可以抽象出“喝”;抽烟、抽风、抽鸦片,可以抽象出“抽”。抽象对应的是具体,抽象之后具体消失,共性出现。这些共性被用来封装为类。类可以定义实例,实例也称为对象。
钩子(hook)。在Windows系统中一切皆消息,按键盘上的键,也是一个消息。Hook的意思是钩住,也就是在消息过去之前,先把消息钩住,不让其传递,使用户可以优先处理。执行这种操作的函 数也称为钩子函数。简单地讲,就是“要想从这过,留下买路财”。要去公共厕所,必须 先经过公厕门口老爷爷的收费允许,老爷爷就是在下“钩子”,这个钩子函数的功能是付款。程序员在讨论时也常说“可以先钩住再处理”,即执行某操作之前,优先处理一下,再决定后面的执行走向。
模板。代码也是有模板的,跟PPT模板一样,有了模板改改内容就可以得到自己想要的东西了。模板就像轮子一样,别人的能用就用,何必自己要先造一个轮子呢?
栈的含义。栈首先是一种数据结构。栈也表示由操作系统管理和分配的一些内存区域,这些内存区域用来存储程序中的变量及参数,程序员常说的“栈溢出”就是指这块内存空间被用完了,内存不够程序就崩溃了。栈也表示信息常指程序出错的打印信息。如果再听到程序员说“栈信息打印出来了吗?”或“把栈发给我看看”,其实是在用栈信息定位问题。还有全栈工程师是指啥都会很牛叉的工程师前后技术都会,一个人能干二个职位的活。技术的垂直度很高的工程师。
开源。程序员写了一些代码,觉得自己写的代码可能会对这个世界上的其他人有所帮助,就在网上公开源代码,让每个人都可以自 由地查看、下载和分发,这就是开源。
接口。指提供一种别人可调用的能力的标准。例如,小明写一封简历找 工作,这个简历就是小明的接口清单,这个接口清单描述了小明具备 的“接口”。简历上写会写文档,老板看到了聘用他让她去写文档。“让后台给我提供一个接口”,这句话在工程中一般表示的是仅仅提供一项能力供调用方使用,这跟我们上文讲的接口的定义不完全一样。例如,后台提供了一项能力,终端可以从后台调用这个接口,查询当前所在位置的天气。这种话在开发过程中讲得比较多,常用于前端和后台 的联调。 “你来设计一个接口,我来实现”,语境一般是在面向对象的程序设计中,对一种能力的抽象分别由不同的开发者实现接口象征着提供出来的能力,定义者和实现者一般是不同的,调用 者并不需要关注具体细节,只需要关注接口暴露出来的能力就可以了。如果程序员说“你给我封装一个接口,我直接调用”,应该他说的意思是:“我不关心你如何实现这个能力,只要我要用的时候,你给我正确的结果就好了。
兼容。它包括向前兼容与向后兼容。向后兼容指的是对已经发出去的老版本兼容,向前兼容指的是对还没有做好的版本兼容。显然,向未来兼容难上加难,理论上也是做不到的,因为我们永远不知道未来要做什么功能或需求。但向后兼容是一定能够做到的,程序员都可以面对老版本分析出当前的状态和兼容的办法。如果有程序员对你说无法兼容老版本,那他一定是想偷懒。总而言之,向后兼容是一定要做的,而且一定是有解决方案的。向前兼容是可以适度做的,但一定是无法长期兼容的。
五、沟通
工作上的沟通无非就是想要解决问题、提高效率,要不然谁没事沟通啊说话的艺术真的很费脑子。
首先要了解程序员的分工,知道他们每一个都是负责什么的,当然如果那个人是全栈工程师就没什么可了解的了。
如何正确地提需求。1.提需求要有节奏感 ,在功能开发、单元测试、集成测试中适当的提出需求。到了灰度验证和上线发布阶段,大家都绷紧了神经,天天盯着用户反馈和线上的各种指标。若这时产品经理突然有了一个绝妙的需求,请 控制一下,因为这时提任何需求都会被记恨。2.先自己尝试评估需求难度 。产品经理评估需求难度这件事需要一点技术含量。有些需求天生很难,例如智能推荐、智能识别和搜索引擎,这些都需要很强的技术能 力。还有些需求需要前后端联调,后端开接口,商量协议,实现起来耗时要翻倍。除了这些,剩下的要取决于是否有现成的“轮子”。尤其是在排需求优先级时,尽量不要出现不确定的语言,什么做不做都行。有条件就做之类的。3.下点功夫做准备。这是个简单的道理,你让别人给你办事,吩咐半天讲不清楚,别人肯定不耐烦。如果你的需求是模仿别人的,可以拿别人做好的效果演示,这是最直截了当的。
写出程序员想要的文档。程序员和产品经理之间产生的矛盾大多是因为一个 叫产品需求文档(PRD)的东西。有一种让人头疼的需求文档,如表所示。
产品经理将这样的文档转交给程序员的时候,程序员的内心一定是崩溃的,他一定会问若干个“如果”:如果发生A情况,该怎么处理;如果发生意外,产生了B情况,又该怎么处理。产品经理收到反馈再来更新需求文档,你问,我改,再问,再改,等大家都疲惫了,需求文档也成熟了。最后谁都看不懂,一份文档束之高阁,没有任何价值。
需求文档中的“优先级”选项也是令程序员很头疼的,优先级分为 高、中、低三个选项,大多数产品经理会说,高优先级必须上线,中低优先级也是需要做的。那还分什么优先级呢?或者说中低选做,这种模棱两可的感觉还不如抽象成做或者不做。当然,这需要产品经理提升能力,能够清晰地评估出一个版本能否涵盖这么多的内容,其实程序员根本不需要这种文字式的需求告白书,这种文档应该是产品经理脑中的思路,而不应该被描述成文字交出来。程序员需要的是一份大家都认可的清晰的交互图,其关键位置需要有一些边界条件的说明。这份交互图不一定非要用专业的原型工具输出,一张草纸加铅笔描述清晰即可。作者认为由产品经理和程序员一起讨论功能的关键路径,并一起确定每一个流程,然后简单地画出草稿,才是效率最高的方式,并且可以少开很多会议。若仅一个人想好了就发起评审,结果往往是需求被改得面目全非,不如大家在初期就一起讨论得出结论。 当然,程序员是很高傲的,产品经理没叫他参与讨论时,他会抱怨:“什么都不叫我,乱决策,现在一团糟,根本实现不了。”产品经理 他的时候,他又会说:“整天跟产品经理在一起讨论问题,技术上都 没有长进,没有积累。”或者抱怨说:“白天跟产品经理讨论,只有晚上加班才能写点代码,筋疲力尽,还总被批评效率不高。”程序员大多认为自己有些武功,所以跟不同的程序员交流要用不同的方法,例如多请他们吃饭。从另一个角度看,所谓能力越大,责任越大,明白的程序员与产品经理早就想明白了,他们每天工作不是为他的老板,而是为自己,无论在哪里干,都当是创业。
精益(mvp)的作用是最小成本验证可行性,把所有资源投入到最大可能的方向。直播兴起的时候,是应该以产品上线为首要目的的,不应该过多地考虑带宽不够怎么办、用户激增到500万怎么办,或者播放质量不够高怎么办等问题。道理很简单,做到却不容易,希望产品经理明确地知道当前目标,而不是抱着“既要……也要……还要……”的想法应对一个验证过程。目标明确,只突出一个点,能促使自己与程序员和设计师更快地达成一致。
六、你只是在为自己工作
在职场,雇佣关系告诉你在为别人打工,使你常常放松自己,有了干多干少都是为老板的感觉。这种想法很容易使你错过最佳的成长时间窗。吴军博士讲过,一个人工作做到95分和100分,其实并不仅仅是5分的差距都远远大于他直接做到100%所用的成本。如果一个人一直在追求那最后的5分,可以为了那5分付出远大于前面95分的努力时,也就区分出了高手和普通人,高手在任何一个领域都会胜出一筹,这来源于长期的刻意训练。
如果你一直觉得工作就是为别人打工,就会习惯性地得过且过、患得患失、抱怨不断,从而缺乏持续性的积累,导致未来成长动力不足。
人生是长跑,至少要工作到60岁,我们必须追求每一天都比前一天更有厚度,只有抱着为自己工作的心态才能做到。工作是为了自己,这 一点永远都最重要。