如何推進你的建站需求分析

發布日期：2013-10-13 閱讀：2823次

　　我們在做一個無錫網站建設的時候，往往需要先分析用戶的需求，全面把握決策的方向，才能讓網站的建設的執行過程中更加順暢。永燦結合自己多年的建站經驗與大家來探討下，如何在建站之前先做好四步基礎步驟——確定、分解、評估、決策，在網站建設中全面推進了解客戶的需求，做一個讓客戶滿意的網站。

　　確定

　　首先要先搞清楚網站的產品模塊，需要解決哪些問題，事先要先做好調研工作，多了解一些信息，才有可能真正了解一個網站真正的需求是什么，在確定環節中，這只完成了一半的工作；接下來我們需要知道對應這個需求，會有哪些角色來使用，我們需要能夠對這些角色涉及到的不同需求做出細分。

　　分解

　　分解的意義在于把大問題化解為小問題，變成一個個可控的模塊，注意這里是說的可控是指你可以通過一定的約束條件和已知存在的變量來實現對問題的描述。通常有兩種分解的方法：

　　一，流程驅動：根據業務流程和業務需求建立對應的uml，或者也可以對應每個角色建立起一個虛擬人物，把整個業務流程完整走一遍，這樣可以模擬出實際操作中會出現哪些具體問題，在完成較終的業務目標前，可能會出現的階段性目標有哪些，同時又會有什么樣零星的小需求出現。很多這些過程中的需求是業務部門不會提及的，你有責任告訴他們這些情況。

　　第二，公式驅動：以應用類產品舉例，如果一個公司可以同時向用戶提供兩種服務A和B，二者的利潤不同，同時又會受到市場季節性需求變化和產能供應量的限制出現數量上的波動；現在要求我們能夠找到合適的資源分配方式，來讓公司獲得較大的盈利。這其實就是一個根據制約條件來找到A和B兩種服務對應各自需要有什么變量的問題。不妨列出一個公式，看看究竟各個制約條件之間是如何影響的，從而找到合適的解決辦法。

　　分解階段另一件重要的事情就是完成流程圖的設計，對應產品人員要做的是業務流程圖，如果有核心開發人員也參與了前期的需求討論分析，可以建議他們同步展開架構流程的思考。在繪制流程圖的時候需要盡可能標明其中的里程碑功能，大約需要哪些功能支撐、需要設計多少個頁面或頻道、組件，對應的管理后臺需要有哪些對應的調用。

　　先做完流程圖，一方面尋找答案，一方面也可以完善你的流程圖。如果能夠一路堅持走下來，基本上可以做到很完整地了解自己要解決些什么問題了。這時候你面對的就不再是一個總的需求，而是一個個細節的問題。接下來要做的就是對各個問題進行評估，

　　評估

　　如果我們把分解理解為找問題，那么評估就是為解決問題做準備。例如，你打算使用多少個頁面、會有多少個功能點出現。這些經過分析提煉后的內容可以用PRD或者低保真原型的方式展現給相關的開發人員和業務部門。

　　評估較重要的工作是需要對這些即將展開的工作做出排序，可能會舍棄一些原本精心構思的內容。對工作的排序是產品自己無法完成的，需要盡可能和開發部門配合。開發人員對于業務需求有著自己的一套理解，同時由于涉及到很多實現細節的問題，也需要在達到共識的基礎上才能繼續推動。

　　在真正展開具體的產品設計工作之前，需要能和開發人員進行溝通，盡可能做到以下幾點：需要多少個功能點來支撐這個產品或滿足需求；這些功能點都是可以在規定項目時間內開發完成的嗎？

　　開發人員對于自己要做的事情有足夠的判斷，知道哪些應該先做，哪些要后置；對于暫時無法實現的功能，是退回給需求方，還是產品重新構思或者延至2.0版本完成，需要說明清楚。對于沒有技術背景的產品，這時候很容易陷入被動，盡可能找到一個能和你順暢溝通的技術經理。

　　決策

　　首先是制定項目計劃，針對每個細分功能拿出具體的實現策略，給出產出物的交付時間，繪制原型圖和PRD文檔。從產品整體框架到頁面布局、頻道功能再到按鈕的位置，彈出層的設計。設計的創意才在這里真正迸發，你所有知道的界面設計、導航架構、交互形式的知識和才能都會在這里得到淋漓盡致的體現。

　　暫且撇下你的設計創意不表，如何把評估階段的成果應用好是我們是否能順利進入決策階段的關鍵。總會有一些功能被砍掉，也有一些新功能提出來，原本想好的某些流程也可能要重新調整。在決策階段，你需要拋棄一些東西，適當做一些讓步，才能保證產品的核心功能延續。

　　總結

　　通過確定、分解、評估和決策把需求分析階段要做的事情做一個梳理，也為后面的設計和開發開了一個好頭。但是在實現上可能需要做一些變通，項目一旦進入到開發編碼階段，時間會非常緊湊，你能做的就是根據新提出來的想法迅速協調好利益相關部門，在開會之前你就能要準備好幾套方案，全面協調與兼顧各個部門的需求。

聲明：本站部分文字及圖片均來自于網絡，如侵犯到您的權益，請及時通知我們進行刪除處理。