需求多做不完怎么办——研发团队如何应对来自多方的用户需求（三）
上一篇我们讲了两个应对措施之一的优化自身的研发过程，今天我们来讲另一个应对措施：管理用户期待
首先要澄清的一点是：管理用户期待的目的不是控制用户期待，而是在与用户的进一步合作中与用户达成共识。
要管理用户期待，我的建议以下两点：
一， 信息透明。
二 ，给用户的交付日期承诺是可靠的。
秉承本专栏短小精悍的原则，本篇先讲第一点：信息透明。
如果用户/需求方提出了一个需求，这个需求就像进入了一个黑匣子，用户不知道这个需求目前进展如何，也不知道什么时候能交付。
在这种情况下，用户所能做的就是等待，并且把实际交付结果和自己内心的期待进行比对。
比如用户觉得1周就应该交付，如果过了1周没有交付，用户就会觉得失望。
如果1.5周的时候还没有交付，用户就会觉得做得有点慢。
如果2周的时候还没有交付，用户就会觉得做得太慢。
如果3周的时候还没有交付，用户就有可能要去研发团队上级那边投诉了。
用户的反应不是完全没有道理，但是用户可能不知道的是：
1. 研发团队不仅仅只是要做他一方提出的需求。
2. 用户的一个需求，不是提出之后就开始编程，编程后就可以交付了这么简单。
每一个需求，从提出，到需求分析、解决方案设计、方案评审、开发、测试、发布，都要经历一个过程，有的需求，可能前期还要做穿刺(Spike)，或者依赖于其他组件的实现才能交付。
研发团队需要把上面两点透明出来，让用户知道。
如何透明？
第一，队列透明。即研发团队需要完成的所有需求（也就是待办事项的队列）对所有用户透明。
在上一篇里我们有说到一点：把各个需求方的需求统一排序形成一个队列。把这个队列透明出来，就相当于把上面的第1点信息透明了。
用户能在队列里看到他自己的需求的位置，就像一个用户来到银行办理业务，他/她拿到一个号，能看到前面在等待的人数一样。
第二，排序规则透明。即研发团队需要完成的所有需求的排序规则对所有用户透明。
银行的排号，就是按照客户来的时间先后顺序来的，而在软件研发中，排号的依据考虑的因素可能更多。
研发团队要做的，就是在所有事开始之前，和各个用户/需求方代表协商，就排序规则达成一致。（排序规则见上一篇）
第三，排序的决策方式透明。
现在来解答排序谁来排的问题，我的建议是：可以多人协商，但到最后，只能是一个人，而不是一个委员会来做最终的排序决定。这个角色就是产品负责人。
有可能研发团队面对的是多个产品需求，不过我们仍然可以沿用产品负责人这个名字。
产品负责人的选择标准建议满足下面的要求：
是一个人，而不是两个人或者委员会；
这个人和研发团队一起密切工作，而不要是一个研发团队平时很难找到的一个人，不论是因为距离还是因为这个人的可用时间；
-
这个人不是兼职在做产品负责人这个角色，因为产品负责人是非常重要的角色，这个角色是一份全职工作。
比如一个人，他/她本来有自己要做的本职工作，然后“顺便”兼任一下产品负责人。不推荐这样的做法。
我曾经看到过一个人同时担任两个研发团队的产品负责人的情况，这种情况的出现通常依赖于产品负责人和各个研发团队自身都已经有比较稳定的工作节奏了。
在初始阶段，通常建议一个研发团队对应一个全职的产品负责人，尤其是这个团队面临比较复杂和多元的需求来源的情况下。
这个人有产品经理需要的技能；
这个人有好的沟通协调能力；
这个人是各个用户/需求方代表，和研发团队各方代表认可，可以担任产品负责人这个角色，对排序做最终决策的人。这意味着大家尊重这个角色的最终决策权，和决策结果。
上面第2点“需求研发过程”的信息透明，也就是在一个用户的需求进入开发阶段之后，用户可以更细化的了解这个需求目前的状态，这可以通过看板来实现。
看板是大家都比较熟悉的一种模式，这里不做太多介绍。（后续会有文章给大家介绍看板的高阶运用，感兴趣的朋友请关注。）
讲完了第一点信息透明，我将在下一篇来讲讲第二点：给用户可靠的交付日期承诺。这一点对研发团队提出了更高的要求。
管理用户期待，你有什么好的独门秘籍，欢迎你在后台留言！
END
精选文章
“轻松做软件”是IT人的效率公众号，不加班必备
科学工作，少走弯路，快来关注吧！