这周加班很多。Jpass项目上线，金牛项目的技术方案终于敲定下来了，算是有了重大突破和飞跃。关于自我的思考也有很多。这段时间对自己的感觉一直不太好，问题核心其实还是在于自己的成长，产品经理必须成为整个团队里成长最快，责任心最强的那个人。本周开始写周记，希望自己可以一直保持思考，保持成长。

一、本周收获：

1.数据型产品字段设计：

之前很少涉及到数据型产品的设计，网上的相关资料也相当少。现在接手商家对账产品，才开始接触数据型产品设计这件事情。

（1）一个好的数据逻辑设计方案应该包括这两部分：

a.数据字段需求：在这个场景下，用户是如何使用这个产品的，在这个过程中，他们会用到哪些数据；

b.这些数据分别在哪些系统，系统和系统之间如何通过一对一的关联关系对应起来。

写出一个好的数据逻辑设计方案主要包括以下几步：

第一步：理清楚大致的数据需求。按照需求定义完产品功能后，列出每个产品功需要包含的数据字段。

第二步：找到我们所需要依赖的数据表，理清表结构和各字段的含义。对于一个小公司来说，产品经理可能很清楚每个表包含的数据和字段含义。但是对于一个大公司来说，上下游系统相当之多，每个字段在系统之间交互的时候，可能已经被重新赋值，同字段名但是字段含义完全不同；可能不同字段名，但是代表了相同的字段含义。所以，梳理各系统的数据表相当重要，如果这一步没有做好，后期可能会形成大坑，研发分分钟想拿刀砍死产品经理。

需要特别注意一下这几点：系统间关联的字段需要校验一下，是否的确是相同字段；包含了枚举值的字段，需要明确包含哪些枚举值；涉及到时间的，需明确时间点在何时写入，何时更新。

第三步：将各系统字段分成三类：a.各系统间关联所需字段；b.我们需要关心的字段；c.我们不需要的字段。将前两类字段整合起来，就成为了如下的数据逻辑模板。

第四步：按照我们梳理出的逻辑，筛选几条测试数据，按照逻辑走一遍，进行排查。这步很重要，特别是涉及上下游诸多系统时，容易出坑，很可能会在研发过程中发现数据之间对不上。

最后，将这些进行整合，产出我们的最终版数据逻辑方案，交付给可爱的研发小哥哥。

2.产品规划：

前段时间好像一直在整理产品规划，用于跟各路老大汇报。PPT写了一版又一版，汇报作了一次又一次，但仍然觉得自己对于产品的思考浮于表层，没有深入肌理的思考。

今天看到一个同事的周报，突然觉得豁然开朗。她将产品按照不同的能力维度进行规划，每个能力维度设置指标，再落实到为了实现该指标，需要具体执行的事情（也就是明确了产品的功能点）。接下来，将功能点整合为迭代周期，大概按照2周-1个月左右的节奏来进行。此外，每个迭代周期产出一个用户故事地图，用户故事再关联详细的PRD。

通过这样一个路径，将产品真正从飘在云端的想法，变成了一个具体可实现的方案。在这个过程中，足够做到让老大可以了解我们在做什么；让相关需求方知道我们的规划是什么；让研发和测试知道他们为什么要做这件事情，以及功能如何实现。

具体操作步骤如下：

第一步：能力维度拆解

从哪些能力维度进行拆解，没有一定之规，具体的拆解办法需要按照团队现状和产品目标来定。

微信支付团队曾经将需求按照基础能力和高级能力，划分成了可用性、更加体验、可扩张能力、生态，形成了一个金字塔结构。如图是微信支付团队所做的拆分。

也有些情况下，在我们对标竞品的时候，会将我们和竞品之间的能力按照不同的维度来区分，并形成一个产品方向。

或者我们通过用户研究，收集到了用户需求，对其进行分类整合，抽象成几大能力维度。

第二步：设置指标

做产品必须知道，我做的这些事情可以带来什么产出，并且及时提醒自己，是否需要调整方向。对于C端产品来说，数据指标的选择相对容易，B端产品和后台产品可能相对困难。

第三步：功能点拆解

将实现目标落实到具体可以做的事情上：做到了哪些，可以实现这个目标呢？

第四步：规划迭代周期

产品迭代周期需要掌握一定的节奏，一般来说，2-4周是一个比较合理的推进速度。

第五步：产出用户故事

第六步：产出PRD

二、本周问题及改进措施

1.对产品方案和边界思考不细致——产出测试用例，用更加边界化的方式来思考

2.项目进度掌控问题：让研发和测试更早介入，尽早发现方案风险点

三、本周其他思考

1.与人沟通上，有问题要及时沟通，了解对方的真实想法；

2.带团队上，要顾全大局，共同带来团队的好结果，同时要保护好自己的业务方、测试和研发，在其中起到沟通协调作用，尽量减少其他各方的压力；

3.与其他人沟通上，必须要做到邮件、消息日清，自己不能解决的问题，也要及时交给相关人员解决，不能影响其他团队的进度；

4.一定要随手记录待办事项，减少心智资源的占用。