結構化產品開發

產品開發是複雜的。因為產品開發人員必須完成成千上萬項工作，而這些工作大部分是與他人工作緊密相關的，協調便成為極其複雜的工作。為了能管理好這些龐大而複雜的工作，產品開發過程必須成為結構合理、定義清楚的過程。 所謂結構化，是指相互關聯的工作要有一個架構結構，並要有一定的組織原則來支援它，比如，在一個自上而下的層次構架中，上層結構簡單一些，越到下層越繁雜越具體。所謂定義，是指每項工作都應清楚楚地明確規定出來。所有與產品開發有關的人應該清楚他們所參與的是什麼工作，用什麼方法去完成。 儘管看起來簡單，但令人驚訝的是許多公司並不能真正做到以上這些。在某些公司中，這種產品開發過程仍然是無結構的，大部分工作也未清楚地定義出來。在術語上沒有一致性，即每個項目小組單獨地確定自己的工作定義，儘管他們的許多定義與其它項目小組相類似。結果，各小組的項目進度表不能互相比較，因為有的小組定義了20項任務，有的小組卻定義了1000項任務。這樣就無法一致地衡量其進度，也不能用標準的周期時間估算方法來制定進度表。這對那些支援多重專案的人來說就更困難。沒有一個共用的構架，產品開發過程便很難得到改進。 有些公司的作法完全相反，它們詳細地定義了產品開發過程，定義得過於詳細了。為了控制每一細節，他們把每項工作應如何完成以及工作完成後應該是什麼樣子都一一設定好。這種方法最典型的特點是以文檔資料為基礎，對每項任務部需要準備一套詳細編製的文檔資料，並申請批准。每項任務的完成情況都受該文檔的準備情況和批准情況的控制。這種官僚的管理方法經常是發布厚厚一本的規章制度，並帶有詳細檢驗標準，規定這些項目應如何完成。幸運的是，多數情況下，人們並沒有真的這麼做。按照他們這種做法，開發一個產品就要多花一倍的時間。 許多公司由於匆匆定義產品開發過程而忽略了對結構的需要。對有些公司來講，構架本身並不合適。不是層次定得不對，就是任務放錯了位置；通常體現為在太短的時間內需要太多的資訊。 在PACE中，結構化產品開發在原則和創造力之間達成一種平衡。一個深思熟慮的過程並不會阻礙創造力，它允許開發小組把精力集中到開發產品這個實際問題上，並不需要每次重建立立開發過程。 在 PACE中，開發活動是以一個階層來構架的：從階段（從最高和最廣的一級）到步驟，到任務，最後再到各項活動（最具體的一級）。階段對所有的項目來說都是一樣的。正如第三章中所述，這是第一個決策層次。步驟對所有的項目也是一樣的（雖然某些項目可能省略一些步驟），這是第一個制定計劃和進度表的層次。任務就某個步驟如何完成提供指南。如果核心小組覺得這些指南合適的話，便可以照此執行。各項活動則完全由核心小組確定。這幾點綜合起來形成了一個決策、項目進度制定、資源規劃、過程衡量以及持續改進的基礎。 結構和定義在開發過程中的必要性。 由於多數公司沒有把新產品開發視為一個過程，他們從不按照開發新產品的需要給要做的工作下定義，甚至連基本術語也沒定義，例如，每個項目包括一份職責說明書。說明書的定義對參與項目的每一個人來說都應該很清楚，而不應該被某個工程師認為是一份10頁紙的小結，被另一個工程師看作一份60頁的檔案，更不應該被第三個工程師看作一份400頁的檔案。 缺乏統一的術語導致大量的時間和精力被浪費掉了，因為使用這些晦澀難懂過程的人極力想把它槁明白。比較常見的是，會議可能開了不少，但沒有什麼效果，開會的目的只是瞭解目前進行的工作。諸如此類的時間浪費，完全是由於缺乏結構所致。 例如，一家資料通訊公司，由於缺乏結構化過程，不得不為進行中的開發工作多花一倍的資源。根據調查，我們發現人們有30％的時間實際花在了產品設計上，而另外70％的時間全浪費在澄清關於正在做什麼和由誰做的事情上。另外，由於術語不一致，使產品的技術規範有四個不同的名稱和兩套定義。 我們在跨行業的許多公司中調查了好幾百個從事產品開發的人，詢問他們是如何從結構化開發過程中有所獲益，得到的結果非常有趣： 1．小組間的交接常常出現誤解和混亂： 2．由於上遊部門出現變化，例如反饋顧客要求太晚、技術規格有錯或一些問題被忽略等，造成42％的工作得重做。於是，每五個工作日中有兩個被浪費了！如果消滅了重複性的工作，開發機構的生產率將會增加72％（有效工作從 58％增加到100％）而不必增加任何人手。 3．至少有48％的開發工作是“救火”，即解決那些出其不意地冒出的必須立刻加以解決的、無計劃的工作。“救火”式的解決辦法往往是“貼藥膏”，因為時間壓力大，資源有限，備選方案有限，而且許多設計已經不能更改了。“救火”式的工作方式是倉促完成的，常常有很多差錯。 4．在開發人員個人制定的計劃當中，有48％受到經理們或同級部門的質詢、懷疑、忽視或被經理們或同級部門否定掉。由於產品開發本身是一個複雜的、涉及多個部門的過程，整個項目的總體進度表是需大量低級進度表的綜合而成的。然而，每兩個進度表中就有一個被否決。為什麼會這樣呢？很可能是因為早期的進度表只有45％是準確的！既然早期的進度表常常不準確，因此根本沒有人相信它們。還有，管理員常提出不合理的要求，開發小組就只好擴充進度表。 5．令人驚訝的是，只有28％的開發工作是全新的，也就是說，72％的工作是熟悉的。如果是這樣，為什麼上述的問題還出現呢？因為沒有結構化過程，沒能汲取教訓。把開發過程結構化是指把以前所做的72％的工作結構化，因為工作流程不暢，阻礙重重，使項目難以進行下去。一旦把這些工作條理化，開發小組就能把精力集中到28％真正新的有創造性的工作上，這才是最具增值的部分。 這些調查結果表明，把開發過程結構化將會帶來巨大的機會。 開發過程結構的要素 革新與創造是無法精確地計劃和控制的，但是，把日常工作安排得井井有條可使注意力集中到更有創造性的產品開發方面。通常，在純技術機構中，人們還很關心開發過程的構架。許多人把產品開發看作成一個創造性的過程。不錯，產品開發的部分工作需要有所創新。重要的是，一旦搞開發創造的人理解了開發過程結構實際上是把他們從繁雜、單調的任務中解放了出來，使他們能將更多的時間花在創造性的增值工作上。例如，如果不讓工程師們把時間花在確定某項功能規格的綱要及格式上，他們就會很有效地把時間用在運用標準格式和定義產品上。 許多人覺得結構把人限制住了，抱怨說它太死板，缺乏靈活性。對此我們表示同意。錯誤的結構層次會造成大量的書面工作和官僚主義。重要的是，應該針對某種特定產品找到合適它的結構層次。 在與客戶的初期交往中，常常聽到這樣的說法，“結構化開發過程在我們這兒不會有用的，因為我們從來不重複同樣的項目。”這話絕對站不住腳，因為即使完全不同的產品也一定有許多共同之處。 而且，如果每次產品開發採用的方式都不同，則會出現兩種情況。第一，沒有積累的經驗可參考，沒有應學習的榜樣，所以當項目做得越來越大時，開發週期時間也變得越來越長。第二，當某個人拿出改進方法或竅門時，沒有把它標準化並運用於其它項目中。如果每次開發過程的步驟不是以同樣方式進行，便很難衡量它的過程並加以改進。 許多技術人員對結構感到很不舒服，擔心受到約束後，會失去靈活性和創造性。然而，如果真正理解了產品開發工作，就很容易明白其中大部分工作並不是新的。正如前面調查中所述的，大部分產品開發工作單位並不真正是新的。如果將重複性的任務進行結構化，技術專家就能把更多的精力集中在真正新的，以前沒有做過的工作上。 例如，一家做先進系統的公司，有一個進階技術員不相信產品開發能夠結構化，當問及她進行中的新設計時，她最初的回答是，“這都是全新的”。進一步調查之後，我們發現，從硬體意義上講，在五十六個電路板中，只有兩個是新的。然後，在對這兩塊電路板逐個進行仔細觀察後，她確認只有四個ASIC整合電路和一些支援邏輯是新的。 還有另一家公司，是專為大的防禦設施承包商設計預警系統的，錯誤地把產品種類多和小批量生產作為成本超支與趕不上進度的借口。這家公司認為，每個項目是不同的，這種迴圈不可能調整過來。一旦該公司明白，雖然項目可能是不同的，但也有共同的過程因素，那麼，它就能夠將過程結構化，提高競爭力。需要進一步結構化的徵兆 公司需要進一步結構化的跡象有很多。 術語和定義不一致 每個公司都有它自己的產品開發語言。不幸的是，這種語言太類似於巴貝爾塔的情形，即各人有各人的講法，但都以為別人和他的理解是一樣的。工作的背景和範圍由於一個項目間的術語不一致，人們就不能瞭解工作的背景和範圍，在一家公司裡，同一個市場評估檔案有十個不同的名稱。每個版本都稍有不同，但是時間一長這些差異就變得比較模糊不清了。最後，沒有人能確切地知道這個檔案該有些什麼內容。這種混亂導致了大量沒有附加價值的活動，因為這些活動是用來理解當人們使用一個術語或說要完成一項任務時它們真正指的是什麼。 進度表不準確 產品開發進度表應該和構成它的步驟一樣準確，如果對步驟的理解不清楚，那麼就很難估計它們要用多長時間。如果它的定義不一致，那麼，就不可能用過去的經驗作為參考。沒有結構化的過程常常導致進度不準確，因為人們制定進度表時依據的假設並不為該機構中的其他人所分享或瞭解。沒有進度表是進度表不準確的極端現象。 無法估計出資源需求 對資源需求的估計必須和對完成每個步驟所需時間的估計一樣準確。對每個步驟沒有一個好的統一定義，就不可能作出合理的估計。如果估計不準確，公司產品的開發就會連續不斷地誤期，其項目資源不是不夠就是過量。結構化有助於首先確定必須做什麼和花多長時間，一旦理解了這一點，就會大大提高對資源需求的準確估計能力。 小組與小組之間的計劃不銜接 如果沒有結構，就沒有做出重要決策的基礎。一個職能部門作的計劃並不一定和其它部門的工作銜接在一起，結果重要的工作給忽略了。有一家缺乏結構的電子系統公司因沒有統一的構架，統一的術語，和統一的定義而飽受其苦。結果，領導人員常常被具體細節搞得暈頭轉向。每一個專案經理都提出不同的格式、過程和具體標準。執行經理們一般見樹不見林。他們抓住不太重要的幾點就作出決策。沒有從全域上搞清楚它們是如何聯絡在一起的。如果沒有結構，小組之間的計劃協調事實上是不可能的。因為每個人對必定出現什麼樣的情況都有不同的理解。 過量的任務間的相互依賴 當開發過程中的任務受到拖延或排隊等候另一項任務完成時，就出現了過量的任務相互依賴現象。沒有結構或結構差的過程就會導致這種大量浪費時間的現象。明確過程任務並對每個過程的要求作出定義可以大大地降低任務的相互依賴性，這樣，低成本工作就不會拖高成本工作的後腿。 對職責理解不夠 結構差使人們不知道誰或哪個小組負責完成哪些具體工作。對那些人們並不能很好地瞭解重要任務的機構，PRTM常給它們提供諮詢。我們發現在一些人員飽和的部門中，沒有人確切知道這個部門在幹什麼。這就是開發過程混亂和工作職責不明晰的重要標誌。   注意力集中在“救火”上 過量的“救火”工作是公司產品開發過程結構欠佳的徵兆。有一家電腦公司向我們諮詢，因為該公司陷入了"救火"的尷尬境地，執行經理熱衷於跳將進來，捲起袖子．協助解決問題。他們覺得，在危機間跳來蹦去，比為每個人制定策略和目標舒服得多。當執行經理要一個項目小組在每大上午八點和下午五點各做一次一小時的最新進展彙報時，這種情況就達到了高潮。每次狀態跟蹤彙報，小組都得花一個小時做準備，這樣每天就浪費了四個小時的有效工作時間。 開發產品沒有一個“統一方法” 有一家電子影像業公司，它的每個項目都缺乏統一性。對每個項目來說，開發新產品所遵循的步驟是在不同的地點和時間發生的。許多工作都有不同的命名方法，這樣，即使是在該部門工作多年的人也難以理解正在幹什麼事。結果，沒有人利用己經開發出來的好方法。 過多的澄清會議 不良的結構過程導致了為澄清工作而召開大量會議。因為下一個步驟模糊不清，所以就要求這些會議要搞清楚已經完成了什麼，下一步必須完成什麼，以及由誰來作。過多的會議是不良結構的一種跡象。 中層管理員太多 如果領導層必須做每一個決策時，就證明需要對新產品開發進行結構。結構化過程使人容易瞭解每個項目與整個產品系列計劃的配合、和研究開發或技術策略的結合，以及它在財務上的合理性。如果沒有結構，就需要更多的中層管理員來處理這種混亂狀況。在具有合適結構層次的一些公司裡，中層人員就比較少，因為不需要他們來控制過程。 浪費在沒有附加值的工作上的時間。 為瞭解釋術語和意圖，不得不做大量的沒有附加值的工作。這種工作量是非常巨大的。如果沒有結構，溝通上的誤解就會使人們把更多的時間花在協調工作和重做已經完成的任務上。 一個將開發過程結構化了的系統公司就消除了過程中的一些空白（空白是指所花費的沒有給項目帶來附加值的時間）。結果這個公司就把新產品的周期時間削減了百分之二十三。一位負責工程的副總裁說，“這件事情的真正價值是我們現在能夠把省下來的時間和資源用在別的地方，使我們能夠騰出時間和精力開發更多的新產品。”