那些年我走过的弯路之——项目价值。

从业几年来，火山一直担任to B类产品经理。to B类产品有一个非常显著的特征：那就是业务部门对于产品形态往往都具有非常强的话语权，有时甚至是可以主导产品的走向，这一点我在上一篇文章《产品经理大忌：脱离用户》中已经做过一些阐述。大多数时候，业务部门的需求就像是连珠炮，一个接一个，让产品经理应接不暇，我们每天都能够听到这样的一些话语：

这个xx需求抓紧做，要不然客户就丢了！

那个xx功能什么时候可以做好呀？客户每天都在抱怨！

我有一个大客户，需要xxx功能，我们能做客户可以签得下来。

……

互联网公司的资源永远都是紧张的，创业型互联网公司尤其如此。这些漫天的需求扑面而来，为了尽可能地满足业务需求，那个时候我们可以说已经是把一个资源掰成两份来用。相当长的一段时间，我们整个产品、技术团队都保持着“996”的工作强度。但即便如此，业务方还是会抱怨我们速度慢，效率低，提了好多需求都没做。

面对这些接踵而至的一些需求，实际上火山当时已经自己总结摸索出了一套用Excel设计的一套需求管理工具，利用这套工具，我们可以随时根据实际需要，按照多种维度进行灵活的优先级排序。但工具再好它也只是个工具，最终执行的时候还是靠人、靠团队来决策的。

以往需求决策逻辑

对于堆积如山需求，我们决定先做哪个后做哪个的时候，决策逻辑大致会有如下几种：

1、谁强势谁优先。

当技术部门与业务部门的需求发生碰撞时，往往业务部门取胜，因为业务部门比技术部门更强势；当销售部门和客服部门的需求碰撞时，往往是销售部门取胜，因为销售部们比客服部门更强势。

2、谁是领导谁优先。

即领导提的需求，基本都是优先执行的，多个领导同时提，那就是那个领导官大，那个领导的优先级就更高。当然，这里需要特别说明的是，这里的领导不包括我们的CEO，我们的CEO是一个情商比较高的人，他经常都是一副我只是提需求，优先级你们排的态度，我们即便不把它的需求往前排他也不会放在心上，因此这条原则对CEO无效。

3、谁催的急谁优先。

差不多的两个需求，A盯得紧，天天催，B偶尔催一下，那基本就是A的需求先做。

4、谁实现快谁优先。

两个需求都很着急，A需要2周才能开发完成，B只需要2天，那基本就是B先做。

5、谁在外部谁优先。

经常听到的措辞就是：这个功能自己人用的，克服一下，先把这个客户的做了吧，这个需求不做客户签不进来啊……所以，几年来很多内部需求大多都是一拖再拖。

现在回想起来，这些原则不见得都错，但是你是否已经发现，我们决策先做什么后做什么的时候，我们缺了一根弦，一根很重要的弦——项目价值。

项目价值

跳槽到现在这家新公司之后，我发现即便是在这样一家技术团队资源10倍于上一家公司规模的公司，依然面临着资源不足的窘境，每天都有来自各方的源源不断的需求，永远都做不完。公司给我分配了一位非常优秀的前辈导师，虽然年纪只比我大1岁，但是工作能力却比我强太多。

我观察到，我的导师面对各方提过来的需求时，一般都是在耐心听完对方提的需求之后，反问对方一句话：你觉得做这个项目能产生多少价值？这个问题很关键，除去一些影响流程的紧急修复优化类的bug或项目之外，大多数常规的需求在经过这个问题的“洗礼”过后，都可以更加“轮廓分明”地展现在我们面前，比如：

销售：这个xx需求一定抓紧做，这个月底做不出来，客户就丢了！

产品：你的心情我非常理解，不过我能先了解一下做这个项目能带来多少价值你们有评估过吗？

销售：能为我争取回来一个实实在在的客户，这就是价值啊！

产品：这个描述太抽象，能否通过一定的方式把价值量化一下，比如我们评估一下这个客户一个月能给平台带来多少销量。

销售：前期量不是很大，大概5万/月。

产品：也就是说大概一年60万，假设后期量有增长，一年100万销量差不多吧。假设我们做了这个项目帮你签下来这个客户，按照现在毛利3%计算，做这个项目大概可以给我们带来的利润价值是3万/年，对吧？

销售：差不多吧。

产品：我们做好这个需求需要2个开发+1个产品+1个测试，工期大概两个月，按照人均12k计算，人力成本差不多需要9.6万，换句话说，我们至少需要3年才能收回我们的投入的人力成本……

销售：额……那好吧，那你们按照你们的计划排把，尽量给我往前排就好……

这就是绷紧一根“项目价值”的弦之后的效果！就像这个案例一样，我就经常发现，有些一开始提需求提得很火急火燎、理直气壮的人，在经过这个问题的“拷问”之后，慢慢就不那么言之凿凿了，开始接受暂缓需求，甚至于有些最后自己主动放弃了。

产品经理核心工作——需求管理

如果要用一个词来总结产品经理岗位工作的核心内容，那火山的答案一定是——需求管理。

每家公司，每个产品经理手里都积攒着堆积如山的需求，这些需求可能来自用户、销售、客服、老板甚至是竞品，每个需求的提出都自有他们的合理性，那么哪些需求要做哪些需求不要做，哪些需要现在就做，哪些可以以后再做，哪些需求需要一次性做完，哪些需求需要分阶段实现，这中间的取舍考验着产品经理的智慧。

我们都知道，一个需求的优先级是由它的重要程度、紧急程度、工作量、需求来源等等各个方面综合确定的，而在我的需求管理工具里面，实际上也有考虑一个需求带来的价值，即“重要程度”的评判维度。但在很长一段时间里，我们都在疲于应付一些所谓的紧急需求，对重要程度这个维度根本就没有做深入地思考，重要程度指数基本都是产品经理凭感觉确定。也就是说，在我们的决策逻辑里面，实际上是缺少了项目价值这根弦。而这种状态直接导致的结果就是，我们看似做了很多的努力，到最后却依旧发现我们的产品并没有质的变化。

如何绷紧“项目价值”这根弦？

那么有没有什么办法，可以让我们在做产品决策的时候绷紧项目价值这根弦，保证它不被遗忘或忽视呢？

对于这个问题，在成熟的互联网公司实际上基本是不太存在的，因为一个项目在立项的时候，它的项目价值是必须要写明的，如果没有写清楚项目价值，或者项目价值评估得不切实际，那根本立项就是通不过的。也就是说，在成熟的互联网公司当中，这根弦已经通过比较规范的需求管理的流程来保证了。那么，如果你身在一家尚未形成规范流程的创业公司当中，如何才能让自己绷紧这根弦呢？实际上，弦能否绷紧是意识问题，终究得靠自己，我也无法回答，但当我们拿到一个需求，对于要不要做以及什么时候做的问题，火山可以分享一点心得。

想清楚这个问题说难也不难，依据个人经验来看，90%以上的需求，对于“要不要做以及什么时候做的问题”，如果能想清楚两个问题，基本就能解决一大半了，这两个问题就是：

1.做完之后，这个项目能带来什么价值？

销量提升、成本节省、用户增长等维度，尽可能量化。

2.如果不做，会有多大的影响？

人工成本、客户丢失、用户抱怨等维度，看看这个影响是否可控可接受。

以上就是今天分享的内容，希望对各位在产品路上不断前行的PM门能够有所启发。

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