研發流程的裁剪

重整鑄價值，變革贏未來！ 最佳管理實踐經驗實踐！上海麥銳德管理諮詢有限公司

引言：

由於企業產品複雜程度的差別，開發工作也有全新開發、區域性開發、最佳化改進等區別，所以不同產品的開發流程不可能是完全一樣的，這就需要在企業已經定義的、相對比較完整和標準的產品開發流程的基礎上，根據實際情況進行裁剪，形成適用於將要開發產品的流程。

流程裁剪時的常見問題

儘管企業已經制定了結構化的產品開發流程，當專案經理需要在專案中使用這個已定義好的流程體系檔案時，面對厚厚的過程檔案往往無從下手，心中也充滿疑慮：

· 我的專案開發週期只有3個月，團隊4、5個人，難道要完全按照公司定義的標準流程執行嗎？如果必須執行所有的流程和子流程，生成所有要求的技術和管理文件，那專案的開發週期恐怕不是3個月，而是4、5個月了。那我的專案還能成功嗎？

· 我聽說過“裁剪”這個詞，不過到底是“裁剪”還是“裁減”，我還沒有弄明白。即便弄明白了應該是“裁剪”，是Tailoring，而非“裁減”，可具體該怎麼操作？我可以隨心所欲將自己認為不必要的或者很費時費事的過程裁剪掉嗎？

· 如果公司有QA，也有《裁剪指南》，那就好辦了，我可以在QA的幫助下使用《裁剪指南》裁剪得到專案的流程，執行就是了。但如果公司沒有QA的角色，我就只能自己進行裁剪了。可是，裁減的結果需要有人批准嗎？

在這裡，我們假定完整的產品開發流程體系是包括了產品開發的方針、原則、流程、指南、模板和表格等一整套的體系。那麼，專案經理該如何是好？

流程裁剪指南的目的和作用

建立裁剪指南的目的是用來指導專案對標準的產品開發流程進行裁剪，以形成符合專案特點的專案定義流程（Project Defined Processes，PDP）。

標準的產品開發流程包括了開發一個完整產品/專案的全流程，以及相應的支撐流程。因此，每個特定的專案都可能無法直接使用這個標準的流程。比如，標準的產品開發流程描述了開發一個系統級產品的完整過程，開發流程中包括了軟體、硬體、結構、工業設計等開發流程。而某個特定專案僅僅包括純軟體的開發工作，在這種情況下，該專案無法也不應該盲目遵照執行完整的流程。或者，某個特定專案，專案的成功標準是按時交付，而客戶要求的專案交付期特別短。為了達成這個目標，專案也不得不對流程進行裁剪以滿足客戶的需要。裁剪指南就是用來幫助專案組裁剪標準的產品開發流程，以形成專案定義流程（PDP），使用專案定義流程來管理專案，實現專案的目標。

裁剪指南能確保所有專案在定義專案特定的工程活動、需求開發和管理、計劃、監控、測量分析、配置管理、質量保證過程時有一個共同基礎。裁剪指南主要可在以下方面指導專案：

· 選擇適當的產品開發生命週期（PDLC），由於各種生命週期模型在產品工程領域已經有深入的研究，業界對於瀑布模型、迭代模型、增量模型、螺旋模型等的使用場合等也基本達成了共識。因此，專案只需要將專案的實際特點與生命週期模型的應用場合相匹配，選擇合適的生命週期型別即可。

· 剪裁標準的產品開發流程，結合所選擇的產品開發生命週期，形成的專案定義流程（PDP），使之符合專案的具體特點。

如何進行過程裁剪

專案特點是裁剪依據和出發點。專案特點包括了：①專案規模，如大、中、小等，通常可以使用功能點（Function Point）或KLOC（千行程式碼）、單板數等單位進行度量；②專案型別，如開發、維護、功能增強等；③專案技術複雜度；④專案週期；⑤產品種類等要素。

裁剪指南應包括以下的內容：

可裁剪的物件。

可裁剪物件確定了裁剪的範圍。

可裁剪物件不僅限於過程元素和活動，還包括標準、方法和工具、輸出的工作產品及模板等。

裁剪所考慮的要素。對於某個裁剪物件，其範圍、頻度、正式度等都是裁剪要素。如，對於已有類似開發經驗的專案，可以適當減少過程培訓、業務培訓等活動；對於開發週期較短的專案，可以適當合併一些評審活動，如概要設計和詳細設計評審合併進行。

專案在進行裁剪時，由於裁剪指南很難列舉所有的裁剪情況，因此有時還是需要專案經理和QA依據經驗進行判斷和決定，這時，最根本的依據就是專案的質量要求和對風險的考慮。首先要分析如果一旦裁剪掉某些活動，是否會給專案帶來風險，帶來多大的風險，以及是否影響專案質量目標的達成。然後綜合考慮後才能決定是否裁剪，如何裁剪。

另一方面，企業建立標準的產品開發流程的目的不是為了“為了規範而規範”，而是為了提高過程和技術的重用。因此，如果專案在裁剪時有很大的靈活度，每個專案定義流程（PDP）都很隨意或者專案定義流程之間相似的內容很少，那麼重用的目的就很難實現了。所以，規範度和靈活度是流程裁剪時需要平衡的另外兩個要素。

概括之，流程裁剪的原則是：質量與風險並重，規範與靈活的平衡。

流程裁剪的主要活動包括：

· 根據標準的產品開發流程和裁剪指南，進行流程裁剪，以符合專案特徵。專案經理在QA的協助下完成該項工作。

· 記錄裁剪的理由，將裁剪的結果整理成專案定義流程文件。

· 由質量部門或EPG（工程過程組）稽核裁剪理由和專案定義流程，並批准。稽核的檢查點主要包括：是否與標準的產品開發流程一致，是否符合本專案的特點，是否記錄了充分的裁剪理由。如果稽核不透過，則重新進行流程裁剪，或進行修改。

· 基於專案定義流程（PDP）制定專案計劃，根據計劃監控專案的實施。

“裁剪”而非“裁減”

常常見到企業的流程體系中赫然存在一份《裁減指南》，員工也往往認為裁剪就是大刀闊斧地“減少”完整的流程要求。如果專案時間緊、缺乏資源，就可以這麼做。這是一個認識的誤區。

所謂“裁剪”就是量體裁衣，根據專案特點量身定做最適合專案的流程，用最經濟的流程實現質量目標。對於一個開發週期超過一年的系統級產品的開發，公司定義的四大決策評審點（Decision Check Point，DCP）：概念DCP、計劃DCP、可獲得性DCP和退出DCP，以及六大技術評審點（TR），TR1至TR6，可能“一個都不能少”。而對於一個快速定製開發的專案而言，一般將概念DCP和計劃DCP合併，某些TR也可以合併。

有些專案經理認為裁剪得到了專案定義流程（PDP），然後就可以開始專案的具體工作了。但PDP並非專案計劃，更不能替代專案計劃。專案經理應基於PDP制定專案的WBS（工作分解結構），以WBS為基礎進行工作量、規模和進度估算，制定專案進度表和完整的專案計劃。後續工作要以專案計劃為基礎監控專案的實施。

有些企業在剛剛建立研發流程體系時，由於很難立即制定一份完善的裁剪指南，所以乾脆一刀切，不允許裁剪流程。但這樣硬性規定的結果是一些維護型、功能增強型的專案要麼就是在搞不清狀況的情況下照著完整的流程執行，生成很多文件，也延誤了開發週期，降低了效率；要麼乾脆拒絕執行流程，仍然按照過去的工作方式開發。顯然，這就違背了建立流程體系的初衷。

另一個極端是企業允許流程裁剪有很大的靈活度，卻沒有設定一些原則。這樣的結果往往是專案隨心所欲地裁剪流程，使開發流程的可重用性非常低，而專案的質量和效率也得不到保證。