Wiki版產品需求---產品需求文檔究竟是誰的？產品究竟是誰的？

     在聽了測試的一通嘮叨以後，"內部實現一堆邏輯，只有一句話的需求文檔"，"文檔那麼簡單，咱們怎麼測試啊"，心中忽然想起來本身曾經乾的一件當時以爲還不錯的事情，可是過後想起來，可能比較二的決定，當時在作一個相似原型的產品，那時候的問題就是時間很短，需求根本就寫不完，研發測試時間也都是很短，因而當時就決定協做寫需求文檔，也就是產品經理先給你們講解一下總體的產品功能，細節的地方沒有講的很透徹。而後在Wiki上先寫一個大概的需求，細節的地方，由開發一邊開發，一邊在和產品經理溝通的過程當中，發現問題，同時由開發進行跟新Wiki文檔，這樣也就是由產品經理寫出骨架，由開發人員進行填充部分細節，而後由產品經理進行完善。

 

      我沒有堅持到這個產品作完，就離開了這個組，前兩天猛然想起這個實驗，或者決定，因而@老熊037 @礦工挖煤 諮詢一下總體的效果，總體比我想的要好點，尚未那麼糟糕。如下的內容是從對話整理出來的。

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

     @南郭先生kaka：不須要粉飾的話，我就問你，若是再有項目的話，你願意這樣作嗎？還有告訴我一些真的話，不足的地方

     老熊037：不論什麼決策都須要上下文 ，當時的狀況那樣的決策是合理的，要不我們的演示版是出不來的。

     老熊037：如今有項目若是給需求的時間充裕，我不肯這麼作.

     老熊037：回覆@南郭先生kaka:開發參與需求是必須的 。好比瑞瑞最近作質檢，作的過程當中就會發現問題 ，並隨時與河山溝通完善。參與需求不給開發帶來明顯額外工做最好。地鐵坐過了一站 ，呵呵

     南郭先生kaka：回覆@老熊037:需求的時間永遠都是不夠的，無論你何時來作。緣由：第一計劃趕不上變化。第二，需求永遠有遺漏的地方，一我的想的不太全。第三，細節永遠是魔鬼。第四，有些事開發決定的事情，而這個其實是影響整個項目的。因此，需求永遠不會大而全

     南郭先生kaka：回覆@老熊037:哈哈，讓你坐過站了。可是隨手貼上去的內容，並無給開發帶來多少的工做量，另外，需求文檔，到底應該是誰的？誰的文檔？這個問題值得深刻探討一下。就相似最後的產品，究竟是誰的？產品經理的？需求的？研發的？測試的？若是想明白了，可能那個會不會帶來額外的工做，就已經迎刃而解了

 

     

     礦工挖煤：老久不上博了，我談下個人感覺：你們共同維護一個產品過程當中的文檔，的確給需求減輕了很多工做量，重要的是你們都參與對業務有了總體認識，同時還能夠記錄過程當中的修正背景緣由。

     礦工挖煤：侷限：目前這種模式對快速迭代研發新產品是不錯的選擇，要是走正常規劃、概要、詳細、評審、開發、測試的流程，開發和測試的參與度應該會下降很多。

 

     和你們聊完了以後，想到了一個問題，也就是我和老熊最後說的那句話。【需求文檔，到底應該是誰的？誰的文檔？這個問題值得深刻探討一下。就相似最後的產品，究竟是誰的？產品經理的？需求的？研發的？測試的？】需求文檔究竟是誰的？產品究竟是誰？如今的大分工，使咱們只會關注咱們本身的那一畝三分地，不少時候，認爲本身的事情作完了，那麼事情就ok了，可是不少時候，事情是不是這樣的呢？咱們在家裏作菜，買菜，洗菜，切菜，炒菜，不到最後的一刻上桌，咱們的這盤菜都是沒法吃的。若是前面都作好了，就沒有炒菜，前面的一切都是零。

     不少時候，咱們想一個事情作了80%，90%等等，實際上，那些只是階段時期的百分比，對於整個產品而言，實際上都是0%，沒有最後的一刻，那麼都是零，多是殘酷的，也多是現實的，也多是誇張的。不少時候，事情都有灰色階段，可是不少時候，事情只有兩個階段，是OR不是。沒有其它的。