寫的有道理，但實際施行卻有相當的困難，專案考量進政治面時，就增加了很多變數，筆者也正是有了政治面的權力，才得以推行。最近遇到還蠻不好處理的情況，政治面的考量太多，專案人員都想做分析、企劃的角色，卻沒有動力去執行，將執行的事情不斷的外推或粗略的執行，無力感倍增~

 ——————

原文轉載自 CNET

自廢武功無疑是下下策，但軟體開發者在面臨專案的巨大壓力下，要如何不自廢武功呢？顯然忽略設計的做法是不可取的，因此，單單只利用系統實作技能來彌補設計不完整的缺憾往往常會把問題弄得更複雜，這樣做其實是本末倒置。

筆者認為開發者應該重視設計概念的整體性，這樣才能用更簡單而富有彈性的設計來解決問題，而要達到這個目的，開發者必須更專注在問題分析與概念設計的能力。

Continue Reading »

起源由從高鐵售票系統談大型公共建設軟體開發專案，當中引起了不少軟體經驗豐富的高手討論…

就經驗來看自已並沒有比這些人來的豐富，但我看到的是，這次的討論不也就代表了目前軟體開發產業中的現象，人人都有自己的一套觀點，人人都有自己的經驗，卻不見得能包容別人的方式、觀點。這個我自己也做不到，相信每人都有自己的專業，但如何在這些專業、經驗中整合出最好的，實在不容易或是可以說做不到，因為就以往的情況看來，最後的結果不是軟體最好的，而是策略上「最好的」，即是大家都可以接受的版本，我想這也是造就這些大型的公共軟體專案問題叢生的問題之一。

大型公共建設軟體專案之讀者討論 「委外分包管理」所提到的問題應該只是很小的一環，文中的前提是主包者可以明確的提出自己的需求，遇過不少的主包者提不出需求，初期要求分包商代替規劃，事後要求分包商不斷修改，這也難保分包商要兩手一攤了，因為根本超過分包商的能力或花費，這樣的主包商何來風險管理？

分析或猜測一事，就高鐵這案來看我想除了該專案開發人員可以實做到分析的事項外，這些的討論都僅能止於猜測問題的所在（實際開發人員有人要跳出來說他的分析情況嗎？），猜測應算是分析的一部份，沒有初步的猜測何來分析？但這當中又有人的問題了，有些人做事只做一半，只做猜測，不做分析，才會有這些問題才是。

如最後 同人 所說，管理是很重要的。管理重要卻困難，特別是在人的管理上面，管理者面臨困難時要如何正確的管理人員來因應，這也是困難的地方，軟體開發人員易尋，好的管理者卻難遇。