做了中台就不会死吗？每年至少40%开发资源是被浪费的！

戳蓝字“CSDN云计算”关注我们哦！

640?wx_fmt=jpeg

文/黄哲铿

编辑/Emma

上周受邀去一家互联网公司做分享，有学员提到一个问题：

“技术中台，如何应对那么多小前台的需求？先做哪个，后做哪个？”

这是个比较普遍问题，尤其在“中台战略”盛行的今天，许多公司都纷纷建设自已的前台、中台、后台系统。

以电商系统为例，前台的微信小程序端、App端都向订单中台提了需求，那么订单中台先做谁的需求？假如他们都声称这是老板的需求，资源冲突的情况下，你又该如何判断？

需求的“失控”，往往是灾难的开始

在那一场分享里，关于这个话题，讨论得非常激烈，其中一位总监就问了上面的问题，我问他目前有没有做需求治理？就是给每个需求一个等级，把所有需求按优先级进行排序。他说，还没有，之前有探讨过要建立这个机制。

我接着问，那之前是如何解决资源冲突的问题？他说，解决不了，所以想请教下老师有什么好的方法？

我心想这是在考我呢，我回复他，如果没有需求优先级，可以先跟需求方沟通，不行再向上升级，大家一起来讨论决定。他说，讨论过了，但是没有结论，或者结论是需求都要做。

我说，那就申请加人吧。他说，提了，但是领导不同意。我说，那就加班吧，996。他说，已经在996了。下面的学员纷纷讨论起来，已经顾不上讲师的存在了，似乎在这个问题上很有共鸣。

没等我回答，那位总监又继续说，这场分享应该叫老板来听的（指他们CTO）。

我苦笑着说，我只是个来做分享的。

个人非常喜欢这家公司的文化，畅所欲言，渴望成长，追求极致，就像他们写在涂鸦墙上的话一样：就算做咸鱼，也要做最咸的那一条！

纵然，作为一条咸鱼，多咸一点和少咸一点，在价钱上是没有分别的，但还是要给这种积极向上的人生态度喝彩！

下面我们来聊聊，关于需求治理的话题，即便你的公司没有采用中台架构，当公司规模达到一定程度的时候，就会出现开发资源冲突，这时候就要做需求治理了。

需求缺乏治理，40%以上的开发资源被浪费

经过对10多家互联公司需求价值达成情况的调研，在所有已上线的需求当中，有将近45%需求是没有达到预期的，其中23%的需求，上线后根本就没有使用过，这直接导致了开发资源被浪费，而这种浪费，通常在需求评审阶段可以避免的。

640?wx_fmt=png

通过建立起需求治理机制，可以减少“低价值”需求对开发资源的浪费，意味着公司战略更聚焦，跑得比别的竞争对手快，就有更大的概率在竞争中胜出。

这里提供两种需求治理的方法，供你参考。

第一，以价值为导向的需求治理机制

把有限的开发资源，投入到更有价值的项目上

以价值为导向的需求治理机制，其目的是把有限的开发资源，投入到更有价值的项目上，该机制分成几个部分：

建立需求管理闭环。以价值为导向的需求治理机制，是在需求提报环节，提出该需求的价值预估，即这个需求将给业务带来什么样的价值，这些价值要能够量化、能够追踪。比如，一个结算系统需求，价值是：提升客户对账效率20%，上线后会来验证效果，看看是否达到预期。

整个闭环，分成：提交需求、排期开发、上线运营、需求调整，4个环节。

在提交需求环节，需求提报方要给出可量化的价值预估。

在排期开发环节，开发团队将需求池里的需求按价值大小进行PK，价值高的需求会排在前面，优先安排开发资源。

上线运营环节，对该需求的价值进行验证，验证的结果将影响需求提出方的信用等级，信用等级将用于需求PK阶段，作为加减分项。

需求调整环节，也将价值做相应的调整，形成新的需求，反复迭代，形成流程的闭环。

640?wx_fmt=png

制定需求优先级的准则。从紧急程度、重要程度将公司的需求分成三个等级，P0为优先级最高，P2为优先级最低。如下图所示，横坐标按重要程度，分为三类：公司战略项目、各部门重要项目、非核心业务项目。

640?wx_fmt=png

例如：公司战略项目和部门重要项目，同时又非常紧急的，这类项目是P0级项目。其它类型项目，你可以轻易的对号入座了。

对于P0级项目，要求所有团队停下手中的项目，优先插入P0级项目。所以这类项目的审批要慎之又慎，因为它对现有开发节奏伤害最大，通常在紧急情况下才允许批准这类项目，例如，离双11还有10天，此时发现一个秒杀系统的性能瓶颈，这个需求就是P0级别，必须马上投入资源做。建议这类需求占比，控制在10%以内。

对于P1级项目，可以等这个迭代完成后，加入到下个迭代进行开发。因此，通常的重要项目多为P1级项目，它的占比能达到70%左右。

对于P2级项目，是要在完成所有P0、P1项目之后，有剩余开发资源了，才可以做。这类项目占比在20%左右。

开发资源冲突解决办法。在协商未果的情况下，自下而上层层升级，直到问题解决。此外，跟业务方的月度需求沟通会，季度需求复盘会，这类正式沟通会议要形成常态。

除了正式沟通之外，非正式沟通也是解决资源冲突的办法，闲聊的时候，业务方会有意无意的提到一些尚在构思中的运营想法，一来可以帮助我们更了解业务，二来我们能够更早的判断未来业务方向。

掌握了这些信息，可以及时提醒开发同学，“此处不要写死，将来是要变的” 做到未雨绸缪，少埋坑。

第二，基于OKR的需求聚焦与创新

向上对齐，左右对齐，让企业实现突破创新

什么是OKR？

OKR是一种战略目标任务体系，是一套明确目标并跟踪其完成情况的管理工具和方法，由英特尔公司发明。
OKR由一个需要极致聚焦的明确目标和量化该目标的数个关键结果这两大主要部分组成。
O是Objectives，KR是Key Results，OKR就是Objectives and Key Results，即目标与关键结果法。

OKR由英特尔公司发明，安迪 · 格鲁夫解释道：

这种目标管理的两个关键词是 “目标”和“关键成果”，它们分别对应着两个目的：目标是方向，关键成果需要得到评估，但是最终结果显而易见，根本不需要出现 “我做了这个吗，或者根本没做？” 那样的争论，是或否，就是这么简单。

英特尔按OKR方法，制定战略，并将其转化为可实施、可协作的项目。

谷歌的创始人之一佩奇，他说OKR对谷歌而言是“一份大礼”，并将其优势总结如下：

OKR方法简单易行，非常容易实施。
谷歌把所期望达到的关键结果描绘成清晰的蓝图，然后将其分解成可以逐步实施的计划。
对领导者来说，OKR可以帮助他们更加清晰地看到企业内部发生的变化，因为OKR可以让企业内部的很多事情变得“可视化”。
同时，OKR也可以作为逆向思考问题的有效方法，例如，你可能会问：“用户为什么不能立即在YouTube上加载视频？这一目标难道不比下一个季度的其他目标更重要吗？”

简而言之，OKR让决策者和公司的其他成员总是能够把时间和精力聚焦在最重要的任务上，从而完成公司的使命。

在OKR的目标和关键结果制定过程中，有一个非常重要的环节，叫做“对齐”，指的是每一次制定完OKR之后，要看看你上级的OKR，跟你定的OKR，是不是方向一致的，这叫“向上对齐”。

同时，也要“左右对齐”，看看兄弟部门的OKR有什么冲突的，或者需要你支持的。比如，你的领导本季度的OKR中有一项：聚焦业务系统开发，支持市场拓展。而你本季度的OKR却聚焦在底层架构重构，不做业务系统的开发。这就有问题了，需要跟上级的OKR对齐，保持方向上的一致。

一旦出现了开发资源冲突，就把大家拉到一起，把各自的OKR列出来，看看我们是否在同一个方向上聚焦，如果不能达成一致。就把上级领导的OKR拉出来，看看他的OKR聚焦哪个方向，甚至看公司CEO的OKR，通过聚焦目标、对齐的方法来解决开发资源冲突。

以上提供了两个方法来解决需求治理的问题，供你参考。关于OKR的知识，篇幅有限不能过多展开，想了解更多的话，请关注我的好朋友黄勇的OKR课程，相信你会有更多收获。

640?wx_fmt=png