如何看懂数据流分析（从0到1如何构建定制化的数据系统）
如何看懂数据流分析（从0到1如何构建定制化的数据系统）最开始，我们与客户的信息和重要程度是没有对齐的。我们紧急时，客户松弛。在全局的产品策略当中，双边拉扯的时间和周期非常长。确定了范围后，我们就进入到需求的讨论阶段。并不是每个客户都对自己业务非常熟悉，所以帮助客户慢慢梳理清楚自己业务流程也是一个必要的过程。确定需要的资源，临时搭建一个数据小分队，包含了产品、设计师、后端研发、BI数据师。没有测试和项目经理的充足的资源，这部分工作由产品兼任。具体的人员从各个职能组中抽选出，然后搭建数据项目组，矩阵型的团队组成方式能够非常快速地响应紧急的任务。这是一个KA-S级的客户，公司非常重视大客户的交付和服务。所以在整个项目的启动开始，整个流程都备受公司的关注。由于项目前期遇到了不可避免的原因，客户的业务进行了提前，所以要求我们提前完成系统的交付使用。双重的压力让整个团队都非常忙碌，一个月内处于24小时待命的状态。每个项目都应该有个交付清单和功能范围边界。
在初次进行数据系统搭建时，产品经理可能会遇到哪些困难？也许你需要结合需求的全流程进行系统搭建。本篇文章里，作者结合实战经验，对其从0到1搭建数据系统的过程进行了复盘总结，一起来看看吧。
从产品团队运作的工作方法和程序，结合实践结果来谈谈第一次做数据产品时常见的坑，
这个项目是为一家食品公司制作的数据看板，从用户心声和赔付2个模块帮助其企业进行成本分析，找到对应的责任方来共同分担售后赔付压力。
一、产研团队的搭建因为项目的周期非常短，需要一个月的时间实现从0到1的上线，涉及的数据及判断规则较多。对于从来没有做过数据产品设计的团队来讲都是摸石头过河，但还是需要继续往前走。
确定需要的资源，临时搭建一个数据小分队，包含了产品、设计师、后端研发、BI数据师。没有测试和项目经理的充足的资源，这部分工作由产品兼任。具体的人员从各个职能组中抽选出，然后搭建数据项目组，矩阵型的团队组成方式能够非常快速地响应紧急的任务。
二、产品策略的制定这是一个KA-S级的客户，公司非常重视大客户的交付和服务。所以在整个项目的启动开始，整个流程都备受公司的关注。由于项目前期遇到了不可避免的原因，客户的业务进行了提前，所以要求我们提前完成系统的交付使用。双重的压力让整个团队都非常忙碌，一个月内处于24小时待命的状态。
每个项目都应该有个交付清单和功能范围边界。在进入需求的调研前期，我们是需要销售、客成、产研与客户方进行明确的信息同频。这不仅让整个项目有目标，也避免交付阶段的矛盾。
三、获得用户反馈及需求
确定了范围后，我们就进入到需求的讨论阶段。并不是每个客户都对自己业务非常熟悉，所以帮助客户慢慢梳理清楚自己业务流程也是一个必要的过程。
最开始，我们与客户的信息和重要程度是没有对齐的。我们紧急时，客户松弛。在全局的产品策略当中，双边拉扯的时间和周期非常长。
如何让客户不要无限地修改需求呢？以下2点很实用：
四、需求管理
- 确定需求的阶段最好拉上最后以公司名义拍板的负责人；
- 最后的需求内容及方案在口头交流后以邮件的形式做二次的确认。
当然，肯定是存在一些需求是在前期没有覆盖和想到的。因为数据类项目无法考虑到完全的方方面面，可能会存在很多的意外，比如技术上的无法实现、平台的数据不全、或者第三方公司不进行技术配合等等。
所以，为了保证信息的及时沟通，需要搭建一个公开的产研沟通群，遇到具体的问题随时沟通。无论是产研团队还是客户方面。
所以，我们需要进行好需求的管理，包含以下几个方面：
1. 对产品需求进行必要的分类
比如哪些是客户提出的？哪些是产品的规划？对于B端的需求来讲，产品规划不一定满足客户的业务需求，还是需要根据实际情况来决定。客户的需求也不并不是实际的业务需要。
2. 记录产品需求的重要属性和背景信息
任何事情多问自己几个为什么？直到问到明确的答案。我的老板经常会问我为什么很重要？解决什么问题？背景是什么？一定要这么做吗？不做会有什么影响？如果自己没有办法想的很清楚或者很有条理，可以用笔写下来。在日常的生活中不断地联系，深度思考是非常重要的！
3. 评估产品需求的预估价值和投入
是不是所有重要的产品需求都要马上做？对于数据类的项目而言，客户觉得每个需求都是非常紧急和重要的，有很多自己的实现想法。怎么更高效地和客户达成方案的价值共识呢？
- 可以先安抚客户的情绪，让她认真地讲遇到的问题，耐心倾听就可以，最后告知我们会进行调研然后我们再沟通下具体的方案；
- 保证方案不止一个，多想可实现的方案，然后与技术团队进行内部思想爆炸；
- 将每个方案的实现过程、利弊以及投入列举出Excel表，让客户做选择题；
- 从业务的角度为客户思考，为他推荐一种最友好的方式。
4. 确定产品需求的优先级
一下子把全部的需求做完？肯定不是的。因为是一个数据项目，所以我们考虑的角度是这个需求如果不做，这个系统可不可以用？如果不行，那么就必须完成。
然后对需求进行重要程度的打标，产品方案评审后与技术团队共同进行拆任务和确定时间，给到交付时间给客户。尽可能任务细致，把时间排的更合理，有充裕的时间进行周转。
5. 对产品需求的状态进行跟踪
因为项目经理的缺失，产品需要兼任对应的工作。其实，在很多公司，大型的项目会有专门的项目经理 。但是对于比较小或者急的项目，大概率是没有专门的项目经理来推动。所以，掌握一定的项目管理能力是非常有必要的！
无论是整个项目的研发管理表，还是细化的小需求，我们都需要有专门的文件进行管理。前期，因为需要和客户进行每日研发工作的同步，所以采用的是飞书的表格管理，甘特图形式来跟踪。便于内部的成本预算等方面的考虑，我们会同步在JIRA上进行需求的记录。
因为是B端的项目，相较于C端必做的竞品调研，我们更关注客户的业务情况。什么事业务情况？直白来讲，他们到底是怎么用的？如果用软件来代替，那么能够解决什么问题？有什么更好的效益呢？如果做不到基础的收益， 那么这个产品是不会被客户买账的！
五、产品功能-规划确定要做的内容和大概的方案后，那么要考虑地更细，因为数据指标一定要考虑是什么，怎么算以及怎么来的问题。如果前期没有思考到，那么后续的问题会接踵而至。指标与指标之间是相互制约和联系的。
所以怎么做好数据项目呢？首先是确定有哪些数据指标及对应的计算规则。从原始数据层、维度数据层、明细数据层、汇总数据层和应用数据层5个层次去考虑。可以用流程图将数据的流转过程进行记录。比如从哪些地方获取数据，如何获取，增量还是全量？
用流程图表示的方法需要注意直接易懂、布局清晰及逻辑完整，这可以很大程度较少团队之间沟通，也是让客户更好确定业务是否是这样的。
接下来是原型的设计，因为现在公司采用数据项目使用前端轻代码，所以页面可以直接在一个系统上套用，选择对应的展现形式，放上SQL语句就可以使用。如果要进行界面或者格式的调整，可以马上修改后立即进行发布上线。
最后是成型的方案，因为迭代的需求会比较多，更改的细节也会多。所以一定是要写文档，并且非常细致。在文档的开篇要注明版本记录。这便于后期可以去查询，代码回滚等也更好追溯。
六、研发、测试并上线虽然前期准备地比较充分，但在研发的过程中仍然会忽略一些小的细节。所以团队内部要保持足够的信息沟通，不能因为个人的原因被卡住，每日的敏捷站会的帮助非常大。内部固定一个时间，用15分钟聚在一起，聊下遇到的问题和待解决的事项。
最困难的阶段是数据校验，如果这个模块不行，相当于前期所有的努力都是白费的。这个项目没有测试，产品兼测试也是常见的。所以，平时可以多看看数据分析及测试方面的内容。
经历过一次小白测试后，在数据项目重点看功能使用、数据准确性以及数据压力三个方面。首先是在视觉上功能能不能用，不可以点击或者使用失败的功能就要及时撤掉。然后是数据准确性，因为这个项目涉及到调用内部数据和导入外部数据，所以数据源的准确性和结果的准确性都是非常重要。
测试的过程中很容易忽略数据压力，单天的几万条可能是好的。如果是查询一个月的量是否响应足够快？如果是下载，是不是可以下载的？可以邀请公司的小白用户来体验项目，他不用看业务，可以体验使用的感受。
七、项目管理听下来，是不是觉得项目很顺利完成的？其实，并没有，中间产研团队几乎每个人都有做到崩溃。熬夜加班，连续3个周末无休是正常的。有时候，周末经常会接到客户的消息，他们很着急分享观点。遇到很多的问题，我们提前告知给客户，但是他认为产研总是会有问题。
不被理解，质疑和老板的施压像家常便饭。但是产品经理哪有那么容易被打倒，所以做项目考验能力的同时也是在锤炼自己冷静从容的心态。
项目管理也是我做这个项目遇到的困难，因为项目紧急，我临时被老板拉进来做产品方案的设计。产品和研发同时被告知1个月做项目，项目经理安排好进度表（前期本来是打算有的，因为被投诉所以取消了）。产品和研发的时间非常少，我以为所有的需求沟通好，但是一切为0。
1个月的时间完全不够，且前期承诺给客户的内容太多，导致实际无法支持到。并且客户投入的钱与实际的价值太大，公司不愿意投入过多的资源做。虽然是知道赔本的生意，为什么要做？一是公司的形象，二是需要该行业的口碑。
所以，前期没有具体的方案时，不要拿空大的话去承诺。如果不能交付就是会被打脸。前期我们的压力非常大，客户无数次说如果你们不能按照这个时间给我们，就算违约收传票。
不做这单生意挺简单，但是这个行业的单子可能都没有了。做好客户的前期预期和项目管理也是非常重要的是。这个项目管理并不是说产研的进度，包含了人力资源、产品范围、成本预估、里程碑计划、风险管理及整体沟通机制。
积极、主动和认真，即使再困难的项目也会有结果。最后，我们终于做完了这个数据项目。过程很痛苦，结果还是存在的。我也是既会做业务也会做数据的小产品啦！bingo~
总结
理论永远要和实践结合起来，或许书里的方式与自己非常契合，或许完全不适用。多听、多看和多做才有可能变得更好，期待我们一起努力~
本文由 @萌沐 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
