對一款OA系統(tǒng)來說，除了從源頭入手，做好模塊化架構(gòu)外，還可以通過哪些層面確保OA系統(tǒng)的高質(zhì)量，給用戶打造良好的體驗?zāi)兀勘疚膶⑨槍@一問題做仔細(xì)展開，希望對你有幫助。

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

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

但是隨著信息化建設(shè)不斷推進(jìn)，用戶的信息化水平也有了很大的提高，在和用戶溝通的過程中，出現(xiàn)最多的反而是“XX功能真不好用”、“首頁加載這么慢”、“這個界面真不好看”、“這個功能不是我們要的”……這類偏用戶體驗的反饋。

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

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

從開發(fā)的角度來看，軟件需要達(dá)到高內(nèi)聚、低耦合、代碼簡潔易懂。稱之為軟件的設(shè)計質(zhì)量，具有外部不可見性，“高內(nèi)聚低耦合”滿足軟件易于擴(kuò)展、易于復(fù)用的要求，“代碼簡潔易懂”滿足軟件易于維護(hù)的要求。易于擴(kuò)展和復(fù)用能夠保證快速響應(yīng)用戶新需求，易于維護(hù)能夠保證快速響應(yīng)用戶需求的變更。

協(xié)同辦公系統(tǒng)（本文簡稱OA）基于公司通用開發(fā)平臺、采用模塊化架構(gòu)思想建設(shè)而成。模塊化架構(gòu)思想從根本上保證了OA系統(tǒng)達(dá)到“高內(nèi)聚低耦合”的建設(shè)目標(biāo)，通用開發(fā)平臺從基礎(chǔ)層面確保了軟件的產(chǎn)品質(zhì)量。除此之外，項目組還重點從以下幾個方面保證OA系統(tǒng)的高質(zhì)量。

一、需求分析階段

有這樣一句話：“風(fēng)險躲在需求的迷霧之后”。充分體現(xiàn)了需求分析的重要性，需求分析工作做得到位，就能為開發(fā)出優(yōu)秀的產(chǎn)品奠定良好的基礎(chǔ)，反之則有可能導(dǎo)致出現(xiàn)潛在的質(zhì)量問題和業(yè)務(wù)價值的喪失。為了撥開“需求迷霧”，項目組在需求分析階段做了大量的工作。

• 要求需求分析人員在與客戶溝通的過程中避免使用計算機專業(yè)術(shù)語，要結(jié)合OA系統(tǒng)特性總結(jié)行業(yè)術(shù)語并在和客戶的溝通交流中逐步學(xué)習(xí)客戶“語言”。這樣可以最大程度打破與客戶之間的溝通障礙，為客戶需求的收集和理解提供便利。
• 除卻常用的通知公告、新聞、工作流、人力資源等通用模塊，OA系統(tǒng)還具有強大的包容性，可以最大限度的容納客戶個性化需求，因此要求需求分析人員能更好地理解客戶的業(yè)務(wù)，必要時采用駐場等方式觀察客戶實際工作流程。如系統(tǒng)開發(fā)過程中為滿足客戶對督查督辦業(yè)務(wù)的需求，項目組派專人負(fù)責(zé)直接與客戶督查室工作人員保持密切的聯(lián)系，及時收集分析用戶需求并反饋給開發(fā)人員。
• 即使是通用模塊，在面對大量客戶的時候也難免會遇到個性化的要求，對此項目組在保證系統(tǒng)穩(wěn)定的前提下積極響應(yīng)并盡量滿足用戶。極力把OA系統(tǒng)打造成一款適用于客戶、讓客戶滿意的產(chǎn)品。

二、實現(xiàn)階段

軟件實現(xiàn)階段的主要活動包含：詳細(xì)設(shè)計、編碼、測試，是軟件項目過程中工作量最大、歷時最長、細(xì)節(jié)最多的階段。如果保證實現(xiàn)階段各項工作的開展，是確保產(chǎn)品高質(zhì)量的重中之重。在實現(xiàn)階段，項目組主要采用以下原則做到質(zhì)量保證。

• 對于簡單需求，關(guān)注重點集中在編碼和測試，盡量弱化詳細(xì)設(shè)計，避免耗費大量時間做無用功。
• 需要做的詳細(xì)設(shè)計也把側(cè)重點放在領(lǐng)域模型設(shè)計、業(yè)務(wù)流程設(shè)計、數(shù)據(jù)庫設(shè)計、核心算法設(shè)計，并在需求變更的時候優(yōu)先調(diào)整詳細(xì)設(shè)計避免設(shè)計與實現(xiàn)脫節(jié)。
• 代碼規(guī)范基于阿里巴巴java編碼規(guī)范結(jié)合具體情況進(jìn)行調(diào)整，使之更符合項目組的要求，比如：要求類、方法、變量等的命名嚴(yán)格使用能代表實際意義的英文或縮寫；簡化對代碼注釋的要求，只有復(fù)雜的算法邏輯才要求必須添加注釋。
• 進(jìn)行不定期code review，代碼走查人員不局限于固定的項目成員，而是采用互查的方式進(jìn)行，通過這種方式可以讓項目組成員學(xué)會閱讀代碼，發(fā)現(xiàn)好的編碼思想和算法邏輯，也能發(fā)現(xiàn)別人代碼中的不足以給自己警示，最終達(dá)到全員開發(fā)能力的提升。
• 要求開發(fā)人員對自己負(fù)責(zé)的功能做到單元測試，并根據(jù)業(yè)務(wù)的變化及時調(diào)整測試用例，也為代碼重構(gòu)工作的開展提供保障。
• 業(yè)務(wù)需求的變更、code review的結(jié)果，都可能需要變更代碼，項目組以此作為代碼重構(gòu)工作的觸發(fā)點。重構(gòu)不是簡簡單單地增加代碼或刪除代碼，需要在對業(yè)務(wù)理解的基礎(chǔ)上進(jìn)行恰如其分的代碼調(diào)整，而代碼重構(gòu)也是開發(fā)人員對業(yè)務(wù)需求加深理解的一個過程。

三、運維階段

關(guān)于扁鵲有一個小故事：

魏文王曾經(jīng)向扁鵲求助：“你們家三兄弟都擅長醫(yī)術(shù)，那么誰的醫(yī)術(shù)最高明呢？”

扁鵲回答：“大哥的醫(yī)術(shù)最好，二哥的醫(yī)術(shù)稍微差一點，而我的醫(yī)術(shù)最差?！?/p>

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

扁鵲給的解釋是：

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

我的二哥治病是在病情剛剛顯現(xiàn)的時候，這個時候病人的病情還不是很嚴(yán)重，病人也沒有什么痛苦，二哥一劑藥下去就可以藥到病除，所以很多人都認(rèn)為二哥只是治小病很靈；

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

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

為了把好最后一道關(guān)，項目組應(yīng)非常重視系統(tǒng)的線上運行狀態(tài)，通過各種監(jiān)控和預(yù)警措施提前發(fā)現(xiàn)問題并將其扼殺在萌芽中。

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

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

本文由 @花田ikdo 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議