数字化团队的需求管理，最小化Output，而不是最大化

“数字化部门明年有什么计划啊？都有哪些事情要做呢？

要做的事情就这么点啊？那怎么支撑预算呀？得多安排点内容啊。”

“数字化部门安排了这么多人手，怎么确保大家工作饱和啊？

每个月安排这么点功能，你怎么保证大家不会划水？得多安排点功能进来啊。”

“我们也想有产品的整体规划，但是我们离业务场景太远，我们希望业务部门或者业务专家，能够为我们提供数字化产品的商业战略指导，但他们也对数字化产品的需求设计也一知半解，更多的只有传统业务的思维，最根本的，数字化产品并不是业务部门的考核指标，能够帮到的都有限。”

“另外，即使有整体规划，却总是被打乱，总是有更高优先级的事情插入进来。给需求排期的需求评审会就像战场，火药味十足，有的事情十万火急，有的事情一拖再拖。这些需求，真的都是根据业务价值优先级来排期的么？有科学的数据支撑吗？还是谁闹得凶，就让谁的需求先上呢？一旦客户方知道这个潜规则之后，大家都来闹，最后乱成一锅粥。”

数字化部门的产品整体规划，常常就这么做成了个笑话。

产品角色是数字化部门的火车头，火车头带的稳健又有节奏，是数字化部门良好运行的关键。

传统企业数字化部门的产品角色有很多种叫法，有的叫PM （Product Manager）也有BA，有的叫PO，有的地方还有大PO，小PO这种叫法，也有地方一个PO忙不过来了，就有几个PO代理人 PO proxy，此外还有很多其他的叫法。

今天不谈这些角色之间该怎么分工，那是完全另外一个话题。

我们今天先来讨论一下，如何更好地管理数字化部门的需求，有没有可能，尽量不要把数字化部门的产品规划做成笑话。

老规矩，我们还是先来看看传统企业数字化部门的需求，都有哪些特点。

1. 来源多，关联复杂。

之前我们也聊过，传统企业数字化部门的需求，来源往往很多，很杂。内部不同部门对同一件事情的描述，很可能互相矛盾。外部不同客户之间的需求好像相似但实际上天差地别。需要考虑的关联系统，关联数据也很多，需要很缜密的系统性思维。一想到同一个数据，不同平台和数据源之间互相矛盾，脑袋就大了。

2. 难制定统筹规划，时旱时涝。

一般软件产品公司，基于企业愿景而制定商业战略，基于商业战略去制定产品目标和迭代计划，都很顺理成章。但这套理论在传统企业数字化部门是常常行不通的。因为传统企业数字化部门不能独立制定商业战略和迭代计划，而是需要考虑主营业务，考虑其他部门，需要考虑客户要求，这些优先级更高的事情。规划总是被打乱，干脆没有规划了。带来的结果就是需求有时候堆积如山，又有时候好像没啥事做了。

3. 离业务场景远，主要靠猜想。

很多次在办公室里做需求分析的时候，我们认为已经推敲的很缜密，很合乎逻辑了。但是一旦拿到业务场景里的时候，往往上来就被打脸。

传统企业的数字化团队想要接触到终端用户，真实的使用场景，很可能需要先越过内部的商务部门，再越过B端客户，最后才能到达终端用户那里。

仔细想一想，内部商务和市场部门，对待甲方爸爸的时候，肯定小心翼翼，生怕影响了客户关系，数字化部门想要随随便便跟客户沟通？门都没有，得先过了自己人这一关。

那这么麻烦还沟通个啥啊，自己想到哪，做到哪就行了。

所谓创新，就是在撞大运。

同时，数字化部门是个花费中心，投入产出比很难计算。那管理层怎么去证明每一笔钱都花得有道理呢？最好的方法就是证明每个员工都饱和到不能再饱和，那就堆功能吧。

收效我们控制不了，但是输出不能少。没准乱拳打死老师傅呢？

一方面，业务场景很难去验证，做什么心里是没底的。另一方面，功能还不能做少了，得多做，让大家忙起来。

哎，太难了。

千万不要以为这是一家两家的特例，上面说的这些是在许多公司里得到验证的通病。

让我们重新回到做产品的本质上来，用最少的Output，获得最大的Outcome，这是做产品的核心逻辑。如果出发点不是这个的话，我们不是在做产品，是在应付上级。

作为有一个产品人，做不出一个好产品，只是为了应付上级做没有价值的东西，这种职业生涯是没有意义的。所以传统企业的数字化团队里面，很难留得住资深的产品人。

说完了现状，我们说回到建议和实践上来。

很多公司都已经采用了需求评审会这个机制，那里也是各个需求方争抢资源，大打出手的地方。

需求评审会里面，大家会用到各种方法来评判优先级，什么Moscow原则，或者WSJF原则，这些都是我们推荐的比较理性和科学的优先级排序方法。也会用到各种非理性的，官职排序方法，性格强势排序方法和嗓门排序方法。

当然，有这样一个会议，是必须要有的，但是远远是不够的。

因为需求评审会只管理了需求的产生环节，也就是从想法Ideas，成为需求Requirements的这个环节。

然而事情远远没有结束，一个产品或者一个功能，都会有一个完整的生命周期。

功能开发可能只是最简单的一步。开发完成了，测试，上线。但依然没有结束。

产品或者功能在市场上推广、应用，需要有一系列指标来衡量是否达到我们的预期，产生价值。谁来定义这些指标？谁来监控、收集这些指标？这些指标衡量了谁的工作？这些角色肯定不能混淆，不能既当裁判又当球员，那谁来定义这些角色？

如果产品在给定的周期内没有达到我们的预期，我们需要如何去挽救，是加大推广力度？更多的宣传？还是继续优化产品功能？

如果依然没有达到预期，我们是否考虑淘汰该产品？淘汰机制是怎样的？如果有几个人用，但是不多，没有达到预期，那么如何合适的退出？微软也淘汰了不少产品，各个老版本的Windows，当年的MSN，MSN空间，马上还要淘汰IE。可以借鉴一下这些产品的退出机制。

相反，如果一个产品反响不错，各个指标显示良好，同时又符合公司的发展战略，那么接下来呢？是加大投入？还是收益套现？

我们打开视野，看一下，一个产品或一个功能的生命周期。

1. idea 想法阶段，可能是自己拍脑门，也可能是某个客户想要。

2. Requirement 需求阶段，这时候我们放进待办列表，安排了一个可能会着手工作的时间。注意了，这里是可能的时间。

3. Deliver 交付阶段，这时候我们终于开始着手开发这个功能了，细节设计，研发和测试，部署都在这阶段完成。

4. Apply 应用阶段，这时候产品或功能被交到真实用户手里，在真实应用场景里了，用的咋样，创造价值了么？各项指标如何？

5. Boost 激励阶段，这时候，产品反响很好，我们可以趁热打铁，增加收益，如果反响不好，可能需要加大投入尝试挽救。

6. End 完成阶段。这里有三种情况，

1. 1. 第一种，产品成了爆款，成为战略级的产品，那就需要正式把这个产品推进下一阶段了，需要提到一个更高的地位上来，单独立项，单独规划投资。

   2. 第二种，产品有人使用，客户粘性也够，但增长空间有限，产生的价值有限，仅仅是维护就足够了。那么需要转化成维护状态，投入成本，团队规模和能力都要做相应调整。

   3. 第三种，产品没人用，或者没几个人用，那就只能宣告产品正式淘汰。

当我们开始接触一个需求的时候，不只是先想它的优先级是在手里这么多事情里面排第几。更应当先想想它的整个生命周期，其中最重要，也是最容易被忽略的几点就是：

1. 这个产品或功能的运转各项指标是什么？谁来监督评审，谁来收集，谁来提升这些指标。

2. 什么情况下要考虑进入激励阶段，激励阶段的投入有多少？就好比赌输了钱，我手里还留有多少筹码可以加码？

3. 这个产品或功能，进入维护期，交给谁来接盘？关停好说，就没有额外工作量了。进入下一阶段也好说，需要单独筹划预算。进入维护期就复杂了，进入维护期的产品越多，业务越复杂，团队的担子越重。

这些都对应着产品生命周期里后面几个阶段。如果没有提前想清楚，就开始给需求排期，开始开发。最后的结果肯定是打乱仗的。头两个项目还好，越到后面，进入生命周期后半场的产品或功能越来越多，数字化团队就开始吃不消了。随着包袱越积越多，最开始还担心工作不饱和，马上就会发现满头包。

那么如何增加对产品或功能全生命周期的关注呢？

1. 升级需求评审会，在需求产生阶段就要考虑运行指标、监管角色、追加筹码的能力，以及善后的工作。

2. 成立产品评审会，定期盘点整个产品资产的健康状态，加快试错和淘汰速度，定期大扫除，给团队减负。

当然，这里说明一下，产品级和模块级的需求才会进入到评审会里来。功能级别的需求，例如Feature级和Story级，像是修改几个字段，增删改查的功能，肯定是日常产品经理自行处理就好了。注意需求分层就好了。

这两个操作在通常情况下，能够减少很多Output，一方面控制进入需求的质量，另一方面去掉没带来价值的产出。

当然，会有很多类似的实践来控制产出，提升成效。目的必须很明确，我们追求的是成效outcome，而不是产出output。时刻需要想到如何最小化Output，获得最大的收益。

这些的前提，只能是控制要做的事情，才能有精力把手头的事情做好。

好了，虽然讲的是需求管理，但这一期并不是讲产品规划该如何做，或者排优先级的方法论，这些方法论太容易被用歪。我们需要的是建立一种机制，能够让组织更活跃，更健康，能够自我调理和成长。

这才是组织的价值所在。

这里是老袁讲敏捷，B站同步更新。