我所理解的需求澄清

-0-

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

-1-

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

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

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

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

-2-

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

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

-3-

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

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

最后更新于