作为公司中的软件交付团队，如果你能有机会对软件生命周期的其中一个阶段进行改变，你最想改变的阶段是什么？
被访谈到的团队，几乎99%的都选择了需求分析阶段。
需求之痛，最痛包括以下：
- 需求范围界定不清，含混性强
- 需求变更频繁，不确定性强
- 需求的价值不可量化
如果打算改善需求分析阶段，你想如何来改变？
这一次，很多同学都指向了一个解决方式：规范化流程，系统化需求文档。甚至大家为应该由哪一个角色来书写需求文档而争论不休。
“Plans are nothing; planning is everything.”——Dwight D. Eisenhower
艾森豪威尔将军曾经对于Business Plan有过此经典的评价。
对于上面的解决方式来说，CC先生也想说一句：
Documents are nothing,Documenting is everything
文档什么都不是，而编写文档的过程却是一切
对于含混性的理解，就像一千个读者眼里有一千个林黛玉（一般说哈姆雷特）一样。
比如对于以下一首小诗的解读：
A Book of Verses underneath the Bough,
A Jug of Wine, A Loaf of Bread—and Thou
Beside me singing in the Wilderness—
Oh, Wilderness were Paradise enow!
from Rubaiyat
黄克孙版译诗：
一箪疏食一壶浆，一卷诗书树下凉。
卿为阿侬歌瀚海，茫茫瀚海即天堂。
郭沫若版译诗：
树荫下放着一卷诗章，
一瓶葡萄美酒，一点干粮，
有你在这荒原中傍我欢歌——
荒原呀，啊，便是天堂！
还有好多的翻译范本。因为不同的译者的经验和能力，出来的翻译各有特色，需求的含混性也是如此。
人的记忆和思维方式各异，可能面对的是同一个用户的需求，不同的需求分析者得出来得用户画像也不尽相同。此时，单纯的追求需求文档的规范性和流程的系统化并不能很好的解决需求理解不一致的问题。
讨论需求文档的过程却是解决这一困局的有效方式。在对需求含混性的不断讨论中，至少团队对一个需求的理解会越来越趋向于一致。敏捷实践中的实例化需求就是一个消除需求含混性的有力手段，它并不能做到穷尽性的需求挖掘，它更大的作用在于促使团队针对需求的含混性、不确定性，不可量化的价值进行进一步的讨论。
Documents are nothing,Documenting is everything
希望下一次写需求文档的时候，大家不会再那么纠结。
