這還是小意思啦，
政府的某些系統建置思維真的怪怪的，
明明可以省很多麻煩，
可是在系統操作流程還要脫褲子放屁。
某機關旗下的系統眾多，
但仔細看，有些系統可以合併整合，
可是背後都讀取同一個資料庫同一個資料表，
那當初為何不整合？
有些時候吼，政府開需求出來，
業界想要跟政府分享建置經驗，
可是政府卻又天馬行空的來搞很多人。
最好笑的是，
某位長官嫌這個系統難用，
大酸某開發公司的技術有夠爛，
但是，你他媽的需求書就是這樣寫的，
而且這份需求書的內容還是那位嫌東西爛的長官主導的。
以上案例歡迎政府長官對號入座
※ 引述《allan4362 (Allan)》之銘言：
: 過去曾經跟政府的相關平台打過交道
: 只能說....
: 事情永遠不是我們想的那樣
: 當初使用的平台
: 已經是算政府「近期」內建置的大型系統
: 但是在系統資料傳輸、建接上
: 效率還是一樣的「驚人」
: 重點是還能越改越難用
: 由於使用上被各地方使用者罵爆
: 後來開會時，才解釋原因
: 重點在主管機關的系統
: 不是直接讓你在資料庫建檔
: 而是你傳你的資料（買車票進車站）
: 傳完就放著 （站在月台）
: 系統固定每隔一段時間才出來撈資料（火車發車）
: 所以大家都在傳，自然月台上擠滿人
: 當月台上人太多，後面買票的卡在入口
: 甚至站在月台的不小心跌下去（沒上傳成功）
: 也是很正經的
: 遇到這種問題，大家一定想加開列車
: 把月台上的資料載走就解決了！
: NO~NO~
: 當初交手的系統，主管機關跟系統商的處理方式
: 是解決買票的人...
: 既然大家都一直上傳會塞車
: 那就限制使用者把上傳按鈕鎖住
: 讓大家30分鐘、一小時才能上傳一次
: 太聰明了
: 完美的解決.........個鬼
: 最後這個系統
: 成功的達成讓大家一邊修身養性，一邊工作的日常
: 甚至有些人會半夜睡前上傳資料
: 這樣隔天早上上班，剛好可以處理回來的資料
: 自主應變嘛！
: 如果還是用這個思維跟方法在處理資料
: 現在的結果也不意外了
: 啊！外面門鈴響了，我去看一下