說說我們開展項目需求分析的過程

      軟體建設，前期最基本的要算需求分析啦（這裡就摒棄和客戶搞關係，項目立項等一系列官面活動啦），對於需求分析的實施過程也是讓很多專案經理頭疼的事情，需求分析做的不好，前期不能認真地瞭解客戶的真是意圖和辦事流程，最終完成的系統必然被否定，好的就是返工，嚴重的就是restart 。

      我經曆了一些項目（不多5-6個），我發現其實很多時候項目組在客戶進行需求分析的時候，客戶首先問的是你們打算怎麼實現，有無現成的系統，具體的細節等你們做出來再看啦。。。等等，很多時候客戶想第一時間看到你的系統，而不是漫天的聽你和他進行業務的討論。如果一個客戶能超過半小時聽你和他討論業務，那恭喜你，你遇到好人啦，或者說你的面子夠大的。。。。

      某一次，在和客戶討論的過程中，他的一句話提醒了我“你的需求文檔太大，沒時間看，是否有更直觀的東西，比如例子、樣品什麼的”。知道啦，客戶需要的是你去引導他參與你的系統構想，而不是放下手頭的工作告訴你系統的業務知識、流程等。

      回來的過程中，我在想如何能拿出個樣品給他？去網上下載個開源的東東？去畫圖？。。。。畫圖？畫圖？對我想到啦，將我的需求分析細化到頁面上，做一個UI系統，通過靜態頁面來實現我的系統，如果說寫文檔是很多程式員都不像乾的事情，那麼做頁面，做業務設計是他們相對喜歡的。說幹就幹，我召集所有項目組的成員，讓大夥都參與進來，畢竟做靜態頁面是很easy的，沒有request，response，action，dao等等。大家一起開工，平均每天能完成2個模組的cuad設計。再讓美工做一個大體的frame,ok完事啦。

     沒幾天，我帶著我們的UI系統和負責的對應模組的成員，去見客戶啦，在第一時間我讓負責模組的成員。示範、介紹其對應業務的處理流程，客戶一看原來你是打算這樣做的啊。。。。，然後就和我們說，你們這樣做哪裡不對，哪裡少個資訊，哪裡少個輸入項等，在他回複的過程中，我的項目群組成員在UI上及時的修改、確認。一天下來，客戶對我們的實現方式有了很好的瞭解，我們呢對客戶的需求有了更明確的認識，連頁面最基本的element我們都做了認真的討論，我呢將其討論內容形成新的需求文檔，交與客戶簽字確認。。

      整個需求分析完成了，我發現最終時間進度向後延遲了50%,但是心想，又要讓大夥加班啦。。。。。，可後來發現需求分析完成延遲的進度在資料庫設計，詳細設計，代碼編寫的過程中贏回來啦，而其還有提前。最終項目圓滿上線。

     通過這個項目，我認識到做這個系統UI的重要性，前期的需求，項目組能和客戶討論細化到頁面的element，這樣做給項目建設代理很多好處：

1. 對於程式員，在代碼編寫的時候，對業務有了全面的認識，即使是剛進入沒有參與需求活東的項目群組成員，也有一個直觀的認識；
2. 對於資料庫設計，完全可以參照UI來進行業務模型、資料表的建立
3. 使系統詳細設計，有了更為直觀的參照
4. 大大降低系統建設的風險行，避免系統後期，因客戶的需求變更而做的大面積修改

 

以上僅是個人對項目需求分析提出的一個解決方案，僅限於個人的理解，很多不足，請大夥指教，好久沒寫部落格拉，一定有錯別字，哈哈。。。