实施Scrum这么久，大多数时间花在帮助团队更高效的产出上。最近参加了一些Conference，和一些身边的人聊了一下之后，发现“明确要做什么”也许是比高效产出更重要的东西。或者说，如果能明确需要做什么，也许高效的产出也就自然而然了。
有一个很简单的问题：“每天你花费多少时间在搞清楚要做什么事上面？”其中包括理解需求、理解需求背后的出发点、理解需求的细节、验证需求理解的正确性、反攻那些理解错的需求等等。我问过很多开发人员这个问题，很多人的回答是：一半！这是一个很惊人的数字，如果能更好地沟通清楚要做什么，是否我们就能瞬间提高许多生产力？
我们先撇开敏捷或者Scrum不谈，软件开发无非就是先知道要做什么，然后做出来，两个环节缺一不可。但是目前许多软件公司的管理思路都重于后者，开发经理和开发流程的存在都是为了保证可以按时把东西做出来。回想一下软件开发的过程，开发人员都会有这样的共鸣：“如果真的知道要做什么地话，做出来总归应该是没问题的，最怕就是做着做着，老板们的思路又变了。”这一方面说明软件开发变化是本性，另一方面来说，澄清需求本身可能是比交付软件更困难的事情。
Scrum中的需求管理也就是一份Product Backlog，优先级排序的需求列表。至于这份列表是如何得出的，并没有定义，或者故意不定义。对于刚刚转型做Scrum的公司来说，新的PO要定义清楚这份Backlog简直难于登天。为什么难？因为PO不非常明确产品的大背景和具体的需求细节，也就是PO也不清楚产品要具体做成什么样的。那为什么不找个合适的PO？找不到真的懂产品而且还能和团队天天在一起的。这是许多公司的现状！所以需求没法澄清怎么办？得找到各种各样的老板一起决定要做什么？决定错了怎么办？再找到各种各样的老板觉得怎么改。下面的团队于是就天天跟着团团转！如果这种现状不改变，用不用Scrum，有没有PO都没有多大分别。即使强行用了Scrum，PO也是个伪PO，后面许多人“垂帘听政”。
产生这种情况的根本原因是整个部门或整个组织对所缺乏对所做产品的整体理解。再问几个简单的问题“你所做软件的最终用户是谁？”“他们为什么要用你做的软件？”“你现在所开发的功能能带给用户什么好处？”有多少人（包括开发人员和经理们）能够信心满满地回答出上述三个简单问题？我所见到的很少。大多人在讨论的是几月几号有deadline，而很少讨论所开发的东西。这点很悲哀，我们在不断被逼着交付着我们也不知道为什么要交付的东西。那如何能敏捷？如何能高效？
要改变这个现状，很简单，就是让开发人员了解自己的产品。最直接的就是使用自己的产品，这点对互联网公司可能比较容易，但是大型设备公司，如电信产品就会比较困难。做不到的话，用视频或者lab实验的方式也未尝不可。另外，要把产品的长期规划和短期规划公开出来，显性地让所有开发人员都知道，这样大家才能有共同的目标。在大多数公司中，这些信息都隐藏在少数人手里，管理层认为没有公开的必要性。如果能做到这两点，接下来应该让团队知道当前的交付版本对产品对客户会有什么增值，为什么我们在某个日期需要交付这样的功能。特别是在交付压力很大的时候，更要让团队知道此次交付的价值或者重要性。如果这三点都做到了，再来讨论团队工作的效率和积极性也不迟。
总结来说，让开发人员知道他在开发什么是软件行业中生产力的前提。可惜现在许多公司忽视了这一点。如果公司想做敏捷转型，想要高效，那就先要把产品带入人心。如果每个人都为他开发的产品感到自豪的话，团队不高效也很难！
