需求是产品建设的动力与基石，而需求价值既是产品商业价值的具象体现，也是需要产品经理首要和根本关注的问题。
1. 需求来源
数据需求一方面源自于业务部门的具体业务场景，需要用数据来做预研、监控、分析和复盘，这种被动接收业务数据需求是主要的来源；另一种就是数据团队通过数据探索、流程梳理、市场调研，以业务方未曾考虑到的视角，提供更全面、深刻、高效的指标体系、模型工具、流程优化等产品方案，这种主动发起的需求，其实才更能体现数据团队的能力和价值。
2. 需求的一致性与协同性
尽管在实际工作环境中，数据部门和业务部门在工作视角、思维方式和做事方法上总会存在着一定的gap，但究其本质而言，数据与业务本就是高度相关——业务脱离数据如盲人摸象，数据脱离业务如空中楼阁，相辅相成才是正道。
所以在一个良好的土壤环境下，业务和数据应该是双赢的局面：业务部门提出高价值需求，数据部门交付的数据的确能帮助业务部门促助业务的发展和提升。反之，如果在恶劣的土壤下，如果业务部门提低价值的需求空耗数据团队的时间和精力，或者数据部门交付物并不能切实有效用于改善业务，那就是双输的局面。
因此数据需求首先要考虑到数据和业务的一致性和协同性：这个需求的确是能促进业务才做的。数据部门主动发起的需求，需要与业务部门充分沟通，取得他们的理解、认同和可落地的行动项；相对地，数据产品经理接收到业务部门的需求，同样要充分考虑评估需求价值。
3. 数据需求价值评估
也许业务部门更希望数据部门“要什么就给什么”，但数据产品经理必须具备独立思考的能力，对需求价值作尽可能充分的评估与判断，尽管可能会给需求方留下“不够配合”的印象，但从数据团队整体和长远的角度考虑下，这个过程是十分有必要的。
数据产品作为典型的2B产品，其价值体现归根结底仍体现在2个方面——
- 提高收益：数据产品给业务人员提供更广泛、更深刻的数据分析，引导他们产生新的发现、洞察和方案，从而给业务提供新的增长点
- 降低成本：基于现有确定的事实，通过产品来优化流程、提高效率，降低业务团队获取数据、使用数据的成本，降低数据团队在低价值工作中的消耗成本
这2个方面说起来简单，实际衡量起来却是比较困难。以下是一些角度和方法，以供参考。
3.1 需求类型判断
接到一个需求，首先要初步理解并判断这个需求的类型。从多个角度考虑：
- 这是一个长期需求还是一次性需求？
- 这是一个偏业务还是偏技术的需求？
- 交付形式是什么？提个数？做个报表？从数据采集、数仓建模、数据分析和数据产品输出的全链路需求？搭建一个数据平台用来概况一整条业务线的核心数据流通、分析和交互体系？
一般而言，需求类型差不多就决定了需求价值的上限——长期需求价值大于一次性需求；偏业务型需求（比如规划指标体系、梳理数据流转流程、设计分析模型和工具）价值大于偏技术型需求（比如数据生产调度、数据质量排查、数据口径查询）；交付形式越复杂的价值大于越简单的。
3.2 是否已有替代方案
通常情况下，业务人员对数据产品和数据仓库了解都不够深，因此存在着重复提需求的现象。如果已经数据产品方案能完全或部分满足需求，则应尽量交付已有的替代方案，以减少需求开发成本，替代程度越高，则需求价值越低。
这就要求着数据产品经理对现有的数据产品和数据仓库要比较熟悉——而这也要求着数据平台和数据仓库要规范建设，要有尽可能全面、专业的文档信息输出，不能靠口口相传，不能到处留坑。
3.3 数据需求与业务行动的紧密程度
根据数据需求与业务行动紧密程度和相关性，业务需求大致可以分为以下几种：
- 业务方自己也不知道要干什么，纯粹就想看看数据，看能不能有所启发
- 业务方做了一些事情，需要用数据看看效果，做做分析、总结、汇报等
- 业务方正在做或者准备做一些事情，准备了PLAN A/B/C，就等着根据数据来调整或者确定行动方向
这几种需求价值依次从低到高。所以接到需求后，要先反问业务方：有了这个数据你能做什么？没有这个数据对你又有什么影响？ 业务方对数据应用场景思考得越充分，对基于不同数据结果采取不同业务决策和行动方案思考得越清晰，则数据需求与业务行动就越紧密，数据驱动业务决策的价值就越大。
3.4 受众规模
交付了数据需求之后，是只有需求方一个人用？还是一个团队在用？还是整个部门都需要用？甚至是全公司都有用？受众规模越大，需求价值越大。因此，一般而言，越庞大、越强势、话语权越大、影响范围越广的业务部门数据需求价值越高；而越小众、越边缘、越没有话语权的部门数据需求价值就越小（哎，世态炎凉啊……）
3.5 使用频次
如果交付了数据产品，需求方只会偶尔用一下，或者大半个月才用一次，那就得考虑是否值得付出相当的开发成本来支持了。像那些每天都要关注的核心指标数据，或者一天要看好几次的实时指标数据，才有较高的价值。
3.6 对数据产品建设的促进程度
这个需求是复用一下过去的方案，套用一下现成的模型就能交付的，还是需要设计新的方案，优化数据产品基础功能才能满足需求？一般而言，越能促进数据产品做出优化和改进的，需求价值就越大。
3.7 对外商业化的可能
尽管数据部门主要定位是支持内部业务部门，但交付的数据产品有没有发展成可对外销售服务的2B产品的可能？如果不仅能对业务部门有帮助，还有商业化的潜力，那这个价值就更大了。
4. 需求优先级判断
对于产品经理来说，判断需求优先级，有一个普适性的公式：紧迫性*需求价值/开发成本（当然，来自于领导空降的需求不在此公式范围内）。
- 首先根据需求价值来判断重要性
- 然后评估需求的紧迫性，基于业务现在的发展阶段，评估是否一定马上就需要，如果交付的较晚，会有哪些风险和成本
- 评估开发成本：作为数据产品经理，理解的一个需求，要通过自己的技术素养快速设想一个技术方案流程，并对工作量和成本有一个初步的判断：要考虑对数据存储和计算资源的消耗情况；同时要综合考虑到执行的技术人员具体情况，如技术能力、工作效率、沟通成本等。
5. 需求评估行动项
综合以上的方法，接收到一个需求，可以采取以下的行动，来尽可能保障数据需求的价值。
5.1 稍微设置提需求门槛
以我过去的工作经验来看，如果业务部门提需求门槛越低，就越可能不会对数据需求抱有深思熟虑的负责任态度，其数据需求价值可能就越低，数据部门就越容易消耗在低价值工作上，从而导致数据部门地位越低。
所以稍微设置一下需求门槛是有必要的：比如一定要跟我讲清楚需求背景和需求目标；比如一定要提供逻辑严谨、内容充实、符合规范的需求文档，不接受张口就来需求；比如一定要经得住逻辑的思辩，而不是仅仅只是说领导需要。
5.2 稍微拖延
需求方表现得很急迫，不一定等于需求真的很急迫；但反之，如果需求方并不急迫，那就可以说明需求并不急迫。所以在无法充分评估需求价值和优先级时，先适当拖一下，观察一下需求方的态度：如果他们自己都不急，那我也不急；如果他们都把这个事忘了，说明这个需求其实并不是真的需要。
5.3 数据产品监控
有时候需求方提起需求比较坚定，但需求交付之后自己却不怎么看。所以数据产品一定要有数据监控，在交付了需求之后，要持续跟踪使用情况。如果业务方提了需求却不怎么看，要去沟通是数据产品的问题还是数据需求的问题，从而判断是数据产品方案或平台需要优化，还是说做了一个伪需求——如果是后者，那么下次需求请他们深思熟虑。
5.4 数据产品需求复盘
然而现实跟理想总会有差距——实际工作中，不可能要求业务方只提高价值需求，也不太可能完全不去支持低价值需求。但是作为产品经理，还是需要尽量基于做过的数据需求作分析总结，对自身和数据团队的工作价值有一个感知——在此基础上，如果有可能，还是要尽个人能力与努力来提升高价值需求的比重，无论对于数据团队和自身的发展，都是有益处的。
