你的程式是資產還是負債？

Your product is an asset, but code is a liability.
Martin Rue〈My Engineering Axioms〉

在幾年以前，我曾經陸續讀到過幾個相似的概念——5S、斷捨離、《怦然心動的人生整理魔法》，它們在我心中逐漸建構起一個共同的核心觀念——「物品的價值在於被有效的使用」，這個概念成立的基礎在於人們能掌握的資源是有限的，特別是時間與空間。當一個物件被閒置在某個角落，而那個堆雜物的角落假設佔了一坪的空間，那麼相當於我花了成本相當於市價一坪的錢買了那塊地，上頭卻供奉著僅僅是被歸類於雜物的物件們，他們紮紮實實的佔據了那一坪空間不是嗎？也因此你與家人的走動空間也確實少了那一坪沒錯吧！

斷捨離

前面提到的概念，在個人的階段，如同斷捨離所倡導的，「斷絕不需要的東西；捨去多餘的事物；脫離對物品的執著」，具體的行為如《怦然心動的人生整理魔法》所實踐的——取出那些閒置物件，一件一件思考它對你的意義，如果它不再令你感到「怦然心動」，那麼就謝謝它曾經帶給你的意義與價值，然後就妥善地將它交給回收車，告別彼此展開新的生活。

如果我們把層次拉高到社會的層面，也會發現社會中也有類似的角落，試著回想你家附近是否曾經有過一個小孩不敢進去的公園，又或者是蓋到一半的爛尾樓、發生過火災的猛鬼大樓等，這些閒置設施（甚至是嫌惡設施）不論是私有的或公家的，顯然不像個人物件那樣能被輕易的斷捨離，必須採取斷捨離以外的手段，像是「都市更新」與「資產活化」都是常看到的做法，政府藉由推動都市更新，改建老舊建物，不僅提升城市形象，對民眾來說生活品質也有所提升，更有感的可能是區段地價房價的上漲，對政府來說則是經濟活動活絡之後帶來的人口與稅收的增加。資產活化則常見於閒置廠房土地的重建，賦予不動產新的附加價值，帶來經濟上（永豐餘）或文化上（西門紅樓、松菸、林百貨）的收益。

程式是資產還是負債？

延續前面的概念，對於軟體資產的認定應該是較無懸念的——有開發、有維護、有用戶、有收入的軟體無疑的是資產，我們花費人力與時間付出成本，換得一個能為我們帶進收益的產品或服務，那麼反過來說，哪些程式我們應該認定成負債呢？或認定為較為無害的「閒置資產」呢？儘管很難用單一的標準認定，但這些閒置資產大多有以下特徵：

無法帶來新客戶，而僅存的舊客戶也只是因為轉換成本過大或沒有特殊誘因所以無法下定決心替換。
在市場上不為人所知，源自於這些程式起初就是為了某個特定單一客戶的單一需求開發的，而當初在開發時沒有設想到降低耦合性的設計，導致只能解決單一問題，無法解決同產業類似的問題，也因此難以往市場推廣。
沒有人用，形成的因素有許多，包括因為當初在開發階段就直接跳過市場調研階段，或者忽視來自市場的反饋，又或者只考慮到功能面沒考慮到應用面或操作面或人性面，又或者只考慮到功能面卻又想做的太多導致 time to market 時間被拉太長，導致錯過最佳上市時機。
半成品，不論是專案或 POC，都還沒養成到能稱為產品的階段就被腰斬，被腰斬的原因有很多，包括資源的缺乏、時機的錯失、外在的干擾、三分鐘熱度等。
缺乏整體概念性，整體概念性來自軟體專案管理名著《人月神話》，意指貫穿整個產品的一致性的概念，概念泛指視覺風格、操作體驗、介面元件、使用流程的綜合感受，而由於現代軟體工程的複雜，以及專案角色的模糊，導致整體概念性不易被建構，最終獲得的就是能用，但不好用的半成品。

綜合以上，程式雖然並不佔據物理的空間，但負債程式帶來的危害卻更大，因為它佔據的是時間，空間可以被清理，但時間過去就是過去了，而閒置程式的另一項特質是它並不是放著不管也不會怎樣的物件，而是一系列需要被維護和除錯的程式碼構成的（記得那些還在使用的老用戶嗎？）。

危老程式的活化提案

想要提升危老程式的資產價值，就必須採取有效的活化策略，包括：

對既有客戶提出專換到新系統的誘因，這樣做的好處是多元的，讓新架構的新系統獲得既有的穩定客戶，也可以讓舊系統退役，降低維護所需要的成本，對客戶來說也可以用優惠的方案取得一套新的系統。
賦予產品更多的附加價值，包括品牌、形象、行銷等面向的資源投注，這幾樣元素很容易被誤解組成產品次要的部分，但實際上真正能打動客戶的往往就在於這些元素，而這其中包括了公司形象的建立。
把專案或 POC 的目標放在驗證市場，而不是驗證功能，你設想好的功能可能根本就不是市場要的，要嘛在實作前先調研市場需求，並且小心地不讓規格外溢成過度設計的樣子，要嘛就先做再接受來自市場反饋的意見，否則下面這張圖的狀況就會一再重演，而消耗的一樣是最寶貴的時間。

結語

回到最初的核心精神「物品的價值在於被有效的使用」，進而產生經濟價值，這樣的程式我們視為資產，反之，那些被深埋在硬碟角落的程式，無論它的功能有多麽的高大上，只要它沒有被有效使用，那它就是負債，因為你終究是花了時間去做它，付出的時間成本卻沒有獲得任何有顯著意義的收入，這樣的程式我們視為負債，然而負債也是能翻身的，前文提到幾個活化手段，不論手段為何，終究是圍繞著「提高產品的附加價值」這個核心觀念打轉，就像把企業把閒置廠房整地重塑一樣，賦予資產新的價值，對軟體這樣的無形資產來說，價值鏈的構成除了功能本身，用戶更能感受到的是產品本身的操作體驗，以及製作公司本身的企業形象，試問自己，當你看到迪士尼＋漫威影業的時候你心裡對他們製作的電影的預期是什麼，而你又希望顧客看到你的網站或 FB 專頁時能獲得什麼樣的印象或資訊？

做為一個產品開發人，常常會落入只追求到 know-how 的思維，卻忘了要去思考 know-what 以及 know-why，或許是被「開發」兩個字所制約，但我們更應該廣義的解讀「開發」，不僅是指「程式開發」，而應該擴大到「產品開發」，而程式只是構成整個產品的一部份，就如同建築的骨架，穩固的骨架當然是個賣點，但客戶不為因為骨架很穩就買單，他們對空間的機能性、外觀、生活機能性、交通等元素都同樣重視，同樣的軟體的用戶也不會只因為你的演算法多麽高大上而買單，他們對操作的便利性和美觀也同樣重視，另外他們也會感受公司與公司代表所呈現的形象，而這些元素都可以成為資產活化的方案之一，別忘了所謂的無形資產不僅是程式，也包括公司的品牌與形象，所謂的產品開發也包括公司的形象構建與傳播——如果你也想認真經營公司的話。