在听了测试的一通唠叨之后，"内部实现一堆逻辑，只有一句话的需求文档"，"文档那么简单，我们怎么测试啊"，心中突然想起来自己曾经干的一件当时觉得还不错的事情，但是事后想起来，可能比较二的决定，当时在做一个类似原型的产品，那时候的问题就是时间很短，需求根本就写不完，研发测试时间也都是很短，于是当时就决定协作写需求文档，也就是产品经理先给大家讲解一下整体的产品功能，细节的地方没有讲的很透彻。然后在Wiki上先写一个大概的需求，细节的地方，由开发一边开发，一边在和产品经理沟通的过程中，发现问题，同时由开发进行跟新Wiki文档，这样也就是由产品经理写出骨架，由开发人员进行填充部分细节，然后由产品经理进行完善。
我没有坚持到这个产品做完，就离开了这个组，前两天猛然想起这个实验，或者决定，于是@老熊037 @矿工挖煤 咨询一下整体的效果，整体比我想的要好点，还没有那么糟糕。以下的内容是从对话整理出来的。
@老熊037: 效果还好吧 ，至少给需求人员减少了不少工作量 ，需求可把精力用在刀刃上。
@南郭先生kaka：不需要粉饰的话，我就问你，如果再有项目的话，你愿意这样做吗？还有告诉我一些真的话，不足的地方
老熊037：不论什么决策都需要上下文 ，当时的情况那样的决策是合理的，要不咱们的演示版是出不来的。
老熊037：现在有项目如果给需求的时间充裕，我不愿这么做.
老熊037：回复@南郭先生kaka:开发参与需求是必须的 。比如瑞瑞最近做质检，做的过程中就会发现问题 ，并随时与河山沟通完善。参与需求不给开发带来明显额外工作最好。地铁坐过了一站 ，呵呵
南郭先生kaka：回复@老熊037:需求的时间永远都是不够的，不管你什么时候来做。原因：第一计划赶不上变化。第二，需求永远有遗漏的地方，一个人想的不太全。第三，细节永远是魔鬼。第四，有些事开发决定的事情，而这个实际上是影响整个项目的。所以，需求永远不会大而全
南郭先生kaka：回复@老熊037:哈哈，让你坐过站了。但是随手贴上去的内容，并没有给开发带来多少的工作量，另外，需求文档，到底应该是谁的？谁的文档？这个问题值得深入探讨一下。就类似最后的产品，到底是谁的？产品经理的？需求的？研发的？测试的？如果想明白了，可能那个会不会带来额外的工作，就已经迎刃而解了
矿工挖煤：老久不上博了，我谈下我的感受：大家共同维护一个产品过程中的文档，的确给需求减轻了不少工作量，重要的是大家都参与对业务有了整体认识，同时还可以记录过程中的修正背景原因。
矿工挖煤：局限：目前这种模式对快速迭代研发新产品是不错的选择，要是走正常规划、概要、详细、评审、开发、测试的流程，开发和测试的参与度应该会降低不少。
和大家聊完了之后，想到了一个问题，也就是我和老熊最后说的那句话。【需求文档，到底应该是谁的？谁的文档？这个问题值得深入探讨一下。就类似最后的产品，到底是谁的？产品经理的？需求的？研发的？测试的？】需求文档到底是谁的？产品到底是谁？现在的大分工，使我们只会关注我们自己的那一亩三分地，很多时候，认为自己的事情做完了，那么事情就ok了，但是很多时候，事情是否是这样的呢？我们在家里做菜，买菜，洗菜，切菜，炒菜，不到最后的一刻上桌，我们的这盘菜都是无法吃的。如果前面都做好了，就没有炒菜，前面的一切都是零。
很多时候，我们想一个事情做了80%，90%等等，实际上，那些只是阶段时期的百分比，对于整个产品而言，实际上都是0%，没有最后的一刻，那么都是零，可能是残酷的，也可能是现实的，也可能是夸张的。很多时候，事情都有灰色阶段，但是很多时候，事情只有两个阶段，是OR不是。没有其它的。