直接回答：這是屬於「系統分析/設計」的領域
間接回答：「經驗」比「理論」重要，就算讀完市面上所有的書，也不會立刻解決你的問題

在經過Demo Stage 後大約有40%的修改及新增開發，...，系統寫得很Hardcode而且沒有結構可言，...。

不知道這是你開發的第幾個系統
等你開發幾個以上的系統之後
我相信你一定可以寫出更有彈性的結構

另外
如果貴公司負責程式開發的人員不超過 10 個人的話
你也不必太期待有多好的系統結構/程式碼

這個問題很複雜，涉及系統分析/設計、架構規劃及作業流程...，面對需求變更過多的狀況可以做以下的確認：

1. 開始coding之前，需求是否明確? 通常長官都說不清楚，這時可以跟使用者確認，或者上網蒐集資料，再將需求整理為文件，與長官確認清楚再動工(Active Listening)，寧可挨罵，也不要糊里糊塗的冤死，筆者遇過太多專案，完成後長官才說『這不是我要的』(很像肯德基廣告?)。
2. 架構規劃：不管是framework或architecture，應針對需求選擇最有彈性的架構，而不是最流行、最新的架構，例如，筆者通常會開發一些工具，讓使用者自行設計，如儀表板、會計報表產生器，這樣使用者有需求，自行搞定，不要來煩我。
3. 作業流程：如果直屬主管支持你，你就可以設計『需求變更申請單』，需求變更一律要填申請單，經過需求影響評估、人力資源/成本估計、雙方部門經理同意，經過一連串的簽核，把一些討厭鬼嚇死。

總而言之，『謀定而後動』是最高指導原則，『先做再說』就好比俄國新兵上戰場，下場可想而知。

砍掉重寫，大破大立

很正常. 當專案需求不明確. 自然容易大改.

以下是"不求薪水多少. 但求問心無愧. 跟做的開心" 的做法.
如果你心中已經有"這又不是我該做. 我也沒領那麼多" .. 那我想無解.

1. 列出有關係的人. 拿到上面有打算做的授權. 最後是要執行的人
   1. 有關係的人都要列席: 不列席也要丟會議紀錄.然後信內寫:若無異議則以此決議.(每次開會對都要再三確認.以免有人不認帳)
   2. 上面有打算做的授權: 拿著雞毛當令箭. 因為很多人不想改變. 沒上級授權. 真的很難
   3. 最後要執行的人: 就算只是作業員. 也要面對面確認. 理解其不悅. 因為最後都會回一句不好用.
2. 再來就是自己包山包海. 這裡不是指都你做. 而是在規劃階段要全包. 全串. 也含設計. 撰寫程式倒不必全包. 壓日期就好. 最好是開會前列出WBS. 然後大家壓期程.
3. 每週進度回報.

大概這樣. 我很習慣同事都是公務員心態. 大家大多只是應付了事. 所以以前常遇到跟自己領一樣. 或領比我多. 卻做不好. 後來秉持. 心存善念盡力而為. 專案我來負責. 規劃. 設計. 但分包下去大家押日期. 拿到主管授權很重要.

最後. 在設計.撰寫階段被大改. 代表你不熟那個領域. 無法主導. 這時最好是該領域的人一起規劃. 而且畫面. 流程都要模擬. ..
規劃+設計 : 撰寫 : 上線, 每個階段沒做好. 對後面工時影響是1:10:100.
規劃+設計沒做好.花1小時改就好
規劃+設計沒做好.都開始寫程式了. 大概要花10小時改
規劃+設計沒做好.都上線了. 大概要花100小時改

簡單心得分享. 我也沒有加班. 每天8小時做我想做. 多做也只是後面我可以不用生氣.
而談需求.引導需求.甚至改善流程... 真的就是經驗了... 加油