实战复盘:从0到1如何构建定制化的数据系统?

0 评论 2737 浏览 16 收藏 15 分钟

在初次进行数据系统搭建时,产品经理可能会遇到哪些困难?也许你需要结合需求的全流程进行系统搭建。本篇文章里,作者结合实战经验,对其从0到1搭建数据系统的过程进行了复盘总结,一起来看看吧。

从产品团队运作的工作方法和程序,结合实践结果来谈谈第一次做数据产品时常见的坑,

用实际的项目快速掌握产品经理必备的方法论

这个项目是为一家食品公司制作的数据看板,从用户心声和赔付2个模块帮助其企业进行成本分析,找到对应的责任方来共同分担售后赔付压力。

一、产研团队的搭建

因为项目的周期非常短,需要一个月的时间实现从0到1的上线,涉及的数据及判断规则较多。对于从来没有做过数据产品设计的团队来讲都是摸石头过河,但还是需要继续往前走。

确定需要的资源,临时搭建一个数据小分队,包含了产品、设计师、后端研发、BI数据师。没有测试和项目经理的充足的资源,这部分工作由产品兼任。具体的人员从各个职能组中抽选出,然后搭建数据项目组,矩阵型的团队组成方式能够非常快速地响应紧急的任务。

二、产品策略的制定

这是一个KA-S级的客户,公司非常重视大客户的交付和服务。所以在整个项目的启动开始,整个流程都备受公司的关注。由于项目前期遇到了不可避免的原因,客户的业务进行了提前,所以要求我们提前完成系统的交付使用。双重的压力让整个团队都非常忙碌,一个月内处于24小时待命的状态。

每个项目都应该有个交付清单和功能范围边界。在进入需求的调研前期,我们是需要销售、客成、产研与客户方进行明确的信息同频。这不仅让整个项目有目标,也避免交付阶段的矛盾。

用实际的项目快速掌握产品经理必备的方法论

三、获得用户反馈及需求

确定了范围后,我们就进入到需求的讨论阶段。并不是每个客户都对自己业务非常熟悉,所以帮助客户慢慢梳理清楚自己业务流程也是一个必要的过程。

最开始,我们与客户的信息和重要程度是没有对齐的。我们紧急时,客户松弛。在全局的产品策略当中,双边拉扯的时间和周期非常长。

如何让客户不要无限地修改需求呢?以下2点很实用:

  1. 确定需求的阶段最好拉上最后以公司名义拍板的负责人;
  2. 最后的需求内容及方案在口头交流后以邮件的形式做二次的确认。

四、需求管理

当然,肯定是存在一些需求是在前期没有覆盖和想到的。因为数据类项目无法考虑到完全的方方面面,可能会存在很多的意外,比如技术上的无法实现、平台的数据不全、或者第三方公司不进行技术配合等等。

所以,为了保证信息的及时沟通,需要搭建一个公开的产研沟通群,遇到具体的问题随时沟通。无论是产研团队还是客户方面。

用实际的项目快速掌握产品经理必备的方法论

所以,我们需要进行好需求的管理,包含以下几个方面:

1. 对产品需求进行必要的分类

比如哪些是客户提出的?哪些是产品的规划?对于B端的需求来讲,产品规划不一定满足客户的业务需求,还是需要根据实际情况来决定。客户的需求也不并不是实际的业务需要。

2. 记录产品需求的重要属性和背景信息

任何事情多问自己几个为什么?直到问到明确的答案。我的老板经常会问我为什么很重要?解决什么问题?背景是什么?一定要这么做吗?不做会有什么影响?如果自己没有办法想的很清楚或者很有条理,可以用笔写下来。在日常的生活中不断地联系,深度思考是非常重要的!

3. 评估产品需求的预估价值和投入

是不是所有重要的产品需求都要马上做?对于数据类的项目而言,客户觉得每个需求都是非常紧急和重要的,有很多自己的实现想法。怎么更高效地和客户达成方案的价值共识呢?

  • 可以先安抚客户的情绪,让她认真地讲遇到的问题,耐心倾听就可以,最后告知我们会进行调研然后我们再沟通下具体的方案;
  • 保证方案不止一个,多想可实现的方案,然后与技术团队进行内部思想爆炸;
  • 将每个方案的实现过程、利弊以及投入列举出Excel表,让客户做选择题;
  • 从业务的角度为客户思考,为他推荐一种最友好的方式。

4. 确定产品需求的优先级

一下子把全部的需求做完?肯定不是的。因为是一个数据项目,所以我们考虑的角度是这个需求如果不做,这个系统可不可以用?如果不行,那么就必须完成。

然后对需求进行重要程度的打标,产品方案评审后与技术团队共同进行拆任务和确定时间,给到交付时间给客户。尽可能任务细致,把时间排的更合理,有充裕的时间进行周转。

5. 对产品需求的状态进行跟踪

因为项目经理的缺失,产品需要兼任对应的工作。其实,在很多公司,大型的项目会有专门的项目经理 。但是对于比较小或者急的项目,大概率是没有专门的项目经理来推动。所以,掌握一定的项目管理能力是非常有必要的!

无论是整个项目的研发管理表,还是细化的小需求,我们都需要有专门的文件进行管理。前期,因为需要和客户进行每日研发工作的同步,所以采用的是飞书的表格管理,甘特图形式来跟踪。便于内部的成本预算等方面的考虑,我们会同步在JIRA上进行需求的记录。

因为是B端的项目,相较于C端必做的竞品调研,我们更关注客户的业务情况。什么事业务情况?直白来讲,他们到底是怎么用的?如果用软件来代替,那么能够解决什么问题?有什么更好的效益呢?如果做不到基础的收益, 那么这个产品是不会被客户买账的!

五、产品功能-规划

确定要做的内容和大概的方案后,那么要考虑地更细,因为数据指标一定要考虑是什么,怎么算以及怎么来的问题。如果前期没有思考到,那么后续的问题会接踵而至。指标与指标之间是相互制约和联系的。

所以怎么做好数据项目呢?首先是确定有哪些数据指标及对应的计算规则。从原始数据层、维度数据层、明细数据层、汇总数据层和应用数据层5个层次去考虑。可以用流程图将数据的流转过程进行记录。比如从哪些地方获取数据,如何获取,增量还是全量?

用流程图表示的方法需要注意直接易懂、布局清晰及逻辑完整,这可以很大程度较少团队之间沟通,也是让客户更好确定业务是否是这样的。

接下来是原型的设计,因为现在公司采用数据项目使用前端轻代码,所以页面可以直接在一个系统上套用,选择对应的展现形式,放上SQL语句就可以使用。如果要进行界面或者格式的调整,可以马上修改后立即进行发布上线。

最后是成型的方案,因为迭代的需求会比较多,更改的细节也会多。所以一定是要写文档,并且非常细致。在文档的开篇要注明版本记录。这便于后期可以去查询,代码回滚等也更好追溯。

六、研发、测试并上线

虽然前期准备地比较充分,但在研发的过程中仍然会忽略一些小的细节。所以团队内部要保持足够的信息沟通,不能因为个人的原因被卡住,每日的敏捷站会的帮助非常大。内部固定一个时间,用15分钟聚在一起,聊下遇到的问题和待解决的事项。

最困难的阶段是数据校验,如果这个模块不行,相当于前期所有的努力都是白费的。这个项目没有测试,产品兼测试也是常见的。所以,平时可以多看看数据分析及测试方面的内容。

经历过一次小白测试后,在数据项目重点看功能使用、数据准确性以及数据压力三个方面。首先是在视觉上功能能不能用,不可以点击或者使用失败的功能就要及时撤掉。然后是数据准确性,因为这个项目涉及到调用内部数据和导入外部数据,所以数据源的准确性和结果的准确性都是非常重要。

测试的过程中很容易忽略数据压力,单天的几万条可能是好的。如果是查询一个月的量是否响应足够快?如果是下载,是不是可以下载的?可以邀请公司的小白用户来体验项目,他不用看业务,可以体验使用的感受。

七、项目管理

听下来,是不是觉得项目很顺利完成的?其实,并没有,中间产研团队几乎每个人都有做到崩溃。熬夜加班,连续3个周末无休是正常的。有时候,周末经常会接到客户的消息,他们很着急分享观点。遇到很多的问题,我们提前告知给客户,但是他认为产研总是会有问题。

不被理解,质疑和老板的施压像家常便饭。但是产品经理哪有那么容易被打倒,所以做项目考验能力的同时也是在锤炼自己冷静从容的心态。

项目管理也是我做这个项目遇到的困难,因为项目紧急,我临时被老板拉进来做产品方案的设计。产品和研发同时被告知1个月做项目,项目经理安排好进度表(前期本来是打算有的,因为被投诉所以取消了)。产品和研发的时间非常少,我以为所有的需求沟通好,但是一切为0。

1个月的时间完全不够,且前期承诺给客户的内容太多,导致实际无法支持到。并且客户投入的钱与实际的价值太大,公司不愿意投入过多的资源做。虽然是知道赔本的生意,为什么要做?一是公司的形象,二是需要该行业的口碑。

所以,前期没有具体的方案时,不要拿空大的话去承诺。如果不能交付就是会被打脸。前期我们的压力非常大,客户无数次说如果你们不能按照这个时间给我们,就算违约收传票。

不做这单生意挺简单,但是这个行业的单子可能都没有了。做好客户的前期预期和项目管理也是非常重要的是。这个项目管理并不是说产研的进度,包含了人力资源、产品范围、成本预估、里程碑计划、风险管理及整体沟通机制。

用实际的项目快速掌握产品经理必备的方法论

积极、主动和认真,即使再困难的项目也会有结果。最后,我们终于做完了这个数据项目。过程很痛苦,结果还是存在的。我也是既会做业务也会做数据的小产品啦!bingo~

总结

理论永远要和实践结合起来,或许书里的方式与自己非常契合,或许完全不适用。多听、多看和多做才有可能变得更好,期待我们一起努力~

本文由 @萌沐 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!