时间: 2021-07-30 09:14:22 人气: 4 评论: 0
作为刚转行成为产品经理的1年新人，笔者将分享在产品设计中踩过的那些坑，给入门的新人一些提醒。
上一篇《数据分析产品设计中，有哪些坑需要注意》，已经从需求分析到需求设计，再到开发及测试，对整个工作流程中的大坑有了一个大致的介绍。
本次主要是笔者从指导技术进行开发以及在平台上线的实际运行过程中发现的一些问题，进行反思，分析产品设计工作中应该注意的一些坑。
笔者为某政府设计打造的数据分析产品，独立于他们的业务办理系统的（业务系统共有10+套，都是不同的厂家建设），不生产数据，只消费数据。
数据分析产品中所有的数据来源均来自于各个业务办理系统，对于这些数据，数据分析产品只做3件事情：业务数据关联展示、数据关联分析统计、数据关联分析风险识别。
以下将举3个例子来说明产品设计中应该遵循的设计原则。
现象
在产品上线使用之后，客户在验证业务数据的准确性的时候，发现数据产品中的业务关联展示数据，与实际的业务办理系统中的数据存在出入，数据相差幅度大约有30%～50%。
由于数据维度很多，这里仅举例其中一个数据维度即可。如A类性质的案件数量，在业务系统中有500件，但在数据产品中，展示出来的A类性质的案件数量仅有300件左右。
分析
根据问题现象，笔者主要从由表及里进行了分析:
1）从表象层数据查询维度进行分析，主要是梳理查询的过滤条件。
业务系统中的过滤条件是A、B、C三种，但是在数据产品中的过滤条件却是B、C、D。笔者从这个维度找到了原因之一，但不确信是否是根本原因。因此在此处需要做假设验证——如果过滤条件一致，即排除C和D的过滤条件的数据差异（可以大概估算），数据产品和业务系统中的数据差异数量。
笔者发现至少还相差了20%左右，因此笔者认为还有更深层次的原因。
2）从里层，即数据层，主要梳理源数据的情况。
根据业务系统的过滤条件，笔者找到开发直接在数据库进行过滤查询，对比分析数据情况。
从这个维度，笔者发现了两个原因：
结论
由此得出的对产品设计的两点思考结论：
一是数据分析产品尽量要保证基础源数据的规则不变，如过滤条件等（也就是数据的统计规则以及查询习惯需要跟业务系统的数据统计规则和查询习惯保持一致）。
二是要分清楚数据分析产品的风险识别是风险识别，业务数据是业务数据，千万不要把风险识别的数据混合在业务数据中进行产品设计，这样开发在建立数据清洗规则的时候，有很大可能**存在问题。因此我们的第一原则就是保证业务系统中的数据，原汁原味清洗到数据分析产品中来。
现象
某政府的业务办理涉及多个系统的衔接，链接起来就是一个完整的业务办理流。数据产品的开发过程涉及多家公司的数据对接，每家公司的数据规则都不同，所以做数据关联分析的困难可想而知。
目前上线的产品，只有弱关系关联展示，而客户希望展示强关系关联分析展示。
举例说明：
当前的业务办理分为A、B、C、D四个环节，每个环节的系统不一样。
当前上线的数据产品，在业务办理的流程关联展示的过程中，只是从宏观的层面分析A环节的A1、A2、A3….各类不同的业务流向的数据量大小，其中A2类和A3类是流向B环节的业务数据。
在B环节的的所有业务被清洗为B类业务，又展示B环节的B1、B2、B3…..各类不同的业务流向的数据量大小。这里是无法关联上某一起案件，在A环节流向B环节的业务流向的。而此需求也是客户的痛点。
分析
根据问题现象，笔者主要从数据结构和数据内容进行了分析。我们的核心诉求就是A类系统中的案件要和B类系统中的案件一一进行对应。因此围绕此核心诉求，通过定型分析和定量分析来确定强关联的方式。
由于没有唯一一个键值进行关联，因此需要从多个维度来确定一一关联的关系。笔者通过2个系统的数据内容进行对比分析，发现两个不同系统的数据字段不一定相同，但数据内容是一致的，得出A、B、C、D…几个字段内容都一致。
筛选方法，需要考虑到系统性能和算法，尽可能得减少计算消耗。因此确定B、E、F三个字段来进行一一对应关联，查找顺序按照B、E、F的顺序进行筛选查找。最后通过定量分析来验证强关联的准确性（在这里需要特别说明，如果有一条数据的关联不对，那么就需要推翻重新建立关联法则）.
结论
由此得出的对产品设计的思考，在数据分析中，由于往往**涉及到业务流程的数据分析，因此一般由浅入深都有两类展示原则，分别是弱关系和强关系。
在本产品设计中，强关系建立之后，**在数据库表中，建立唯一关联字段进行清洗;并且还需要在表中建立更多的字段，来表示在不同系统中的业务状态（这个时候，字段内容可以由产品经理根据业务情况进行自行定义）。以便在本产品中提高产品的关联分析能力，提高系统性能和数据的可靠性。
现象
数据产品分析中最核心的是风险识别，产品中对于风险主要有3类风险：是否违反规定时限、是否违反规定流程动作、是否违反政策法规。
此处仅举例其中一类风险说明，比如违反规定时限。
客户在使用系统的时候，验证A类业务的办理时限风险数据，发现至少有50%属于是误报风险。
客户在办理A类业务的时候，原本监督时限是xx天。但是由于业务办理的流程多样，在办理过程中，遇到节点B，则走向另外一条业务办理流程。
此时的业务办理时限是yy天，从业务的角度来判断是没有违规的。但是数据产品在统计数据的时候，没有抓取到原本的A类业务办理结束的结算时间点，导致数据产品中A类业务办理时限违规。
分析
问题点很明确，就是时限风险误报，因此笔者筛选了几例误报的数据进行分析。
在这里很重要的一点就是需要跟开发交流，明确开发在实际开发过程中的风险判断逻辑。
在这样发现主要有两类问题：一是业务流程覆盖不全，不同的业务流向，时限是不同的；二是业务节点抓取有问题，导致时限计算判断有问题。
结论
由此得出的对产品设计的两点思考：
一是在数据风险识别的过程中，往往**涉及到流程，因此需要结合风险识别，配套一个流程图，用于开发从宏观的层面知道业务办理的概貌；
二是在风险识别的每一个流程中，一定要明确每个节点的数据内容是什么（比如起算时间点）；明确流程节点的转变规则是什么，如何获取用于判断的数据内容（比如当业务处理结果为A时，流程进入A1办理，以及A的数据如何获取；当业务处理结果为B时，流程进入B1办理，以及B的数据如何获取）；明确流程的范围是什么（比如结算时间点，某个规定的动作）。
开发是产品经理的方案的具体执行者，如果产品经理都不知道宏观、微观的具体内容和逻辑，那么开发肯定是无法按照客户的要求开发出满足需求的产品。
所以产品经理们在做数据分析产品的时候，一定要对数据的来源、获取渠道、以及判断逻辑和统计逻辑都要有清晰的认识；并且在产品设计时，把需要写进需求文档中，在必要的时候需要配合业务流程图和数据流向图。
本文由 @萧羽 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
