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

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

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

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

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

一、新建中

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

1.1 判断合理性

从需求的背景描述，以及与业务方的沟通中确定对方想要解决的问题是什么？数据是否可解决？

是否已有数据？因为有部分需求会因为不同业务方之间没交集而产生需求重复的现象，而且很多。

是否有数据产品工具可供业务方自行实现？有些数据产品工具就可解决业务问题，但产品却因为「信息不对称」而不为人所知。

需求边界问题，有些更适合业务团队自行实现的需求，被提到了数据团队，则需要过滤掉。

1.2 检验完整性

报表类需求：检验「维度x指标」是否完整合理，确认指标计算逻辑、口径是否完善。所谓巧妇难为无米之炊，没有给出指标精确的计算逻辑和所依赖的库、表，是没有办法启动施工的；

非报表类需求：如工具产品，赋能类等，需要判断业务方是否有足够的使用场景来支撑工具的开发。否则一个产品化的工具需求被开发出来，使用者聊聊无几，实在得不偿失。

1.3 确定优先级

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

我们该如何判断？

需求受益方是谁，这是最直接的方法。比如是CEO的需求，那毫无疑问就是最高优，因为将会直接影响「顶层决策」。

需求本身所覆盖的业务，是单业务还是多业务？如果是多业务，则缺少当前这个需求这一环是否会影响的是全局的进度？则需要酌情提高优先级。

需求实现成本如何？需要判断需求实现的难易程度，如果是一个大型需求需要占用很多工时，若被提高优，那么则会直接影响开发人员手中项目的进度。若是简单的，「顺手」就能完成的需求，则亦可酌情提高优先级。

二、规划中

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

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

2.1 是什么？

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

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

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

2.3 怎么做？

能预估需求计算会依赖哪些数据库、表，计算逻辑的复杂度如何？

需要预估存储及计算资源的消耗如何？

其他。

三、开发中

如何避免蒙头做事？

3.1 评估

是否有现成数据？因为有些现成的数据在产品层面根本不知道或没有能力知道，但开发间会相互知晓（例如：在服务器中，在仓库里，在某个只有开发人员才有权限的系统中）。

数据是否已具备？（不具备则需要推动上游解决）

3.2 开发

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

3.3 优化