编辑导读:为什么产品经理和程序员之间总是发生矛盾,很多时候是因为认知不同。如果产品经理能掌握更多的技术支持,相信沟通会更加顺畅。本文作者将围绕思维碰撞、工作流程、基础技术、技术术语、沟通技巧等多个维度进行讲解,希望对你有帮助。

上一篇文章我们讲了《产品经理要不要懂技术的底层逻辑》,没看过的同学可以先行阅读,再回来看本章节内容可能理解会更深刻。

由于篇幅原因,并未讲解技术的具体内容,本章将围绕思维碰撞、工作流程、基础技术、技术术语、沟通技巧等多个维度进行讲解,所有内容均为互联网内容,争取用简单的语言来描述技术内容,让非技术出身产品能轻松理解、学以致用。

01 思维碰撞

1. 产品思维

我理解的产品思维,是通过用户和数据发现现象,分析现象的根本原因和是否需要解决,然后提出具体的解决方案,并将解决方案标准化和产品化的过程;

就像写命题议论文,命题人所描述的可能是一个问题、一种现象、一种感受、一种情绪、甚至是一个结果,我们要去理解他的真实意图,寻找有效的论点和论据组成解决方案,可以从多个角度进行论证,同时要求我们在论证时做到:

  1. 有观点和立场:不能出现无目的、无意义的内容
  2. 是一个整体:不能出现毫无关联的内容
  3. 严谨和逻辑自洽:不能出现自相矛盾的内容

整个过程是层层递进且存在着不确定性,分析出的问题可能是错的,提出的解决方案也可能解决不了问题,因为结果的不确定性,这时我们只会考虑解决方案的可行性,是否能解决用户的问题,以及如何提高解决方案成功的概率,不会对实现方式过多的思考。

2. 技术思维

技术思维是一种方案实现的思维方式,基于已经证实的原理和确定的数据为支撑,并从影响面、编码复杂度、投入人力成本等三个变量评估实现难度的过程;

有点像解数学题,在已知的数学公式中寻找解决思路,可以存在多种解法,但答案只有一个,最终只有有解和无解两种结果,要不就找到了答案,要不就是题目本身错了;

在思维碰撞时,大多的争论都在产品逻辑前后矛盾和逻辑缺失,以至于开发要自己脑补逻辑,在开发心中产生了极大的不确定性,技术思维是不擅长解不确定性的题的,因此会不断提问来修补确认,作为产品经理,我们在提需求时要尽量消除这种不确定性;

然后,由于之前对实现方式缺乏思考,在评估后发现实现难度过高,开发会本能的出现退缩的现象,并质疑题目是否正确,这时,我们需要抛出需求价值(观点和立场)来强化需求的目的,拔高需求的投产比,让开发能感受到完成带来的意义,以此根据需求目的提出对应方案以此来降低实现难度;

产品经理可以在一开始不讲“为什么要这么做”,但一定要在开发询问时能及时进行解答,以专业的姿态让需求变得完整、前后呼应;

在做需求时,对一些感觉可能会有障碍的功能,先做提前沟通,在影响面、编码复杂度、投入人力成本三个变量进行预判,并做好了充分的逻辑思考,或者适当修改自己的方案,以满足产品最优解,这就是具备了一定的技术思维。

02 人员分工和流程

1. 岗位分工和职责

  • UI设计:对软件人机交互的视觉效果设计,负责页面美观度、切图
  • 前端:将设计好的图片,转换成用户能操作的软件界面或HTML页面,负责产品界面和交互
  • 后端:提供数据库、平台和接口设计,负责功能逻辑实现和数据存储处理
  • 测试:验收开发出来的产品与预期是否相符,负责把关产品质量
  • DBA:负责数据库的管理和运维,保证数据库的稳定、安全、完整和高性能
  • 运维:对网络、服务器、系统环境、服务的生命周期各个阶段的运营与维护,在成本、稳定性、效率上达成一致可接受的状态

2. 产品开发流程

一个完整的开发流程如下:

03 基础技术内容

1. WEB基础技术

  • URL:统一资源定位符,用来访问网页、图片、视频等内容,互联网上所有资源都有一个唯一的URL,以http开头,可以是ip也可以是域名,其实是一种路径
  • TCP/IP:是指能够在多个不同网络间实现信息传输的协议簇,它是在网络的使用中的最基本的通信协议
  • HTTP:全球超文本传输协议,基于TCP之上,是互联网的基本协议,所有的WWW服务都必须遵守HTTP协议,保证客户端与服务器之间的通信
  • SSL:可以在互联网上提供秘密性传输,使用户/服务器应用之间的通信不被攻击者窃听,并且始终对服务器进行认证,一般用于安全要求较高的系统,比如网络支付

2. 前端技术

  • SDK:指辅助开发某一类软件的相关文档、范例和工具的集合,包括软件、框架、硬件、系统等,以前端使用最为广泛,可以极大减少开发难度,提高开发效率;比如我么要接入移动支付,就可以下载一个支付宝的客户端SDK,配置并调用支付接口即可;
  • POST/GET:是两种常见的http请求方式,Get 是用来从服务器上获得数据,而 Post 是用来向服务器上传递数据;Get数据放在URL中,对用户可见,Post通过request body传递参数,对用户不可见;
  • AJAX:使用异步数据传输,网页应用能够快速地将增量更新呈现在用户界面上,而不需要重载(刷新)整个页面,这使得程序能够更快地回应用户的操作,在用户端体验会更加友好(刷新页面在视觉上会出现跳帧让用户失去了焦点);
  • COOKIE/SESSION:两种会话储存技术,多用于用户身份识别或状态存储,cookie是储存在本地(浏览器中可修改查看),session储存在服务器会更安全;
  • TOKEN:服务端生成的一串字符串,以作客户端进行请求的一个令牌,一般用作用户登录后判断身份,无需再次输入账号密码,就像我们拿卡代替钥匙开锁一样;
  • 原生开发:是指在Android、IOS等移动平台上利用官方提供的开发语言、开发类库、开发工具进行App开发,优点是体验好、性能佳;缺点是不同手机系统要开发两遍,开发周期长,成本高;
  • 混合开发:使用原生(native)+ HTML5 进行开发,然后打包成不同平台的app,优点是开发快,UI表现一致;缺点是性能和原生有差距,有些能力无法实现;
  • 小程序:是一种不需要下载安装即可使用的应用,用户用完即走,不用关心是否安装太多应用的问题;小程序开发门槛低,能满足大多数业务需求,使用也很方便,由微信16年第一次提出,现在几乎所有超级APP都内置了小程序;

3. 后端技术

  • 短连接:客户端和服务器每进行一次HTTP操作,就建立一次连接,任务结束就中断连接,大部分web服务都为短连接,比较省资源;
  • 长连接:客户端和服务器在建立一次连接后,一直保持连接,多用于操作频繁的、对消息及时性要求较高的场景,比如游戏、即时聊天;
  • 同步:按顺序执行,调用某个东西是时,调用方得等待这个调用返回结果才能继续往后执行;比如ATM机取钱,取完一个才能下一个;
  • 异步:调用方不会立即得到结果,而是在调用发出后调用者可用继续执行后续操作,被调用者通过状态来通知调用者,或者通过回调函数来处理这个调用;比如点餐,点完后旁边等待出餐,下一个继续点餐,出餐后用喇叭通知取餐;
  • 队列:可以理解为现实生活中的排队,队尾进队头出,即“先进先出”,常用于秒杀或团购活动中,防止并发过大导致服务宕机;
  • 栈:又叫堆栈,采用“后进先出”规则,比如进出电梯,后进去的因为站在门口要先出去;

4. API接口

是客户端和服务端进行数据传输和交互的协议,是两个系统间同步数据的一个途径,一般由错误代码、错误消息、数据内容三部分组成,可以是JSON、XML、或字符串等形式返回,由服务端开发编写,且要提供接口文档以方便前端使用。

接口的设计极大的减少了依赖,提高了数据访问的安全性,技术人员常说的前后端分离,就是让前后端专注于自己的业务逻辑,通过标准的接口来进行数据对接。

需要注意的是,为了让用户体验更加友好,尽量使用非专业的文字来描述错误消息,不要显示错误代码在页面上。

5. 行业名词

  • 服务器:在网络中为其它客户机提供计算或者应用服务,我们的代码就要部署到服务器上,和我们的电脑主机类似,但它比电脑运行的更快,每个服务器可以分配一个公网的ip,才能对外提供访问服务;
  • 系统:一般指运行在服务器上的操作系统,应用程序需要在操作系统上才能运行,常见的服务器系统有windows、linux(开源);
  • 数据库:按照数据结构来组织、存储和管理数据的仓库;分关系型数据库(如:Mysql,SqlServer)和非关系型数据库(如:MongoDB);类似现实中的仓库,货架对应的就是数据表,货架上每一格货物类似数据表中的一条条数据;
  • 缓存:指可以进行高速数据交换的存储器,它先于内存与CPU交换数据,因此速率很快,缓存的作用不直接访问数据库,防止访问量过大导致数据库宕机,提高我们数据的访问效率;如常用的内存型缓存Redis、Memcache;
  • 定时任务:在服务器上每隔一段时间执行一段代码,以取得某个结果的操作,一般使用crontab,我们常将一些比较耗时的比如数据统计,放在凌晨访问量少的时候定时执行,生成数据表、发邮件;

6. 工具的使用

  • IDE:是用于提供程序开发环境的应用程序,一般包括代码编辑器、编译器、调试器和图形用户界面等工具(男人的工具箱,里面什么都有),IDE的出现让开发过程变得简单、便捷,开发们都有自己喜欢的IDE,也通过不断优化和配置形成自己独特的习惯,它是士兵上战场的武器;
  • Postman:是一个接口测试工具,它相当于一个客户端,可以模拟用户发起的各类HTTP请求,将请求数据发送至服务端,获取对应的响应结果,验证响应中的结果数据是否和预期值相匹配;
  • Firebug:也叫开发者工具,它是集HTML查看和编辑、Javascript控制台、网络状况监视器于一体,是前端开发得力工具,可以直接在浏览器中调试代码;原本是火狐浏览器的一个扩展,由于过于优秀极大的方便前端开发调试,目前浏览器都已支持;

04 技术常说的术语

1. 技术术语

搭环境:分开发生产和产品运行环境。

  • 开发环境:新员工第一天入职,都要先搭建自己的开发环境,即岗位所需要的IDE、运行、调试软件的集合,还会根据自己的习惯来配置IDE,提高开发效率;
  • 运行环境:产品开发完后需要放到服务器上,这样用户才能使用和访问,就需要搭建服务器环境,同样的也是一些列的软件、插件的集合,有的时候还需要优化下操作系统的配置,就像你优化自己的电脑设置一样;
  • 环境分类:运行环境还要区分dev(开发)、test(测试)、product(生产)等环境;严谨一些的还有预发布环境(使用的是生产环境的数据,但代码还没有发布到生产环境),灰度环境(小部分人群可以看到)环境等等;

建表:根据业务逻辑需要,设计数据库表结构,用于存储数据,主要是后端开发的工作,也有可能是DBA的工作;

写死:

  • 是指参数或者配置内容写死,代表着这些内容是要写在代码里,修改需要重新发布代码;如用户注册时选择省/市,可以直接写在前端代码里,无需通过后端提供接口,就省去了建表和写接口的时间;
  • 写死的好处就是开发效率高,坏处就是修改不方便,需要重新发布版本;

2. 开发说的“做不了”包含了哪些信息?

  1. 现有的技术根本无法实现,也就是经常说的超出了技术边界,比如想要下载速度达到10G/s
  2. 受限于公司研发能力和技术栈限制,超出了能力边界,比如原本是做小程序的要求去做人工智能开发
  3. 平台或生态的限制,不支持这种做法,或者没有开放对应的接口,比如微信没有对外开放获取好友列表的接口
  4. 现有技术架构不支持,如果要做成本会很高,需要重写底层代码,时间紧、任务重、不划算
  5. 实现方法比较复杂,没有快速实现的方法,无法满足短时间内实现的要求
  6. 觉得所提的需求价值不大,没有做的意义,也没有动力去做
  7. 单纯的不想做
  8. 烦你

搞清楚具体是哪一种情况,然后才能有效的进行判断和解决。​

05 和开发友好沟通

1. 协调估时方法

开发估时主要都由团队中的技术主管来把控,他们有责任来辅助估时、把控进度、协调任务;

因此这里说的方法不是让产品经理来代替开发估时,而是在遇到估时远超预期时,我们所能采取的策略;

判断估时第一步:我们先看总时长,找出将总时长拉长的人的时间节点,看是否是任务安排不合理(个别人任务多)、还是顺序衔接有问题(出现时间真空)、还是有其他任务打扰;

判断估时第二步:解决个别人时长过长,有些人可能任务量正常、复杂度和其他人差不多,但估时就是比别人多;

  • 先评估个人能力和所分配的任务是否匹配
  • 然后询问原因,可能会发现信息不对称(如对需求的理解不对、对代码库的了解、对某些技术不了解等),产品经理可以引导其找对应的人解决,或者直接帮他解决,进行信息对称
  • 最后,这个人可能说不出为什么,也没有意愿去解决时长过长的问题,产品经理有必要让开发对他自己的任务进行拆解,可以按开发步骤、接口数、逻辑点拆解到天,直到无法拆解为止
  • 可能有人说,我没这个权力啊,我做不到让开发和我详细拆解任务,很多人确实没有,但问题还是要解决,可以好言好语、可以求助他人,反正是想尽一切办法来解决

判断估时第三步:经过前两步后,发现时长还是超,那只有砍掉一些不那么紧要的需求,按时交付永远比完美上线更有价值。

2. 任务估时难度判断

看逻辑:

    • 逻辑本身很简单,没有很多的判断(比如只是增删改查),功能也比较独立的,基本上评估1~2天是比较合理的,手脚快的可能半天就搞定了
    • 如果知识纯展示,从几张表中拉去数据,加一些简单的判断,前端的复杂度和交互相关,后端复杂度较低,基本上也就半天一天的事
    • 如果只是替换文字内容、图片、简单样式(颜色、大小等),哪怕页面比较多,也可以批量操作完成,可能繁琐但不复杂,可以在短时间内完成,属于举手之劳

看资料:

    • 一般有现成的接口文档和SDK的,实现起来也较为简单,花点时间研究下即可使用
    • 有通用组件的,且之前有功能实现过,如果变化不大可以直接使用

通用复杂度:

    • 兼容性问题会比较复杂,特别是一些不常用机型的的问题,有时还不好定位问题
    • 性能问题通常比较难,需要一点点的去分析找到性能瓶颈,并测试优化
    • 核心功能会比较复杂,尤其是要提供给很多模块使用的功能
    • 研究性的工作通常比较耗时,产品经理在做需求时,如果发现可能需要用到新的技术,可以提前和开发打招呼,让他们先研究起来,把耗时问题先前置解决

3. 沟通和提问

掌握一门知识,不是为了将别人比下去,而是让自己做事情更有章法和效率;

懂技术能让你在沟通时有底气,不会被人问倒,也能根据对方的回答提出合理的问题,大多数事情是可以通过面对面沟通解决;

我们在沟通时要“多认可、少讽刺”,尽量做到平等对话,有些直白的语言,换成另外一种话语,会换来意想不到的效果:

把“为什么做不了?”,换成“我想了解下具体原因?”或者“有没有其他的方法实现?”

把“这么简单的需求,要这么久吗?”,换成“我觉得这块时间有点久,能加快点吗?”

把“X,有bug”,换成“这里操作不了,看下是我哪里操作有问题吗?”

不轻易放弃,不接受模棱两可的答案,对开发说的内容不满意应该继续追问,直到拿到令你信服的答案;

产品经理为产品的最终结果负责,遇到问题,没有人会反过来替你想怎么解决,也不要指望问题能自动消失,能解决问题的只有你,懂技术只是手段,不是目的;

鼓足勇气、翻越障碍、高山登顶。

 

作者:周武,曾就职于腾讯、边锋,现在一家上市公司产品负责人;公众号:周武说