這個話題很明顯是個仁者見仁，智者見智的話題。作者也只是分享一下自己的心得體會，如果高見還望指教。

不知各位讀者在看到管理這個詞的時候，第一反映聯想到的是哪些詞，是人員，還是資金，還是流程，還是專案。作者曾經參加過PMP的培訓，給作者留下印象最深的就是這樣一個圖片：一個三角形，三個頂點分別是範圍，時間，成本；三角形的內部是質量。反映出來的道理就是三個頂點所代表的因素最終影響了所完成的工作的質量。如果大家都認同這個道理以及成本是固定的道理，那麼對於一個需求已經明確的任務（相當於確定了範圍因素），如果提出了明確的質量要求，再限定了工期（相當於確定了時間因素），那麼成本也就確定了；如果成本是簡單地以人員數量來體現的，那麼就相當於人員的數量也是確定的。如果成本達不到合理的數值，那麼就會出現質量下降

第一階段：假想階段

在本階段需要反覆驗證這個假想的可行性，成本，收益；如果行業內已有類似的可參考的軟體那麼就會簡單一些，如果沒有就只能利用一些模擬和預測的方法來幫忙了。在假想確定要實施的時候一定要組織一次啟動會議，參會人員包括所有的利益相關方，由總裁級別的領導宣佈這個專案的正式啟動；目的就是給大家一個前進的方向和希望各方通力合作。

第二階段：需求開發階段

軟體的5個特性中的易用性在本階段要重點考慮。本階段可能是爭議最多的階段，對於同一種業務功能需求會有多種解決方案，每一種解決方案會有一套詳細的軟體功能描述，不同的解決方案所需要的成本一定是不一樣的，易用性也會不一樣。如果站在業務部門的角度一定是易用性越好越滿意，但是站在資訊部門的角度如果成本超出了預算就不得不追加預算，如果不能批准就不得不和業務部門反覆探討協商了。資訊部門各個方面的專案負責人一定要參與到這個階段的討論中，如果在某個方面的成本超出了預算一定要及時提出，包括開發方面，測試方面，硬體方面。通常見一些公司只有一個專案經理或者銷售人員代表資訊部門參與到這個階段的討論中，接受了很多成本遠超出預算的業務需求，殊不知這一個人怎能精通各個方面，怎能準確地計算出成本。不知這些公司的上層領導們是怎樣想的。如果是一個乙方公司這樣不專業的做法通常的結果就是虧本買賣，唯一的解決辦法就是不斷壓榨一線的技術人員。在國內這種不正常的現象很普遍。作為一個資訊行業的從業人員真希望這種現象會盡快好轉，多給技術人員一些尊重和成長的機會，最終形成良性迴圈。

通常在這個階段一線的技術人員不會參與進來，對於參與的技術人員負責人要求比較高，他要熟悉公司的現有技術架構，使用或者複用時的成本；具有較強的溝通協調能力；對於公司財務部門，預算部門，採購部門的工作流程比較熟悉；所有的素質要求都是為了能夠深刻理解和把握開篇提到的那個三角形標示出來的三個要素和高質量的標準。

站在整個專案的負責人的角度看平衡各方利害通常是很有挑戰性的任務，作者曾經參加過競越公司開辦的一門叫做思維技術的課程，其中提到過從一個問題的多個解決方案中選出最適合各個利益相關方的的方法論。作者認為完全可以把這個方法論使用在本階段爭議比較多的焦點上。

如果本階段沒有爭議是不正常的現象，本階段的爭議越多後面階段的爭議相對就少，站在整個專案的角度看成功率就

第三階段：設計階段

在上一個階段的工作做得足夠充分之後本階段的工作才更加有意義和價值。本階段的工作至關重要，承上啟下。

軟體方面：作者主張需求開發階段參與的技術負責人，設計階段的負責人，實現階段的負責人，以及軟體在執行期間的第三層運維支援負責人是同一個人。這四個負責人可以分開，但是要保證下一個階段的負責人能夠充分理解上一個階段負責人的工作輸出的想法並且是認可的。如果四個責任人分開會面臨以下幾個管理問題：

1.由於上一個階段的負責人並不繼續向下負責，所以可能出現不認真或者輸出結果不達標的問題；下一個階段的負責人可能會出現同樣的問題，以至於問題一直留到最後解決，甚至於無法解決，成本高到遠遠超出預算。

2.知識傳遞的問題，如果下一個階段的負責人不能理解上一個階段的負責人的理念，那麼就需要兩位負責人在一起充分溝通達成共識，但是如果兩位負責人不能達成共識又會引起另外的問題。

但是如果四個負責人都是同一個人，也許有人會質疑說一個人的精力有限，對於一個大專案來說一個人無法勝任。在這裡作者必須宣告作者是個敏捷開發主義者，實際工作過程中通常都是一個月或者兩個月釋出一次版本，測試通過就上線執行。這樣一個人的精力有限問題就解決了，實際上也就是把在開篇提到的那個三角形中的範圍因素設定為正好適合一個負責人能夠勝任的界限。這種做法最大的好處不言而喻，專案成功率高，風險度低，也可以儘快實現軟體的價值-為業務服務。也許還有人會質疑如果每一次釋出的版本的新增功能太少，在架構設計方面可能會有偏差，會需要不斷重新設計架構。作者一直以來的理解是軟體的架構和軟體的原始碼是可以分開考慮的。舉個形象的例子就是架構和原始碼的關係就像書架和書的關係，可以在開始就準備一個大書架，然後一本一本新增書籍，很長時間都不需要換書架。如果開始準備的是一個小書架，書籍很快就會把書架填滿，這時一個小書架就不夠用了，解決辦法可以增加一個小書架，也可以換成一個大書架。增加一個小書架就相當於增加一個子系統，換成一個大書架就相當於重新設計架構，然後增加新的模組。但是作者不能確定在開始是用一個小書架好還是用一個大書架好，如果一定要給一個觀點，作者主張把書架設計成可以由一個人就能夠靈活新增或者減少書架體積的模式。這時架構設計們的價值就明顯地展示出來了。放書的工作就相對簡單多了。

硬體方面和測試方面的道理應該是類似的。

第四階段：實現階段

有了質量標準，有了設計方案，接下來的工作就是加工實現了。在實現的過程中要不斷檢查質量是否達標，是否是按照設計方案來實現的。如果這個階段的負責人是設計階段的負責人和將來的第三層運維支援負責人，那麼這兩項檢查工作會很順利。軟體方面一定要有一個原始碼管理工具。硬體方面一定要有一個配置管理工具。

第五階段：質量檢查階段

實現階段的質量檢查屬於內檢，本階段的質量檢查屬於外檢，換成專業的質量檢查人員從另外的角度看問題，看是否能夠達到質量標準。作者主張需求開發階段參與的技術負責人，設計階段的負責人，質量檢查階段的負責人和運維期間的重複質量檢查負責人都由同一個人來擔當。

本階段還面臨一個管理問題就是質量檢查人員和開發人員之間的溝通問題，所以缺陷管理工具和完善的質量報告是很必要的。對於軟體上線執行後出現的事故，調查事故原因如果是一個未發現的軟體缺陷，如果一定要有懲罰措施，作者主張開發方面負責承擔60%的責任，質量檢查方面負責40%的責任。作者不主張獎懲措施，主張主人翁精神的培養。因為很多時候功與過實在是難以劃定清楚，必然會引起不公平現象的出現；但是讓大家明白公司業績好了，獎金就會多，福利就會提升以及公司存在個人的工作就會存在這樣的道理卻很容易。但是主人翁精神的培養是個太過高階的話題，超出了作者的工作經歷所覆蓋的範圍，只是有一點深刻體會就是公司要給予員工家的感覺，只要是一如既往全心全意為公司服務，那麼公司就沒有拋棄這位家人的理由，每年工資的提升至少不少於通貨膨脹率。作者認為這樣的家人應該會有比較強的主人翁精神的。

第六階段：部署階段

這個階段實現了軟體和硬體的結合。作者能夠提到的幾點就是：

1.本階段可以使用自動化部署工具。

2.可以把軟體的部署分為應用程式層和資料庫層。

3.如果使用的是Windows伺服器和域管理，應用程式到資料庫之間的連線一定要使用整合身份驗證。

4.應用程式池的賬號一定要使用服務賬號，密碼要使用密碼管理工具。

5.服務賬號只能用在應用程式池用來連線應用程式和資料庫，不能遠端登入伺服器和使用在連線資料庫的客戶端軟體上。

6.如果不是域管理能夠做到的，那麼所有的密碼都應該使用加密功能。

總結：

軟體開發生命週期管理有很多方法論，也有很多開發模型；但是作者比較推薦的是具有普遍意義的PMP和ITIL管理方法。也許有人會說ITIL是用於軟體運維生命週期管理的方法論，但是曾經一個老師給作者的啟示是ITIL也一樣可以用於軟體開發生命週期管理，如果開發任務常規化之後就適用了，仔細一想，回味無窮。