[toc] --- ## 困局 相信很多人經歷的一些專案都進入過一個相同的困局： - 組員有點屈：每天加班幹，專案還延期 - 老闆不滿意：每次都延期，後果很嚴重 從事軟體開發多年的老兵都知道，在一個軟體專案的生命週期裡，不可避免地會生產很多變化（人不一定一開始就知道自己要什麼，人也不一定明天要的和今天要的一樣，知道自己想要什麼，也是個迭代過程。此外，資訊從一個大腦到另一個大腦的過程中，必然會發生丟失或改變，這也是引發變化的一個原因），這必然會導致一些返工，嚴重時甚至導致專案的徹底失敗。雖然變化無法完全預測，但是還是存在一些方法論，能使得將變化帶來的問題降到可接受的水平，甚至將快速適應變化視為團隊的核心能力。這裡試提出一些方法，主要從需求分析可開發流程兩個方面討論： ## 需求分析 ### 從大局出發 不謀全域性者不足以謀一域，需求分析的最初階段應該從大局考慮，不要迷失於細節，需做到： 1. 瞭解主要干係人的期望 2. 列出系統都有哪些模組 3. 搞明白哪些是核心模組，哪些時輔助模組 4. 搞明白模組和模組之間的關係 5. 定義好術語 一個專案的成敗與否取決於其結果是否能夠滿足主要干係人的期望，所以首先要搞明白主要干係人的期望是什麼。比如：為什麼要開發一個新系統，目的是什麼？如果已有老系統，干係人希望新系統能夠帶來哪些老系統沒有的東西。 然後就是對系統的整體把握，列出大致的模組劃分，但是不能一視同仁地對待所有模組，應該搞清楚哪些是核心，哪些是輔助，這取決於主要干係人的期望是什麼。這樣在後續開發的過程中可以把精力和資源多分配在核心模組上。 最後就是術語，我覺這是軟體開發中非常重要的一個因素，但是經常被忽視，以至於影響對業務的理解和團隊成員之間的溝通。子曰：“名不正則言不順，言不順則事不成”。語言就是大腦對世界的建模，如果術語不統一，很可能會導致大家認識的偏差，比如某專案裡的“後臺使用者”、“會員”、“內部使用者”、“人員”等，鄙人覺得這幾個術語看起來 很像，甚至在我們溝通的過程中時有混用，有事不免會引起一些誤會。 如果能把術語確定下來，並且大家使用同樣的術語，專案已經成功了一半，畢竟術語就是對需求的建模，有了一套清晰的團隊術語，意味著專案的整個藍圖是清晰的，在諸位大腦裡是基本一致的。術語不能僅停留在口頭溝通上，應該在資料庫表，程式碼變數命名上把它表現出來。如果一段業務很難抽象為一個簡單的術語，需考慮業務是否太多複雜，是否可以分割等。我比較推薦團隊維護一張如下圖這樣的術語表： |術語|英文|說明| |-|-|-| |後臺使用者|user|可以登入後臺系統的使用者| |會員|member|可以註冊並登入手機端App的使用者| |內部使用者|InnerUser|本公司員工中的**後臺使用者**| |人員|person|後臺系統中XXX模組中的資料記錄| 術語定下來後，以下幾個地方要務必使用： 1. 口頭溝通時 2. 需求、設計文件中 3. 程式碼中的變數（有時候用英文複數表示，如**人員**的集合用“people"，而單個人用"person"） 4. 資料庫表（建議用複數，如**人員**表用“people”） ### 詳細的需求 詳細的需求不必一定在開發完成之前全部做完，我覺得應該和開發保持一致，反覆迭代，不斷進化（下文會說到）。況且想在開始開發前就制定一份完美的詳細需求是不可能的。 鄙人覺得我們的需求工作還可以從以下幾點改進： #### 做好記錄 可以簡略地記錄需求內容、提出者（提出著不一定是主要的干係人，需結合干係人的重要程度和功能的重要程度決定需求的優先順序）、時間等，但不建議記錄的非常詳細（可通過口頭溝通彌補細節，至於什麼樣的詳細程度才能正好做到既能說明問題又不至於陷入文件災難，那就是一門藝術了），起一個喚起記憶的作用就好，省的日後撕逼。 #### 群策群力 一些關鍵需求儘量大家都互通一下有無，包括開發人員，測試人員和團隊領導等。團隊的目標是一樣的，不應該把工作分的太分明，人人有份，只是大家擅長的不一樣而已。比如有著豐富開發經驗的程式設計師，也可以參與對需求的討論，也許可以及早發現坑坑窪窪，及早填埋，需求是最關鍵的一環，應該群策群力，做到最好（當然，最後拍板還是需求分析師說了算，如果沒有拍板人，可能會陷入無休止的爭論），反倒是開發的重要性在其次，一般的業務，西二旗隨隨抓一個年輕人，都會寫的。 #### 分清楚方案和問題 干係人有時候會善於提出方案，不善於提出問題，而他提出的方案也許不是一個好方案，經驗豐富的需求分析師或開發者應該通過方案看到問題，然後再根據問題尋找更優的方案，並說服干係人採納。 ## 開發流程 推薦使用敏捷開發方式，以小步快走的方式逐步釋出功能，而不是一次性完成所有功能。具體方式為： - 以2到3周為週期，釋出一次可執行的系統 - 每個週期的末尾，邀請干係人試用，記錄干係人的反饋 - 某個週期的工作任務包括開發新功能和根據上個週期的反饋修改系統 之所以要小步快跑，而不是等所有功能都做完再上線是因為一個軟體系統更像是一個不斷進化的生命體，而不像一個設計好圖紙就可以開工的建築物。這裡有很多不確定因素，會伴隨軟體開發的整個過程，如： - 需求分析師最初對業務的認識不夠深入，容易忽略某些關鍵點，甚至理解錯誤 - 干係人在沒有看到可以執行的軟體前很難確切地知道自己到底要什麼 - 干係人的想法會變 - 資訊從干係人大腦到需求分析師大腦的過程中產生了丟失或改變 如果採用短週期逐漸交付可執行軟體系統的方法工作可以解決如下問題： - 及時發現和更正錯誤，不至於積重難返 - 及時響應來自干係人的變化 - 干係人在整個開發過程中都有對專案進度的把控感 ## 總結 從更高的角度看專案的成敗，其實最重要的是團隊成員的士氣。士氣足，才可以討論方法，士氣衰，幹啥都難。怎麼保持士氣？除了員工待遇，還可以考慮： - 搞好團隊氣氛。定時搞點有意思的活動，比如大家輪流抽空做演講 - 領導重視專案。比如召開專案啟動大會，及時鼓勵團隊 - 別把人機器化。最好是讓大家有權參與專案的方方面面，不要侷限於某一個重複性固定工作 全文完。