[原創]軟體企業過程改進開展--之高層管理者支援

pharos發表於2019-04-09
軟體企業過程改進開展
--之高層管理者支援
 
摘 要 隨 著軟體行業的發展，軟體企業對軟體開發的一致性、高效、低成本、高質量提出了更高要求。本文從軟體企業開展過程改進的關鍵干係人—高層管理者角度出發，分 析和提出如何推動過程改進的一些觀念和見解。本文是筆者《軟體企業過程改進開展》系列文章之一，後續將會從工具支撐、團隊實施等角度嘗試分析。
關鍵詞 軟體過程改進 SPI CMM/CMMI PMBOK ISO9000 度量
1         引言
軟 件企業在發展到一定階段時，對軟體開發質量、進度和成本會有越來越高的要求，於是軟體過程改SPI （Software Process improvement）進成為必然。我國引進過程改進已經多年，包括CMM/CMMI體系、ISO和歐洲一些模型標準的推廣等。20世紀90年代初，我 國開始引進國際流行的質量管理標準ISO 9000。20世紀90年代末，軟體界又開始逐漸把注意力轉向了CMM，越來越多的軟體企業開始注意軟體過程改進SPI。與此同時，以提升專案管理能力為 目標的美國專案管理知識體系PMBOK也引入中國。在這些標準、體系引領下，有的企業在質量和過程方面取得顯著成效，有的則不夠理想，甚至有的沒有什麼成 效，拿到個證書也只是做做樣子，用於裝扮自己的企業。
為什麼會有這樣大的差別呢？關鍵在於企業或組織如何改進自己的過程。無論 是藉助標準或模型還是自我內部需要，企業需要結合自己的實際，找到可行的方法和途徑。這裡面涉及公司高階管理層的支援、人力和物力（如工具）的投入、團隊 實施等一系列問題，只有解決了這些問題過程改進的開展才可能有成效。
進一步說，眾多軟體企業對如何制定軟體過程改進策略？過程改進需要哪些基礎支援？過程改進如何開展？等問題並不很清楚，也沒有達成某種程度上的共識。這樣，過程改進多趨於形式化，進而無法有效開展。
2         軟體過程改進開展概述
過程（Process）是為實現既定目標的一系列操作步驟[IEEE-STD-610]。
那麼，軟體過程（Software Process）則是指人們用於開發和維護軟體及其相關產品的一系列活動、方法、時間和革新。
軟體過程涉及軟體工程和軟體管理兩類，工程類的主要過程域：需求開發、系統設計、軟體實現、軟體測試、軟體維護等等；管理類的主要過程域：專案規劃、專案監控、需求管理、質量管理、配置管理等等。
2.1        軟體過程改進策略
通常，軟體過程改進有自上向下和自底向上兩種模式，前者是基於標準的，由標準來規範實踐；後者是基於實踐的，由組織中待解決問題出發，選擇和裁減標準。
對 於大、中、小軟體企業而言，採取的軟體過程改進策略不一樣，關鍵看是否符合自身的實際情況。中小企業的實際情況是：管理基礎薄弱，資源不足，生存壓力大， 缺乏統一而有力的文化，人員素質良莠不齊；而大型企業相反。大型軟體企業自上而下的模式比較容易推動，對於中小型軟體企業在沒有正式評估的壓力情況下，採 用自底向上模式更合適。
以下是針對中小軟體企業的一系列具體的過程改進策略[1]。
策略一：兩個方針
重診斷，輕評估 以診斷和解決企業實際問題為SPI方法論，不追求商業評估。
策略二：兩手抓
實施制度化的同時，並行實施企業文化；既要施壓，又要清障。
中小企業往往制度化體系很不健全，存在著隨意決策的管理習慣，甚至基本的企業紀律都不具備，企業還處於人治和法制的爭論中，這樣的狀態和某些大企業實施SPI的狀況是不同的，需要特別強調行政施壓。由於缺乏統一的企業文化，所以理念的統一也要加以重視。
策略三：推行兩種工具
要推行配置管理工具和專案管理工具這兩種工具，工具將有效分解事務性工作，從而緩解人力資源投入不足的矛盾。
策略四：補兩門基礎課
為了解決基礎薄弱的問題，需要在SPI前期為企業補基礎管理和基本軟體工程兩門課。
軟體企業需要補的基礎管理內容包括：基本時間管理、角色轉變、目標管理、溝通管理、基本人力資源管理等。基本軟體工程則包括基本的軟體工程生命週期、階段劃分、基本文件編制等。
策略五：發動三方參與
一是高於專案管理的層面，稱為高層經理。他們提供資源和戰略兩方面的支援，所以高層經理應該對體系總體架構、體系實施必要性、可行性、障礙和風險、資源等負有責任。
二 是專案管理層面，含專案經理和SPI人員。SPI人員作為制度化體系的執行者和推行者應該加強自身修養，要求別人的事，一定要自己能做到。而專案經理作為 主要的一線實施人員，需要對整個體系的細節有深入瞭解和研究，應該把日常工作時間的30%～50%放在工程化管理相關事宜上，要貫徹公司的SPI整體制 度，積極主動在專案組內進行推行。
三是專案組成員，包括開發和測試人員，要求團隊以紀律性要求自己，做好區域性和整體、短期和長期的矛盾平衡。
2.2        軟體過程改進開展的基礎支援
軟體過程改進SPI是變革管理的一種，凡是變革管理都需要進行干係人分析，包括企業的高階管理層、部門管理、專案經理、專案成員、客戶等幾部分。軟體企業在確定適合自身的實施策略後，需要這些利益相關人的支援，特別是高層管理者的支援。
同 時，所謂巧婦難為無米之炊，軟體過程改進需要一定的人力、物力的投入，包括設立EPG組織、專職SPI人員、專門的工具等。通常SPI專職人員的比例應該 佔公司研發團隊總數的3~5%；過程資料的採集和分析需要工具的支撐，要考慮是外部購買還是自我開發支撐工具。這些都涉及一些投入成本。
企業有了以上這些基本支援，軟體過程改進才能有保障。
2.3        軟體過程改進開展的團隊實施
確定了適合軟體企業自身軟體過程改進的策略，獲得了高層管理等干係人的支援，有了一定專門的人力和物力投入，那麼軟體過程改進的實施關鍵就剩下在組織團隊中推廣了。推廣的步驟，參考如下[2]：
步驟1 – 準備專案列表
識別所有當前正在執行的專案
識別專案狀態
步驟2 – 識別要開展流程的專案
識別專案中需要匯入的過程
識別專案中需要開展的過程
步驟3 – 準備匯入或開展流程的計劃(包括專案)
專案成員的角色和職責
從專案團隊中獲取支援
召集會議並說明角色和職責
步驟4 – 提供支援
SEPG應該輔助專案組填寫模板
SEPG應該注意解決過程的疑問
SEPG應該為實踐者所遇到的的問題提供可行的解決方案
SEPG應該對所開展的過程有積極的評論
步驟5 – 收集反饋意見&進行改進
每日召集專案成員開專案會議（15分鐘左右）
收集反饋意見和所面臨的問題
在每天的SEPG會議上進行討論
識別解決方案來合併反饋
當過程需要變化時進行過程改進
步驟6 – 提供培訓
解釋為什麼過程發生了變化？
給實踐者提供詳細的過程培訓
過程輸入
過程步驟
過程輸出
解釋需要使用的模板
步驟7 – 在組織範圍內推行
在組織範圍內推行過程
SEPG在開展過程期間要給予支援
重複開展步驟4中的活動
步驟8 – 準備開展總結報告
SEPG準備推廣總結報告以提供每週的過程開展狀況
步驟9 – 提交給SEPG負責人
SEPG要走查過程中的每一個模板，應該理解過程，理解過程輸入，過程步驟；理解模板中應該納入什麼內容,理解何種資訊需要被納入及應該如何被納入。
3         SPI與高層管理者支援
如 果軟體企業簡單制定軟體過程改進策略後草率推進，我們可以想象：在SPI狀態評估會上，通常只有密切參與SPI實施的部門總工持堅定的支援態度，市場總監 擔心客戶的抱怨，副總則探詢SPI能給我們帶來什麼好處？SPI主管發現，他不得不在SPI已進展到一半的時候回答一系列最基本的問題：為什麼要實施 SPI？SPI能給各方面帶來什麼好處？這些好處何時見效……
其實，分析其抗拒原因主要有三條：
一、不瞭解目標，感到迷茫，從而產生恐懼，為不瞭解；
二、損害了既得利益，為不願意；
三、與原來的做事方式有差異，不知道怎麼做，為不會做。
如何解決這些問題？首先，要獲得高層管理者的全面認可和支援，一把手的態度往往決定SPI的有效性；其次，對過程改進中的其他干係人進行分析、培訓和指導，讓他們沒有過多顧慮。
3.1        高層管理者牴觸軟體過程改進的原因分析
國內眾多軟體企業是在網際網路蓬勃發展時代下成立發展，這造就了一些軟體企業領導相對年輕。他們對市場敏感，對客戶需求理解清楚，但在軟體產品開發規律等方面的理解相對樂觀，對開發團隊能力提升、提高成熟度等方面缺乏認識。
還有部分企業領導人，他們是改革開發的先驅者，他們年長、有能力、在財富積累上也先人一步，轉行進入軟體行業，他們對過程改進等新事物的理解相對保守。
軟 件企業領導由於以上的自身背景原因，或者在自下而上過程改進實施過程中，溝通不暢，不能深刻理解EPG組成員提出的意見和建議，從而缺乏領導的全面有力支 持。或者對於自上而下實施改進的企業，企業領導人的初衷更多是為了過級、過認證。一旦過程改進實施涉及到大量的工作和來自專案經理的部分反對聲音時，生 存、進度等壓力就會戰勝提升企業內部能力提升的過程改進。
從而，使得改進失去最主要的推動力。
3.2        如何得到高層管理者的支援
3.2.1        讓領導系統瞭解過程改進好處
要讓領導們進一步理解SPI的優勢。
雖然每個軟體企業由於自身情況的不一樣，但絕大多數的軟體企業可以把軟體改進目標與商業目標結合在一起，這樣高層管理者會看到SPI帶來的收益。
通常，軟體企業的商業目標有：
Ø         提高軟體產品和專案的質量，降低缺陷率
Ø         提高客戶滿意度，減少客戶投訴
Ø         降低軟體開發成本
Ø         提高軟體開發進度，減少延期交付產品的情況
Ø         提升企業知名度，增加企業市場競爭力
可以看出，上述商業目標實際上是相互影響的，在實施過程改進開始的時候，不要把目標定得過高過大，只要把過程改進認真落實，並且保持著組織中對於過程改進的焦點和關注，經過一段時間後，勢必會在上述這些方面獲益。
3.2.2        制訂合理的軟體過程改進組織方針
可以這樣制定公司SPI組織方針，讓領導從形式上承諾支援，比如：
1、 公司的EPG組作為軟體過程制定和優化的專業小組在公司長期存在。
2、 EPG組長是由公司任命並直接向公司高層管理負責。
3、 公司高層管理者全力支援、相關部門全力配合EPG組的各項工作，共同建立高質量的過程標準。
4、 軟體過程改進要結合市場特點和專案特點，具有可操縱性。
5、 切實推行已定義的過程標準，提高軟體質量，加強公司在軟體市場的競爭力，為進行大型軟體開發打下基礎。
3.2.3        軟體過程改專案管理化
軟體過程改進也可以看作一系列專案，不同階段制定不同的目標，通過不斷的專案達成讓領導切實看到效果。用一句形象的表達，高層管理者通常是不見兔子不撒鷹的。只有上一個目標達成了，高層管理者才會無顧慮的進行下一輪的過程改進。
因此，過程改進專案管理化，針對每個階段的目標設定一些里程碑milestone，在每個里程碑總結匯報。
裡 程碑（基線、基點）則是一個軟體配置項在生存週期內的某一特定時刻正式設計並固定的靜正式批准的版本，不管媒體如何，它是階段性目標（可以認為是一箇中 間產品）。配置項是一個配置中的實體它滿足一項最終使用功能，並能在給定的參考點上單獨標識。里程碑應該是團隊階段性工作完成的標誌，對於任何一個里程碑 都應該給於認真的檢查、審定和批准。 一般里程碑應該少於兩個月，多於三個星期，里程碑給團隊帶來成就感，提高士氣。軟體專案通常必須含有的里程碑為：
里程碑1：調研                     標準輸出：調研報告
里程碑2：需求分析              標準輸出：需求規格說明書、結構設計報告
里程碑3：資料分析              標準輸出：資料字典
里程碑4：概要設計              標準輸出：概要設計報告
里程碑5：詳細設計              標準輸出：詳細設計報告
里程碑6：編碼                     標準輸出：各配置項編碼、測試報告、產品文件
里程碑7：釋出                     標準輸出：使用者使用報告、產品文件、總結報告
一個SPI專案開展，通常至少可以設定5個里程碑[4]：
3.2.3.1     里程碑1：體系診斷
標準輸出：診斷報告，通常的方式為面談、文件查閱、檢查表填寫等形式。
3.2.3.2     里程碑2：方案設計
標準輸出：SPI解決方案
體系診斷評審結束後，策劃組要對評審結果進行分析，篩選出一些改進點；然後將每個改進點都作為一個改進專案，分別制定改進方案。
SPI方案應該包括以下內容：
Ø         本組織軟體過程改進的歷史
Ø         過程診斷
n         診斷方法
n         診斷結果和差距分析
Ø         改進方案
n         總體目標
n         總體工程化管理系統設計
n         詳細改進措施
Ø         預期收益
Ø         實施負責人
Ø         對成本、資源和專案週期的估計
Ø         計劃進度概要
n         前提和承諾
n         資源需求預測
Ø         風險
Ø         子里程碑
方案中還應該說明建議使用的實施方法，例如是否進行試用等。估計成本時要包括：過程定義的時間、試用期間人員培訓的成本、處理反饋意見的時間和重新試用的成本。同時，可以基於CMM/CMMI、SEBOK（軟體工程）、good practice (最佳實踐)、PMBook、ISO等模型和標準設計，也可以融合設計SPI方案。
因為所有的改進工作不可能一次實施，所以要確定各個改進專案的優先順序。我們怎麼確定改進活動的優先順序呢？主要是通過考察三方面的因素，即：對商業目標的影響、風險和在過程改進模型標準中的定位（如CMM/CMMI）。
有些公司還會對各方案進行成本/收益分析（例如，考察投資回報率），但是1級或2級的企業往往沒有充分的歷史資料，因此無法準確估計過程改進的無形收益；4級和5級的企業通常就能作到這一點，3級的企業也有可能作到。
1、對商業目標的影響
對商業目標的影響是指某項改進工作對總體的戰略目標的影響。
首 先，策劃小組要和主管的高層經理進行討論，明確公司商業目標、並分析確定決定商業目標能否實現的5-7個關鍵成功因素（CSFs）。如果公司沒有明確成文 的商業目標，小組的首要工作就是確定商業目標；如果商業目標已經非常清楚、明確，並且形成了文件，策劃小組的核心工作就是分析關鍵成功因素並每個關鍵成功 因素確定權重。
接下來，我們要對每項改進活動進行分析，按其對每個關鍵成功因素的貢獻進行評分，然後將結果進行加權平均，作為最後比較的一個依據。
2、風險因素
風險是指實施改進工作的困難程度，我們要考慮實施某項改進是象賭博一樣冒險麼？結果是不是有一定的可預測性呢？通常，風險的來源主要有三個方面：專案的規模、結構的問題和技術。
專案規模風險，是指實施的人工成本，一般人工成本越低風險越小。
結構方面的風險，主要有以下因素：參與該專案開發的功能組的數量、專案的複雜程度、制定解決方案的人員在該過程域的經驗是否豐富、對改進中帶來變更，預期存在牴觸行為等。
技術風險，這裡就不分析了。
3、過程改進模型標準中的定位
如果企業有認證過級的目標，那麼需要結合起來考慮。
3.2.3.3     里程碑3：專案策劃
標準輸出：SPI專案計劃
如 果我們把軟體過程改進看作一個專案，象其他專案一樣，它也要有一個好的計劃，這個計劃不但要滿足公司的商業目標，還要包含過程改進戰略和具體的實施步驟 （子專案）。軟體過程改進非一日之功，急於求成必將導致失敗；因此，如果不進行系統的戰略策劃而盲目進行過程改進，只會浪費時間和資金而不會取得好的效 果。有了有效的戰略計劃，我們才能在這項長期的活動中獲得管理人員、開發人員和公司的所有者的理解和耐心的支援。
Ø         專案目標 
n         整體目標
n         本階段目標
Ø         假定和約束
Ø         專案組織
n         組織結構
n         介面關係
n         報告關係
n         責任矩陣
Ø         專案進度跟蹤方式
Ø         專案里程碑
Ø         交付物
n         文件編制
n         人員培訓
Ø         風險管理
Ø         專案激勵
Ø         專案驗收
3.2.3.4     里程碑4：過程管理
標準輸出：定期的過程管理度量資料包告
計劃制定好以後，還要對 SPI的的實施過程進行定期和不定期的過程跟蹤，才能確保及時糾正和預防計劃執行中的偏差，最終達成專案的成功。
一般可通過“周”和“子里程碑”兩種定期進行跟蹤，周跟蹤的內容為進度、完成量、問題、風險，通過週報和週會的形式進行；子里程碑跟蹤的內容為進度、工作量、人力開銷、風險等，還要對專案管理的經驗和教訓進行總結。里程碑也是識別典型案例和收集最佳實踐的良好時機。里程碑跟蹤活動通常包括“里程碑總結報告編制”和“里程碑總結會”兩種形式。
3.2.3.5     里程碑5：專案驗收總結
標準輸出：SPI資料包告、軟體專案SPI工作產品、總結報告
3.3        引導領導對SPI的客觀認識
在讓高層管理者對軟體過程改進對企業帶來好處的同時，還需要讓他們客觀認識軟體過程改進的客觀規律，包括投入和持續改進的思想。
3.3.1        讓領導知道過程改進的基本投入
軟體企業的過程改進，一方面要高階管理層知道SPI是需要投入的，包括人力（專職和兼職SPI人員）和物力投入（資金、工具等）；另一方面要他們認識到，SPI會要求他們改變以往的粗放管理方式。同時，不能短時間對SPI結果期望。
對 大多數的國內中小軟體企業來說，都是在求生存中求發展，因此，企業很難在人力、物力和財力上有足夠的投入來進行革命性的質量改進。因此，企業需要結合本企 業的實際情況和可能的投入，確定每階段質量改進的重點並各個擊破，這樣不但可以在較短的時間內收到明顯的效果，而且不會讓公司投入過大而對後續工作改進供 血不足，有利於形成良性迴圈。
對於高層管理者來說，需要正確認識過程改進帶來的額外工作量，配備必要的資源。比如，會增加一些的事務性管理工作，這要求設立一些專職的角色，如SEPG組人員、SQA、SCM等，配備適當的度量、跟蹤工具。
3.3.2        讓領導知道過程改進對現有團隊的暫時影響
過 程改進會增加一些的事務性管理工作，這些工作會影響專案經理的管理精力，同時會規範專案團隊的行為引起一定的陣痛。只有把相應的工作量從專案經理的身上分 離出來，才能切實在專案中展開軟體過程改進。否則，一旦技術和管理展開競爭，犧牲的肯定是管理。這一點高層管理者必須要清楚。
過程改進會修改已有的規範制度平衡體系，建立新平衡，這個過程中體系會有短時間的“混亂”，可能會對正在執行的專案會產生一定的影響。甚至於在個別企業中，出現技術人員由於適應不了新的工作方式而離職的例子。
同時，高層管理有必要改變自己的管理習慣，原來很多事都口頭裁決，現在需要依據規範執行。帶頭榜樣的做用是無窮大的。
這些情況，高層管理者都應該心理上有所準備，對過程改進抱有堅定的信心。
3.4        如何動用高層管理者深入開展SPI
3.4.1        高層管理者是SPI的資源
有 時候我們認為得到高層管理者對SPI的支援是一件比較難的事情，甚至有時候會有息事寧人的想法。其實，高層管理者是SPI開展很好的資源。在得到高層管理 者對SPI的支援後，他們會提供資源和戰略兩方面的支援，他們對體系總體架構、體系實施必要性、可行性、障礙和風險、資源等負有責任。也就是說他們是 SPI專案的sponsor！
SPI開展過程中，SPI人員會有兩類常見的看法：一種認為員工都是自覺的，只要把道理講清楚了，制 度就能得到實施。但這種假定是不現實的，如同法律，如果假設人們都是遵紀守法的，那麼法律本身就沒必要存在了。實際情況是，人們在組織中總是有區分的，有 的人主動順應變革，有的人推一推也能動，有的人可能推十下也不動，從而成為變革的障礙。所以變革的落實需要一個強的推力。另外一個觀點剛好相反，認為沒必 要對員工講為什麼，只要告訴怎樣做就行了。這又走到另外一個極端，體系在強力的推動下可能會暫時得到執行，但是由於並沒有解決觀念轉變的問題，一定難以持 久。
針對這兩種意見，高層管理者恰恰可以為SPI提供強有力幫助：一方面利用高層管理者強有力的行政權利，可以有效推動SPI活動的進行；另一方面，利用高層的感召力，通過宣傳SPI對企業商業目標的幫助和對個人利益的提升，可以有效激發員工的自主改進熱情。
3.4.2        高層管理者是SPI的客戶
SPI是一個持續的過程，時間一長高層管理者對SPI可能會失去關注焦點。同時，高層管理者在經營管理方面佔用了大量精力，對SPI的細節資料沒有時間或者沒有能力去認真分析。
為此，SPI人員特別注意：高層管理者是SPI的重要客戶。對於客戶，提高滿意度是關鍵。要讓客戶物有所值感，又要讓客戶清楚自己的投入做了些什麼。這樣，就很清楚了，SPI人員可以採取如下措施：
1、 定期總結，簡化彙報：有重點的開展SPI工作，將收效和問題及時總結匯報
2、 考慮設定一些指數，讓高層管理人通過指數直觀瞭解SPI開展情況
比 如，質量指數、進度指數，PMBook強調的掙值管理就是一個好的方法。也可以，將所有資訊彙總為一個引數。比如，高層管理更關心質量，那麼將所有的行為 對質量的影響歸一為一個質量指數進行彙報；關心成本，那麼可以將所有的行為歸一為成本指標。這裡可能會有很多工作要在下面做足。
4          總結與展望
軟體過程改進是企業高效率、高質量和低成本地開發軟體的必經之路。其中，軟體過程改進至關重要的一點是需要企業高階領導的重視和大力支援。此外，如何制定SPI策略、如何投入SPI人力物力、如何在專案團隊中開展SPI等問題也是制約SPI實施的關鍵因素。
5          參考文獻
[1]《軟體過程改進實踐》， 北京SPIN，2004.1
[2] 個人部落格，龔雲卿
[3]《Exposure Draft Practice Standard For EVM 4-04》，美國專案管理協會 (PMI)
[4] 《以專案形式管理SPI》，雅行，計算機世界網，2002
[5]《軟體專案管理中的三要素控制研究》，淦未宇，徐細雄，2006
[6]《對軟體企業質量管理標準的探討》，葛曉斌，2003.10
         [7]《專案管理度量模型及其基礎度量元的研究》，張紅彥，相慧如，2006

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/3433/viewspace-142940/，如需轉載，請註明出處，否則將追究法律責任。

相關文章