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