[西安|内门弟子]PM-谭华杰|2019年09月02日的日报-技能树.IT修真院

发表于： 2019-09-02 21:53:42

1 413

今天完成的事情：（一定要写非常细致的内容，比如说学会了盒子模型，了解了Margin）

一、了解金融产品和电商产品订单模块的区别：

首先来看电商产品当中订单的作用，

（1）订单是用户的交易信息记录汇总，显示此笔交易的主要信息（下单时间、状态、金额、收货信息等），作为交易凭证。

（2）显示订单状态：交易过程中，订单可能产生的过程及状态，如下6类常见订单状态：

待付款：下单后的用户，订单生成，在此状态未收到付款请求时，状态不变。
已付款：订单收到第三方传来的付款成功token数据时；
待发货：在经过风控规则线上和线下的审核后，综合给出等待发货的状态；
已发货：物流反馈的已发货数据后，订单状态为已发货；
待收货（查询物流状态）：接入第三方物流平台的实时数据；
已完成：订单完成，用户可评价，或者获得积分。

（3）电商的订单在不同状态下支持不同的处理，待付款的订单支持随时取消，而收货之前的订单都支持退款，收货之后的订单支持退货退款，同时卖家可以编辑订单信息，修改错误的收货信息等

金融产品的交易通常是以交易记录来显示交易信息的，交易状态来看的话不存在电商产品这么多的状态，只有购入和卖出两种，期间可能存在份额确认等状态，但是一旦用户付款成功后，这笔交易的信息和状态就无法再更改了，只有通过卖出的形式赎回资金，不需要订单显示过多的状态也不支持退款（活期退款就是卖出，定期产品不支持提前赎回），同时金融产品的每一笔交易都是建立在实名认证基础之上，不存在代买的情况，不需要在订单上修改信息，所以金融产品通常不需要订单

二、了解了一个问题：为什么支付宝以及其他应用在绑卡开通快捷支付的时候发送的验证码不是来自银行而是来自应用？

在支付宝想绑定我的卡时，银行应该以自己为落款方，给我发一条短信，告诉我支付宝提交了我的姓名身份证以及预留手机号，现在银行把验证码发给你，如果你把验证码给了支付宝，支付宝给了我，我就确定你允许支付宝扣你账户的钱。

不过那个落款方写成支付宝也不代表是支付宝给我发的短信，只是告诉我现在是支付宝在申请授权能划扣我的资金。不然支付宝如果不需要我填写短信就已经知道验证码内容，那相当于是否通过授权的决定权已经提前下放给支付宝了，感觉不妥

三、了解老大说任务五应该做一个分类，这样逻辑才好捋清楚

基本功能

校验功能

安全体系

错误提示

体验优化

四，看了给产品经理讲技术资料，突然联想到需求表的思路很类似

我们一般是把需求表当成一个房子，而之中的模块不是拆成房间，是按照材料来分，这个时候我们可以的逻辑思路应该可以按照分布式的思路来做

但是它们之间事彼此有联系的，它们的联系要通过入口来维持的，而顺序可以按照页面来走下去

五、学习五要素的调研分析方法

1、五要素在我的理解里面，可以从产品的需求产生开始，需求产生，进行市场调研，得出产品的定位和用户的主要需求，这是战略层；

2、当我确定我要做这个产品之后，我开始考虑里面应该有什么功能，比如说知乎，战略层上想把它做成一个问答社区，那范围层我应该考虑问答社区需要包含什么，提问、回答、收藏、评论、赞同、反对等等，还有一些是限定内容范围的，这都是范围层需要考虑并确定的东西；

3、当具体开始考虑某些功能之后，我必须分清楚哪些功能是大模块，优先级高，我应该把它放在首页，那这个大模块下又应该包括哪些小模块，理清层级结构，比如说专业人士的问答和一般用户的问答应该是归属于不同类别的，而一般用户的问答也应该按照话题不同划分为不同的类别，每个类别下都有哪一些内容，这样分层的话如果有个用户要寻找一些消遣时间的问答，就会去一般用户的问答类别里找而不会进入专业人士的问答列表；

4、确定层级之后开始研究具体的页面排布，比如PC端用户浏览最先看到的是左上角，那么顶部和左侧栏也许可以放一级导航，知乎的问答内容很多，用户搜索的需求比较大，那就把搜索框放在首页顶部，用户进入APP马上就能看到，具体页面的布局就是框架层需要考虑的东西；

5、最后就是表现层，表现层几乎都是UI的工作，文字颜色，图标怎么画，用什么主题色，这种第一视觉上的东西就是表现层的内容。

在我看来目前的任务就是先通过调研倒推产品用意，然后在自己画原型图的时候又从正向的角度重新思考，针对某一个功能模块设计也必须从根本目的出发，这是我的理解

明天计划的事情：（一定要写非常细致的内容）

整理整合真实项目的资料

继续看师姐日报

遇到的问题：（遇到什么困难，怎么解决的）

暂无

收获：（通过今天的学习，学到了什么知识）

做个搬运工

一、流程图，泳道图赛高

流程图以描述对象分类，包括：业务流程图、页面流程图、功能流程图、数据流程图等

业务流程图（Transaction Flow Diagram, TFD）

抽象地描述事物进行的次序和顺序，不涉及具体操作与执行细节。在互联网软件行业通常指脱离产品设计的用户行为流程。

首先抛开限制条件，只画极简流程

以购物为例子：

以上的三步组成了一个最简的一个流程，其完全涵盖了任何购物行为的核心。无论是网购还是在实体超市，都是以这三个行为为主体，然后进行扩展的，整理出主干后再依据上面的最小流程单元进行扩展

页面流程图（Page Flow Diagram）

定义：指电子产品具体所呈现的页面跳转流程图。其承载了业务流程图所包含的业务流转信息。

还是以购物为例（淘宝）：

由上图红框中的三个节点我们可以看出，页面流程图依然是包含在业务流程图的。相较于一开始的极简流程图，现在的流程图已经渐渐变得复杂了一些。我们将抽象的业务，映射在了具象的页面上，用软件的页面承载起了业务需求。而以上就是由业务流程图到页面流程图的转化过程。

功能流程图（Function Flow Diagram）

定义：指单页面内或多页面之间的功能操作流程，其包含在页面流程中。

任何功能都是被包含在页面内的，但一个页面内往往不止一个功能，所以单单页面流程图可能无法完整表达所有流程，而这时就需要用功能流程图来更加具体表达每个页面内所包含的功能。

由上图红框中的四个节点我们可以看出，功能流程图同样也是由页面流程图拓展而来的。功能流程图是在页面流程图的基础上继续深化，变得更加复杂。

数据流程图（Data Flow Diagram）

定义：特指软件产品中，描述数据在不同节点被处理的过程所画的图表。主要表达计算机程序对于业务的实现原理。用户在功能流程图中的每一个操作，对应都会反映在数据流程图中。同时，数据流程图也可以叫程序流程图（Program Flow Diagram）。

它是一种能全面地描述信息系统逻辑模型的主要工具。它可以利用少数几种符号综合的反映出信息在系统中的流动、处理和存储的情况。数据流程图具有抽象性和概括性。

可能业务流程图、页面流程图和功能流程图大家都耳熟能详，但数据流程图恐怕了解的就比较少了。其实，每个流程图中都有一个核心伴随着不同操作在整个系统中不断流转。比如业务流程图大多以人为核心，每个节点都是在传递人的不同行为。而页面流程图和功能流程图也类似，都是以人的操作行为为核心，在不同页面和功能间进行流转。但数据流程图不同，它是以数据为核心，展示整个系统中，数据是如何被处理的。

其更偏技术思维，更多的是展现后台程序的实现原理。所以，常常是开发人员绘制此图，而产品经理涉及较少。但随着产品经理地不断成长，向上提高到战略层，而向下则会深入到实现层。理解程序的开发原理和背后的数据流转，无疑会让产品经理对产品设计有更加深刻的理解。

下面仍以购物流程为主题来展示数据流程图。

相较于之前的图表，数据流程图增加了新的维度——程序。客户端在展现用户操作行为的同时，也表达了程序在用户行为背后的动作。而往往大家说一个产品复杂的时候，可能只注意到了它的前端交互复杂，而忽视了后端逻辑的复杂。对于一个优秀的产品经理来说，不止要关注前端的用户体验，更要能看清事物背后的逻辑。

流程图的颗粒度，其实就是指流程图的细致程度。

我在画流程图时也常常会犹豫纠结，这个功能点用不用描写得更详细？这条分支用不用标出来？这个和服务器的交互事件用不用在流程图体现？等等这些问题，也都是产品经理在日常画图时会遇到的。

依然拿购物流程为例，最简的业务流程分为三个步骤，那如果细化一些，是否可以画出不同的流程图呢？

显而易见，即便针对同一个流程，也能画出不同的流程图。如上图，将挑选商品拆分为三个步骤，将结账拆分为两个步骤。但两个流程图依然表达的是一套流程。而这就是每个人对于颗粒度的把握有所不同。有很多新人总想一步到位，一次画出完美的流程图。但这其实是一种非常不可取的思维。任何完善的流程图，都需要经过由简单到复杂的过程，而不是一蹴而就。

理论上来说，流程图的细致程度越高，产品设计就越准确顺畅。但实际情况中，过度的详细反而是浪费时间。而对于度的把握能力，则需要经验积累以及团队磨合，这里也是体现产品经理对颗粒度把握能力的地方。我们画流程图的最终目的是让团队成员理解我们的产品设计，而不是需要画一幅非常详细的流程图。理想的情况应该是以最简的形式，画出团队都能理解的图表。

泳道图

泳道图是流程图中的一种画法，是将流程图中的一些流程节点按操作角色的不同而划分。比如刚才的数据流程图其实就采用泳道图的画法展示，其中顶部为两个不同角色——用户和服务器。同时在竖向的基础上也可以添加横向泳道，以不同页面来给操作分类。

对于涉及到多角色比较复杂的流程图来说，画泳道流程图会看起来更加清晰明了。

作者文章里还有摩拜和ofo的流程图案例，附上地址：

http://www.woshipm.com/pd/818876.html

二、敏捷开发

了解了一下有关敏捷开发的看板

（1）基本概念

a.适合采用看板开发的场景

需求总量大，团队资源不足

需求变动频繁，需要团队快速应变

需求相对分散，不需要大规模协作

团队整体素质高，能够独立推进项目

b.看板开发三要素

可视化

信息可视化 - 重点突出，信息辐射，影响力

规则可视化 - 明确，丰富，渐进，全员了解，合作方了解

在制品限制

团队维度

个人维度

管理流动

拉取系统

周期时间

持续改进

c.特点

不断找BUG，促进团队自我反思，持续改进

强调团队成员的独立思考能力与全局观

（2）看板基本形态

这个表格有 5 列：Backlog（原始需求）、Selected（被选中的需求）、Develop（开发阶段）、Deploy（部署阶段）、Live（上线阶段）

其中 Develop 阶段包括 2 个子阶段：Ongoing（进行中）、Done（已完成）

包括 3 中角色：产品经理（红色小人）、开发人员（蓝色小人）、部署人员（绿色小人），还有项目经理贯穿于始终，不在此图显示。

在 Backlog 中放置了许多小卡片，它们在 Kanban 中被称为 WIP（Work In Process，在制品）。对于产品经理而言，WIP 是需求，而对于开发人员与部署人员而言，WIP 却是任务。

实际这些 WIP 卡片上都带有一些文字描述，包括：标题、描述、优先级等信息。

需要注意的是，Selected、Develop、Deploy 下方有一个数字，该数字表示此阶段中最多可以放置的 WIP 数量。例如，在 Selected 中最多只能放 2 个 WIP；在 Develop 中（包括它的子阶段）最多只能放置 2 个 WIP。这里的数字只是一个示例，具体多少可根据团队实际情况而定。有一个经验公式可以参考“WIP 上限 = 团队规模 * 2 - 1”，减 1 表示大家需要协作，例如：4 人的团队，WIP 上限是 7。

对于多个项目而言，可以在这张表格中添加更多的泳道（行），每一行相当于一个项目，所有的项目进度清晰明了。

（3）使用看板流程

产品经理挑选了 2 个 WIP 到 Selected 中，此时，由开发经理决定该任务的技术难度，并由项目经理将任务分配到指定的开发人员，也可将同一个任务分配给两个人，让他们去结对编程。

开发人员（架构师与程序员）可对 Selected 中的需求进行工作量评估，可采用投票的方式进行，最终给出一个合理的评估值，整个估算过程，项目经理无需参与，主要是开发人员共同完成。

开发经理可以对任务设置一个“分值”，这个分值可直接影响到后续的绩效考核，所以对大家来说，这个分值是公开可见的，谁做的多，谁做得少，一目了然。当然，开发人员也可以主动承担具有更具挑战的任务（为了锻炼自己，也为了多拿点钱），但任务分配的决定权始终在项目经理手中。

现在假设 A、B 两个任务已经分别被不同的开发人员处理了，那么这些任务就应该移动到 Ongoing 中，同时，产品经理可以从 Backlog 中挑选出 2 个优先级较高的需求到 Selected 中。这样就保证 Selected 与 Develop 都达到了 WIP 的上限。

有人已经把 A 做完了，那么 A 就可以移动到 Done 中了。随后，部署人员就可以开始干活了。

部署人员就可以将 A 从 Done 中移动到 Deploy 中，表示部署人员正在做这件事情。同时，做完了 A 任务的开发人员可以再做其它新任务，只需从 Selected 中移动到 Ongoing 中，移动这件事情不是开发人员随意操作的，而是有项目经理负责的。产品经理发现 Selected 中只有一个 D，就可以考虑放入一些新的需求了。