项目管理与群体智慧
知識的詛咒（The Curse of Knowledge），通俗的說是指我們一旦知道了某事，就無法想象這件事在未知者眼中的樣子。
?
當我們把自己知道的知識解釋給別人的時候，因為信息的不對等，我們很難把自己知道的完完全全給對方解釋清楚。是我們擁有的知識“詛咒”了我們。
為什么會出現知識的詛咒這種現象呢? 我認為是人類集體的智慧和文明經過數千年的進化,積累了如海洋一般無限量的知識，但是人類單顆大腦的容量和信息處理能力是有限的，每個人經過多年的教育和工作經歷之后，都只能獲得人類知識庫的一小部分知識，一旦你成為一個領域的專家，在其他領域就很難再成為專家。
?
舉個很常見的例子，大家去醫院看病的時候，疑難雜癥通常會由多個科室的專家會診之后才能做出比較精確的診斷，就是這個道理。人類文明的偉大之處，就在于這種群體智慧的力量，單個個體的體力和腦力有限，但是一旦形成協作之后力量就會非常強大，能完成工作量和難度巨大的工程活動。
?
“知識的詛咒”會給人類的協作帶來很多的困難，因為每個個體都只有局部的知識和信息，如何從全局的角度做頂層設計和正確決策就是一個困難的問題。
?
軟件項目研發活動不同于其他工業工程,是人類歷史上最為復雜的技術密集,知識密集和智力密集型工程活動,不同于蓋樓、修鐵路、橋梁這類體力密集型的工程，研發一個大型軟件項目需要成百上千知識工作者的分工協作共同完成，一個軟件項目所處理問題的復雜性之高，所涉及的知識面之廣，已經不是幾個會寫代碼的工程師就可以解決的問題。
?
以現在大家熱談的中臺戰略為例，在實施的過程中失敗的案例比比皆是，就是因為中臺的本質是企業級的整體設計，一個用戶視角的完整應用，涉及上百個技術組件，需要成百上千業務人員、架構師、研發人員之間的溝通和協作才能夠完成，整個企業的業務人員、技術研發人員會成為一個整體，協作的范圍和復雜度遠遠超過了原來單體時代的項目。
?
現實情況往往是懂業務的不懂技術，懂一個業務領域的不懂另一個業務領域，從業務人員到技術人員之間、不同項目組的技術人員之間都有巨大的信息鴻溝。
?
一方面，軟件項目的規模之大、難度和復雜性之高需要成千上萬不同領域之間的專家、業務人員和技術人員的協作和集體智慧才能完成，另一方面，“知識的詛咒”現象會給項目的進行帶來很大的困難。項目過程中的很多問題都直接或者間接和這個現象有關的。
?
舉幾個項目過程中常見的問題:?
?
問題一、業務與產品、開發之間的溝通問題
?
業務人員、產品人員和開發經常是各說各話，產品設計人員經常吐糟開發人員做的太慢或者做出來功能的不是自己設計的效果，開發人員回懟說產品人員設計的功能太理想不能實現……
?
出現這個現象是因為產品人員設計的原型或者效果圖是從用戶的業務需求和最終效果來考慮的，是一個主觀的設計過程，往往會忽略技術原理、實現的細節等過程性因素，而開發人員是從客觀的技術可行性、實現過程等角度考慮，業務人員純主觀的設計和技術人員客觀的思維方式兩者之間本身就是存在矛盾的。
?
問題二、始終如“一”的項目管理
?
這個在軟件工程領域的專業術語叫驗證和確認(Verification and Validation)。通俗來講，就是最終實現做出來的軟件功能要和最開始的需求、設計目標、約束等保持一致,也經常被大家叫做以始為終或者以終為始。
?
在一個項目研發團隊中，需求分析人員的職責在于調研客戶需求，建立清晰的需求規格及軟件藍圖(原型或功能設計說明書)，開發人員的職責在于設計和實現藍圖，測試人員的職責在于驗證系統的實現是否和需求人員的藍圖是一致的。這種角色分工模式帶來的一個問題是前一個角色的輸出作為后一個環節的輸入時出現偏差，經過眾多研發測試環節之后最終實現的系統偏離了設計預期以及客戶的需求。
?
現代軟件工程為了解決這個問題發明出各種各樣的方法來解決這個問題，從若干年前的UML建模到近年流行的DDD(領域驅動設計),BDD(行為驅動設計)、軟件形式化方法等等,目標都是如何清晰準確的對客觀世界建模定義軟件的功能和預期行為，幫助不同角色共同分析復雜業務模型、建立業務全貌和統一的溝通語言，減少信息在不同角色傳輸的損益。測試領域的TDD(測試驅動開發)、實例化需求等方法，目標是讓測試的輸入和需求階段的輸出保持一致。
?
除此之外，還有項目管理常用的需求追溯矩陣、全流程審計等方法，都是為了實現這個目標。然而在現實的研發管理中，實現始終如一這個目標仍然是一個困難的問題。
?
問題三、問題定位排查過程
?
生產出現問題的時候，拉上一波研發人員排查定位問題，往往會出現從頭開始兜了一圈還是沒有定位，在復雜的單體項目，一個系統的整體功能是由若干子系統完成的，每個子系統又分為若干模塊，子模塊，出現問題的時候只能從頭開始逐步縮小搜索范圍, 定位問題的系統, 子系統，模塊，子模塊等。
?
在當前中臺和分布式架構盛行的時代，問題的定位和排查更是一個困難的問題，用戶視角的一個完整功能，可能會調用數十個組件的服務，雖然有鏈路追蹤系統的輔助定位，問題的定位仍然是一個十分麻煩的問題，動輒幾十甚至上百人如熱鍋上的螞蟻一樣手忙腳亂的排查問題更是家常便飯，經歷過的同學肯定都會心有余悸。其原因就是每個個體都只了解整個系統的一部分知識，只有把每個個體所掌握的知識和信息整合起來才能掌握系統的全貌。?
?
問題四、項目經理的決策過程
?
由于每個個體都只具備一部分知識和信息，項目經理作為項目全局的決策者，要做出正確的決策是一件非常不容易的事情，需要具備和掌握正確的思維方式才能夠做到。然而什么是正確的思維方式是個見仁見智的問題，因為每個人的思維方式和觀點都是不同的(個人認為大概有如下幾個方面，正確的思維方式應該具備以下幾個方面，全局性、客觀性、動態性、開放性等，以后作者將專門就這個話題進行探討)。
?
項目經理的決策過程，通常要以大量其它角色提供的信息為基礎，綜合集成判斷之后才能做出，由于每個個體的水平是非常參差不齊的，如何保證其他角色提供的信息正確客觀是個非常困難的問題。一旦項目經理的信息輸入出了問題或者項目經理的決策模型出了問題做出錯誤的決策，后果將非常嚴重。
?
當年的723動車事故，以及多架波音飛機墜機的事故等等都是活生生的實例，當系統的規模和復雜性達到一定程度，項目經理如果不能做出正確的決策就會給正常的生產和生活帶來巨大的損害。
?
從上面的問題我們可以看到雖然每個個體都有局部的知識和信息，在項目經理的統一調度和管理下形成協作和分工，就能研發完成規模巨大精密運行的產品和系統(雖然過程充滿了混沌和曲折)，從這點來看，和指揮樂團演奏出華麗的樂章一樣，項目管理確實也是一門藝術。
?
軟件行業已經越來越復雜，不僅所處理問題的復雜性大大提高，所涉及的知識面也越來越大，軟件開發是比足球活動更需要團隊協作的一項團體活動，軟件項目管理是運用組織、流程和工具將每個大腦連接形成一個智慧共同體的過程。
總結
- 上一篇： vlan、三层交换机、网关、DNS、子网
- 下一篇： Python 内置方法和属性应用：反射和