軟體研發之管理債

這是即將在Scrum Gathering上海2012大會http://scrumgathering.cn上演講話題《軟體研發中的管理債與債管理》的第一部分。如果你是一位軟體研發人員，想了解軟體研發為何如此困難，怎樣才算做好軟體；如果你是一位管理者，想知道哪些管理措施可以奏效，為什麼一些管理措施效果不佳；如果你是一名敏捷精益實踐者，想深入瞭解敏捷精益背後的思維模式。你可以來看看，以債出發的視角也許會給你帶來驚喜。

在軟體研發組織中“管理債”不斷堆積，這是因為採用了與軟體研發的特點不匹配的管理模式。

軟體研發管理債是什麼？
“技術債”是一個隱喻，這幾年已經被大家熟悉並接受。如果向一個軟體系統增加功能時需要額外的工作量或難度，那麼這個軟體系統存在技術債，這些額外的部分就是為技術債支付的利息。
受到“技術債”的啟發，在此提出軟體研發“管理債”的概念。當一個軟體研發組織達成軟體研發目標時需要額外的工作量或難度，我們就認為該軟體研發組織存在管理債，這些額外的部分就是為“管理債”支付的利息。
軟體研發“管理債”普遍存在於軟體研發組織中。隨著時間的流逝，債務從開始的小瑕疵變成龐然大物，越來越成為生命不能承擔之重。其在軟體研發管理上的主要表現為：1）成本越來越難以控制，超出預算；2）達成目標的時間越來越長，超出時間；3）開發出的軟體不能達到市場期望，不符合需求；4）質量低下；5）軟體越發龐大，難以維護。
誰應該為“管理債”負責？當從軟體研發管理的角度去看時，似乎管理應該為此負責。（畫外音：命名為管理債，肯定是管理負責啦，這種提法有誘導性，說服力不足。）
“管理債”與40多年前的軟體危機非常類似。軟體危機的主要表現是：1）軟體常常超出預算；2）軟體研發超出時間；3）軟體不符合需求；4）軟體質量低下；5）難以維護。為了應對軟體危機，對應的解決方案是軟體工程。軟體工程是研究和應用如何以系統性的、規範化的、可定量的過程化方法去開發和維護軟體，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來的學科。然而40多年過去了，仍然沒有一種得到證明的軟體工程方法能夠解決軟體危機的問題，它仍然以“管理債”的形式大量存在。

是何種假設導致問題在持續？
如果方向是正確的，那麼順著方向走，找到答案只是時間問題。然而，方向不正確的時候再多的努力也不能真正解決問題，就如牛頓力學與相對論，歐幾里得幾何與非歐幾何。我們認為的正確往往都建立在假設上，如果假設不成立，那麼結論亦不成立。那軟體工程、軟體研發管理對應的假設是什麼？
先來審視管理與軟體工程的定義。管理是管理者和他人及透過他人有效率且有效能地完成活動的程式。管理就是計劃、組織、領導、協調和控制。軟體工程是研究和應用如何以系統性的、規範化的、可定量的過程化方法去開發和維護軟體，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來的學科。再觀察大多數軟體研發組織的做法，常見的包括：以產出為導向、明確的分工、規範的過程、精確到人的績效管理、計劃管理和不斷積累的最佳實踐過程資產。
可以觀察到一個核心假設，那就是：假設存在一種正確的管理方式，這種管理方式能夠規範的、定量的解決軟體研發中的問題，我們的工作就是積累經驗，找到該管理方式，不斷修正我們的行為直至完美遵循為止。這個假設是否真的成立？

在軟體研發中該假設不成立
假設存在正確的管理方式，假設可以通過系統性的、規範化的、可定量的過程化方法進行軟體研發，這是軟體工程得以存在的基礎。然而，這一假設在軟體研發中並不成立。
定量、規範、系統性、過程、管理，這一切是典型的現代管理思路。而現代管理是建立在物質經濟的基礎上的。物質具備三大特點，首先是可衡量性，產出和中間產物都是物質的，可衡量的；其次是不變性，除加工步驟外，中間產物在傳遞過程中保持不變；最後是不相關性，產出與原材料不相關，第100個產出和第一個產出間不相關。因為產出可測量，並且不同產出間的生產過程相關性小，可重複性高，從而提升產出效率成為現代管理的核心追求；傳遞無損耗有利於進行步驟分解，步驟分解後可對步驟進行單獨的測量和效率優化，使得精細化分工成為可能，這有帶來了整體產出效率的提升。簡單總結一下，現代管理的核心思想就是“衡量是基礎，產出是追求，分工是核心”。一個典型的例子就是：澳大利亞生產鐵礦石，在中國粗煉，到日本精煉，在德國加工成零部件，在美國生產成精密儀器，賣到中國。
現代管理對知識經濟的代表-軟體研發並不適用，知識的特點與物質截然不同。首先是產出的不可衡量性，知識沒有體積、重量和其他任何可見的測量方式，知識與知識間無法直接比較，知識的價值取決於使用這些知識的人而不是生產這些知識的人；其次是高損耗，知識存在與大腦之中，必須轉換為資訊後才能進行傳遞，而接收者需要從外界獲取資訊並將之轉換為自己的知識，這一過程存在巨大損耗；最後是強相關性，開發第100個功能和前面的99個功能存在巨大關聯，這大大有別於物質生產。這三大特點打破了現代管理的基礎，因為這三大特點，產出不可衡量導致分步驟優化的作用受到質疑，如果強行優化僅能帶來區域性優化，全域性作用不一定明顯；巨大的傳遞損耗使得步驟分解變得不合理，使用者決定價值的特點使得步驟間無法隔離，步驟劃分難以執行，並且無法衡量步驟劃分的價值，這使得建立在步驟劃分上的分工不再可行；產出間的強相關性導致做的越多，負擔越重，以後做的越慢，所以用做的更多來進行產出衡量意義不大。“衡量是基礎，產出是追求，分工是核心”這些現代管理的核心思想被打破，以現代管理思想驅動的軟體研發管理遲早陷入困境。

軟體研發管理債源於不匹配的管理模式
將基於物質經濟的現代管理應用於知識經濟的代表-軟體研發是軟體研發組織的常見做法，這必將帶來軟體研發管理債的不斷增長。軟體研發管理需要不一樣的管理模式，這種管理模式應該是什麼呢？可否從管理思想和軟體研發方法的發展上獲得一些啟示？後續大家來共同探討吧。

相關連結，摸索的足跡
從2月份提出管理債到現在，跌跌撞撞摸索之中。重新學習和摸索債、管理、軟體工程、經濟等基礎概念，這種不斷學習的感覺實在是太好了，一些博文記錄了前期的收穫。
得懂點財務 - 從房奴養成四部曲到管理債
管理是資產？不，管理是負債
管理是這樣從資產變成負債的