我以前去某間出名的薪水低、工時長，公司經營幾十年的電腦系統整合公司面試，對方有給我看他們的文件，說他們的系統分析文件都很豐富，就像一本書那樣。我大概翻了一下內容，裡面沒甚麼UML啊、流程圖之類的，就一大堆的文字。我也遇過問問題回答一大堆，但根本都沒講到重點的爛工程師(但偏偏需求是他去談的)。
系統分析文件這種東西，如果是大型專案，常常都只是個浪費地球資源、給客戶做做樣子的垃圾。隨隨便便就幾百頁甚至上千頁，印了好幾本，客戶可能還只用word拼字錯誤檢查有多少錯誤要修，文件還要出好幾個版本，如果程式設計師要看大概也會看得很痛苦，平常幾百頁甚至上千頁的書就不太會短時間看完了，規格書有時間仔細看嗎?但如果不看那文件，可能又會不太理解需求，而談需求的人也可能只會把文件丟出去說需求都在裡面，叫別人自己看。
看文件與理解需求是需要時間的，資訊量越大，越需要時間過濾(沒用的垃圾)與吸收(有幫助的資訊)。那種大量內容的文件對需要理解與作後續動作(寫系統設計文件、寫程式、了解測試情境)的人而言會是種痛苦。甚至到了專案後期，當初的談的需求可能又會有很大變化，文件可能就變成很多內容都已過時，雖然就一般走系統分析、設計、撰寫、測試、維護的流程來說，需求應該前期就能確認個大概，但是軟體工程對鬼島文化而言向來只是形式罷了，搞得一團亂再罵軟體工程無用是很正常的。
舉個簡單例子，台灣軟體業的開發團隊結構很多情況是：
出一張嘴的人：談需求、開規格
實作的人：實作，可能還要兼任測試人員
規格一般會給不懂技術的客戶確認，客戶也常常不會好好地確認與想清楚內容，如果確認ＯＫ，這規格會直接給實作的人看。
因為這規格會給不懂技術的人與技術人員看，而通常不懂技術的人又比較重要，所以就會往適合不懂技術的角色看的方向撰寫，對實作的人而言，文件很容易變成內容一大堆，但又不太符合現實，也搞不太清楚重點在哪。
就寫規格的人而言，他可能會覺得只要所有要的資訊都說了，他的責任就完畢了，但也丟了很多沒用的資訊給開發人員，增加開發人員的困擾。有時寫得豐富，只是一種逃避責任的做法，避免有人說他都沒說有這需求。
我認為所謂的效率應該是時間有很高的比例是花在有用的事物上面，而不是花很多時間在處理沒用的資訊上。理想的規格應該要針對不同看的角色去撰寫不同的規格，尤其不要系統分析和系統設計文件合在一份文件寫。只是這是理想，鬼島文化是不講理的，寫在一起比較省時間，對寫規格的人而言可以比較快完成工作而做更多專案，讓人覺得績效比較好。
結論：描述需求最重要的是精準，而不是豐富
留言列表
