我無論是在甲方，或是在乙方工作，講到從0到1建置一套系統，一律不建議做到完美。
為什麼？
還真不是為了賺錢 XDD，主要是以下幾點：
- 資源有限，而人類慾望無窮
- 世界唯一不變的，就是一切都在改變
- 欠缺客觀需求
通常負責規劃的使用者，因為"身負重任"，總是會把規劃做得很細緻，但越是這樣，每個機制間就配合得越緊密，或是要花很多成本，去達成一件簡單的事。
再加上周邊其他使用者，對新系統多少都會有自己的期待，這邊加一項，那邊加一項，最後需求就會越來越大。
然而資源是有限的。
當預算、上線日壓在那兒，人力有限的狀況下，在建置期要做到"一次到位"，簡直就是不切實際的造夢計畫。
我們的職責是帶團隊安全降落，所以雖然殘忍，但還是得把大家拉回現實——建置期最重要的目標，應該是托舉整個系統的核心需求，完成70-80%慣常使用的重要功能。
其次就是，每個系統在規劃時，當時面對的客觀環境（無論是使用者、技術、或是使用情境…）都有可能與後來不同。
各位是否有時會碰舊系統，看到一些天怒人怨的糞code，搞不懂當時的人為何要幹這種蠢事。
我倒是覺得，無論是人的能力、當時整體技術只能繞路解決，或是user堅持要這樣做……這就是該系統當時聚合而成的客觀環境，沒有對錯，更無好壞，只是當時的選擇而已。
人的能力會變強，技術也在進步，就連user的想法都有可能隨著時間更改，建置期認為機制應該走A方案設計，也許一年後，反而會認為B方案會更合適。
當系統架構或機制，在建置期就設計得十分"環環相扣"，當有一天客觀環境變動，就難以從中間找到合適的切點進行變動，屆時若不是放棄新需求，就是要花更多成本，才能調整。
最後，也是最重要的一點——建置期的規劃，通常都是以過往"沒有這個系統時"的經驗，進行設計。
當有系統後，實際運作一年後，這時遇到的難處、想解決的問題，才是系統使用者每天面對，且困擾著他們的。
所以，以"實際碰到的問題"來規劃系統，會比用"腦袋思考系統要做哪些功能"，更能貼合使用者的需要，並達到降低資源浪費，減少無用功能在系統裡堆疊的狀況。
個性雞婆使然，我在收到需求後，很常進一步向使用者求解——這個需求，想解決什麼問題。
先知道要解決什麼事，再盡可能依照實際的狀況，配合目前系統設計架構，去思考如何以最小成本，去處理這件事。
講得很美好，能不能實際做到，還是一樣要看"客觀環境"是否允許。
做系統有點像談戀愛，需要雙向奔赴才行。
不是單一個人、某個單位單方面努力就能完成的，若某方一昧前進，不知退讓，那也不會是個好用的系統。
