軟體專案復雜性

1.技術架構與框架

Reuse is about people and education, not just architect. -------- 《97 Things Every Software Architect Should Know》
認為設計優良的框架，細致考慮并精巧實作的架構自然會被人們重復利用，事實上，即便是最精美，最優雅的框架，可復用性最高的系統，也必須滿足下面的條件才可能被復用，
（1）大家知道它們存在，
（2）大家知道如何使用它們，
（3）大家認識到利用已有資源好過自己動手，如果大家找不到可復用的資源，或者不知道如何使用這些資源，人的天性就會發揮作用，他們會自己動手實作，

反思我們設計框架與組件的團隊，是否滿足以上原則，不滿足實際是不成功的，

2.專案進度

更多的專案之所以沒有被宣布為失敗，很大一部分程度上是因為專案的實施者（或者用戶）接受了充滿缺陷的成品、同意追加了成本或者延長專案交付時間，軟體工程中的時間黑洞永遠讓人無法看清其本質，

前人總結:

Adding human resources to a late software project makes it later. ---《人月神話》

Maximize the velocity and volume of information flow. -------How google works

提高開發效率，一些非技術因素:優秀的團隊總是能額外產出大量的檔案，并經常組織內部分享，

3.Cynefin框架

是由Dave Snowden在知識管理和組織戰略中提出的一個概念框架，用于輔助領導者認知問題并進行決策，

簡單問題Simple：不言而喻

如果一個問題的因果關系非常明了和單一，則這個問題就是一個簡單問題，大家對于這個問題的原因有著統一的不言而喻的理解，這個問題的發生原因非常的確定，幾乎沒有什么變數，即“知道的知道”，

比如，在一個炎熱的夏天回到家里，發現房間里也被太陽曬的熱烘烘的，這種情況下，我們幾乎不假思索就會打開空調，房間立馬就涼快下來了，所以對于房間很熱這個問題而言就是一個簡單問題，可以迅速的找到解決問題的方式，

簡單問題，一般的處理方式是：了解-歸類-回應，

歸類是人類最擅長的處理問題的方式，當遇到一個問題時，首先我們會將這個問題在自己的大腦中進行快速檢索，如果這個問題被大腦判斷為是一個熟悉的問題，那就調取相應的經驗庫并在這個經驗庫中找到匹配這一類問題的答案，這個“類”就是所謂的pattern，它是人的大腦在經驗積累的程序中不斷對問題進行抽象、分解、簡化而形成的，因此，簡單領域的問題一般也都會有一些最佳實踐，

但是在這個問題域需要警惕落入思維范式的陷阱，大腦在思考問題的時候往往是很偷懶的，本著能不思考就不思考的原則，有時候會拿著pattern去套問題，不管這個問題是不是真的能夠被歸類，部分大企業管理者經常會通過做冥想來回顧一整天所做的決策，就是為了避免落入思維范式的陷阱，提醒自己不要被偷懶的大腦所蒙蔽，

繁雜問題Complicated：專家意見

和簡單問題不同，一個繁雜問題的因果關系往往不是單一和清晰明了的，也就是說，一個繁雜問題可能是由多個原因造成的，并且這些原因并不直觀，相比于簡單問題可以依賴經驗庫快速檢索、歸類找到答案，繁雜問題往往沒有經驗積累，無從歸類，所以遇到這類問題，需要進行分析，即：了解-分析-回應，

一個典型的繁雜問題的場景就是Debug，在生產環境上報出bug之后，開發需要進行問題復現、審查代碼、除錯、根因分析等等一系列動作之后才能找到原因，而且可能還不止一個，

奔馳車主發現發動機異響后送修4S店，技師進行拆解找到問題，更換零件最終修復，這個問題也是繁雜的，一開始包括技師在內誰也不知道為什么發動機會有異響，是在一層層拆解，打開發動機，找到破損零件之后才定位到問題，這個問題原因的追溯是需要分析程序的，因果關系不是顯而易見但是確實存在，即“知道的未知”，這是繁雜問題的特征，

前面說到，繁雜問題一般是新的知識領域的問題，沒有經驗積累，但是注意，經驗是依賴于人的，是相對主觀的，也就是說同樣一個客觀存在的問題對于不同人而言可能是不同域的問題，比如，車輛故障對于剛入行沒多久的技師而言是一個繁雜問題，但是對于作業了10多年有豐富經驗的技師來說這個問題可能就顯而易見，是一個簡單問題，所以在這個領域，專家意見尤為重要，

復雜問題Complex：事后方知

復雜問題的因果關系是事前不可預知的，這個因果關系是不穩定的，即“未知的未知”，這種情況下，解決問題往往沒有標準正確答案，

復雜問題跟繁雜問題的區別就像是由零件組成的汽車和由人組成的團隊，汽車構造雖然很繁雜，但是拆解之后還是能原樣組裝回去，任何一個零件的破損可以預測會導致什么樣的問題產生，它雖然繁雜但卻是一個穩定的靜態結構，而團隊則不同，人的行為難以預測，更別說團隊的組織行為了，團隊是一個動態的整體，其中某個隊員的一個行為，我們難以預測會對整個團隊造成什么影響，

典型的場景，比如在進行團隊retro的時候發現這次生產環境無法登陸的問題，可能追根溯源是某個開發在部署的時候組態檔有誤造成的，但是為什么這個開發會把組態檔搞錯，是因為粗心？還是流程不到位？甚至有沒有可能就是這個開發被個人家里的事情所擾，作業狀態不好才導致這個問題的呢？即使采取改進措施解決了這次的問題，能否在以后杜絕該類問題的發生？我們發現這里有太多的不確定性，

于是解決復雜領域的問題，就不能單純靠還原論的解題思路，一個復雜的動態系統整體遠大與構成該系統的各個部分之和，同理一個動態系統的問題也不能單純通過分而析之的方式來解決，

解決這類問題的思路是：試探-了解-回應，

如果可以進行“輸得起”的試驗，指導性規律就會浮出水面，正是出于這個原因，不必冒進試圖采取一系列行動，而是要耐心等待前進的道路自行顯露，首先須探尋，然后了解情況，并做出回應，也就是說，這時候的解決方案是經過不斷試探之后“涌現”出來的，而非精心設計出來的，

混亂問題Chaotic：莫名其妙

如果一個問題的因果關系不可知，完全無法了解問題發生的原因，或者問題的原因太過多變，那么就屬于混亂，這個時候，尋找問題答案已經變得沒有意義，首要任務是及時止損，迅速采取行動，嘗試將所處領域轉變為其他領域，

這些問題常見于一些突發性的社會問題，比如汶川地震，在混亂的局面下，及時果斷的采取行動，嘗試建立秩序變得尤為重要，嘗試從混亂轉變為復雜問題，

歸納總結一下各個領域之間的區別，

希望對大家專案管理有幫助，

今天先到這兒，希望對云原生，技術領導力，企業管理，系統架構設計與評估，團隊管理, 專案管理, 產品管管，團隊建設有參考作用 , 您可能感興趣的文章:
領匯入怎樣帶領好團隊
構建創業公司突擊小團隊
國際化環境下系統架構演化
微服務架構設計
視頻直播平臺的系統架構演化
微服務與Docker介紹
Docker與CI持續集成/CD
互聯網電商購物車架構演變案例
互聯網業務場景下訊息佇列架構
互聯網高效研發團隊管理演進之一
訊息系統架構設計演進
互聯網電商搜索架構演化之一
企業資訊化與軟體工程的迷思
企業專案化管理介紹
軟體專案成功之要素
人際溝通風格介紹一
精益IT組織與分享式領導
學習型組織與企業
企業創新文化與等級觀念
組織目標與個人目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共享
高效能的團隊建設
專案管理溝通計劃
構建高效的研發與自動化運維
某大型電商云平臺實踐
互聯網資料庫架構設計思路
IT基礎架構規劃方案一(網路系統規劃)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之采購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之性能實時度量系統演變

如有想了解更多軟體設計與架構, 系統IT,企業資訊化, 團隊管理資訊，請關注我的微信訂閱號：

MegadotnetMicroMsg_thumb1_thumb1_thu[2]

作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文著作權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利，該文章也同時發布在我的獨立博客中-Petter Liu Blog，

轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/285976.html

標籤：其他

上一篇：如何對待工程師團隊犯錯誤

下一篇：我，管理100多人技術團隊的二三事