研发团队如何应对源源不断的、来自多方的用户需求和期待？（一）

我曾在不同的地方看到几乎同样的故事:一个小型研发团队(几个人到十来个人不等)独自面对来自多方的需求，各方需求源源不断地涌现过来，而研发团队似乎除了加班苦干别无选择。

过程很痛苦，结果还不尽如人意：因为需求没有及时交付，不仅需求方抱怨团队低效，团队上级也质疑团队能力不及。

而且随着时间的推移和源源不断的需求涌现，这一切似乎难有改善的迹象，研发团队常常束手无策。

面对这个问题，我觉得可以从两个侧面来应对——优化自身研发过程，和管理用户期待。本篇先讲第一个侧面，优化自身研发过程。

这里需要做两件事：

不论需求的来源有多少，团队始终工作在一个排好序的需求队列上。这个需求队列一定只能是一个，而不是多个。

排优先级，按照排的优先级挨个做。

第一点，先要将各个来源的需求合并成一个队列。这么做的原因很明显，不多说。 我们来看第二点：排列优先级。

我看到的排序有两种，拍脑袋式，和动脑筋式。

拍脑袋式并不是说就一定不好，拍脑袋式的本质其实就是PMP里讲的专家判断，在需求涌现速度和需求来源比较少、需求方之间容易达成一致的情况下是适用的。

显然，本文讨论的这个场景，比如队列里有大几十，甚至上百个需求，拍脑袋式会不够用，所以我们着重来看看动脑筋式。

在需求非常多，需求队列比较长的情况下，我通常都建议团队使用优先级加权评分的方法，给需求打分，然后按照分数来排列，分数越高，优先级越高。

这就涉及到一个算法的问题。我建议根据需求的多样性的程度采用相应复杂程度的算法。无论在何种情况下，采用尽可能简单和够用的算法。

比如就只有几个简单的维度，每个维度是0到10分，然后加起来算总分。

0到10都是本次在需求队列中的需求和需求相比的相对值，而不是这个需求在所有发布过的需求里的绝对值。

可能可以考虑下面这些维度，按实际需要采用其中的几个或者更多维度来计算总分。

用户价值，即用户会得到的好处。

延迟可能造成的损失，比如修复刚刚挂了的服务器(这也是需要和需求统一排列顺序的待办事项)。

对降低风险的帮助，比如要做一个有挑战的技术的穿刺，看用这个技术实现需求行不行。

对本次交付价值完整度的贡献大小。

在讲解这个维度的时候，我喜欢用和大闸蟹这道菜一起上上来的醋碟的例子。

醋单独对用户并没有贡献太大用户价值，但是它对这道菜的完成度有大的价值。

商业价值。

举个例子，朋友圈你看到的微信发的广告，这对于产品团队具有商业价值，但是用户价值就比较有限，如果不把控好度，甚至可能损害用户价值。

如何计算优先级加权分呢？

举个例子：比如采用用户价值、延迟可能造成的损失，和对本次交付价值完整度的贡献大小这3个维度来进行优先级排序。

对于需求R08, 它的用户价值是8， 延迟可能造成的损失是3，对本次交付价值完整度的贡献是6。那这个需求的优先级加权分就是17。

然后用同样的方法评估其他的需求的优先级加权分，最后把所有的需求的优先级加权分放在一起统一排序。

再复杂一些，可能再加一个维度：需求的规模，就是完成需求需要的工作量的大小。需求规模的通常用法是：把上面的各个维度加起来的总分除以需求的规模得分。(这样做的依据是WSJF原则, Weighted Shortest Job First,通俗翻译就是说先做投入产出比高的事情) 。

当需求来源特别多样的情况下，比如来自不同的部门，建议可以加上这个维度，因为这样可以有效促进需求方降低/分解需求规模。

说完了怎么排优先级，再来说谁来排的问题，这个和下篇的主题如何管理用户期待相关性比较大，所以放在下篇一起来讲。

今天讨论的话题，你有遇到过这样的情况吗？你当时是什么角色？你是怎么处理的？欢迎你在后台留言。留言中有趣的故事和好的应对方法我会分享出来。

如果你希望看到更多这样的文章，欢迎关注本订阅号“又快又好做软件”。