数据从业人员，该如何管理需求？

需求的生命周期管理是一项难度不小，但实实在在值得去做的事情。数据团队也应该紧跟甚至需要**前于业务团队，做到「事前感知，事后追踪」。

本文是个人工作中的一些心得，虽是「个人心得」，其实内容却不乏有数据工作中客观存在的事实，你躲不过也绕不开。主要面向于数据相关的从业者，如：数据分析师、数据工程师等。

在我们团队内部，有一个「需求流程」，虽然粗暴、简陋，但却简洁有效。我也将**从流程中的各个节点聊一聊。站在「陈述事实」的角度把需求流程这件事讲清楚，也希望能得到一个共鸣与修正。

下文按照「需求流程」讲解：「新建→规划中→开发中→测试中→上线」和「需求生命周期」。

一、新建中

这个环节是业务需求落实到具体「文档」最初始的阶段，也是数据产品经理最早跟需求有接触的阶段（当然不排除有些口头需求，业务及数据产品同学口头约定描述需求概况及可行性调研的部分），这时候数据产品需要做：

1.1 判断合理性

1. 从需求的背景描述，以及与业务方的沟通中确定对方想要解决的问题是什么？数据是否可解决？
2. 是否已有数据？因为有部分需求**因为不同业务方之间没交集而产生需求重复的现象，而且很多。
3. 是否有数据产品工具可供业务方自行实现？有些数据产品工具就可解决业务问题，但产品却因为「信息不对称」而不为人所知。
4. 需求边界问题，有些更适合业务团队自行实现的需求，被提到了数据团队，则需要过滤掉。

1.2 检验完整性

1. 报表类需求：检验「维度x指标」是否完整合理，确认指标计算逻辑、口径是否完善。所谓巧妇难为无米之炊，没有给出指标精确的计算逻辑和所依赖的库、表，是没有办法启动施工的；
2. 非报表类需求：如工具产品，赋能类等，需要判断业务方是否有足够的使用场景来支撑工具的开发。否则一个产品化的工具需求被开发出来，使用者聊聊无几，实在得不偿失。

1.3 确定优先级

最常见也最符合心理学的一个现象，是每个业务方提过来的需求都火急火燎，都把自己的需求优先级设为最高，这些多数需求只不过是在业务同学提出时恰好「被紧急」了。而实际上却并没有我们想象中的那么紧急，甚至被标记为最高优的需求，在隔日就被遗忘，一周内也不再被提起。这种就属于是「脑热型需求」。而另外却存在一类真实高优的需求，直接涉及到顶层决策。

我们该如何判断？

• 需求受益方是谁，这是最直接的方法。比如是CEO的需求，那毫无疑问就是最高优，因为将**直接影响「顶层决策」。
• 需求本身所覆盖的业务，是单业务还是多业务？如果是多业务，则缺少当前这个需求这一环是否**影响的是全局的进度？则需要酌情提高优先级。
• 需求实现成本如何？需要判断需求实现的难易程度，如果是一个大型需求需要占用很多工时，若被提高优，那么则**直接影响开发人员手中项目的进度。若是简单的，「顺手」就能完成的需求，则亦可酌情提高优先级。

二、规划中

开发同学不理解需求怎么办，如何快速上手？关键字：学**提问。

当需求从「新建」移动到了「规划中」，则是完成了产品层面的把关。但这并不等于产品经理的工作就完成了。因为在规划中的需求，需要产品同学去推动开发人员给出明确的排期。开发人员对需求的排期能力也是考验自身开发能力的重要标杆，对于规划中的需求，开发同学需要知道：

2.1 是什么？

需求背景，要解决的问题是什么。

2.2 在什么时间，做到什么程度？

需求的优先级如何，数据的实时性及准确性有何要求？

2.3 怎么做？

1. 能预估需求计算**依赖哪些数据库、表，计算逻辑的复杂度如何？
2. 需要预估存储及计算资源的消耗如何？
3. 其他。

三、开发中

如何避免蒙头做事？

3.1 评估

• 是否有现成数据？因为有些现成的数据在产品层面根本不知道或没有能力知道，但开发间**相互知晓（例如：在服务器中，在仓库里，在某个只有开发人员才有权限的系统中）。
• 数据是否已具备？（不具备则需要推动上游解决）

3.2 开发

依赖的相关指标，有没有其他同学计算过，逻辑是否可复用或可借鉴。

3.3 优化

有没有更巧妙，优雅的解决方案。这方面则需要长期不断的总结积累。你**发现同样的需求，开发人员能力的不同，最终的方案「优雅」程度也**不一样。

四、测试中

如何进行数据测试？

有些公司数据团队里已经配备专业的测试人员，**有严谨的测试用例，有的测试人员也**手写SQL及各种小工具来校验数据准确性。但如果没有配备测试人员，开发及产品同学需要怎么办呢？

4.1 精确

首先，务必要保证自己开发的逻辑与需求无偏差。如果是需求本身模糊，则必须要确认精确的逻辑。数据计算这事儿，只能严谨。

4.2 心中有数

开发好了计算逻辑，在校验数据的时候，需要开发人员自己心中有数。即无论是用户、交易、商品等范畴内的基础数据，也都要有最基础的业务量级感知，这能有助于快速判断一个数据计算结果是否合理（多看报表、邮件）。

4.3 校验

与线上或业务线相关指标做对比（前提是可比）。

五、上线后

5.1 新上线的报表业务方质疑数据不准确，该怎么办？

老铁稳住，别慌！对自己的开发逻辑要求严苛，然后有信心。

思考：为何业务同学**觉得数据不准确？无非就是两个方面：

1. 用新开发出来的数据与历史同名指标数据作对比（逻辑上可能**不一样，不具有可比性）；
2. 与第三方数据对标（数据源及计算逻辑无法确认是否一致，不具有可比性）。

以上两点思考完了，也就有了解决方案。

5.2 遇到数据异常怎么办？

需求上线一段时间后，某天发现数据产生异常了，该怎么办？

思考两点：

1. 先从自身看，去快速思考数据流从上到下是否有问题。收集、ETL、计算、展现等，顺藤摸瓜
2. 让信息对称（多问，多咨询，看看数据是否是因业务活动、渠道原因、不可抗力、竞品等导致）

六、需求生命周期

业务数据需求上线后，是不是就结束了？

每个数据人，都应该有这样的基本操守：「需求上线是开始不是结束」，至少还需要注意两方面事情：

（1）告警及任务监控机制建立

（2）倾听业务反馈

1. 需求上线后，是否对业务方有帮助？追反馈。
2. 是否有优化空间？何时该下线？做加法的同时，减法如何做。
3. 能不能做到自动化「任务/报表/邮件」的自动生命周期管理。

如今，整个市场瞬息万变，业务也**跟着市场的步伐在跑，这对任何一个数据团队都是不小的考验。你**发现一个月前还非常重要，还有很多人使用的模块/报表现在却没人理**，那是因为方向标变了，一切都在变。需求的生命周期管理是一项难度不小，但实实在在值得去做的事情。数据团队也应该紧跟甚至需要**前于业务团队，做到「事前感知，事后追踪」。

本文由 @ 黑夜月 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

给作者打赏，鼓励TA抓紧创作！

**赏

4人打赏