印度專案質量管理經驗

計算機和通訊技術的迅速發展，特別是Internet技術的發展與普及，為企業內部、企業與外部提供了快速、準確、可靠的資訊交流渠道。

[@more@]資訊化企業運作管理系統已成為企事業單位參與全球市場競爭的必備支援系統。正是由於這樣的市場需求與技術發展現狀，為我國的IT行業帶來了空前發展的機遇，特別是軟體行業。軟體企業能否抓住這樣一個難得的發展機會需要多方面的努力，其中軟體質量保障在其發展過程中佔有重要的位置。 眾所周知，印度已成為世界上軟體業增長最快的國家，目前每年軟體業產值達數十億美元，並且還在以每年30%～50%的速度增長。比較我國和印度的軟體產業，就不難發現:中國擁有巨大的軟體市場和世界公認的軟體開發資源，在基礎研究和對技術前瞻性的把握上，也有自己的優勢，就整體社會經濟環境而言也優於印度。此外，中國的軟體開發人員費用比較低廉，僅是世界市場的1/3左右。雖然中國人並不缺乏軟體開發的天賦，但是在越來越強調規模化經營的今天，先天不足的管理痼疾使我們舉步維艱，難以擺脫小作坊式的軟體開發模式。而印度軟體業從一開始就立足於為美國軟體企業服務，並遵循其軟體開發的管理模式，與國際標準接軌。
管理上的問題不能得到徹底的解決，軟體的質量保障就無從談起。筆者最近在與印度一家透過了CMM4級評估的軟體公司（以下簡稱A公司）進行合作的過程中，較為詳細地瞭解了他們有關的一些詳細情況，更深刻地感受到了專案管理的規範化與企業軟體質量保障之間的密切關係。下面想著重從軟體企業的構架，軟體專案計劃、專案管理、專案經理的職責等方面對印度軟體的專案管理及我國軟體質量保障應注意的問題進行一些經驗總結，供業內人士參考。
1.軟體企業的組織結構
(1)A公司結構
圖1是A公司的組織結構圖，同國內公司差異較大的部門有QA、SSG和人力資源部門。

圖1
* A公司中，QA(Quality Assure)部門與研發部門獨立，負責監督流程的執行。QA同時負責領導與研發部門組成的聯合組，制定公司流程。
* SSG(System Support Group)類似我們的IT部門，負責公司所有計算機軟體和硬體資源的分配和管理。所有的辦公環境和開發/實驗室環境由SSG負責安裝和維護，計算機資源屬於SSG，由各個專案向SSG提出需求，專案結束後，裝置需要交還給SSG。個人和專案組沒有固定的軟體和硬體資源。SSG是與研發平行的部門。
* 人力資源部門負責公司的人力資源管理，並維護員工的技能。專案開始時，專案組向人力資源申請人力，向SSG申請計算機硬體和軟體。專案結束時需要釋放計算機資源給SSG，釋放人力資源到人力資源池，並同時更新員工的技能資料庫。研發部門的人力資源由研發總負責人和其助手分配(類似我國各公司的人力資源部)。
(2)專案組結構
1) A公司對專案組進行獨立核算，專案具體負責人為PC(Project Coordinator)，負責專案計劃和執行，對專案具體成員進行分工。在每個階段的結束會議上(如概要設計結束)，PC要接受QC(Quality Coordinator)的審查。除了PC與QC的介面外，所有外部介面都由EM(Engineer Manager)完成，EM負責與客戶打交道，向SSG、人力資源要求資源，與其他專案組協調進度。
2) 彙報關係為:
Team Member->Team Leader->PC->EM->研發總負責人。
3) 印度工程師分為7級，半年一次考評，即半年有一次升級機會。
1級:Software Engineer，剛畢業的本科生和研究生。
2級:Senior Software Engineer。
3級:Project Leader。
4級:Project Manager。
5級:Senior Project Manager。
3級可以成為PC，4級可以成為EM。剛開始平均2年升一級，越往後升職越慢。
A公司規定，一人最多可以同時兼任兩個專案的PC，EM管理的專案沒有限制。
A公司通常的專案組為4到5人，最多不超過10人。
以上是A公司（同時也是印度大多數規範化的軟體公司）的組織結構和專案組結構。可以看出，A公司的組織結構非常清晰，各個部門分類非常細，任務明確，軟體生產的每一個步驟都有專門的部門、專門的人員負責，從最基礎的開發人員到負責統領全域性的總經理，層層管理，溝通渠道暢通。而在我國，管理的不規範往往首先體現在公司的組織結構上，集中表現為部門的缺失和管理的交叉上。我國的軟體公司，大部分規模較小，開發人員超過100人的公司很少。在印度，軟體公司無論大小，都是“麻雀雖小，五臟俱全”，絕不會因為公司的規模大小而改變合理的組織結構。因此筆者認為，國內的軟體企業要想有效地保障產品質量，首先就要在構架合理的組織結構上下功夫，這就如同蓋高樓首先要打好地基一樣，地基不打牢，結構不合理，其他方面再下功夫也是徒勞。有人說，因為國內軟體企業規模小，所以造成結構設定的欠缺，但筆者認為恰恰是因為沒有建立一個規範化的組織結構，才會使軟體產品質量不保，進而嚴重影響了企業的發展擴大。
2.專案計劃
凡事預則立，不預則廢。這裡的“預”就是指計劃。對於軟體企業，計劃的重要性是不言而喻的。讓我們先看看A公司的專案計劃是如何制定的:在A公司，專案開始之前必須先估計專案的規模（以程式碼行數來衡量）;然後制定專案計劃。通常時間為2～3周，已知的最長有5周。EM負責制定專案 EWP(Engineer Work Paper)，其中定義了專案需要的人力和計算機資源，由相關部門同意，並報研發總負責人批准後才能開始專案。
專案的正式開始時間由專案組的Kickoff Meeting算起，Closeout Meeting結束。
大概很多人都聽過這樣一句話：“計劃趕不上變化”。這種“變化”對某些行業而言也許並不會產生太大的影響，但對於軟體企業而言，卻會給軟體產品的帶來嚴重的負面影響。為什麼會造成這種“計劃趕不上變化”的現象？究其原因，筆者認為主要是因為對計劃的重視程度不夠，計劃過於籠統、粗糙導致可執行性太差，再加上一些人為因素的影響，必然會產生這樣的後果。
如果我們的軟體企業都能像A公司這樣，在作計劃時能考慮到每一個細節，不是倉促做出決定，而是由所有的相關部門共同對產品計劃進行反覆研究、制定、討論、修改，最終形成一套系統、嚴密、具有很強的可執行性的計劃。計劃一旦形成，就嚴格按照計劃去執行，而不受某個人、某件事的影響，那麼就不僅能夠減少大量資源的浪費，產品的質量也得到了保障。
因此，對計劃的高度重視、周密制定、嚴格執行是企業有效保障產品質量的一個重要環節。
3.專案管理
當企業構架了合理的組織結構並制定了縝密的計劃後，就進入了產品的開發階段。在這個階段中，專案管理起了重要作用，它所涉及的環節相當具體複雜，下面先介紹一下A公司在專案管理上的具體細節：
(1)開發階段和專案週期
開發階段比較明顯，注重各階段應完成的功能，對本階段應完成的工作不能留到下一階段。
(2)流程
* A公司對流程比對專案更重視。
* 軟體開發流程非常規範和系統化，其流程的可執行性很高，並且能在實踐過程中不斷改進。A公司的流程已覆蓋到了一個專案研發的所有方面，包括從最開始的意向到最後軟體的版本釋出(release)，都有相應的流程規定，基本上已形成一種工業化的軟體開發。
* 人和流程是保證專案成功的兩個最關鍵因素。由好的人按好的流程進行專案開發，才能最大限度地保證專案的成功。一個好的流程可以保證差的人做出來的東西不至於太差，但不能確保做出精品。透過流程可以實現一種規範化、流水線化、工業化的軟體開發。
(3)計劃
1) 計劃詳細、周到。
2) 流程中明確定義開發階段。
3) 每個階段都列出了該階段的各項活動，並詳細描述每項活動的屬性:
* 進入條件，輸入;
* 驗證方法;
* 結束條件，輸出。
4)每個階段結束都要召開階段結束會議。前一個階段結束才能進入下一階段。
5)計劃中每個活動都比較具體，每個活動的時間以天（半天）為單位。計劃包括了開展質量控制活動的時間。
(4)Review
按印度公司流程，一般把Review和作為保證軟體質量兩個主要手段。測試的重要性就不需說明了，而Review則是一個非常簡單有效並能儘早發現軟體中錯誤的方法，可以說，任何交付物都要經Review後才能進行基線化。目前A公司有很詳細全面、可執行性很高的Review流程和各種交付物的Review Checklist。
在印度軟體企業，現有這麼一句口號：凡事有計劃，凡事必review。
(5)QA
QC（質量經理）作為質量保證部門（SQA）的代表，監督和保證專案的進展遵循QMS各項流程和模板，並且收集專案中發現的一些問題和解決方法以最佳化流程。
(6)度量資料
中比較強呼叫資料說話，對專案過程中基本上所有的資料都會有記錄，最後把收集的資料提交質量保證部門進行分析，以改進流程。A公司的專案經理和質量經理很重視專案中的資料收集，包括各種Review資料、測試資料以及專案組員每天的活動資料等。專案經理也要維護一個專案檔案，在這個專案檔案中可以說包含了專案開發過程中所有的產出、開發活動、管理活動等的記錄。可以這麼說，有了這個專案檔案，你就可以完全瞭解這個專案的開發過程。
(7)團隊精神
印度公司都比較強調團隊精神、合作精神，應該說，其流程本質上就要求員工之間的互相協調和理解。相對而言，印度員工的合作精神和協調精神都比我國員工要好得多。
(8)培訓
印度公司都比較強調培訓，一般有專門的培訓部門進行協調。在新員工進入公司後都會有公司流程和其他一些公司普遍章程的培訓，以保證員工對流程的理解和執行。對於具體專案，專案經理在制定專案計劃時就會在專案計劃中提出所有的培訓需求，包括技術上的培訓和其他所需的培訓。
(9)配置管理
在專案正式開展前，專案經理就要制定配置管理計劃，並且指定配置管理員建立起配置管理庫，按配置流程嚴格進行配置管理。在配置流程中也詳細提供了對更改的控制，沒有經過批准的更改請求是絕對不能進行的。
(10)記錄
記錄及時、充分、比較準確。這些記錄包括:重要的郵件、會議紀要、稽核記錄、缺陷報告、測試報告。
1)與客戶和其他專案組的所有往來必須郵件記錄。
2)對所有的活動都有一個跟蹤落實的過程，比如對所有的Review記錄和更改請求都會有一個狀態標識，標識其當前狀態，透過跟蹤其狀態來監督其落實。
3)對所有的活動，包括對文件和程式碼的更改都會有一個歷史記錄。
4)記錄比較準確、比較客觀。
5)許多記錄都是透過定量的數值記錄，強調以資料說話（CMM4級的重點就是量化管理）。
以上是A公司在專案管理中所涉及到的一些主要環節，很值得國內的軟體企業在制定專案管理規劃時借鑑。除此之外，我國的軟體企業在產品開發管理的過程中，還易出現以下幾個方面的問題:
1)需求說明差─需求不清楚、不完整、太概括、或者不可測試，都會造成問題。
2)不切實際的時間表─如果在很短的時間裡要求做許多事，出現錯誤是不可避免的。
3)測試不充分─只能根據客戶意見或系統崩潰來判斷系統的質量。
4)不斷增加功能─在開發正在進行過程中要求增加許多新的功能。這是常見的問題。
5)交流問題─如果開發人員對客戶的要求不瞭解，或者客戶由不恰當的期望，必然會導致錯誤。
這些問題的出現，將會對軟體質量的保證產生不良影響，針對上述問題並結合A公司在專案管理方面的經驗，筆者提出一些相應的解決方法，以供參考：
1)可靠的需求─應當有一個經各方一致同意的、清楚的、完整的、詳細的、整體的、可實現的、可測試的需求。為幫助確定需求，可使用模型 (prototypes)。
2）合理的時間表――為計劃、設計、測試、改錯、再測試、變更、以及編制文件留出足夠的時間。不應使用突擊的辦法來完成專案。
3)適當測試─儘早開始測試；每次改錯或變更後，都應重新測試。專案計劃中要為測試和改錯留出足夠時間。
4)儘可能堅持最初的需求─一旦開發工作開始，要準備防止修改需求和新增功能，要說明這樣做的後果。如果必須進行變更，必須在時間表上有相應的反映。如果可能，在設計階段使用快速的模型，以便使客戶瞭解將會得到的東西。這將會使他們對他們的需求有較高的信心，減少以後的變更。
5)溝通――在適當時機進行預排和檢查;充分利用團組通訊工具―電子郵件、群件(groupware)、網路故障跟蹤工具、變更管理工具、以及因特網的功能。要確保檔案是可用的和最新的。優選電子版文件，避免紙介質文件:進行遠距離聯合作業及協作;儘早使用模型，使客戶的預想表達清楚。
4.PC（專案經理）
專案經理是專案成敗的關鍵人物，其對專案的成敗負主要責任。因此在這裡將專案經理的有關內容單獨提出，以A公司為例詳細說明PC在整個產品研發過程中所扮演的角色，希望能對國內軟體企業的專案經理有所啟示。
（1)在A公司，按流程在一個專案正式開展之前，專案經理需要完成：
* 專案計劃(Project Plan):在此描述整個專案所應完成的交付物、專案時間表、培訓需求、資源需求、質量保證計劃以及過程和交付物的定量質量目標等。
* 專案配置管理計劃(Project Configuration Plan):在此指定配置管理員，描述專案配置項列表、配置管理庫、版本管理計劃等等。
*專案過程手冊(Process Handbook):在此描述本專案所採取的裁剪後的生命週期模型和流程。
（2）在專案開發過程中，專案經理需非常瞭解專案進度，進行工作任務細化、具體計劃和安排專案成員工作任務等工作。對突發事件專案經理需能及時合理地進行協調。
（3)總的說來，PC安排工作有這麼幾個特點:
a.PC對軟體開發具有豐富的經驗，瞭解軟體開發的普遍流程，瞭解各個階段所需完成的工作，這是安排好專案組成員工作的前提，在A公司對PC的整體素質要求非常高。
b.在專案正式開展前，PC準備專案計劃文件，在專案計劃中包含了專案進度時間表，但此時間表比較粗，只能給出各個階段和各個子階段的起始結束日期。對各個階段和各個子階段的詳細工作安排和各項工作責任人只能在專案開展工程中根據專案實際情況進行安排，一般是在每週專案組例會上進行本週詳細工作安排。
c.PC對工作安排往往精確到天，有時甚至精確到小時，要做到這一點，需要:
* PC對本專案進展非常瞭解。瞭解渠道通常是每週組員的狀態報告和直接與組員接觸瞭解，這也需專案組成員能如實彙報工作。
* 對現階段或本週所需完成的工作非常瞭解。知道現在該做什麼，並且能把各項工作進行合理細緻地劃分，因為各個分解的工作比較細緻，因此能相對精確地評估出這些工作完成所需的時間。
* PC對專案組員的能力比較瞭解，安排工作時能做到有的放矢。當安排的員工對工作不熟悉時，會指定相應的組員進行協助。
* PC對組員的工作安排都比較細緻飽滿。一般不會出現有些員工有事幹，有些員工沒事幹的情況，當出現這種情況或員工提前完成工作時，PC就會進行相應的協調。
d.PC在專案組例會上的工作安排一般只限於本週或甚至是過後的二、三天，一般不會太長，對長時間工作的安排容易失去精確並且不易控制。相對而言，短時間的工作安排就比較精確而且容易控制，並且能不斷根據完成的工作進行調整。當然，這就要求PC能根據專案計劃中的專案時間表進行整體進度的把握。
e.專案組例會一般一週一次（時間不能太長），但必要時（如組員工作已完成或其他事情），也可在中途召開專案會議進行工作安排，一般時間都比較短（十幾分鐘左右，一般不超過半小時，以免浪費時間），總之，當PC覺得需要時，就會召開專案會議。
f.當專案組出現意外事件或影響專案團結的事件時，PC能及時合理協調，解決專案組內的不和諧氣氛。
g.PC善於鼓勵手下，發揮員工的潛能，PC往往會讚揚很好地完成了工作的組員。
從上面可以看出，對PC的能力（包括技術和管理能力）要求是非常高的，我國的軟體企業往往只重視PC的技術能力，但事實上，一個只精通技術的人往往不能成為一個合格的領導者， 筆者認為對PC而言，首先要求他能夠比他的下屬看得更遠一步，順利時不盲目樂觀，遇到挫折時不茫然失措，使整個團隊始終保持高昂計程車氣。
總結　　
以上結合印度軟體專案管理的經驗總結了一些我國軟體質量保障應注意的問題。曾有人提出:這樣一味地學習模仿，民族軟體工業沒有多大希望。但筆者認為，在這個問題上不妨採取“拿來主義”的辦法，對於好的，事實證明是成功的經驗，首先是“佔有”，然後才是“挑選”和“創新”。如果能把印度的管理經驗真正領會並付諸實踐，相信對我們的民族軟體工業一定會起到積極的推動作用。