Wiki版产品需求---产品需求文档究竟是谁的？产品究竟是谁的？

     在听了测试的一通唠叨以后，"内部实现一堆逻辑，只有一句话的需求文档"，"文档那么简单，咱们怎么测试啊"，心中忽然想起来本身曾经干的一件当时以为还不错的事情，可是过后想起来，可能比较二的决定，当时在作一个相似原型的产品，那时候的问题就是时间很短，需求根本就写不完，研发测试时间也都是很短，因而当时就决定协做写需求文档，也就是产品经理先给你们讲解一下总体的产品功能，细节的地方没有讲的很透彻。而后在Wiki上先写一个大概的需求，细节的地方，由开发一边开发，一边在和产品经理沟通的过程当中，发现问题，同时由开发进行跟新Wiki文档，这样也就是由产品经理写出骨架，由开发人员进行填充部分细节，而后由产品经理进行完善。

 

      我没有坚持到这个产品作完，就离开了这个组，前两天猛然想起这个实验，或者决定，因而@老熊037 @矿工挖煤 咨询一下总体的效果，总体比我想的要好点，尚未那么糟糕。如下的内容是从对话整理出来的。

     @老熊037: 效果还好吧 ，至少给需求人员减小了很多工做量 ，需求可把精力用在刀刃上。

     @南郭先生kaka：不须要粉饰的话，我就问你，若是再有项目的话，你愿意这样作吗？还有告诉我一些真的话，不足的地方

     老熊037：不论什么决策都须要上下文 ，当时的状况那样的决策是合理的，要不我们的演示版是出不来的。

     老熊037：如今有项目若是给需求的时间充裕，我不肯这么作.

     老熊037：回复@南郭先生kaka:开发参与需求是必须的 。好比瑞瑞最近作质检，作的过程当中就会发现问题 ，并随时与河山沟通完善。参与需求不给开发带来明显额外工做最好。地铁坐过了一站 ，呵呵

     南郭先生kaka：回复@老熊037:需求的时间永远都是不够的，无论你何时来作。缘由：第一计划赶不上变化。第二，需求永远有遗漏的地方，一我的想的不太全。第三，细节永远是魔鬼。第四，有些事开发决定的事情，而这个其实是影响整个项目的。因此，需求永远不会大而全

     南郭先生kaka：回复@老熊037:哈哈，让你坐过站了。可是随手贴上去的内容，并无给开发带来多少的工做量，另外，需求文档，到底应该是谁的？谁的文档？这个问题值得深刻探讨一下。就相似最后的产品，究竟是谁的？产品经理的？需求的？研发的？测试的？若是想明白了，可能那个会不会带来额外的工做，就已经迎刃而解了

 

     

     矿工挖煤：老久不上博了，我谈下个人感觉：你们共同维护一个产品过程当中的文档，的确给需求减轻了很多工做量，重要的是你们都参与对业务有了总体认识，同时还能够记录过程当中的修正背景缘由。

     矿工挖煤：局限：目前这种模式对快速迭代研发新产品是不错的选择，要是走正常规划、概要、详细、评审、开发、测试的流程，开发和测试的参与度应该会下降很多。

 

     和你们聊完了以后，想到了一个问题，也就是我和老熊最后说的那句话。【需求文档，到底应该是谁的？谁的文档？这个问题值得深刻探讨一下。就相似最后的产品，究竟是谁的？产品经理的？需求的？研发的？测试的？】需求文档究竟是谁的？产品究竟是谁？如今的大分工，使咱们只会关注咱们本身的那一亩三分地，不少时候，认为本身的事情作完了，那么事情就ok了，可是不少时候，事情是不是这样的呢？咱们在家里作菜，买菜，洗菜，切菜，炒菜，不到最后的一刻上桌，咱们的这盘菜都是没法吃的。若是前面都作好了，就没有炒菜，前面的一切都是零。

     不少时候，咱们想一个事情作了80%，90%等等，实际上，那些只是阶段时期的百分比，对于整个产品而言，实际上都是0%，没有最后的一刻，那么都是零，多是残酷的，也多是现实的，也多是夸张的。不少时候，事情都有灰色阶段，可是不少时候，事情只有两个阶段，是OR不是。没有其它的。