在初次进行数据系统搭建时,产品经理可能会遇到哪些困难?也许你需要结合需求的全流程进行系统搭建。本篇文章里,作者结合实战经验,对其从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协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。