笔记 |「产品经理」必懂的技术(七)

一、技术词汇扫盲

1.打印:不同于普通人口中的打印,工程师的打印指的是程序的输出,具体是输出到命令控制台上,测试程序是否运行正确

2.写死:具体指的是本地技术实现方案;例如:设计一个下拉框切换不同的城市,技术实现方案有两种:

 城市数据储存在服务端,客户端通过数据接口获得列表显示在下拉列表中,优点是可以线上随时做出变动,比较灵活

 城市数据储存在客户端,直接从本地使用数据显示出来,这就是写死的方式,因为在本地不需要数据接口,也不能轻易的在线上做出变动

3.架构和框架:

 架构:对系统的结构设计和规划,类似于盖房子,你决定盖一个19层的大厦,并给出了设计方案

 框架:是利用现有的成熟技术简化开发的过程,类似于每一层楼怎么盖的都有成熟的经验可以借鉴

4.组件和控件:

 控件:产品的最小组成元素,产品都是文本框,按钮的等基础元素构成的,即控件

 组件:是多种控件的一种组合,来完成一个复杂功能,大部分产品底层都有几套组件模板

5.进程和线程:

 进程:一个正在运行的App或者EXE就是一个进程

 线程:是更小的执行单元,一个进程可以存在多个线程,例如微信是一个进程,发朋友圈是一个线程,语音聊天是一个线程,两个线程互相独立,各不影响,这叫做异步线程;同步线程是一个进程的子任务按一定顺序完成

6.脚本:

 脚本类似于拍电影的剧本,剧本里有剧情,剧组严格执行拍摄;而脚本里有对计算机的指令,计算机会严格按顺序执行

7.半量上线:

一种缩写,半量服务器面向全体用户上线,不是半量用户上线,好处是新产品有Bug切换到原程序所需时间比较短,切换惯性低

二、技术架构与技术思维

1.技术的基本架构了解
在这里插入图片描述
其中客户端研发又包括:Android、IOS、Web前端三类;

服务端又分为接口开发和数据库开发等,例如A给B发送微信消息,其流程是A发送到服务端然后再到B,服务端起到了中间处理的作用

黑盒测试指一般的功能性测试,主要模拟用户使用产品的场景进行全流程测试;白盒测试更进一步深入代码层次;测试有一套测试标准叫测试用例,其覆盖越全测试就越保险

运维:在开发和测试结束后,持续监控和优化系统的运行状态,对交付后的产品进行持续维护,出现问题时及时响应并处理

2.工程思维和产品思维

工程思维往往从实现需求的难易程度和系统的角度定义产品,它的弊端在于容易脱离需求的实际场景,脱离需求的用户价值,变得为了设计和设计,但一个需求的价值不在于它技术实现难度,而4x在于是否帮助用户解决了实际问题

入门产品经理往往具有功能思维,过于关注功能本身,忽略了业务目标和用户价值;而高级产品经理应该具有产品思维,在充分理解商业战略的情况下完成产品定义和产品设计,通过业务场景提升产品的可用性和易用性;

三、简单编程知识

我们为什么要学习简单的编程知识?

有助于我们与工程师交流和理解技术产品,工程师在和PM沟通中多多少少会使用一些技术语言,提前了解这些语言,可以降低沟通成本,拉近与程序员的距离

学习时该有的正确心态:在技术领域,其实编程并没有很难,只需要把规则结构化的背下来即可,放松一点,就像背诵小学课文一样掌握它~

什么是程序?

程序由数据结构和算法组成,简单讲数据结构就是数据组织和表示的结构,算法是对解决一个问题所需步骤的描述;

程序的最小执行单元是函数

函数包括输入、内部运算、输出三个流程;

常用的编程语言及其特点:

C、C++
非常底层的语言,程序运行速度很快,用途很广,后者强在可以面向对象编程

Java
可面向对象编程、兼容性好,用途很广从网站到安卓App

PHP、Javascript
用于Web和HTML页面开发

Python
语法简单,但是运行速度较慢,不如底层语言;优势是可以让使用者更加专注解决问题本身,而不是记住语言的使用规则

Objective-C、Swift
用于IOS系列的App开发

简单的数据类型:不同类型的变量可以相互转化

int(整型变量)
表示是整数,不能有小数点

float、double(浮点变量)
表示小数,

Char(文本变量)
表示文本,不同的编程语言有不同的显示方法;值得注意的是,我们平时填写在App和网页上的许多数字都是文本表示,如果后台需要对其进行数学运算需要将其转化为数字的变量

布尔变量
只有0和1;0代表false,1代表true

特别的,产品经理应该注意下固定字符和动态字符的组合可能需要用到字符拼接,这个时候PM可以特殊标记下动态字符,降低开发的理解成本

例如:我们在客户端看到的数字+文本的组合文字,就是数字变量在后台计算,得出结果后转化成字符型变量然后显示到客户端的结果
在这里插入图片描述
四、产品经理必备的数据知识

1.常见的四种简单的数据结构(对数据进行组织和表示的结构)

数组:最简单的数据结构,同一个数组只能存储相同的数据类型,可以理解成一个数组有从0到N个坑位,每个坑位又存有数据,通过调用数组名+坑位号就可以获得其中的数据

例如下图:A[0]可以找到a,A[1]可以找到b;
在这里插入图片描述
栈:类似一个只有一端开口的容器,先进后出
在这里插入图片描述
可以看到A是最先进来的,但是只能等C和B都出去之后才能可以轮到A出去

队列:先进先出,就和排队一样,早来早走,队伍的两头都是开口
在这里插入图片描述
树形结构:一个根节点可以衍生出下面很多子结点
在这里插入图片描述
产品设计案例分析:设计一个用户注册功能,第一步是设置用户的登录信息:包括账户和密码;第二步是填写用户的个人信息:爱好、性别、姓名等;其中涉及的数据结构如下:

栈结构:利用栈结构实现页面的跳转,只有完成第一步设置完成,才可以进入到第二部的个人信息设置

数组结构:一系列个人信息构成了一个字符型的数组结构

树状结构:微信首页底下有四个模块,这是由一个根节点控制的四个子节点,可以相互切换,同时每个子节点还有很多子节点

2.数据库基础

数据库定义:数据库运行在服务器中,我们可以对其进行增、删、改、查等工作,目前主要有两种数据库:关系型数据库和非关系数据库,前者运用更广泛,MYSQL就是其中之一

关系型数据库:数据库中有不同的实体,实体之间可以产生某种联系,或者说某种关系,每一个实体都有一个唯一的ID来进行定位,叫做“主键”;常见的数据库有MYSQL, SQL SERVER,ORACLE

例如:人是一个实体在数据库中,其中有爱好、性别,职业等属性;但性别也是作为一个实体存在,有男女等属性;两个实体具有一定的联系;

这种关系可以是一对一,也可以是一对多,多对多;例如人的性别只能有一个,就是一对一的联系;

人可以有多种职业,职业是一个实体,两个实体发生了一对多的联系;

当然这种关系也可以是多对多的,比如商品和订单这两个实体,在数据库中,一个订单可以有多个商品,一个商品也可以存在于多个订单

数据库操作语言:SQL,我们利用这个语言编程和数据进行互动,进行增删改减等操作

非关系型数据库:常见有 MongoDB和CouchDB等

此种数据库只能实现一个简单的键值对应关系,通过调用某一个键,得到一个对应的值;例如通过输入peopleID可以得到001

数据储存和数据恢复

数据储存过程分为两步,第一在索引区建立索引,第二在把数据储存在数据区;删除只会先删除索引,数据并不会立刻被删除,所以恢复索引关系即可回复数据

互联网产品设计的删除一般都是假删除,先标记数据成为删除状态,用户恢复时标记为正常状态即可,当然超过一定时限会进行物理层面的真实删除

工作场景

当产品经理设计一个新功能时,工程师可能说这里有的字段数据库内不存在,或者这个功能导致了现有数据库结构的改变;这个时候产品经理应该考虑两个方面的问题

第一:新的设计应该调整数据库结构还是删除相关字段?

第二:考虑数据兼容性的问题,为了迎合新功能做出的改变会导致老功能受到何种影响?

3.产品经理须知的数据分类

技术视角的数据的分类:

结构化数据:按照固定的格式储存的数据,好比我们按照格子一个一个放数据;

非结构化数据:是对零散的数据进行集中化管理,好比在一个格子里放了很多东西

通过分析结构化数据,我们可以得到数据趋势,预判未来风险;比如说淘宝商品有一些固定属性是结构化数据,例如销量,我们通过过往销量就可以大致分析未来的销量

通过分析非结构化数据,我们可以进行一些行为分析和相关推荐;例如浏览记录是非结构化的数据,我们发现用户的浏览记录经常覆盖工科类书籍,那我们就可以推送更多的相关数据,提高关注度和成交率;

产品视角的数据分类

用户数据:用户相关的数据,如DAU/MAU、新增用户、留存率。

行为数据:用户使用产品产生的一些动作相关的数据,如PV、UV、转化率、访问时长等;

UV(UniqueView): 独立访问数,每一个独立的IP地址仅被记录一次

PV(PageView):页面访问数,一个用户的多次访问都会被记录

业务数据:实际产生的代表业务价值的数据,如 GMV、付费人数、付费转化率、付费频次等。

五、产品经理必备的客户端技术:一般指PC、手机、平板三端

1.工作场景:

产品经理工作时需要绘制产品原型,需要利用控件对界面进行布局,这个时候工程师可能会说这个View的位置可能会影响到某某控件,或者某某控件系统并不存在需要自己写,对于不懂技术的产品经理听完后无疑一团雾水

定位问题是否发生在前端?是否需要客户端的同学协助进行解决?如果BUG出现在服务端,PM却去寻找客户端的同事解决问题,则会降低很多工作效率

安卓的工程师和IOS的工程对同一个东西会有两种表述,可能会导致产品经理听了一头雾水

大致理解一下客户端的整体实现方式,即通过不同控件之间的组合实现了前端的显示效果

2.安卓和IOS客户端常用控件五种控件对比
![在这里插入图片描述](https://img-blog.csdnimg.cn/c98acab136fa4c88b6acf76d3da4ed46.png3.Web技术基础:

域名:我们访问的网址其实是服务器的IP地址,例如:http://109.102.22.1,但是由于这串数字比较难记忆,于是我们用http://baidu.com来代表IP地址

URL:UniformResource Locator,统一资源定位符;互联网上的所有资源像图片和语音等都有自己的唯一地址,URL由三部分构成,例如:“http://www.xxx.com/aa/bb/c.png”

第一部分是超文本协议:HTTP协议,意思是我们可以传输出了文字文本以外的资源

第二部分是域名或者服务器的IP地址:网站所有的资源都在主站的域名下

第三部分是资源的具体路径:也就是域名斜杠后面的部分,规定了资源的具体路径和名称

4.Web App和Native App:
在这里插入图片描述5.Cookie和Session:

日常上网我们常用到,功能都是保存用户信息,前者保存到本地,后者保存到服务器;想象一下我们登录淘宝网购物,当换一个电脑时,账户密码需要重新输入,但是我们的购物习惯还保留,系统会推荐一系列商品,因为账户密码通过Cookie技术保存在本地,更换电脑即消失;而购物习惯通过Session保存在服务端;

另外有一个Cookie的有趣例子:常常我们使用A公司的产品留下本地Cookie记录,B公司通过访问本地Cookie,了解你的搜索结果,精准推送广告;比如你百度搜索汽车,微信通过Cookie发现后就会在朋友圈投送小鹏汽车的广告~

六、产品经理必懂的服务端知识:也常被叫做后端和云端

一般来说服务端的技术难度会高于客户端,开发们常用PHP和Java进行卡开发,主要包括接口开发和数据开发两种;无论使用哪种语言进行开发,服务端的核心目的都是接收并处理运算客户端的请求,将处理后的请求发送至客户端

后端因具有逻辑运算的功能,常常因为算力过大而崩掉,这就是我们常说的服务器蹦了,就是所谓的后端出了问题,因此良好的后端技术架构是决定产品后期表现力的关键;双11,618等节日直接考验着各大电商的后端承受力;

1.涉及的业务场景

对服务器有基本的了解

了解上线的基本流程

了解每一次产品发布的流程,提高PM对产品全局把控的能力

2 一些基本定义:

接口 = API:是服务器的一部分,负责接受数据,进行内部处理,并发出数据;如果想把A业务的数据传输到B业务,那么有两种方式;A可以开发一个传输接口给到B,或者B开发一个接受接口给到A;实际工作中谁想要数据或者说谁有求于人谁就来做开发

灰度测试:上线前的测试,选取小范围用户进行测试功能,发现问题并改进,如无问题则全量发布

AB测试:按用户维度进行划分测试,对全量用户发布,不同用户收到的功能不同,然后收集不同的数据反馈,从而判断不同版本功能的优劣

3.服务器和客户端的数据交换有两种数据结构

Json结构:下例代码为例,Json结构主要由键值两个部分组成,冒号左边的是键,右边的是值,值是要传输的数据

{

“username”:“ryan”,

“password”:“123”

}

XML结构:例如“〈name〉中国〈/name〉“,前一个name是标签头,后一个是标签尾,中间的“中国”是传输的数据

4.如何判断服务器是否出现在服务端

前端显示“服务器异常”、“数据异常”、前端不显示数据等

七、如何与工程师正确沟通?

沟通时的一些注意要点:

尽量用第三人称描述问题,保持客观公正

多用我们,而不是你和我(这些词会潜意识把PM和开发对立起来);比如我们一起看一看这个问题;少用我觉得,我认为

沟通前一定要熟悉产品设计的每一处细节,这样你才能时刻为产品代言,要明确自己为什么这么设计,其后背的原因需要很清楚;工程师的技术思维很少去考虑用户价值,可能会推荐产品经理修改需求从达到技术实现难度更低的目的,但PM应该明白产品设计背后的用户价值

不要轻易说BUG,在工程师的世界中这是一个贬义词,意味着他写的代码出了某种问题

驱动技术团队的方法:

首先明确一点:我们PM没有任何行政权力,类似于大领导的外部命令式、管理式的驱动是行不通的,这就需要我们点燃团队其它人内部激情,使其变得内部驱动,具体包括三个方面:

思想领导力:想要驱动团队和领导团队,光靠和大家打好关系可不行,还要依靠深刻的独立思考,对产品的战略定位深入理解,对产品的方向和原则有清晰的认知,明确知道该做什么,舍弃什么

行动领导力:意味着快速行动和拥抱变化,它的本质是带头冲锋,从行动上带领组织快速破局,实现办法是更加积极主动、勤奋努力的工作吧

团队领导力:不是通过实力和地位发出命令驱动团队,而是利用愿景驱动团队,这更难做到,但是也更有效,因为愿景驱动的团队对比机械执行的团队更具有创造力;因此产品经理应该能够清晰的描述愿景,并给出实现路径,不断重复,使团队相信并认可。

  • 4
    点赞
  • 40
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值