好的管理的一個重要特徵是對職位進行管理，而不是針對人的管理。

  我一直認為，很多道理都隱藏在我們的周圍，只不過我們沒有認識到罷了。在這裡我先從一個簡單的故事開始。這個故事我已經在很多場合講過。在找到更好的故事之前，我將一直用它。
    我說的這個故事的名字叫“總經理與秘書”的故事。這裡沒有任何桃色新聞，這點恐怕會讓某些人失望:)。
    上海的一家公司的總經理A明天需要到北京參加一個非常重要的會議，他叫過來自己的秘書B吩咐道:“B小姐，請幫我訂一張明天早上9點到北京的機票。”
    第二天，A總經理來到公司向B秘書拿機票，B秘書回答道：“昨天機票沒有訂到”。A總經理勃然大怒：“你知道這個會議對公司多麼重要嗎？”。A總經理嚴厲的斥責了B，隨後暗暗發誓等回來一定要換一個秘書。
下面我們將從軟體的角度分析這個故事。
    這個故事出現了兩個類總經理A和秘書B，由於是A訂票需要B的協助，所以可以畫一條箭頭從A指向B的線，1。

    結果類A就知道類B的很多細節，任何A向B發送訊息的執行結果都應該由A檢查。顯然，這並不符合現實情況，這樣的總經理活的也太辛苦了。因為他吩咐手下要做的每一件事都需要他自己關注執行結果，一旦關注不到位就可能出亂子。所以，現在很多老總都希望自己的員工讀一讀《給加西亞的信》這本書。但事實上給加西亞的送信的員工一定是一個稀缺資源，請這樣的員工，工錢一定不會少。所以“加西亞”只能用在關鍵的、確實需要的崗位。

    那麼這樣的模型有問題，我們可以改進一下，2。在這個圖上，增加一條從B到A的箭頭。B和A之間關係更加緊密。讓我們將這個模型放在這個故事中看看結果如何。在A發出一個訂票訊息後，B及時把訂票的每一個進展都向總經理反饋，如果訂票順利也就罷了，可是一旦過程中出現問題，總經理一定會備受騷擾。一旦公司中所有的員工都是這種勤彙報的人，那麼總經理的辛苦程度一定不會比上面情形中的總經理差。
    從軟體設計角度來看，這種雙向聯絡的這兩個類之間是強耦合的關係，不是特殊原因盡量避免。因為既然兩個類需要互相知道，為什麼不合并成一個類了？
    兩個圖都否定了，看來沒有辦法了。這時候向大家隆重介紹軟體設計的一個非常重要的原則(請鼓掌)。
“依賴倒置原則(DIP)”。
* 高層模組不應該依賴於低層模組，二者都應該依賴於抽象。
* 抽象不應該依賴於細節，細節應該依賴於抽象。[1]
    好，根據這個原則我們可以得出正確的結構見圖三。這裡面引入了一個新的類，即服務於總經理的秘書類。還是用這個“總經理與秘書”的故事來分析，這個結構為什麼能解決問題。總經理A根據自己能開出的工資條件定下了秘書職位（注意，是職位，不是秘書）的職責和工作程式。這樣，秘書B對遇到正常情況，都能依據公司的規範來正確處理。只有遇到異常情況才向總經理報告，這個異常情況很快也將補充進新的規範之中成為正常情況。

    所以，好的管理的一個重要特徵是對職位進行管理，而不是針對人的管理。回到軟體設計。我曾經說過，介面的集合就是架構，而架構在整個軟體中無處不在。作為一個想成為架構設計師的程式員來說，“依賴倒置原則”的運用是一個好的起點。