M產品研發日誌–開篇

      M產品醞釀了那麼長時間，終於大規模的研發了，實屬不易，但是擺在K君面前的困難還是不少的。6大模組同時發力，需求欠缺，只有概要需求，時間期限很緊，人員缺失，研發人員，需求人員都存在著瓶頸，並且年底前需要出α版本。想到了這些腦袋就已經大了。

 

      如何做？怎麼做？那麼多的需求，需求人員對應的過來嗎？研發人員一起研發6大模組，還是像以前一樣，等待著需求寫出來，評審完畢在進行嗎？那麼到了年底，估計需求還沒有搞完呢，更別提示範版了。那麼如何去做，需求成了瓶頸，how can we do？

 

      不過K君也很興奮，因為越是這樣，就越有挑戰，只有這樣，才能磨合出另外的一套山寨敏捷，也是最想做的另外的純山寨版的流程，說幹就幹吧。

 

        首先和需求的Z君進行了協商，要求他們全力配合進行，需求需要進行概要講解，全力配合後面的隨時諮詢事項。也就是他們可以唯寫隻言片語的需求，剩下的就靠說，只要說能應付過來就可以。剩下的，功能節點設計，都靠討論進行。其餘的細節需求，由研發人員跟上，進行補充。

 

       那麼如何保證這樣的流程順利呢？什麼樣的工具最適合這樣的流程，這些的協作呢？沒錯，當仁不讓的出現在K君腦海裡面的就是Wiki，比較了幾大Wiki之後，選擇了HDWiki，大家一起寫需求，不再依賴需求人員，需求人員搖身一變，已經成為了產品經理的角色了。

 

       具體編寫需求流程討論後，決定，由需求人員現在Wiki上面編寫部分內容，也就是關鍵的內容，然後研發人員根據這部分需求進行討論，分析，形成新的功能點設計，討論的細節，內容，更新到wiki上，這個可以由需求人員和研發人員共同完成。後續再研發過程中的討論細節點，由研發人員逐步更新完善到Wiki上。最後時刻，由需求人員進行完善。

說的容易，做的難，後續還有很多需要考慮的，還有很多困難，但是慢慢來吧，K君做好了充足的準備和打算。

 

        也正是因為會有很多的苦難和挫折，所以打算從現在開始，進行記錄下M產品的研發過程，記錄過程中的痛與苦，記錄過程中的思考和挫折。為自己將來的分析提供素材，也為大家提供一個參考。不過對於錯，它都是一個經驗。