PDCA質(zhì)量控制方法在外包業(yè)務軟件開發(fā)項目中的應用

肖嵐

（國家衛(wèi)星氣象中心 北京市 100081）

1 引言

隨著現(xiàn)代社會專業(yè)分工的細化，將項目整體或部分進行外包的形式日漸普遍。軟件項目的外包是由交辦方提出任務需求, 將本單位需要開發(fā)的軟件項目外包給專業(yè)從事軟件研發(fā)的企業(yè)或組織, 從而達到合理利用資源，提高工作效率的目的。

采用外包形式的軟件開發(fā)項目，作為任務交辦方，面臨如何對外包開發(fā)項目進行檢查控制，確保項目承制方如期交付符合實際業(yè)務需求的軟件產(chǎn)品。交辦方如果對外包軟件項目疏于控制，可能引發(fā)項目出現(xiàn)一些質(zhì)量問題, 如進度的延期、運用技術過時等，這些質(zhì)量問題會給交辦方造成不良后果或帶來很大的損失。因此，作為項目交辦方,制定有效的質(zhì)量控制方法和措施是項目成功的重要因素。

2 質(zhì)量管理與質(zhì)量控制

2.1 定義

質(zhì)量管理可定義為：“確定質(zhì)量方針、目標和職責，并通過質(zhì)量體系中的質(zhì)量策劃、控制、質(zhì)量保證和質(zhì)量改進來使其實現(xiàn)的所有管理職能的全部活動?！?/p>

質(zhì)量管理一般具有三項任務：

（1）制定質(zhì)量方針目標及其實施規(guī)劃；

（2）實施質(zhì)量保證；質(zhì)量保證是為使人們確信企業(yè)能滿足質(zhì)量要求而開展的,并按需要進行證實的，有計劃和有系統(tǒng)的活動；

（3）實施質(zhì)量控制；質(zhì)量控制是對質(zhì)量形成的過程進行監(jiān)視、檢測，并排除過程中影響質(zhì)量的因素。

由質(zhì)量管理定義，我們可以看出，質(zhì)量控制是質(zhì)量管理的一部分。

2.2 PDCA循環(huán)

有著“統(tǒng)計質(zhì)量控制之父”之稱的沃爾特·休哈特（Walter A.Shewhart）首先構想出PDS（Plan-Do-See）的管理模型。到了20 世紀50 年代，美國著名質(zhì)量管理專家由愛德華茲·戴明（W.Edwards,Deming）將PDS 模型進一步完善，提出了PDCA（Plan-Do-Check-Act）循環(huán)質(zhì)量持續(xù)改進模型。因此，PDCA 循環(huán)有時也被為戴明環(huán)（Deming Wheel）或持續(xù)改進螺旋（Continuous Improvement Spiral）。

PDCA 循環(huán)是全面質(zhì)量管理的思想基礎和方法依據(jù)，它分為四個階段，包括：

（1）P：Plan 計劃—計劃目標，確定方針和目標，確定活動計劃；

（2）D：Do 執(zhí)行—按照所制定的計劃組織實施；

（3）C：Check 檢查--將實施效果與計劃目標對比，檢查執(zhí)行的情況，判斷是否達到了預期效果，再進一步查找問題；

（4）A：Act 處置--對檢查結果進行總結和處理：成功的經(jīng)驗加以肯定，納入標準，遺留問題轉入下一個PDCA 循環(huán)。

PDCA 循環(huán)具有階梯式上升的特點，四個階段的活動不是運行一次就結束，而是周而復始，每循環(huán)一次，就取得一部分工作進展；到了下一次循環(huán)，又有了新的目標和內(nèi)容，上了一個階梯,即新的水平比原有水平提高了。

圖1：PDCA 循環(huán)示意圖

PDCA 循環(huán)是質(zhì)量管理體系的一種普遍方法,可以說在各行各業(yè)中，都得到了廣泛的實踐應用。

3 外包項目質(zhì)量控制中出現(xiàn)的問題分析

我們以某信息處理平臺的外包建設過程中出現(xiàn)的問題為例, 分析外包項目質(zhì)量控制中可能出現(xiàn)的兩類問題。

3.1 需求理解的偏差

某信息處理平臺的任務需求是對數(shù)據(jù)完成采集后，進行數(shù)據(jù)處理，最終生成數(shù)據(jù)產(chǎn)品。在需求與概要階段,任務交辦方與承制方對任務需求有過溝通,承制方也提交了概要設計文檔。此后雙方未進行進一步溝通，至開發(fā)收尾階段，承制方聯(lián)絡交辦方，交付測試版本，交辦方才發(fā)現(xiàn)承制方對信息流程的規(guī)劃與實際信息流程有差距，概要設計文檔中的設計只提供了框架設計，雙方按照各自的理解來解讀。 由于對需求理解的偏差，帶來了設計上的偏差。

3.2 各種原因引起的進度滯后

為保證開發(fā)任務按照計劃進行，在項目之初都會制定軟件開發(fā)計劃，但實際往往會出現(xiàn)進度比預期滯后的情況，例如由于前述需求理解的偏差導致的返工，將不可避免的會對進度產(chǎn)生影響；另外承制方開發(fā)人員的流動性也帶來了進度的不可控因素，這在某信息處理平臺的開發(fā)階段后期尤為明顯。

3.3 外包項目中的質(zhì)量控制責任

對于外包項目的按需交付，承制方有著不可推卸的責任與義務，交辦方對于外包項目的質(zhì)量控制也必須盡責，實施有效的質(zhì)量控制手段，對外包項目的質(zhì)量進行檢查、監(jiān)視與控制。

4 基于PDCA的外包業(yè)務軟件開發(fā)項目的質(zhì)量控制

4.1 背景

為避免以往外包項目出現(xiàn)的問題重現(xiàn)，對外包軟件開發(fā)項目進行有效的質(zhì)量控制至關重要。

以某業(yè)務支撐平臺開發(fā)項目為例，作為交辦方，對業(yè)務支撐平臺進行了業(yè)務層面的設計，包括人員權限管理、故障處理、資源狀態(tài)監(jiān)視顯示、業(yè)務操作記錄、關鍵業(yè)務數(shù)據(jù)的監(jiān)視顯示等功能。 研制任務書由交辦方進行編制，開發(fā)實現(xiàn)則采用了外包的形式，由專業(yè)軟件開發(fā)公司承擔業(yè)務支撐平臺的軟件開發(fā)任務。

作為交辦方，有責任對承制方的軟件開發(fā)過程進行監(jiān)督和質(zhì)量控制。質(zhì)量控制依靠事后檢查是不足夠的，更重要的是事先預防和事中監(jiān)控。因此，我們引入基于PDCA 循環(huán)的質(zhì)量控制方法。

4.2 持續(xù)改進的PDCA循環(huán)質(zhì)量控制

圖2：第N 周工作計劃節(jié)選示例圖

此項目的持續(xù)改進的PDCA 循環(huán)質(zhì)量控制以周為單位進行。包括：制定每周工作計劃（P）-＞按照計劃執(zhí)行本周工作任務(D)-＞檢查本周計劃完成情況(C)-＞本周工作完成情況的處置(A)。

4.2.1 P: 計劃

首先明確目標: 對承制方的軟件開發(fā)過程進行質(zhì)量控制，確保承制方按照進度要求，開發(fā)出符合任務書要求的業(yè)務支撐平臺。

根據(jù)以往的教訓，外包開發(fā)項目進度容易存在前松后緊的情況，即前期進度未控制好，后期局面被動。原因可能有多方面，如前期溝通不足導致理解有偏差，承制方項目組自身管理能力不足等原因，深層原因則是交辦方對項目的質(zhì)量控制力度不夠。為避免這一問題的再度發(fā)生，我們以周為單位開展質(zhì)量控制活動。

在需求分析階段, 承制方項目組編寫了軟件需求規(guī)格說明書與軟件開發(fā)計劃。為了達到質(zhì)量控制目標，我們要求項目組對軟件開發(fā)計劃進一步細化。以功能完成為出發(fā)點, 制定細化到模塊級的開發(fā)計劃：

（1）以進度控制和技術實現(xiàn)為出發(fā)點, 在模塊開發(fā)計劃的基礎上，制定細化到每周的工作計劃。

（2）每周工作計劃還應包括對上一個PDCA 循環(huán)轉入的問題進行原因分析后，所制定的執(zhí)行措施計劃。

4.2.2 D: 執(zhí)行

（1）承制方項目組按照事先制定的周工作計劃，執(zhí)行本周開發(fā)任務。

（2）交辦方按計劃與承制方項目組進行技術討論，以及提供必要的資源。

4.2.3 C: 檢查

交辦方質(zhì)量控制人員根據(jù)計劃，對承制方項目組上周工作任務完成情況進行檢查，并記錄檢查情況，識別出全部完成、部分完成、和未按計劃啟動的模塊；對部分完成的模塊估算完成進度百分比。

承制方項目組的項目經(jīng)理、項目質(zhì)量保證工程師對每周的檢查予以配合，展示完成情況，如有未按計劃完成的本周工作任務，必須說明原因。交辦方質(zhì)量控制人員記錄未完成原因，并生成每周檢查報告。

4.2.4 A: 處置

每周開項目周例會，參會人員包括但不限于：

交辦方：業(yè)務領導、業(yè)務技術骨干、質(zhì)量控制負責人

承制方：項目經(jīng)理、項目主要開發(fā)人員、項目質(zhì)量保證工程師

周例會一般分三部分：

（1）由交辦方質(zhì)量控制人員做上周開發(fā)任務完成情況的檢查報告。

（2）承制方項目經(jīng)理對上周開發(fā)工作情況進行說明。

（3）交辦方對上周工作進行總結分析，對已實現(xiàn)并達到要求的功能模塊予以肯定并放行；找出存在的問題，對問題的解決給出指導性意見。將問題解決轉到下一個PDCA 循環(huán)，并添加到下周工作計劃中。

4.3 采用PDCA方法問題解決實例

我們以周為單位，采用PDCA 方法對承制方的項目開發(fā)進行質(zhì)量控制，在此過程中所發(fā)現(xiàn)的問題，同樣采用PDCA 的方法對問題予以解決。

4.3.1 技術問題解決實例

（1）P 計劃: 關于APP 開發(fā)有幾種技術框架，native app(原生)、web app、hybrid app(混合)，承制方應采用何種APP 技術框架，對應使用哪些技術不夠明確。為了解決這一問題，做出計劃：1 雙方進行技術討論2 承制方項目組提交符合要求的APP 框架設計方案。

（2）D 執(zhí)行：雙方進行了專題技術討論，承制方項目組對討論內(nèi)容整理分析后，完成APP 框架方案設計。

APP技術框架采用web app，依托于瀏覽器的形式，跨平臺使用，無需分別開發(fā)Android/ios/pc 端多種版本，這樣開發(fā)成本低，開發(fā)速度快。采用前后端分離架構: 后端采用node，前端采用PWA 技術。

（3）C 檢查：對承制方的方案從技術層面進行檢查評審。

（4）A 處置：APP 框架方案評審通過，在概要設計中將此APP 框架設計方案包括進去。

4.3.2 進度問題解決實例

（1）P 計劃：在項目進展過程中, 發(fā)現(xiàn)個別模塊的開發(fā)進度有停滯現(xiàn)象，與項目經(jīng)理溝通后，分析原因，負責該模塊的開發(fā)人員被臨時抽調(diào)到其它項目組了，項目經(jīng)理無法保證該開發(fā)人員何時回歸本項目組。針對這一問題，立即制定與承制方高層進行溝通的計劃，目標是確保進度不受影響。

（2）D 執(zhí)行：與承制方主管該項目的高層進行溝通，督促承制方高層進行干預，確保人員到位，項目進度不得延誤。

（3）C 檢查：經(jīng)交辦方質(zhì)量控制人員檢查，人員已經(jīng)到位，該模塊開發(fā)工作恢復。

（4）A 處置：該進度問題得以解決，總結經(jīng)驗：對影響進度的原因（如：技術原因、人為原因、計劃未估計到的原因等）進行分析，及時采取措施消除影響進度的因素。當開發(fā)進度出現(xiàn)延遲或停滯，項目經(jīng)理解決情況不理想的情況下，及時向承制方高層反應，保障開發(fā)進度。

4.4 PDCA質(zhì)量控制中的領導作用

在GB/T19001-2016 質(zhì)量管理體系要求中，“領導作用”是質(zhì)量管理七大原則之一。在PDCA 循環(huán)中，領導作用處于核心位置。

在外包業(yè)務軟件開發(fā)項目中,領導的核心作用對項目的質(zhì)量控制起著關鍵作用。領導對項目質(zhì)量的重視，推動全員積極參與業(yè)務支撐平臺開發(fā)項目的質(zhì)量控制活動，確保資源可獲得，PDCA 各個階段工作順利開展，最終項目開發(fā)取得預期的效果。

5 結語

我們采用基于PDCA 的質(zhì)量控制方法，開展了對外包業(yè)務支撐平臺軟件開發(fā)項目的質(zhì)量控制工作。每周一個PDCA 循環(huán)：制定計劃，實施計劃，檢查執(zhí)行情況，對完成情況進行總結處置； 同時對特定問題的解決也是采用PDCA 方法。正是基于有效的PDCA 質(zhì)量控制方法，解決了軟件開發(fā)過程中出現(xiàn)的問題，承制方按照進度完成了開發(fā)任務，業(yè)務平臺如期上線使用。事實證明，基于PDCA的質(zhì)量控制方法在外包開發(fā)項目中適用，實現(xiàn)了質(zhì)量控制的預期目標。