You never learn, until it happens!

很久以前就說，新的AP 只要WEB化就好了。

原來廠商使用一種轉換工具，將舊的Client-Server AP轉成新的Web-based AP，才可以省很多分析的工作。

新系統上線，第一天只存活了兩個小時，原因不明，第二天只存活了半個小時，資料庫死當。然後第三天，決定新系統停用，轉回舊系統，新系統的所有已經完成的作業回舊系統重新做。

就當我預言成真的一個紀錄吧。

奇文共欣賞

註:
1.我是業主。
2.能夠收到這一篇奇文，雙方都有責任，但是系統開發商寫出這麼沒有專業的東西，真是奇文。也難怪本資訊專案難產。

鑒於軟體系統開發案，本質上即具有需要業主協力配合部分，故本案在契約變更後，須在雙方全力配合下，始能順利完成。若依業主要求之時程於明年底完成建置，本公司需業主配合事項如下：

1. 有關業務流程再造作業, 因涉及業主組織運作，建議請業主於組織內先行完成整合明確訂定後，再提交本公司作為進行系統開發與建置之依據。
2. 成立功能分析小組，由雙方派遣專人編成，集中作業，每次需求訪談時業主業務單位，資訊單位之小組成員均應同時出席。
3. 各系統每週至少應安三天需求訪談，以密集之訪談方式執行，目前各子系統每週分配3小時。 以XX子系統為例九個月共訪談50場次，共計25工作天但花費近一年時間，訪談時程冗長。
4. 改變需求訪談模式，由業主依RFP所列功能提出說明，而非由本公司一再簡報。
5. 業主應先訂定文件製作標準，本公司再據以製作文件。
6. 測試情境的擬定由業主負責編制。
7. 文件之審查應簡化，並相互訂定確認時間，例如每件 SA/SD 文件送請業主審查後，最遲應於10個工作天內完成審覆。
8. 應用系統功能之查驗，應以雙方確認之系統分析及設計報告書所述之系統功能所展開之程式為基準，而不是以畫面之操作步驟來作為系統測試之基準。
9. 配合次階段系統整合性分析和整體應用系統設計兩階段需求之一致性，請業主於各應用系統進行系統細部設計訪談與確認前，召開次階段系統設計的內部說明會議，以使參與人員具有相同認知。
10. 由雙方派遣專人編成資料庫資料遷移小組，集中作業。
11. 次階段應使用之系統軟體併入各年度硬體採購。
    

新的AP 只要WEB化就好了

終於把一個原本2億兩年的專案在5年內做完。老闆捧著3000萬的預算，開始規劃下一個AP的開發。這個舊AP是公司內業務執行的重要AP，以Power Builder開發，從2000年上線到現在已經老舊不堪了。從當初開發的功能以後，配合業務單位的需求，功能修修補補已經不曉得蓋了多少違建。

老闆說，5年的專案做完了，獲得的教訓是不要做大；只有少少的3000萬，也沒有辦法做大，把目前的 AP的畫面與功能做成Web page 即可。呃，Power Builder 的AP要變成Java/.Net的MVC Web App真的只要照抄畫面與功能即可嗎？不需另外作新的分析設計？

老闆又說不要重做Business Analysis，從舊AP的功能開始SA規劃即可！那花2億做出來的東西與舊系統功能相重疊的地方怎麼辦？不與未來的AP做整合了嗎？現在AP的功能真的合乎目前與可預見的未來的業務需求嗎？

我好像又看到了組織獲得另外一個3000萬失敗教訓的機會。