軟件生命週期
項目規劃
需求方和開發方共同確定軟件開發目標,同時進行可行性研究；
- 經濟可行性。從成本和收益角度分析,看投入產出比。不僅要分析短期利益,還要分析長期利益,看是不是值得做。
- 技術可行性。從技術角度分析是否可行,如果有技術上解決不了的問題又能否規避。
- 社會可行性。社會可行性涉及法律、道德、社會影響等社會因素。比如,觸犯國家法律的事情肯定不能做;產品如若不符合道德標準,可能帶來較大的社會負面影響,那麼也要慎重考慮。
需求分析
對需求方提出的所有需求,進行詳細的分析。這個階段一般需要和客戶反覆確認，以保證能充分理解客戶需求，最終會形成需求分析文檔。
- 收集需求:對用戶需求進行收集整理;
- 分析需求:對需求進行分析,挖掘用戶真實需求;
- 需求評估:篩選過濾掉不可行的需求;
- 需求設計:針對用戶需求提出解決方案,設計成產品方案;
- 驗證需求:驗證方案是否可行。
軟件設計
根據需求分析的結果,對整個軟件系統進行抽象和設計,如系統框架設計,數據庫設計等等，最後會形成架構設計文檔。
架構師如何技術選型？
- 明確目標或要解決的問題；
- 技術調研。調研行業中現有的一些解決方案，重點考慮優缺點、社區活躍度、普及度以及代碼質量等幾個因素；
- 驗證；
- 決策；
如何項目管理？
要管理好一個項目，關鍵是要管理好項目中的人和事。
項目中的人包括客戶和項目成員。對客戶的管理，本質是管理好客戶的期望值，即軟件質量、時間、成本和範圍四個因素間的平衡，”金三角“理論可以幫助我們權衡取捨；對項目成員的管理，要做到”法治“，依靠流程規範管理項目成員，單純的靠項目經理管理，容易出現分歧和瓶頸；
對事的管理即對軟件開發過程的管理，首先選擇好開發模型，然後制定項目計劃，按照計劃推進跟蹤，並及時做好項目的風險管理；
軟件管理金三角
一個軟件/項目沒法發同時實現質量高、時間短、成本低、和功能多的，需要在四個要素間進行取捨。”金三角“理論要求質量不能妥協，在保障質量的前提下，項目管理人員需要在時間、成本和範圍之間權衡。
舉例說明，這幾年流行的MVP開發模式（一開始只推出最核心的功能,滿足用戶最核心的需求,然後在用戶的使用過程中收集反饋,進一步升級迭代），其實就是在保障時間短、成本低的時候，對範圍進行了調整。
流程規範
爲什麼需要流程規範？
- 提高團隊效率；
- 好的實踐可以標準化流程化、有助於沉澱出工具；
- 有助於項目管理；
如何制定流程規範？
- 明確問題；
- 提出解決方案；
- 達成共識，推廣執行；（最好能工具化）
- 持續優化，不斷改進；
業界好的流程規範
- 開發模式： 瀑布模式、敏捷開發等；
- 代碼規範： 阿里巴巴Java開發手冊、Google Java Style Guide；（個人推薦阿里的Java規範，從編程規約、異常日誌、單元測試、安全規約、MySQL 數據庫、工程結構、設計規約七個維度詳細說明了Java開發的流程規範）
- 源代碼管理流程： Git是目前的主流，基於 Git 的代碼管理已經有很多成熟的流程規範可以參考，例如阮一峯老師寫過的《 Git 使用規範流程 》、《Git 工作流程》和《Git 分支管理策略》；
- 部署流程： 持續交付是目前的主流，方便自動化打包、部署、測試等，以及部署規範的實施；
項目計劃
如何制定項目計劃？
- 任務分解。任務儘可能的拆分的細，一方面有助於周全方案；另一方面，有助於工作時間的精準評估；
- 估算時間。爲了精準估算時間，一方面，任務要拆分的足夠細；另一方面，開發人員參與共同評估；最後，考慮增加一些餘量，防止突發事件或者存在未考慮到任務；
- 排任務路徑。根據任務的依賴關係和資源佔用情況，排出合適的順序。避免任務路徑過長，儘可能並行進行；
風險管理
什麼是風險管理？
風險管理就是指在項目進行過程中,識別可能的風險,對風險進行評估,並加以監控,從而減少風險對項目的負面影響。
如何進行風險管理？
- 風險識別，識別可能存在的風險
- 風險量化，對風險進行評估量化（概率和損失）
- 應對計劃，對風險指定應對策略；對於概率大,後果嚴重的風險,需要高優先級重點考慮;對於概率不高但後果嚴重的問題也要考慮,不過優先級略低;對於概率高但後果不嚴重的風險事件,可以優先級很低或者不考慮;對於概率低後果不嚴重的,則可以不予考慮。
- 風險監控，對風險進行監控預警
風險分類
- 項目風險:項目預算、進度、用戶和需求等方面的問題;
- 人員風險:人員離職、人手不足等問題;
- 技術風險:採用的技術所可能帶來的風險;
- 商業風險:與市場、產品策略等有關的商業風險。
常見項目風險
- 第一版做太多功能 ;
- 太依賴新技術平臺;（技術風險）
- 與公司另一個有份量的產品競爭;（商業風險）
- 團隊人手不足;（人員風險）
- 複雜的問題,需要複雜的解法;
- 成員開始隱藏進度落後的事實和原因;（人員風險）
- 不斷更改、增加的需求 ;（項目風險）
- 2.0 症候羣 - 非要更大、更強、更美 ;（項目風險）
- 產品沒有市場立足點;（商業風險）
- 你根本無法解決的大問題；
如何應對需求變更？
- 提升需求確定性,減少需求的變更。這就要求產品經理在需求分析階段就能對用戶需求理解透徹, 比如用原型設計低成本響應用戶需求變更，做好需求分析和確認，減少需求變更；
- 規範需求變更流程,減少需求變更。通過規範變更流程，減少無意義的變更，或者提升變更的成本；
- 通過提升技術或管理的方式，快速響應需求變更。比如通過靈活的架構設計和強大的配置，或者快速迭代，縮短版本週期；
參考：
- 極客時間《軟件工程之美》