如何用七步，实现数据产品设计闭环

　　这是一篇讲数据产品设计方法的文章，将解读一个数据产品从业务问题到最终落地为产品及应用的全流程。这里的数据产品指的是解决数据运营或分析问题的功能型产品，虽然数据产品与其他产品相比具有其特殊性，但也有会有些常规产品的基本原则，我通常遵循的原则是：以人为本，源于需求，服务于需求，超前于需求，本人也还在不断学习中。
　　当我们手里有一把锤子的时候，看什么都像钉子。数据产品设计也不例外，偶尔会陷入一类自上而下的思维误区，“先开发出产品，告知业务方能解决什么问题，然后推广使用”，往往这么做收到的效果并不理想。数据产品设计的流程应该是自下而上，从业务出发，源于需求，抽象问题本质，评估解决方案是否可工具化等，最终开发应用，服务于业务。
　　以下全文以留存分析工具为例，讲解实际的设计流程（共七部分）
　　一、明确问题：需求调研
　　准确定义问题是一个数据产品形成的关键，我认为这环节是最基本也是最重要的。那么当我们要设计数据产品前，该如何通过调研定义核心问题呢？
　　以下列出定义核心问题的三类调研方法：
　　（1）用户访谈：常见的做法是，跟业务同学吃饭聊，或者对接需求的时候聊，等等。总之，想尽一切办法获取情报。这么做之后，肯定能从沟通中获得一些关键信息，知道业务同学平时在应用数据时的痛点，也可以借机验证自己对目标产品设计的想法是否妥当。
　　（2）问卷调研：通常通过线上的手段实施，在构思产品的时候，分别列出关键问题：
　　留存分析工具可以列几个问题：
　　什么场景下会看用户留存？
　　平时怎么实现留存计算？
　　使用频率如何？
　　拿到什么结果，是否要二次处理？”
　　最后利用企业微信挨个拜访，收集用户反馈。
　　（3）数据分析：一类是通过需求管理工具，收集跟留存相关需求在历史需求中出现的频次；另一类是通过线上报表及数据产品的使用情况，通过使用频率、使用时长等指标评估，抽象提炼出与当前调研产品相关的有用信息，结合用户访谈和问卷调研一起双向验证，最终判断需求真伪。
　　通过调研会得到几个信息：
　　使用场景：在上线新业务、新版本、新模块等情况下会看用户日留存、周留存；
　　如何计算：通常找业务组RD写SQL解决，或直接向数据团队提需求排期开发。但实现周期长、效率低下；
　　使用频率：不定期。部分用户留存是单次分析，部分用户留存是短期长期观测；
　　结果处理：通常拿到数据后需要做二次处理，加工可视化，进行趋势分析或用户群之间的对比分析。
　　基于以上信息，我们可以总结出：
　　业务同学在许多业务场景中会使用留存分析，以日留存和周留存最为频繁；
　　用户留存计算的实现方式较为原始，需求实现周期长，且低效；
　　不定期会使用到，单次分析和短期长期监控均有需求。对灵活性要求高；
　　需要可视化，需要进行不同用户群间的趋势分析、对比分析。
　　二、制定方向：产品定位，商业评估
　　有了业务调研后，接着我们需要确定接下来该设计的产品是什么，以及这个即将被设计出来的产品其长期商业价值多大，到底值不值得将其工具化，到底需要做到什么程度？
　　基于调研，已经可以明确留存分析工具这个数据产品的定位，确定产品边界，以及它应该需要解决的用户痛点，和实现什么价值。
　　产品定位及边界：
　　通过一中的信息，我们可以抽象进而明确产品定位，明确产品需要具备的核心功能：
　　实现便捷、高效：用户白盒操作，系统黑盒执行；一次配置，多次应用；
　　灵活性强：可自定义，自助管理任务类型及上下线，随启随用、随用随停；
　　可视化能力：自动可视化，支持趋势分析及对比分析。
　　商业评估：
　　原始方案：每月约20任务，每任务1人日，合计20人日；
　　新方案：系统实现，人工成本为0。更灵活，更高效。
　　三、搭建框架：产品雏形，技术初审
　　有了产品定位和基本的商业评估之后，便可将初步方案设计出来，进行技术初审。得出产品商业价值评估的同时，将要投入的技术资源评估，同样尤为重要。否则难以评估最终产出是否会入不敷出。
　　讲需求：因为要设计的产品初稿是为了进行技术初审，且初稿可能会面临较大的改动甚至会被推翻，因此这一步要做的事是快速的把事情讲清楚，只作简单的推演图和简单方案，待初审通过后再进行细化。
　　搭框架：讲清楚产品核心功能，明确产品边界。如下图：清晰的将产品核心功能拆解成了三大模块任务管理、留存新建、留存分析，并体现出大概的交互方式。
　　任务管理：用于管理用户自己新建的任务，自助管理留存任务上下线，随启随用、随用随停。因为从调研中我们得知，对分群用户的留存监控不一定是长期的，可能是单次计算、可能是短期监控或长期监控，所以任务管理是为了用户自定义留存任务而设计。
　　留存新建：明确留存计算中数据的输入方式，定义留存计算类型、留存类型、起始行为、留存行为等。
　　留存分析：明确留存分析中数据的输出方式，即：需要通过何种方式展现任务管理中的数据，具备数据表、数据图，支持单任务分层对比、多任务留存对比等。
　　其中有两个前提：
　　你所在的公司团队已经拥有规范的埋点和完善的收集机制，数据的基础决定一个埋点划分一个用户群这个规则是否可用；
　　技术同学有能力解决留存模型的设计及开发问题。
　　定目标：
　　在技术初审中需要明确产品的一期目标，即：在多长时间内达到什么程度？
　　什么需要做，什么不做？
　　把最核心的功能先开发出来，用尽量小的技术成本实现产品最小MVP。
　　以最快的速度开发并应用起来，最后在使用中按需迭代。
　　待初审结束后，我们便可以在实现成本和产品收益之间有了较好的权衡。也明确了产品的最小MVP目标，同时也更便于去拆解细节，进行原型设计和需求文档撰写，避免不必要的资源浪费。
　　四、拆解细节：原型设计，需求文档
　　在这个环节里，必须遵循一个设计原则简单，产品做复杂很容易，做简单却很难。因本文主要讲解方法，对具体细节产品设计不展开描述。
　　原型及产品设计：
　　（1）任务管理：该页面用于管理个人用户的留存任务，核心聚焦在实现新建编辑测试上线下线查看结果删除的功能上。
　　如下图：
　　（2）留存新建：该页面用户新建留存任务，主要区分日周留存，起始留存行为，单一行为不同频次分布等。
　　如下图：
　　（3）留存分析：该页面用于展示留存计算结果，主要内容为数据表和数据图。功能核心逻辑聚焦在：单任务不同分层留存对比；不同任务的全部留存对比；数据下载。
　　如下图：
　　以上三个页面构成了我们留存分析工具的骨架，其中还需要特别注意在任务管理中任务处于不同状态时候的逻辑切换，即任务管理流程：
　　待完善产品原型和需求文档后，则需要进行二次技术评审，把与项目相关的所有方拽到一起评审。如果说初审是为了把事情讲清楚，那二审核心要解决的就是把期望讲清楚，把细节定清楚，并且所有的细节评审都应该明确地更新、记录在原型和需求文档中。
　　同时在评审中的细节微调也需要及时的将可能散落到各处的文档实时更新，以保证多人协作中的信息对称，避免不必要地沟通纠纷和开发返工。
　　五、快速迭代：功能开发，测试上线
　　需求提完，并不等于产品经理的工作就完成了。让正确的事，相继发生是一名产品经理最应该具有的能力。撰写产品方案及二次评审完成后，研发同学需要将项目拆解，给出明确排期，以最快的速度让轮子先转起来。
　　与此同时建立关键事件里程碑，也就是约定在什么时间点，完成哪些重要事项，若项目优先级混乱，排期不细致，预估不准确，则项目必然难以按原有计划保质保量完成。
　　那么在实际项目开发及测试上线过程中，分别需要注意哪些问题呢？
　　任务拆解，准确排期：同样项目排期预估是技术人员应该具备的基础能力，从技术的角度将项目拆解的越细致，最终预估出来的排期会越准确。为了保证排期更准确，要学会尽量逼研发同学将项目以足够细致的方式进行拆解排期。并以有效途径将排期结果公示，公示最大的效果是能起到严肃的监督作用。
　　明确分工，及时同步：任务拆解完，一定要有明确的任务分工。避免功能遗漏，别让到联调时还有重要模块没有人认领的情况发生。
　　进度管理，里程碑验收：每日站立会，及时同步不同模块的开发进展，保证各模块间开发进度信息透明，并且设立里程碑验收制度。一个项目如果开发周期较长，则不应该等所有的重要模块都上线了再逐一验收测试。而是在完成某个重要功能的时候，及时测试、校验功能是否符合预期，提早发现问题，并修正。
　　测试上线：数据产品有别于其他产品，除了产品本身功能满足需要之外，更重要的是输出的统计结果必须准确。所以测试环节中，数据测试成了重中之重。产出结果是否符合预期？与现有手工统计是否有偏差？有偏差的部分是否可解释或可修正？都需要严格保证。
　　六、推广应用：产品宣传，反馈优化
　　产品正式上线之后，为了让业务同学更方便，更快速地上手使用，我们通常会做几件事情：
　　（1）上线邮件
　　邮件会发送给与之相关的产品运营等同学，邮件内容主要包含产品功能、使用位置、使用方法的简单介绍，并用简洁的语言讲清楚它是什么以及怎么用两大问题。同时也会在内网wiki中写更精细的使用指南，便于一键收藏，随取随用。
　　（2）使用分享
　　通过以往数据产品调研开发上线应用的总结，我们有两个基本判断：
　　一是数据产品使用具有一定的门槛；
　　二是多数用户不知道或懒于学习如何使用。
　　很多情况下并不是你设计出来的产品解决不了分析问题，导致业务方不使用。而是多数用户不知道怎么使用，或不愿意去学习如何使用。
　　基于此，我们在发送完上线邮件之后，需要准备一场或多场产品使用分享，在分享会上直接把产品如何解决问题这个事情讲清楚，并现场演示。直到让一部分人先用起来，尝到甜头，在组织内部形成口碑后，自然大家也就更乐于去学习，甚至依赖使用产品了。
　　（3）意见收集
　　之前我们讲到用户调研能反馈出用户面对的需要用工具去解决的问题是什么，但并没有人知道我们将要开发的东西会长啥样。等真正的产品实物上线，直至更多的人使用之后，才可能会得到更多的有效反馈，促进我们不断打磨和优化产品，逐步迭代，逐渐完善。
　　七、收益评估：评估长期收益，生命周期管理
　　若非必要，勿增实体。既然产品是按需求开发出的实物，那么它就应该会产生实际价值。但数据产品的收益评估有别于其他类型产品，本身很难量化，只能通过评估释放实际需求人耗和间接产生的决策依据作为参考。如果碰到收益较差或者长期毫无收益的产品，就需要反向来看，到底是哪一个环节出了问题，并做好产品的生命周期管理。
　　及时停掉不再使用的功能或线上任务，以节省计算资源和存储资源开销。
　　以上，是我在从事数据产品设计工作中的心得，欢迎交流，共同成长。