對一款OA系統來說，除了從源頭入手，做好模塊化架構外，還可以通過哪些層面确保OA系統的高質量，給用戶打造良好的體驗呢？本文将針對這一問題做仔細展開，希望對你有幫助。

大家在提到質量的時候大多會想到一些形容詞，如：好、壞、一般，用這些詞來指定某個産品是否好用、是否耐久、是否有缺陷。所以大多數人一提到質量，總難免想到産品缺陷，因此，缺陷少就自然而然地成為了高質量的代名詞，軟件産品也不例外。那麼軟件缺陷少就能代表軟件産品質量好嗎？

“這是肯定的”。也許在10年前甚至更早的時候用戶會這樣回答。

但是随着信息化建設不斷推進，用戶的信息化水平也有了很大的提高，在和用戶溝通的過程中，出現Z多的反而是“XX功能真不好用”、“首頁加載這麼慢”、“這個界面真不好看”、“這個功能不是我們要的”……這類偏用戶體驗的反饋。

美國著名質量管理專家J.M.Juran博士從客戶的角度出發，提出了産品質量就是産品的适用性，即産品在使用時能成功地滿足用戶需要的程度。由此可見，軟件缺陷少不再能夠代表軟件的質量高，而是僅僅成為了衡量軟件質量的其中一項指标。

“好看、好用、bug少、能解決實際問題”是用戶對軟件高質量的Z直接反饋。但是如何才能保證軟件的高質量呢？

從開發的角度來看，軟件需要達到高内聚、低耦合、代碼簡潔易懂。稱之為軟件的設計質量，具有外部不可見性，“高内聚低耦合”滿足軟件易于擴展、易于複用的要求，“代碼簡潔易懂”滿足軟件易于維護的要求。易于擴展和複用能夠保證快速響應用戶新需求，易于維護能夠保證快速響應用戶需求的變更。

協同辦公系統基于公司通用開發平台、采用模塊化架構思想建設而成。模塊化架構思想從根本上保證了宜昌OA系統達到“高内聚低耦合”的建設目标，通用開發平台從基礎層面确保了軟件的産品質量。除此之外，項目組還重點從以下幾個方面保證宜昌OA系統的高質量。

一、需求分析階段

有這樣一句話：“風險躲在需求的迷霧之後”。充分體現了需求分析的重要性，需求分析工作做得到位，就能為開發出優秀的産品奠定良好的基礎，反之則有可能導緻出現潛在的質量問題和業務價值的喪失。為了撥開“需求迷霧”，項目組在需求分析階段做了大量的工作。

要求需求分析人員在與客戶溝通的過程中避免使用計算機專業術語，要結合OA系統特性總結行業術語并在和客戶的溝通交流中逐步學習客戶“語言”。這樣可以Z大程度打破與客戶之間的溝通障礙，為客戶需求的收集和理解提供便利。

除卻常用的通知公告、新聞、工作流、人力資源等通用模塊，OA系統還具有強大的包容性，可以Z大限度的容納客戶個性化需求，因此要求需求分析人員能更好地理解客戶的業務，必要時采用駐場等方式觀察客戶實際工作流程。如系統開發過程中為滿足客戶對督查督辦業務的需求，項目組派專人負責直接與客戶督查室工作人員保持密切的聯系，及時收集分析用戶需求并反饋給開發人員。

即使是通用模塊，在面對大量客戶的時候也難免會遇到個性化的要求，對此項目組在保證系統穩定的前提下積極響應并盡量滿足用戶。極力把OA系統打造成一款适用于客戶、讓客戶滿意的産品。

二、實現階段

軟件實現階段的主要活動包含：詳細設計、編碼、測試，是軟件項目過程中工作量Z大、曆時Z長、細節Z多的階段。如果保證實現階段各項工作的開展，是确保産品高質量的重中之重。在實現階段，項目組主要采用以下原則做到質量保證。

對于簡單需求，關注重點集中在編碼和測試，盡量弱化詳細設計，避免耗費大量時間做無用功。

需要做的詳細設計也把側重點放在領域模型設計、業務流程設計、數據庫設計、核心算法設計，并在需求變更的時候優先調整詳細設計避免設計與實現脫節。

代碼規範基于阿裡巴巴java編碼規範結合具體情況進行調整，使之更符合項目組的要求，比如：要求類、方法、變量等的命名嚴格使用能代表實際意義的英文或縮寫；簡化對代碼注釋的要求，隻有複雜的算法邏輯才要求必須添加注釋。

進行不定期code review，代碼走查人員不局限于固定的項目成員，而是采用互查的方式進行，通過這種方式可以讓項目組成員學會閱讀代碼，發現好的編碼思想和算法邏輯，也能發現别人代碼中的不足以給自己警示，Z終達到全員開發能力的提升。

要求開發人員對自己負責的功能做到單元測試，并根據業務的變化及時調整測試用例，也為代碼重構工作的開展提供保障。

業務需求的變更、code review的結果，都可能需要變更代碼，項目組以此作為代碼重構工作的觸發點。重構不是簡簡單單地增加代碼或删除代碼，需要在對業務理解的基礎上進行恰如其分的代碼調整，而代碼重構也是開發人員對業務需求加深理解的一個過程。

三、運維階段

關于扁鵲有一個小故事：

魏文王曾經向扁鵲求助：“你們家三兄弟都擅長醫術，那麼誰的醫術Z高明呢？”

扁鵲回答：“大哥的醫術Z好，二哥的醫術稍微差一點，而我的醫術Z差。”

魏文王不解：“那為什麼隻有你聞名天下呢？”

扁鵲給的解釋是：

“大哥治病是在病人發病以前，這時候病人都不知道自己有病，大哥下藥就把病情扼殺在萌芽中，即使他的醫術不被世人所理解，但在我們家，都認為他的醫術很高明；

我的二哥治病是在病情剛剛顯現的時候，這個時候病人的病情還不是很嚴重，病人也沒有什麼痛苦，二哥一劑藥下去就可以藥到病除，所以很多人都認為二哥隻是治小病很靈；

而我治病，是在病情已經很嚴重的時候，病人已經受到了很多的病痛折磨。所以他們看到我用針放血、或用毒藥以毒攻毒、或者動大手術，讓病情很快痊愈。所以病人都認為我的醫術非常高明，隻有我聞名天下。”

運維階段的質量問題往往是設計、開發階段積累造成的，如果真的在運維階段出現了要動大手術的情況，那麼形勢就真的不容樂觀了，動的好則如扁鵲一樣“名揚天下”，動不好可能就是“亡羊補牢，為時已晚”了。所以項目組在實現階段加強對代碼質量的嚴格把控是很有必要的。

為了把好Z後一道關，項目組應非常重視系統的線上運行狀态，通過各種監控和預警措施提前發現問題并将其扼殺在萌芽中。

雖然項目組在質量管理方面做了很多準備和努力，但是對質量的把控仍然不能稱之為完美，還需要項目組把更多的精力放在質量管理上，需要公司提供必要的支持，需要所有人參與到質量管理工作中。我們的目标：實現全面質量管理。

何為全面質量管理，答：就是一個組織以質量為中心，以全員參與為基礎，目的在于通過讓客戶滿意和本組織所有成員及社會受益而達到長期成功的管理途徑。