最近遇到兩個軟體開發的決策問題，一個是既有程式的加強，另一個則是全新的專案。有趣的是，同一個邏輯會導出來一個功能上的死結。

大前提是，公司的每一個小組，應該朝向降低軟體開發成本的目標而努力！(Keroro 軍曹如是說)
眾小兵: 喔!!!

[場景一]

Tamama: “Giroro 伍長，關於您先前寫的這個飛彈發射程式…..我發現您當初只實作了即時作戰的指令，平時的維修保養那段在藍星標準上的那部份程式都沒有實作….”
Giroro: “馬鹿野狼，我是軍人，只負責作戰，維修保養這種事應該不需要我來操心吧!”
Kululu: “Kekeke…..我可以 patch 喔~*詭異的笑*”
Tamama: “真的嗎? 太感謝了! Keroro 軍曹, 我們可以修改這個部份的程式讓它支援自動保養的藍星標準嗎?”
Keroro: “當然~~~不可以啊~ 我們現在沒有足夠的人力做回歸測試，雖然你們改的部份只是自動保養，但我們必須要重新跑一次戰爭模擬才行~ 不行不行，等到我們有預算做戰爭模擬再改吧! 要不然萬一為了支援自動保養而讓即時作戰的功能受到影響，總部怪罪下來我的蛙頭可是要落地的…”

摩亞桑: “也就是說，設計程式的時候要 「一步到位」?”

[另一個場景]

Tamama: “Keroro 大哥~ 你要的最新藍星攻擊雷射系統我已經設計好了….”
Keroro: “嗯~~很好~~ 等等，為什麼自動保養的界面也要加入開發的時程呢？我們的規格書上不是寫只要可以發射就好嗎?”
Tamama: “因為軍曹大哥上次說，如果我們要修改已經開發完的系統，就得要做完成的回歸測試；我想，與其到時候重做回歸測試，不如現在一開始就把這功能寫進去….”
Keroro: “不行不行，總部的規劃只有十天，你光是實作藍星標準就得花上八天了，這樣專案會延誤，萬萬不可，萬萬不可啊~~”
Tamama: “可是….現在不做，將來不是更做不了嗎?”
Keroro: “這問題我會反映到總部的，總作戰部後勤科會收集大家的需求然後做出共通的零件….”
Tamama: “那，大概要多久呢？”
Keroro: “依據經驗，大概是一年吧…..”

摩亞桑: “也就是說，「遙遙無期」？”

公司內部的專案如果以成本導向，理論上應該可以讓程式設計者更容易做決定。”成本導向” 並不只是看開發的成本，同時也需要看開發的效益；(收益-付出) 才是真正的成本。每一個新功能理論上 PM 應該要能夠訂出其收益，而軟體開發者可以定出其所需要付出的開發成本，測試者當然也可以列出其測試成本，進而對不同功能的先後順序進行整理。

但是，對於和開發者成本直接相關的函式庫，卻很難由 PM 預估其效應；把散落在程式各處的程式整理成函式庫，會記在本次專案的成本上，但其他獲益的專案卻不會反饋到這個專案上；某個工具程式如果很多專案都會用到，把它一次實作完整，會比每一個專案都自己實作自己需要的部份來得有益，但是這種決定卻很難在底層做出來，因為底層每一個人只希望先顧好自己的成本再說。

可是問題往上反映，就真的能夠被解決嗎？太底層的東西，往上反映顯得太旁枝末節；如果事情只要跨部門就需要大主管協調，似乎也是僵化的前兆啊….

還沒有想到什麼好的解決辦法，只能說，用成本導向來開發是對的，但兩個對的事情加起來可能是個死結，目前看起來，也只有由人來手動介入才有辦法解決這種死結了。