我第一個「具規模」的ERD圖是虛擬一個「樂透彩中獎資料建檔系統」，
我第一個「完成且具增刪修功能」的系統是「情趣用品店進銷存系統」。
由此可知，像我這種沒什麼才能又不用功的學生，一向靠著”聲東擊西”小聰明策略，讓改作業的助教眼睛為之一亮，心中為之一振，然後忽略了這作業本身的實質技術與內涵有多貧乏…。
工作後，面對使用者提出的包羅萬象要求，白爛小聰明再也不管用，我也一次又一次嘗到了不懂掌控「需求工程藝術」的苦果（書沒讀好真後悔）。
最近發生了一件血淋淋、落落長的案例，越想越有趣，決定留下記錄當紀念：
甲使用者啟動了新專案，會議記錄白紙黑字提出需求A，我懷著躍躍欲試，測試新技術的心態直說「太簡單，還有沒有什麼煩惱？我可以幫你們分擔效勞喔！」
一旁的乙使用者拿出了需求B，看起來有點意思，也比較有挑戰性，心裡OS：「完成後要是被歌功頌德挖矮拍勢啦～」
→雞婆憐憫心－大忌！除了天才開發者跟佛心來的，不然不要輕易開支票。
接下來就開始埋頭苦幹…
由於需求B比較棘手，且乙使用者很忙碌，也彷彿聽不懂我在問些什麼，我就自作主張裝氣魄：「啊不然你東西拿來，我自己研究啦～」於是整個專案我大概耗費70%精力在搞定這個不在文件申請開發之列的需求B。
→假會（台語較傳神）－需求是來自使用者，不是開發者的，如果無法引導需求也不要裝懂硬/gin/；
尤其當需求不是原配，而是不被正式承認的小三時，站錯邊就是悲劇的開始。
尤其當需求不是原配，而是不被正式承認的小三時，站錯邊就是悲劇的開始。
過程中仍舊有透過電話、郵件、會議不斷騷擾乙使用者問東問西，但幾乎處於自問自答狀態。
偶爾會想起需求A，催促使用者們記得測試，但這時甲使用者說：「基本上這個業務已經轉交乙使用者處理，我不方便干涉了。」乙使用者說：「這個…我不知道喔，那是甲使用者提的，你要問他比較清楚啦。」
偶爾會想起需求A，催促使用者們記得測試，但這時甲使用者說：「基本上這個業務已經轉交乙使用者處理，我不方便干涉了。」乙使用者說：「這個…我不知道喔，那是甲使用者提的，你要問他比較清楚啦。」
→抓重點－這一段可以發現需求已經失焦了，而我卻沒有把大家抓回主軸，還在專注「開發本身」的種種問題，
但身兼專案管理時，搞定key man及做對重點才能事半功倍。
但身兼專案管理時，搞定key man及做對重點才能事半功倍。
就這樣拖拖拉拉終於在期限內完成需求A與需求B，提出驗收時，乙使用者這時竟然不領情：「需求B…應該是可以用啦…啊我的需求C咧？」
哇靠！？哪來的需求C啊？？？
甲使用者：「我當初的確是提需求A，但對於乙使用者可能不適用，他需要的是需求B跟需求C。」
老天爺啊～到底什麼時候說過要做需求C，誰來評評理？！
是怎樣，需求B沒列進文件，我卻可以趕工偷開發，而需求C也應該如法泡製嗎？
我一把眼淚一把鼻涕拉拔出了一個需求B沒人在意，因為大家覺得這都是「理所當然」的；而憑空冒出來的需求C，竟然成了否定整個專案的關鍵！？
→後門別亂開－報應就是砸自己的腳。
還有，過程再辛苦不要指望有人能體會諒解，這畢竟還是一個「注重結果」的現實世界。
還有，過程再辛苦不要指望有人能體會諒解，這畢竟還是一個「注重結果」的現實世界。
氣到眼冒金星的我吃了一記大悶虧，真想通通砍掉不給用。
最後我做了一個很無聊的行為，偷偷弄了一個需求C的雛型丟在需求A與需求B中，讓使用者們看的到，點的到，卻無法使用…，以洩心頭之憤。
→好弱喔，現在想想根本沒有殺傷力吧？
是沒錯啦，如果我實力夠強，就一口氣弄出需求A+B+C，歡喜到你們艱苦到我。
或是打從一開始我就守住本分，只要做好需求A，不管對方怎麼鬧就是拿出文件證據依法辦理。
但是「需求工程」是門藝術，實在很難拿捏到使用者爽，開發者爽，專案管理也大爽的合家歡境界。我想通通討好卻又沒有那種能力，想堅守一方卻又害怕傷了和氣，最後就是落得全盤盡輸…
誰能教會我這堂課啊？！
