本文笔者针对自身在实践中遇到的一些需求管控的的困惑，找出造成这些情况的原因，探索做好需求管控的方法。

01 困惑

之前有讲过数据产品经理工作主要集中于平台建设及用户需求满足，事实上以满足用户需求居多。很多时候，数据产品经理会越来越没有成就感，因为一直都在做需求，但是开发的产品没有被用起来，周而复始的做着同样的事情。

在开始一个产品研发前，数据产品通常要跟用户博弈很多次，用户在发起需求的同时，对开发出来的数据产品，其实是带着很大的期待去帮助他解决问题的。但是，往往产品开发完毕后，又会因为这样或那样的问题而不被使用，最后不了了之，用户花费了精力，我们也付出了人力物力，却付诸东流。

02 溯因

产品没有被用起来，原因有很多种，但我认为很大一部分原因在需求管控环节没有做好。

原因基本可以分为两类：一类是数据产品经理还没有形成需求管控意识，特别是对于一到两年的数据产品，容易形成一切以用户为主被动接需求的状态；第二种可能因为客观因素影响，譬如承接项目需求承接，数据产品难以介入内容设计环节。

数据产品经理的需求管控意识不是一蹴而就能很快形成的，毕竟我们也需要不断的成长才能少踩一些坑。对于我自己而言，同样经历了很多个项目的洗礼，我才意识到需要做一定的规则去约束需求的提报，或者在平台上去做一些通用性的开发减少用户需求的提报。

03 体系化需求管控是基础

需求管控类似于打柜子的过程。

简单的理解，可以将整个集团的大数据平台理解为一个大衣柜，衣柜里面应该有多少个格子，每个格子该放什么衣物，已经放了多少衣物，还能放多少，满足了多少人的日常穿搭等，要有相对清晰的认知。

对应到数据应用管理体系，数据产品经理可以建立一个简单的集团层面数据应用体系，平台上有多个报表、多个看板、多个切片等，已经支撑到哪几块的业务数据需求，满足了多少用户的数据需求，还有哪一块的业务数据还没有涉及到等。

这个数据应用管理体系可以按业务组织来划分，也可以按业务分析主题来划分。一般数据平台刚建立时，采取前者是最方便的，譬如：对于零售行业，可以按组织将大数据平台分为线下渠道、线上渠道、商品供应链、财务、人资等，每一块大组织下面有不同的部门，每个部门提报的应用需求安置在对应的组织下面即可。

但是，随着时间的推移，业务部门之间的数据交叉应用会比较多，按组织架构划分已经不太适用，这个时候可以考虑建立一个比较完整的集团层面数据分析体系，将相应的数据应用放在不同的分析主题或场景之中。

如下图所示：

有了这个数据应用管理体系，数据产品经理针对用户的需求就能分门别类的进行管理及管控，做到有迹可循。现在，我所在部门就在开展全集团业务分析蓝图梳理工作，并着手于建立配套管控机制，未来用户需求必须基于业务蓝图进行来决定是否进行研发。

04 需求可行性评估是保障

很多情况下，数据产品可行性评估在数据产品考虑范围之内，但是技术性评估是首要考虑因素。然而，往往朝着如何实现的方向去评估，产品不仅会大打折扣，时间上也会出现延期情况。因此，可行性评估上，建议在需求层面做的更加多元一些。

建议从以下几个方面考虑：

1. 技术层面

研发人员说的比较多的一句话就是：只要你给时间，没有开发不出来的需求。但是在实际项目过程中，时间是有限的，实际交付出来的产品功能上或者页面呈现效果，会与用户预期存在较大的差异。

因此，产品经理提前需要与技术研发人员进行可行性评估，确定可以完成的功能及效果展现，并与用户确认是否能影响到他们的使用热情。

2. 数据质量层面

数据质量重要性无需多说，产品研发前，对数据质量问题进行评估，并给出解决方案是确定产品能否用起来的关键。但是，数据质量治理问题是个老大难，数据治理是个 繁琐且需要多方配合的过程，甚至会直接影响到用户的业务以及业务系统再开发，

在产品研发前，产品经理最好组织多方人员，针对数据治理可行性方案进行沟 通，再考虑是否针对这个需求进行研发。

3. 用户层面

我经历过一个项目，报表已经全部研发完成，但是数据质量只能达到95%的准确率，达到百分之百准确流程，需要有专门人员对于业务系统一个字段的数据质量定期维护管理。

在报表研发前，我们与用户都觉得是一个很简单的问题，到时候安排一个人就行了。但事实上，由于这个工作会占用比较多的时间，负责的用户需要额外承担工作量，之前说的简单的一个问题就这样不了了之，最终影响到产品也没有用起来。

在一个产品研发前，需要用户参与的工作部分，我们往往高估了用户的配合性，甚 至是用户自己。

在可行性评估阶段，数据产品要将会遇到的问题与用户沟通清楚，并基于 评估结果给出是否建议研发的意见，甚至与用户达成约束条件，保证产品使用频率。

05 需求优先级管理是最后护航

很难说用户在提一个需求之前没有经过慎重考虑，但事实上，经常会出现用户自己提的产品需求自己却不用的情况，经过上面两轮需求管控之后，仍然建议产品经理将用户需求排优先级，倒逼用户再对需求进行进一步的筛选。

我上一个项目，经过前两轮的沟通后，最后还剩25个报表需求，但用户坚持是必须要开发的。基于这个情况，我让用户将25张报表进行了高中低优先级的排布，选出8张表为期一个月进行最优先级开发，并要求用户针对每张表对应的岗位以及每月使用次数做了使用频次评估及承诺。

最后，开发出来的表使用情况都达到了用户约定，但是剩余表到今天为止用户仍没有要求继续。

06 需求管控不是为了让用户不提需求

之所以要做需求管控，绝对不是为了让用户不再提报需求，退一步讲，他们没有开发需求，那我们这批人存在的价值在哪里？

大数据火了好几年，但是很多公司仍处于摸索的阶段，我们允许去试错，但是不代表要盲从去满足。开发资源很少，时间也很有限，我们希望每一个开发的产品都是真正用户需要的且能被使用的。数据平台上的产品从上线下线要有良性的周期循环，且朝着越来越好的状态进行。

所以，需求管控很重要，他决定了一个项目是否能成功，甚至影响到数据平台的建设及影响力。

以上，希望能对你有帮助。

作者：王小涂，微信公众号：数据产品经理进阶之路（ID：DATAPMLZ）希望和你一起探讨数据产品经理进阶之路！

本文由@王小涂 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsaplsh, 基于CC0协议