这周加班很多。Jpass项目上线，金牛项目的技术方案终于敲定下来了，算是有了重大突破和飞跃。关于自我的思考也有很多。这段时间对自己的感觉一直不太好，问题核心其实还是在于自己的成长，产品经理必须成为整个团队里成长最快，责任心最强的那个人。本周开始写周记，希望自己可以一直保持思考，保持成长。
一、本周收获：
1.数据型产品字段设计：
之前很少涉及到数据型产品的设计，网上的相关资料也相当少。现在接手商家对账产品，才开始接触数据型产品设计这件事情。
（1）一个好的数据逻辑设计方案应该包括这两部分：
a.数据字段需求：在这个场景下，用户是如何使用这个产品的，在这个过程中，他们会用到哪些数据；
b.这些数据分别在哪些系统，系统和系统之间如何通过一对一的关联关系对应起来。
写出一个好的数据逻辑设计方案主要包括以下几步：
第一步：理清楚大致的数据需求。按照需求定义完产品功能后，列出每个产品功需要包含的数据字段。
第二步：找到我们所需要依赖的数据表，理清表结构和各字段的含义。对于一个小公司来说，产品经理可能很清楚每个表包含的数据和字段含义。但是对于一个大公司来说，上下游系统相当之多，每个字段在系统之间交互的时候，可能已经被重新赋值，同字段名但是字段含义完全不同；可能不同字段名，但是代表了相同的字段含义。所以，梳理各系统的数据表相当重要，如果这一步没有做好，后期可能会形成大坑，研发分分钟想拿刀砍死产品经理。
需要特别注意一下这几点：系统间关联的字段需要校验一下，是否的确是相同字段；包含了枚举值的字段，需要明确包含哪些枚举值；涉及到时间的，需明确时间点在何时写入，何时更新。
第三步：将各系统字段分成三类：a.各系统间关联所需字段；b.我们需要关心的字段；c.我们不需要的字段。将前两类字段整合起来，就成为了如下的数据逻辑模板。
第四步：按照我们梳理出的逻辑，筛选几条测试数据，按照逻辑走一遍，进行排查。这步很重要，特别是涉及上下游诸多系统时，容易出坑，很可能会在研发过程中发现数据之间对不上。
最后，将这些进行整合，产出我们的最终版数据逻辑方案，交付给可爱的研发小哥哥。
2.产品规划：
前段时间好像一直在整理产品规划，用于跟各路老大汇报。PPT写了一版又一版，汇报作了一次又一次，但仍然觉得自己对于产品的思考浮于表层，没有深入肌理的思考。
今天看到一个同事的周报，突然觉得豁然开朗。她将产品按照不同的能力维度进行规划，每个能力维度设置指标，再落实到为了实现该指标，需要具体执行的事情（也就是明确了产品的功能点）。接下来，将功能点整合为迭代周期，大概按照2周-1个月左右的节奏来进行。此外，每个迭代周期产出一个用户故事地图，用户故事再关联详细的PRD。
通过这样一个路径，将产品真正从飘在云端的想法，变成了一个具体可实现的方案。在这个过程中，足够做到让老大可以了解我们在做什么；让相关需求方知道我们的规划是什么；让研发和测试知道他们为什么要做这件事情，以及功能如何实现。
具体操作步骤如下：
第一步：能力维度拆解
从哪些能力维度进行拆解，没有一定之规，具体的拆解办法需要按照团队现状和产品目标来定。
微信支付团队曾经将需求按照基础能力和高级能力，划分成了可用性、更加体验、可扩张能力、生态，形成了一个金字塔结构。如图是微信支付团队所做的拆分。
也有些情况下，在我们对标竞品的时候，会将我们和竞品之间的能力按照不同的维度来区分，并形成一个产品方向。
或者我们通过用户研究，收集到了用户需求，对其进行分类整合，抽象成几大能力维度。
第二步：设置指标
做产品必须知道，我做的这些事情可以带来什么产出，并且及时提醒自己，是否需要调整方向。对于C端产品来说，数据指标的选择相对容易，B端产品和后台产品可能相对困难。
第三步：功能点拆解
将实现目标落实到具体可以做的事情上：做到了哪些，可以实现这个目标呢？
第四步：规划迭代周期
产品迭代周期需要掌握一定的节奏，一般来说，2-4周是一个比较合理的推进速度。
第五步：产出用户故事
第六步：产出PRD
二、本周问题及改进措施
1.对产品方案和边界思考不细致——产出测试用例，用更加边界化的方式来思考
2.项目进度掌控问题：让研发和测试更早介入，尽早发现方案风险点
三、本周其他思考
1.与人沟通上，有问题要及时沟通，了解对方的真实想法；
2.带团队上，要顾全大局，共同带来团队的好结果，同时要保护好自己的业务方、测试和研发，在其中起到沟通协调作用，尽量减少其他各方的压力；
3.与其他人沟通上，必须要做到邮件、消息日清，自己不能解决的问题，也要及时交给相关人员解决，不能影响其他团队的进度；
4.一定要随手记录待办事项，减少心智资源的占用。
网友评论