我所理解的需求澄清

-0-

需求澄清是软件开发过程中一个重要的过程。开发团队都知道，一个好的靠谱的需求，一个设计合理，一个在开发过程中不会变更，一个在验收的过程不出幺蛾子的需求，十有八九是开发团队的美好记忆。它那么爽，就像是夏日里的冰冰凉。现实情况通常不是如此。

-1-

于是人们纷纷追逐靠谱的需求，通常会说，一份靠谱的需求（文档）。鉴于我辅导过的很多团队还在瀑布和敏捷套路之间漂泊，这个重责通常是落在BA的肩上。于是我们对BA提出各种各样的要求，规范各种流程，甚至去制定标准，期待能交付更靠谱的需求，让开发更顺利。如果一个BA能达到这样的标准，那问题就解决了。看，如果事情没有做好，我们就会说：你看，一个合格的BA多么难找啊，现在的BA都不合格。于是靠谱的需求就基本上是不可能的。这是一个上限。

我们来看看这个过程。虽然我们希望有个完人出现，他懂业务，也懂技术，除了开发也懂测试，甚至，连运维耶不遑多让，更有甚者，他了解硬件、虚拟化、网络传输、……这样就完美了。看下面的常见交付价值流：

需求设计就交付了完美的需求给研发，澄清完美，一待排期，开发就轻松交付了。然而，真的可以这样吗？问题是，开发吸收了多少？测试接受了多少？UAT能认可多少？时间上可以接受吗？性能呢？发布需要多长时间？一堆的事而等着呢。就像下面这张传球的图：

而且一个人真的可以搞定？其他人真的没问题？我在想一群人的事情，把责任推到一个人身上。小了说是推卸责任，往大了说就是没有底线吧。一个球队进攻，发动攻击的这个人就相当于是需求，踢的好不好是他个人的能力，球队能不能进球不是球队的配合问题吗？

-2-

我们来看一下乔哈里视窗模型。在整个需求的澄清过程中，我们不是应该将澄清需求的内容把它变成我们的公有知识吗？那在这个过程中，什么能力重要？那就是立足于当下，如何使参与研发（包括需求和运维等）的人，可以充分的对齐信息，让需求可以靠谱的交付。

就像是在Scrum从橄榄球中学习的方式：

-3-

我们经常看到的澄清方式就是一个人坐在前边念。一群人带着电脑，在下面噼里啪啦的参与。这球传着关注的人都少，还指望传个好球就可以进球？

是时候改变一下观念和方法了。