Russell Ackoff博士的系統思考要點 - kislayverma
Russell Ackoff博士是著名系統思想家,他的觀點對於複雜系統DDD和架構設計都有借鑑意義:
解決問題的方法:
- 忽視:忽略問題並希望它會消失
- 通常解決方案:根據先前的經驗和定性判斷解決問題。這就是“令人滿意”——做得夠多總比什麼都不做要好。但這會導致進一步的問題,這些問題通常比原始問題更復雜。
- Dissolution化解的解決方案:重新設計系統以消除問題。(banq注:推薦這個,找出問題上下文:天時地利人和,化解上下文從而解決問題,因此重寫軟體比重構才真正解決問題,重構是一種看上去美好的不切實際增加壓力的教條主義方法)
一個系統是一個整體,由它在一個更大的系統中的功能定義,它是一個更大的系統的一部件;並且這個系統至少由兩個部件組成,沒有這些部件,它就不能完成它的定義功能。
一個系統的基本部件必須滿足 3 個條件:
- 每個重要部件都可以影響整體的行為或屬性(banq注:物件的子物件會對這個物件的行為和屬性有影響)
- 沒有必要的部件對整體有獨立的影響
- 每個部件的子集都可以對整體產生影響,但不會產生獨立的影響。
一個系統的基本特徵取決於它的部件如何相互作用,而不是它們如何單獨行動。
- 一個系統的任何部件都不能獨立完成整個系統的功能
- 當一個系統的各個部件的效能分開提升時,這個系統的整體效能不一定會得到改善。
我們透過設計過程瞭解系統的各個部分如何相互作用。透過理想化的設計,我們瞭解系統應該如何執行。(banq:設計過程不能因為複雜而沒有,應該敏捷進行)
為什麼領導力課程沒用?
領導力是一門藝術和才能——無法傳授,領導時不同角色的區別:
- Administration:使用某種手段指導他人追求目標,其中目標和手段均由第三方選擇
- Management:使用某種手段指導他人追求目標,其中目標和手段都由經理選擇
- Leadership:在目標和手段都由第三方他們自己選擇的情況下,使用某種方式引導和鼓勵他人追求目標
Leadership領導力要求有能力使他人的意願與領導者的意願一致,以便他們自願遵循。這是靈感,而不是說服。
願景是領導者產生的理想化設計:
整個互動過程都帶有魅力型領導的想法,而不是自下而上的領導。DDD中共享上下文最好由一些領導者來完成。
改變改革失敗的原因
改變需要識別問題的智慧和解決問題的勇氣(智勇雙全是不可能的),兩種型別的錯誤:
- commission錯誤:做錯某事
- omission疏忽錯誤:沒有做應該做的事情。
在大多數問責制中,只記錄commission錯誤。
因此,理性的人不會沉迷於改變(是不是有點保守?以靜制動)。
是否存在靈丹妙藥?
正確的人做錯事,你就變得錯誤!
常識:
- 管理應該針對我們想要的而不是我們不想要的。不能只關注產出質量而不是工人的工作生活質量。
- 需求必須在設計過程中被發現——軟體架構師需要知道這一點
- 持續改進其實跟不上臺階跳躍
- 流程再造:如果專注於系統的不同部分而不是整個系統,這是反系統的且會無效!
- 縮小規模:組織的目的是創造和分配財富。因此裁員是不道德的行為;去官僚化和去壟斷內部虧損單位
- 部分基準測試是反系統性;整體的基準測試就是競爭。以競爭為基準 -> 持續改進 -> 放棄了理想地設計我們想要的東西的機會;將比賽設定為黃金標準。
創造力
每個創新過程都包含三個步驟:
- 辨識那些會限制我們選擇探索方向的假設前提
- 去除這些假設
- 檢查和利用現在浮現出的新選擇方向戰略
創造力原則(這些是在企業環境中創造性解決問題的更多技巧)
- 否認“案件事實”而是去自己把它們找出來(banq:不要相信客戶的代理,例如代表客戶的那些人或組織)
- 去除外部強加的約束
- 影響那些無法控制的人
- 擴大系統
- 以問題的根源作為解決的角色逆轉
關於組織的其他想法
消除那些工作要求描述:
- 他們實際是在限制
- 找個好人,把他們放在一個區域/部門,並要求他們做他們認為需要做的事情。
- 提供指導並繼續討論他們將要做什麼和如何做。
薪水不應僅限於地位:
- 不為地位設立管理者,按需增加薪酬
- 支付員工的價值,地位/角色是偶然的
樂趣:
- 樂趣=自我決定
- 讓人們知道他們想做什麼
管理不是一種專業,而是一種就業形式:
- 專業有標準,專業人士負有最高義務。例如醫生的希波克拉底誓言
- 員工對組織的利益負有最高的義務 (有些管理錯誤意見:砍去員工腦袋讓員工不用思考只執行,這種僵化層次不適合創新)
團隊/組織的使命宣言必須是精心設計的表達方式。如果陳述的反面在邏輯上不可行,那麼使命陳述就不太可能具有指導意義
例如,“我們希望為我們的股東提供更高的回報”是沒有意義的,因為作為目標的反義詞是沒有意義的。因此,該宣告不會產生任何實際行動(口號而已)。
相關文章
- CRM系統選型的要點
- 資訊系統建設要點
- 秒殺系統設計的5個要點
- CRM系統管理客戶的四個要點
- 關於MES業務系統解耦的幾點思考解耦
- 為什麼很少有組織採用系統思維? - ackoff
- Android Build系統要點總結AndroidUI
- 21-分析要點:辯證思考(1)
- 22-分析要點:辯證思考(2)
- 複雜性系統的戰略分析要點 -Dave
- 關於後臺系統自動生成的一點思考
- 選型招聘系統需要考慮的幾個要點
- Cordova在Android系統下的檔案操作要點Android
- 系統移民須知:Linux作業系統安裝要點(轉)Linux作業系統
- 前端埋點統計方案思考前端
- 關於系統高可用的思考
- 【話題討論】漫談生產系統升級的一點思考
- 企業文件管理系統選擇的四大要點
- ERP系統訂單管理的一些要點問題(轉)
- 系統模組劃分設計的思考
- CRM系統選哪家?常規選型要點是什麼?
- 訊息佇列在大型分散式系統中的實戰要點分析!佇列分散式
- 企業用好WMS(倉庫管理系統),需要注意的幾個要點
- 測試的思考點
- 什麼是系統思考家?
- 線性思考、設計思考和系統思考三者權衡
- 【幣修】《系統思考》的正確姿勢
- redo與undo的一點點思考
- BI資料分析系統運營要注意這4個要點
- 銀杏谷創始人陳嚮明博士談雲原生的投資策略與思考 | 雲原生加速器觀點
- win7系統要重灌如何保留自己的系統設定Win7
- 如何進行系統思考? - skybrary
- 關於難點的思考
- 遊戲安全的一點思考遊戲
- 架構思考:不靠譜的元件與可靠的系統架構元件
- 秒殺系統設計中的業務性思考
- Spotify CEO推薦:系統思考的一生
- 關於作業系統的一些思考作業系統