做IT的人都懂得的一個軟件開發流程：需求-設計-開發-測試-交付。放到自然界中變成公用的做事流程：做什麼-怎樣做-做-檢驗做的對錯-做完了去做另外一件事。但是做什麼還不是最重要的，做什麼的範圍纔是最最重要的。
由於引入一個新的碼頭，客戶數據庫中會生成針對新碼頭的數據，所以我們要分析是否新碼頭會對系統代碼有影響。爲了確保系統可以正常運行，我們用了一些臨時的視圖view，代替了表table，將新生成的碼頭數據先轉成老數據，然後等系統都改成可以處理新碼頭的業務時，再改回原來的表。
這樣上週五分析一天哪些SQL中用到了這些表要改成視圖，因爲悶頭做，沒有考慮這件事的需求範圍是什麼，也就是哪些SQL及時用了這些表，但不用考慮要做任何改動。到了晚上客戶和我說了一下，我才反應過來。導致週末又來加班，把不用改動的SQL從總結好的SQL中排除掉了。
所以需求範圍也就是做什麼的範圍纔是我們要開始寫代碼和做某件事之前，最要考慮清楚的，要不肯定會浪費自己的時間，效率又談何說起呢。