# 我所理解的需求澄清

-0-

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

-1-

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

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

![](/files/-MDsDl2eUCHCMLpYKjYd)

![](/files/-MDsDoCaykQhvX0ooPOJ)

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

![](/files/-MDsSxjcz5aDer3gBh5l)

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

-2-

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

![](/files/-MDsmqNoETD9N-lMa5aR)

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

![](/files/-MDsT4wkRrdXCXwsZi_b)

-3-

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

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.oulan.com/feel/thoughts/wo-suo-li-jie-de-xu-qiu-cheng-qing.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.