「我們採用Agile開發流程，使用雲端軟體Atlassianconfluence、Jira作專案管理與問題的追蹤；用Sourcetree、Bitbucket作版本管控；並考量未來每天千萬次的連線請求與後續資料探勘的運用，使用了SPDY與HAProxy…」一天擔任專案經理的好朋友跑來跟肥蝦說：「他們家的RD團隊要離職了！」肥蝦兩肋插刀的跑去聽朋友公司的交接說明。

看到對方RD團隊作了那麼多版本與專案管理的作業，並考量後續的發展，如此煞費苦心、深謀遠慮的作了那麼多預先工作，肥蝦不禁深感佩服！但聽到程式架構與資料庫結構，一下就傻眼了！肥蝦疑惑地問：「資料庫全部十幾個表格，那…表格是作什麼用的？系統有些類別是何用途？」準備離職且異常年輕的技術總監說：「因為很多歷史因素，所以有些程式與表格用不到，但因為時間與工作優先順序安排的關係，所以沒有刪除與修正。」那肥蝦又問說：「請問有沒有作業流程圖或使用案例之類的文件？」技術總監說：「我們完全從系統技術的角度來思考！」肥蝦是不敢直接問說：「目前該系統的開發只有兩位成員，系統尚未成熟到產品的地步，而PM也才一位，這那麼多工具會不會花了太多的功夫？」

版本管控與專案管理重不重要？當然非常重要。系統架構的預先構想重不重要？當然非常重要。但是系統或產品的開發，純以技術考量！整個團隊才三個人，需要使用四種工具！產品還未完成，處處留下歷史的包袱！這好像有點本末倒置，化簡為繁。

就肥蝦個人的觀念裏，任何系統開發或專案執行，最重要的是目標的達成，而目標是要明確並切實可行的。就比如網頁系統的建置，應先請業務或行銷部門概估未來一到三年的使用量，技術部門可據此加倍作為第一次建置的目標，並設想短期內使用量激增的可能因應之道；系統的開發，尤其是初版應特別注意系統的乾淨性，不要產品都還沒推出就留了一堆垃圾在裡面；至於專案管理、版本控管等理論或方法都在協助促進目標的達成。

因此朋友公司的RD團隊(兩個人也算團隊)用了版本控管的工具，知道每次修改的要點與對應的程式，那用不到的部分為何還不移除！系統尚未正式推出前，版本控管目的就只在版本控管？那為何要控管呢？尤其這技術總監的一句：「以技術考量開發產品。」這…那產品是要作什麼的？年輕的技術總監說：「Facebook跟Google都是技術卓絕才能有這麼大的商機呀！」這…肥蝦一下子三條線！他好像因果有點反置了，也許缺少行銷或者商業上的常識吧。

會後，肥蝦跟朋友聊聊，發表了些個人不成熟的想法與建議：「我想這整個系統規模就因應業務或行銷的需要並不複雜；很多原有的工具在目前階段應該不需要使用，不是說不重要，而是先以簡單的工具如Excel等進行。但是目前急迫的重點應該放在業務釐清，需求的溝通與產品的開發上。到底這系統所應對的業務是要以何為中心，必須儘快確定，再進一步確定業務的流程，並且設定市場使用群體的可能目標與階段成長量。」

產品或是系統的建構與開發，一定是在滿足特定的需求，不管是業務需求、技術需求…等，最終的使用者一定是人。就肥蝦朋友的產品開發專案，需求的來源來自業務或行銷人員，他們是以商業的用語與思維在建構一個商業系統；而相對地，資訊人員應從系統與資訊的觀點協助他們進一步去釐清業務的重點與目標，共同擬定目標與工作的優先順序，並提供成本與時程的估算，以實際去建置一套商業應用系統。

如果您跟業務或行銷人員溝通過，您會發現他們的夢想都很偉大，並且有著一個很大很大的範圍，滿足很多很多人的需求。但是為了付諸實踐，資訊人員必須要有【簡】與【化】的技能。【簡】：從複雜與實際的陳述與現況中，瞭解全貌後抽出重點核心、流程與例外，並且考量後續的擴充性，以及滿足可能的發展性-以建構出系統平台；【化】接著依據系統提供服務的要旨轉化成友善與方便的使用介面、符合人類行為使用的流程、資料與作業處理的結點，以及錯誤的控制、問題的預防與控制、意外的控制。

肥蝦曾在專案管理的生活思維部落格中針對【簡化】寫了下列陳述：

簡化的目的是要能建構整體的全面觀；

簡化的重點是要抓住精髓與理解主要的脈絡；

簡化的過程是要直指中心確認目標。

自己的生活態度要能簡單；

自己的物質慾念要能簡約；

提供別人的產品要能簡易；

提供別人的服務要能簡便；

交付別人的報告要能簡潔。

化是要化暴戾為祥和；

化是要化零散為完整；

化是要化腐朽為神奇。