軟體專案管理（CMMI成熟度）實踐——之決策分析（3）

        續《軟體專案管理（CMMI成熟度）實踐——之決策分析（1）》、《軟體專案管理（CMMI成熟度）實踐——之決策分析（2）》，後記。

        關於前端開發技術架構決策分析的活動已經結束了，按理說不應該這麼快來寫總結，但是，的確發生了很大的變故。因此在此寫寫後續發生的事情吧。

        我很高興，專案組開發人員在通過長時間熱烈的討論、研究後，終於通過決策分析方法選擇引入JavaEE技術架構，並把Cordys產品放在後臺。我感覺到我的壓力驟減，主要原因如下：

        （1）受Cordys產品限制、制約，大幅減少；

        （2）採購Cordys產品廠商現場技術支援服務緊迫性降低，能避開公司人員劃撥動盪期；

        （3）採購合作伙伴人員相對容易多了，因為JavaEE開發人員，人力市場上很多，而基於Cordys平臺的很少見；

        （4）通過公司協調，新加入專案組開發人員，不受技術限制，能很快投入到工作中；

        （5）專案組成員溝通也順暢多了。

        也許是高興太早了。

        今天，在跟蹤專案進度和計劃安排過程中，感覺部分人員對需求理解不全面，存在核心頂層設計不清晰的問題，進度滯後。因此，緊急召集設計人員開會討論。會議紀要中結論內容摘錄如下：

        （1）設計人員對支撐流程視覺化快速開發辦的公能力平臺的需求範圍、內容、目標等基本資訊比較清晰，細節可能需要溝通；

        （2）系統部署、使用範圍為省公司+13地市；

        （3）要求系統按鬆耦合方式設計，支援資料適配、元件化、服務化；

        （4）要求系統能提供運維支撐，例如：服務監控、介面監控等；

        （5）要求系統能管理應用叢集，支援線上部署、啟停應用，某處故障不影響全域性，保障系統穩定性。

        ……

        突然發現，基於開源JavaEE技術架構，系統運維、應用叢集管理等平臺能力，都需要自行設計和開發，這個工作量將是巨大的，還存在很大的風險。如果不設計這方面內容，那麼系統將處在裸奔狀態，故障時只能重啟服務，還不可控。這是不可能的。而這些能力卻是Cordys產品自帶的原生能力。

        怎麼辦？

        改設計方案，重新回到Cordys平臺上（因為沒有第二套可行的方案），再加HTML的技術架構。

        最後，設計人員終於認可去年年末的0.77版的技術方案（請參考方案原型《雲端計算統一辦公運營平臺服務能力設計方案》，以及2013年的博文《使用雲技術升級改造現有應用系統的思考》）。

        出現這種情況，是好事，不實施哪裡知道方案可行性，只是這條路，彎彎又漫長。

        總結以下三點原因：

        （1）我對需求宣講不清，遺漏重點了，比如0.77版方案中（150多頁），有大篇幅Cordys平臺產品的特性沒有講清楚，反而對於這些特性，使用者、客戶都瞭解。也想當然認為設計人員都瞭解了；

        （2）缺乏培訓，設計人員對產品、相關技術標準認知不統一，例如SaaS模型的定義（參考《 在IT系統中使用多租戶技術提供人員跨部門及虛擬團隊的解決方案（草稿）》）。

        （3）最關鍵的一點：缺乏穩定的開發團隊，特別是在資訊科技快速發展的今天，鬆散、臨時組建的團隊，缺乏溝通上下文環境，溝通成本、時間成本、返工成本的產生，是必然的。

        可惜，能有多少人認識到這一點啊，說不定還可能認為我給大家挖坑呢。殊不知，我也剛剛發現，我也掉坑裡了。感慨鬱悶！

        專案管理，就是這麼回事，每次遇到的情況都不一樣。