正文

charter開發(fā)流程的意義（開發(fā)流程的四個階段）

發(fā)布時間：2023-03-14 02:32:34 稿源：創(chuàng)意嶺閱讀： 71 問大家

大家好！今天讓創(chuàng)意嶺的小編來大家介紹下關(guān)于charter開發(fā)流程的意義的問題，以下是小編對此問題的歸納整理，讓我們一起來看看吧。

ChatGPT國內(nèi)免費在線使用，一鍵生成原創(chuàng)文章、方案、文案、工作計劃、工作報告、論文、代碼、作文、做題和對話答疑等等

只需要輸入關(guān)鍵詞，就能返回你想要的內(nèi)容，越精準，寫出的就越詳細，有微信小程序端、在線網(wǎng)頁版、PC客戶端

官網(wǎng)：https://ai.de1919.com

本文目錄:

1、項目管理體系的流程是什么？
2、軟件開發(fā)過程中的需求分析與開發(fā)框架的區(qū)別
3、上下協(xié)同，用友IPD的研發(fā)管理之道（下）
4、3 IPD介紹- IPD（Integrated Product Development，集成產(chǎn)品開發(fā)））

charter開發(fā)流程的意義（開發(fā)流程的四個階段）

一、項目管理體系的流程是什么？

一個完整的項目管理流程，包括：需求、計劃、設(shè)計、開發(fā)、測試、交付、運維維護。CoCode作為軟件開發(fā)全生命周期管理平臺，采用最先進的開發(fā)流程，和自動化的開發(fā)和管理工具，讓整個軟件開發(fā)更高效，大大降低開發(fā)周期和開發(fā)成本，提高產(chǎn)品質(zhì)量。

目前我們平臺的Co-Projec智能項目管理工具、評審分析工具、故事點估算工具，免費使用。

charter開發(fā)流程的意義（開發(fā)流程的四個階段）

項目開發(fā)工具

一個完整的項目管理流程：

需求：通過史詩、特性和用戶故事三級需求分析，明確需求。

計劃：對項目開發(fā)規(guī)模進行科學地估算和計劃，并智能匹配開發(fā)人員。

設(shè)計：針對需求進行相關(guān)設(shè)計，通過智能評審工具，及時發(fā)現(xiàn)評審缺陷，以保障項目構(gòu)架合理，需求滿足。

charter開發(fā)流程的意義（開發(fā)流程的四個階段）

項目管理流程

開發(fā)：對項目開發(fā)過程，進行全程閉環(huán)管控，以確保項目進度和質(zhì)量。

測試：提供測試用例管理與測試計劃執(zhí)行，實時掌握測試用例執(zhí)行情況，以檢驗項目缺陷，確保項目質(zhì)量。

交付：任務完成率和消缺率達到100%后，在線提交項目開發(fā)成果，并可下載相關(guān)文檔和結(jié)果。

運維維護：用戶通過反饋記錄，提交項目問題，平臺會自動生成Bug并分配相關(guān)開發(fā)人員，進行完善。

二、軟件開發(fā)過程中的需求分析與開發(fā)框架的區(qū)別

需求分析奠定了軟件工程和項目管理的基礎(chǔ)。我們在建造軟件系統(tǒng)這座大廈的時候，如果需求分析的基礎(chǔ)不夠堅實和牢固，那么往往會導致軟件系統(tǒng)問題百出，甚至被馬上丟棄。在建造軟件系統(tǒng)的過程中，如果我們經(jīng)常習慣地沿用一些不規(guī)范的方法，其后果便是產(chǎn)生一條鴻溝──開發(fā)者開發(fā)的與用戶所想得到的軟件存在著巨大的“期望差異”。因此“需求”這個名詞的定義不僅僅是從用戶角度對系統(tǒng)外部行為的描述，以及從開發(fā)人員角度對系統(tǒng)內(nèi)部特性的描述，其關(guān)鍵的一點是“需求”必須文檔化。

需求的類型

軟件需求包括三個不同的層次──業(yè)務需求、用戶需求和功能需求。除此之外，每個系統(tǒng)還有各種非功能需求。

業(yè)務需求（BusinessRequirement）表示組織或客戶高層次的目標。業(yè)務需求通常來自項目投資人、購買產(chǎn)品的客戶、實際用戶的管理者、市場營銷部門或產(chǎn)品策劃部門。業(yè)務需求描述了組織為什么要開發(fā)一個系統(tǒng)，即組織希望達到的目標。使用前景和范圍（vision and scope）文檔來記錄業(yè)務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（project charter 或 market requirement）文檔。用戶需求（UserRequirement）描述的是用戶的目標，或用戶要求系統(tǒng)必須能完成的任務。用例、場景描述和事件響應表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統(tǒng)來做些什么。

功能需求（Functional Requirement）規(guī)定開發(fā)人員必須在產(chǎn)品中實現(xiàn)的軟件功能，用戶利用這些功能來完成任務，滿足業(yè)務需求。功能需求有時也被稱作行為需求（behavioral requirement），因為習慣上總是用“應該”對其進行描述：“系統(tǒng)應該發(fā)送電子郵件來通知用戶已接受其預定”。功能需求描述是開發(fā)人員需要實現(xiàn)什么。

非功能需求（Non-functional Requirement）定義了軟件產(chǎn)品為滿足用戶業(yè)務需求而必須具有的除功能需求以外的特性。包括系統(tǒng)的完整性（聯(lián)機幫助、數(shù)據(jù)管理、用戶管理、軟件發(fā)布管理、在線升級等）、性能、可靠性、可維護性、可擴充性、對技術(shù)和業(yè)務的適應性等。

需求分析的任務

1 解決的問題

1) 齊全、準確地找出目標系統(tǒng)全部的功能、性能、限制； 2) 找出全部的輸入流、輸出流； 3) 找出所有的加工；

4) 產(chǎn)生完整的分層的DFD、數(shù)據(jù)字典、加工的描述； 5) 補充的意見。

2 綜合要求

確定對系統(tǒng)的綜合要求，系統(tǒng)功能要求，系統(tǒng)性能要求，運行要求，將來可能提出的要求。

3 任務

圖1為需求分析任務圖，需求分析階段要完成的具體明確的最終任務就是形成一份經(jīng)開發(fā)方和用戶認可或達成共識的軟件需求分析文檔（需求規(guī)格說明書、修改后的項目開發(fā)計劃、初步的用戶手冊、確認測試計劃、數(shù)據(jù)要求說明書）。這個文檔能清晰準確地說明系統(tǒng)將要開發(fā)什么，能夠規(guī)定出詳細的技術(shù)需求，包括所有面向用戶、面向機器和其它軟件系統(tǒng)的接口?？梢哉f需求文檔在開發(fā)過程中一直起指導作用。

為了更好地完成軟件開發(fā)第一階段的需求分析任務，提高質(zhì)量，需求管理是必不可少的。

需求管理的目的是在客戶與開發(fā)方之間建立對需求的共同理解，維護需求與其他工作成果的一致性，并控制需求的變更，主要體現(xiàn)在跟蹤和控制需求變更管理。需求管理是開發(fā)工作有效進行的保證，是一種很高層次的系統(tǒng)行為，涉及整個開發(fā)過程和產(chǎn)品本身。

需求分析的方法

需求分析方法由對軟件問題的信息域和功能域的系統(tǒng)分析過程及其表示方法組成，大多數(shù)的需求分析方法是由信息驅(qū)動的。信息域具有三種屬性：信息流、信息內(nèi)容和信息結(jié)構(gòu)。

常用的需求分析方法有：面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法（SA），面向數(shù)據(jù)結(jié)構(gòu)的Jackson方法（JSD），面向數(shù)據(jù)結(jié)構(gòu)的結(jié)構(gòu)化數(shù)據(jù)系統(tǒng)開發(fā)方法（DSSD），面向?qū)ο蟮姆治龇椒ǎ∣OA）等。選擇那種方法要根據(jù)哪些資源在什么時間對開發(fā)人員有效，不能盲目套用。這里著重闡述面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法（SA）。

面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法

面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法（Structured Analysis，簡稱SA），是面向數(shù)據(jù)流進行需求分析的方法，是需求分析使用最多的方法之一。 SA也是一種建?；顒?，該方法使用簡單易讀符號，根據(jù)軟件內(nèi)部數(shù)據(jù)傳遞、變換的關(guān)系，自頂向下逐層分解，描繪出滿足功能要求的軟件模型。適用于數(shù)據(jù)處理類型軟件的需求分析，這一方法除了簡單，容易掌握之外，還能和設(shè)計階段的結(jié)構(gòu)化設(shè)計（SD）銜接，從而取得良好的設(shè)計結(jié)果。

自頂向下逐層分解的分析策略

SA方法的基本手段：“分解”和“抽象”。這是系統(tǒng)開發(fā)技術(shù)中控制復雜性的兩種手段。它先將系統(tǒng)“抽象”成一個模型，此模型是有輸入和輸出并有系統(tǒng)名稱的盒子，然后打開這個盒子，對它進行逐層分解，直到能被理解，可以實現(xiàn)為止。因此分析的策略是自頂向下，逐層加細，由抽象到具體的過程。如圖2。

結(jié)構(gòu)化分析方法使用工具

SA方法利用圖形等半形式化的描述方式表達需求，簡明易懂，用它們形成需求規(guī)格說明書中的主要部分。描述工具是

1) 數(shù)據(jù)流圖：描述系統(tǒng)由哪幾部分組成，各部分之間有什么聯(lián)系等等。 2) 數(shù)據(jù)字典：定義了數(shù)據(jù)流圖中每一個圖形元素。

3) 描述加工邏輯的結(jié)構(gòu)化語言、判定表、判定樹：詳細描述數(shù)據(jù)流圖中不能被再分解的每一個加工。

由于分析中的主要依據(jù)是數(shù)據(jù)傳遞及數(shù)據(jù)變換所形成的數(shù)據(jù)流，所以結(jié)構(gòu)化分析一般采用的方法是使用數(shù)據(jù)流圖的分析方法，最終結(jié)果是產(chǎn)生需求規(guī)格說明書，該文檔包括一套數(shù)據(jù)流圖，對數(shù)據(jù)流圖中的成分進行定義的一本數(shù)據(jù)字典及對加工邏輯的描述。

結(jié)構(gòu)化分析步驟

用結(jié)構(gòu)化分析方法進行系統(tǒng)需求分析的具體步驟是： 1) 了解當前系統(tǒng)的工作流程，獲得當前系統(tǒng)的物理模型。通過對當前系統(tǒng)的詳細調(diào)查，了解當前系統(tǒng)的工作過程，同時收集資料、文件、數(shù)據(jù)、報表等，將看到的、聽到的、收集到的信息和情況用圖形描述出來。也就是用一個模型來反映自己對當前系統(tǒng)的理解，如畫系統(tǒng)流程圖。

2) 抽象出當前系統(tǒng)的邏輯模型。物理模型反映了系統(tǒng)“怎么做”的具體實現(xiàn)，去掉物理模型中非本質(zhì)的因素，抽取出本質(zhì)的因素，構(gòu)造出當前系統(tǒng)的邏輯模型，反映了當前系統(tǒng)“做什么”的功能。

3) 建立目標系統(tǒng)的邏輯模型。分析、比較目標系統(tǒng)與當前系統(tǒng)邏輯上的差別，明確目標系統(tǒng)到底要“做什么”，從而從當前系統(tǒng)的邏輯模型導出目標系統(tǒng)的邏輯模型。

4) 作進一步補充和優(yōu)化。為了對目標系統(tǒng)做完整的描述，還需要對得到的邏輯模型做一些補充。

說明目標系統(tǒng)的人機界面。

說明至今尚未詳細考慮的細節(jié)（包括出錯處理、系統(tǒng)的啟動與結(jié)束、系統(tǒng)的輸入/輸出和系統(tǒng)性能方面的需求等）。

其他（系統(tǒng)特有的其他必須滿足的性能和限制，也需要用適當?shù)男问阶龀鰰嬗涗洝? 分析階段結(jié)束時，系統(tǒng)分析員必須和用戶再次認真地審查系統(tǒng)文件，爭取在系統(tǒng)開始設(shè)計之前，盡可能地發(fā)現(xiàn)其中存在的一些錯誤并及時糾正，直至用戶確認這個模型表達了他們的要求后，系統(tǒng)文件（軟件需求規(guī)格說明書等）才作為用戶和軟件開發(fā)人員之間的“合同”而最后得到確定。

結(jié)構(gòu)化分析方法的優(yōu)缺點

1) 優(yōu)點：結(jié)構(gòu)化分析方法是軟件需求分析中公認的、有成效的、技術(shù)成熟的、使用廣泛的一種方法，它較適合于開發(fā)數(shù)據(jù)處理類型軟件的需求分析，該方法利用圖形等半形式化工具表達需求，簡明易讀，也易于使用，為后一階段的設(shè)計、測試、評價提供了有利條件。 2) 缺點：① 傳統(tǒng)的SA方法主要用于數(shù)據(jù)處理方面的問題，主要工具DFD體現(xiàn)了系統(tǒng)“做什么”的功能，但它僅是一個靜態(tài)模型，沒有反映處理的順序，即控制流程。因此，不適合描述實時控制系統(tǒng)。② 上世紀60年代末出現(xiàn)的數(shù)據(jù)庫技術(shù)，使許多大型數(shù)據(jù)處理系統(tǒng)中的數(shù)據(jù)都組織成數(shù)據(jù)庫的形式，SA方法使用DFD在分析與描述“數(shù)據(jù)要求”方面是有局限的，DFD應與數(shù)據(jù)庫技術(shù)中的實體聯(lián)系圖(ER圖)結(jié)合起來(如同IDEF0功能模型與IDEF1信息模型相結(jié)合一樣)。ER圖能增加對數(shù)據(jù)存儲的細節(jié)以及數(shù)據(jù)與數(shù)據(jù)之間，數(shù)據(jù)與處理過程之間關(guān)系的理解，還解決了在DD中所包含的數(shù)據(jù)內(nèi)容表示問題，這樣才能較完整的描述用戶對系統(tǒng)的需求。③ 對于一些頻繁的人機交互的軟件系統(tǒng)，如飛機訂票、銀行管理等系統(tǒng)，用戶最關(guān)系的是如何使用它，輸入命令、操作方式、系統(tǒng)響應方式、輸出格式等都是用戶需求的重要方面，DFD不適合描述人機界面系統(tǒng)的需求，SA方法往往對這一部分用自然語言作補充。④ 描述軟件需求的精確性有待提高。 5 需求的變更

在開發(fā)項目過程中，用戶隨時會提出一些新的需求，要求開發(fā)方解決，這些需求的提出，有時在開發(fā)階段中有時在開發(fā)階段后。這種在需求分析的兩個相鄰子階段中，或者在迭代周期的需求分析中，后一段或周期的需求分析結(jié)果與前一次不一致，我們把這種不一致稱為需求變更。產(chǎn)生需求變更的原因主要有以下幾個方面：1) 在需求分析階段，開發(fā)方與用戶的溝通不夠。在需求分析階段，開發(fā)方與用戶沒有很好的交流，開發(fā)方就根據(jù)用戶提供的大概信息，自己推導出用戶的需求。通過這種需求分析得出的需求往往會和用戶的實際需求相差甚遠，導致用戶提出更改需求。2) 項目的實施周期過長。隨著時間的推移，用戶對整個系統(tǒng)的了解也越來越深入。他們會對模塊的界面、功能和性能方面提出更高更多的要求。3) 技術(shù)更新過快。由于技術(shù)的快速更新，企業(yè)可能引進一些新的設(shè)備，而這些設(shè)備可能就會與我們的目標系統(tǒng)有直接的關(guān)系，由于這一變化可能發(fā)生在解決用戶原先問題之前或者之中，那么開發(fā)方不得不加入這一新的需求。[3]

為了盡可能地避免發(fā)生需求變更，以及保證需求分析的高穩(wěn)定性，可以采用以下方法：1) 分工明確，系統(tǒng)分析員和程序員各有不同的職責。系統(tǒng)分析員處在用戶和程序員之間，溝通用戶和開發(fā)人員的認識和見解。系統(tǒng)分析員一方面要協(xié)助用戶對所開發(fā)的軟件提出需求，另一方面還要和程序員充分交換意見，探討其合理性和實現(xiàn)的可能性。如圖3所示，系統(tǒng)分析員在需求分析階段起著重要的作用。

2) 開發(fā)方與用戶進行協(xié)作和交流。在用戶提出需求變更時系統(tǒng)分析員應該認真聽取用戶的要求并加以整理和分析。分析需求變更的原因并提出可行的替代方案；同時向用戶說明這些需求變更會對整個項目的開發(fā)帶來的不良后果。3) 合同約束。由于需求變更可能會對整個項目產(chǎn)生影響，所以，開發(fā)方和用戶在簽定項目合同時，可以對需求變更增加一些相關(guān)的合同條款。4) 建立需求文檔并進行版本控制。需求分析的最終成果是一份客戶和開發(fā)方對所開發(fā)的產(chǎn)品達成共識的系統(tǒng)文檔。有了這份文檔，即使開發(fā)方人員的角色有所變動，也不會對需求分析的前期工作有所影響。對每次的需求變更都用一個新的版本來標識。5) 需求評審和設(shè)立需求基線。為了讓開發(fā)方詳細了解用戶的需求，讓不同人員從不同的角度對需求進行驗證，作為需求的提出者（用戶方），在需求評審過程中，往往能提出許多有價值的意見，同時，也是對需求進行最后確認的機會，可以有效減少需求變更的發(fā)生。需求在通過正式評審和批準之后，應該確定需求基線，進一步的需求變更將在此基線的基礎(chǔ)上，依照項目定義的變更過程進行。設(shè)置需求基線可以將變更引起的麻煩減至最小。

軟件架構(gòu)（software

architecture）是一系列相關(guān)的抽象模式，用于指導大型軟件系統(tǒng)各個方面的設(shè)計。軟件架構(gòu)是一個系統(tǒng)的草圖。軟件架構(gòu)描述的對象是直接構(gòu)成系

統(tǒng)的抽象組件。各個組件之間的連接則明確和相對細致地描述組件之間的通訊。在實現(xiàn)階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在面向

對象領(lǐng)域中，組件之間的連接通常用接口_(計算機科學)來實現(xiàn)。

軟件體系結(jié)構(gòu)是構(gòu)建計算機軟件實踐的基礎(chǔ)。與建筑師設(shè)定建筑項目的設(shè)計原則和目標，作為繪圖員畫圖的基礎(chǔ)一樣，一個軟件架構(gòu)師或者系統(tǒng)架構(gòu)師陳述軟件構(gòu)架以作為滿足不同客戶需求的實際系統(tǒng)設(shè)計方案的基礎(chǔ)。

軟件構(gòu)架是一個容易理解的概念，多數(shù)工程師（尤其是經(jīng)驗不多的工程師）會從直覺上來認識它，但要給出精確的定義很困難。特別是，很難明確地區(qū)分設(shè)計和構(gòu)架：構(gòu)架屬于設(shè)計的一方面，它集中于某些具體的特征。

在“軟件構(gòu)架簡介”中，David Garlan 和 Mary Shaw

認為軟件構(gòu)架是有關(guān)如下問題的設(shè)計層次：“在計算的算法和數(shù)據(jù)結(jié)構(gòu)之外，設(shè)計并確定系統(tǒng)整體結(jié)構(gòu)成為了新的問題。結(jié)構(gòu)問題包括總體組織結(jié)構(gòu)和全局控制結(jié)

構(gòu)；通信、同步和數(shù)據(jù)訪問的協(xié)議；設(shè)計元素的功能分配；物理分布；設(shè)計元素的組成；定標與性能；備選設(shè)計的選擇。

但構(gòu)架不僅是結(jié)構(gòu)；IEEE Working Group

on Architecture 把其定義為“系統(tǒng)在其環(huán)境中的最高層概念”。構(gòu)架還包括“符合”系統(tǒng)完整性、經(jīng)濟約束條件、審美需求和樣式。它并不僅注

重對內(nèi)部的考慮，而且還在系統(tǒng)的用戶環(huán)境和開發(fā)環(huán)境中對系統(tǒng)進行整體考慮，即同時注重對外部的考慮。

在Rational Unified Process 中，軟件系統(tǒng)的構(gòu)架（在某一給定點）是指系統(tǒng)重要構(gòu)件的組織或結(jié)構(gòu)，這些重要構(gòu)件通過接口與不斷減小的構(gòu)件與接口所組成的構(gòu)件進行交互。

從和目的、主題、材料和結(jié)構(gòu)的聯(lián)系上來說，軟件架構(gòu)可以和建筑物的架構(gòu)相比擬。一個軟件架構(gòu)師需要有廣泛的軟件理論知識和相應的經(jīng)驗來事實和管

理軟件產(chǎn)品的高級設(shè)計。軟件架構(gòu)師定義和設(shè)計軟件的模塊化，模塊之間的交互，用戶界面風格，對外接口方法，創(chuàng)新的設(shè)計特性，以及高層事物的對象操作、邏輯

和流程。

一般而言，軟件系統(tǒng)的架構(gòu)（Architecture）有兩個要素：

它是一個軟件系統(tǒng)從整體到部分的最高層次的劃分。

一個系統(tǒng)通常是由元件組成的，而這些元件如何形成、相互之間如何發(fā)生作用，則是關(guān)于這個系統(tǒng)本身結(jié)構(gòu)的重要信息。

詳細地說，就是要包括架構(gòu)元件（Architecture Component）、聯(lián)結(jié)器（Connector）、任務流（Task-flow）。

所謂架構(gòu)元素，也就是組成系統(tǒng)的核心"磚瓦"，而聯(lián)結(jié)器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結(jié)果，任務流則描述系統(tǒng)如何使用這些元件和

聯(lián)結(jié)器完成某一項需求。

建造一個系統(tǒng)所作出的最高層次的、以后難以更改的，商業(yè)的和技術(shù)的決定。

建造一個系統(tǒng)之前會有很多的重要決定需要事先作出，而一旦系統(tǒng)開始進行詳細設(shè)計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關(guān)系統(tǒng)設(shè)計成敗的最重要決定，必須經(jīng)過非常慎重的研究和考察。

對于較大的通常應用應該使用框架，可能節(jié)省不少時間.。能使你很輕松的開發(fā)出一款軟件來。

（軟件開發(fā)一般比較會關(guān)注設(shè)計模式而不是架構(gòu)設(shè)計）

三、上下協(xié)同，用友IPD的研發(fā)管理之道（下）

建設(shè)和運作IPD本身并不是最終的目的，是達成目的的手段。不管何時何境，企業(yè)穩(wěn)定運行與發(fā)展自始至終都應該最為關(guān)鍵的。流程的定義與企業(yè)的目標、業(yè)務模式及企業(yè)所處的競爭環(huán)境等因素緊密相關(guān)。如果企業(yè)本身對其業(yè)務的內(nèi)在規(guī)律不加以考察的話，所謂最完整的管理體系所能起到的效益也會有限。IPD的引入同樣也要考察企業(yè)的實際需要，不能只關(guān)注模仿其他成功企業(yè)流程體系的外在形式，而是吸收其精髓與企業(yè)實際需要相匹配，定義自己的產(chǎn)品業(yè)務流程；當然，可以借鑒成功企業(yè)在某些方面的具體做法。

讓企業(yè)的業(yè)務骨干共同參與到體系建設(shè)中來，在體系建設(shè)的過程中，有目的性地相互交流、學習、研討，明確共同的工作方式并深刻理解其中的深意，同時發(fā)現(xiàn)相關(guān)環(huán)節(jié)的不足，并針對這些不足制定相應的改進計劃，以指導后續(xù)的學習、培訓。

隨著時代的發(fā)展，產(chǎn)品越來越復雜，客戶的需求越來越多樣化，產(chǎn)品的開發(fā)越來越離不開專業(yè)的分工與緊密協(xié)作，要想做得好，方法、能力、協(xié)作一樣都不能少，哪一項是弱項呢？那就是產(chǎn)生困難的原點。

不懂方法，就要學習；能力不夠，就要實踐積累；協(xié)作不好，就要改變溝通機制與態(tài)度，堅持客觀與信諾。先易后難，先小后大，逐漸樹立組織的信心，保持適當?shù)募钔苿咏M織與個人越過自身的心理關(guān)隘。

作好相應的心理準備與資源準備，研發(fā)管理體系的建設(shè)才有保證、落地才有基礎(chǔ)，用實踐來證明困難到底有多大。有句老話，“只要精神不滑坡，辦法總比困難多”。

1. IPD 的核心流程

1. 結(jié)構(gòu)化流程

結(jié)構(gòu)化指互相關(guān)聯(lián)的工作的一個框架結(jié)構(gòu)，并需要一定的組織原則來支持它。沒有結(jié)構(gòu)化就沒有約束，過程不可重復，效率低下；過度結(jié)構(gòu)化，則規(guī)范過多、過細，缺乏靈活性。

結(jié)構(gòu)化流程是指管理研發(fā)的整個流程體系，包括IPD流程、TD流程，以及相關(guān)使流程執(zhí)行的支撐方法（CBB設(shè)計、用戶體驗設(shè)計、技術(shù)研發(fā)、DevOps、敏捷/精益方法、上市/發(fā)布管理、精益運營等）。其目的是保證以客戶為中心，以市場為驅(qū)動，產(chǎn)品研發(fā)過程有序?qū)嵤?，以提高研發(fā)效率，降低研發(fā)成本，支撐公司有效增長

2. 技術(shù)研發(fā)與產(chǎn)品開發(fā)分離

技術(shù)研發(fā)與產(chǎn)品開發(fā)相分離，對于關(guān)鍵的技術(shù)和技術(shù)平臺有時需要在產(chǎn)品開發(fā)之前由專門的團隊研發(fā)出來，并能夠?qū)崿F(xiàn)技術(shù)轉(zhuǎn)化，這樣可以大大減少產(chǎn)品開發(fā)的風險，加快產(chǎn)品開發(fā)周期，而且有利于技術(shù)的突破和進步。同時技術(shù)和平臺又是產(chǎn)品的組成部分，規(guī)劃可以放在一個流程中進行，在產(chǎn)品開發(fā)中進行驗證。

ITMT負責公司技術(shù)投資決策，IPMT負責產(chǎn)品線產(chǎn)品相關(guān)的技術(shù)管理和決策；技術(shù)研發(fā)為產(chǎn)品開發(fā)提供產(chǎn)品需要的技術(shù)和能力，技術(shù)達到要求的成熟度遷移到當前產(chǎn)品開發(fā)中，如果技術(shù)不符合當前產(chǎn)品發(fā)展的要求，IPMT就可以在產(chǎn)品開發(fā)大規(guī)模投入前終止使用。

3. 產(chǎn)品開發(fā)IPD

為規(guī)范和指導產(chǎn)品開發(fā)各生命周期環(huán)節(jié)的活動，按產(chǎn)品版本類型指導設(shè)計。首發(fā)版/大版本分七個階段（產(chǎn)品規(guī)劃、概念、計劃、開發(fā)、驗證、發(fā)布、生命周期），明確各個階段的決策評審點、輸入、輸出、關(guān)鍵活動，針對關(guān)鍵點評審要求目標明確，評審材料齊全。同時支持迭代小版本，為快速響應市場提供持續(xù)改進產(chǎn)品，流程可裁剪成關(guān)鍵的過程活動，如需求規(guī)劃、需求實現(xiàn)、上線、運維。

² 區(qū)分不同產(chǎn)品類型：軟件產(chǎn)品和云服務包括首發(fā)版/大版本（周期超過6個月，或原產(chǎn)品功能有重大變化）、快速迭代小版本。

² IPD流程設(shè)置：通過多個決策評審點對產(chǎn)品開發(fā)進行戰(zhàn)略管控，商業(yè)決策評審（DR）、技術(shù)評審（TR）。

² 融合精益敏捷思想：客戶價值流動，產(chǎn)品快速推向市場，從概念到落地，組織可以快速的將想法變成價值交付到用戶。

² 結(jié)合DevOps實踐：DevOps以價值的快速和高質(zhì)量交付為目標，融合了敏捷與精益的理念原則和實踐，覆蓋從開發(fā)、測試、交付、運維等過程階段。

4. 技術(shù)研發(fā)TD

技術(shù)研發(fā)的目標使技術(shù)與業(yè)務高度融合，最終帶來生態(tài)鏈的創(chuàng)新，打造出體驗一流的產(chǎn)品和服務，保證技術(shù)價值的實現(xiàn)，保持前沿和技術(shù)領(lǐng)先。技術(shù)研發(fā)與產(chǎn)品開發(fā)類似，分七個階段（技術(shù)規(guī)劃、概念、計劃、開發(fā)、驗證、遷移、技術(shù)維護），技術(shù)達到成熟度要求（技術(shù)遷移標準）后，技術(shù)成果遷移給PDT，在產(chǎn)品開發(fā)中作為構(gòu)建模塊按異步研發(fā)的模式漸增構(gòu)建到產(chǎn)品（或平臺）中，繼續(xù)完成開發(fā)、驗證到發(fā)布階段產(chǎn)品商用的后續(xù)開發(fā)過程，以實現(xiàn)技術(shù)成果快速轉(zhuǎn)換，縮短整體研發(fā)周期的目的。

² 支持異步研發(fā)：技術(shù)研發(fā)與產(chǎn)品開發(fā)分離，并單獨進行管理，以便更好的降低風險，實現(xiàn)異步研發(fā)。技術(shù)規(guī)劃和技術(shù)研發(fā)流程是創(chuàng)新和技術(shù)管理方法，建立相應的技術(shù)管理體系是其有效運作的保障。

² 結(jié)合TD流程設(shè)置：通過多個決策評審點對技術(shù)研發(fā)進行戰(zhàn)略管控，商業(yè)決策評審（DR）、技術(shù)評審（TR）。

² 預研和CBB組合管理：一方面面向客戶需求的下一代新產(chǎn)品和解決方案、新商業(yè)機會進行探索與研究。另一方面打破產(chǎn)品線界限，識別出公共的、基礎(chǔ)的以及公司發(fā)展需要的關(guān)鍵技術(shù)，構(gòu)建技術(shù)研究的能力中心。

2. 組織和職責

IPD的全稱是集成產(chǎn)品開發(fā)，顧名思義，IPD強調(diào)的就是“集成”——不僅僅是產(chǎn)品的高度集成，還包括企業(yè)內(nèi)部研發(fā)流程的高度集成、組織的高度集成……所以，有的企業(yè)在實施IPD時，管IPD的實施過程叫做“拆墻”——不僅僅要拆掉部門辦公室之間的實物墻，更要拆掉業(yè)務人員心里的“墻”。為了讓企業(yè)所有人都能面向市場和客戶，IPD通常按層級組建三類跨部門的團隊：負責產(chǎn)品開發(fā)/技術(shù)研發(fā)決策評審的決策團隊——IPMT/ITMT；負資市場管理與產(chǎn)品/技術(shù)規(guī)劃的組合管理團隊——PMT/TPMT；負責產(chǎn)品開發(fā)的產(chǎn)品開發(fā)團隊——PDT；負責產(chǎn)品平臺與技術(shù)開發(fā)的技術(shù)開發(fā)團隊——TDT。每個團隊組織設(shè)計都要符合三個方面的要求：專業(yè)化、跨邊界和橫向聯(lián)系。

（公司IPD組織結(jié)構(gòu)）

（公司TD組織結(jié)構(gòu)）

1. IPMT/ITMT: 對商業(yè)決策/技術(shù)決策負責

IPMT/ITMT代表公司的決策層，是一個高層管理者組織的跨部門的團隊，代表公司制定產(chǎn)品/技術(shù)發(fā)展規(guī)劃、對產(chǎn)品開發(fā)/技術(shù)研發(fā)項目進行投資決策、培育市場管理和產(chǎn)品開發(fā)/技術(shù)研發(fā)流程，并挑選合適的人來保證整個實施過程的有效落實。IPMT/ITMT一般由企業(yè)的高層組成，有些企業(yè)會聘請專家團隊加入到IPMT/ITMT中，以在決策過程中聽取專業(yè)意見。

2. PMT/TPMT ：對市場管理與產(chǎn)品/技術(shù)規(guī)劃的組合管理負責

PMT/TPMT是市場/技術(shù)管理的執(zhí)行者，是一個由各職能部門代表組成的跨部門團隊。PMT/TPMT依據(jù)公司的市場/技術(shù)管理流程，通過收集和分析市場信息和客戶需求。結(jié)合企業(yè)的內(nèi)部能力來制定具體的市場測量和產(chǎn)品/技術(shù)規(guī)劃，并對產(chǎn)品/技術(shù)市場表現(xiàn)和市場/技術(shù)需求變化進行跟蹤。PMT/TPMT是IPD研發(fā)組織中最重要的部門，它一頭連著市場，通過收集和分析市場表現(xiàn)和市場需求變化制定產(chǎn)品策略，并向IPMT/ITMT進行匯報，另外一方面，它還要管理經(jīng)IPMT/ITMT決策的產(chǎn)品開發(fā)/技術(shù)研發(fā)過程和市場推廣過程。

3. PDT/TDT ：對產(chǎn)品開發(fā)/技術(shù)研發(fā)全過程負責

PDT是產(chǎn)品開發(fā)的具體實施團隊，也是由各職能部門代表組成的跨部門團隊，在項目開始時成立，產(chǎn)品上市或項目取消時解散。產(chǎn)品開發(fā)團隊對客戶需求進行匯總和分析，并通過分解反映在具體的設(shè)計當中。產(chǎn)品開發(fā)團隊對產(chǎn)品的市場成功和財務成功負責，這意味著，PDT在產(chǎn)品開發(fā)時就必須不斷刺激市場需求并收集反饋，以期在產(chǎn)品投入市場時獲得最大的收益。PDT掌握著企業(yè)最為核心的技術(shù)秘密，因此嚴格的信息安全管理是必不可少的。

TDT是產(chǎn)品平臺和技術(shù)開發(fā)的實施團隊，同樣也是由各職能部門代表組成的跨部門團隊。TDT下與PDT不同的是，PDT主要是針對某個具體產(chǎn)品開發(fā)和實施，而TDT則是針對產(chǎn)品平臺和技術(shù)進行開發(fā)和實施。產(chǎn)品平臺在開發(fā)之初，并不考慮某個客戶或者某個特定市場的客戶需求，而是針對這些需求進行擴展和提升，從設(shè)計的一開始就考慮到一系列可能的客戶需求和可能的市場需求，然后根據(jù)這些需求設(shè)計一個基礎(chǔ)平臺?；A(chǔ)平臺并不具有任何實用意義，但是它可以通過接駁不同的功能組件，滿足不同的客戶具體需求或者市場具體需求。

3. IPD 決策評審

1) IPMT 職能的行使，以及與PDT之間的正式溝通對數(shù)情況下都是通過會議方式進行，所以會議的效率非常重要，如果會議沒有好的準備，可能會有以下后果：

² 會前沒仔細閱讀資料，會上無法決策，致使整個會議不完整（尤其決策質(zhì)量受影響，每個IPMT成員代表一個部門）；

² 沒有與PDT充分溝通，導致PDT不能事先準備，無法回答問題，使一個DR（決策評審）會議延續(xù)為多個；

² 太多問題事先沒有討論達成一致，尤其是密切相關(guān)部門之間，可能使決策會變成討論會或爭論會；

² 對重要問題，沒有收集部門他人的意見，使得在會上無法代表部門而只能代表自己；

² 未明確區(qū)分商業(yè)決策評審和技術(shù)評審，評審文檔不能提前發(fā)出：

² 文檔還沒編寫完，但里程碑節(jié)點已經(jīng)快到了，所以邊進行評審會組織邊準備著文檔；

² IPMT評委不提前閱讀評審文檔，評審會變?yōu)橐粋€講解文檔會；會上無法決策，致使整個會議不完整；

² 會前缺少充分溝通，有些評委提前閱讀了文檔，發(fā)現(xiàn)了嚴重問題，不提前溝通，一些嚴重的問題，本應延期或取消評審；

² IPMT評委本人不參加，安排代表參加評審，不能給出有效意見或決策，只是來收集問題再回去反饋；

² 部分會議沒有結(jié)論，不是安排對口序列的人做評審記錄，評審會議結(jié)束前沒有對所記錄的問題現(xiàn)在再次回顧、明確。

2) IPMT成員會前一定要做好準備，準備內(nèi)容包括：

² 認真閱讀評審材料；

² 與PDT溝通，了解產(chǎn)品開發(fā)進展情況，對照決相關(guān)文檔（比如決策評審標準）進行檢查，并在本功能部門內(nèi)部達成一致。不同的DR（立項、計劃、上市等）要應用不同的檢查清單，因為不同的DR所關(guān)注的重點不一樣；

² 提出疑問請PDT解答或準備，并和本功能代表達成一致意見；

² 對PDT中需要本部門決策的事項（如資源、進度等）進行充分準備；

² 在項目任務書發(fā)布（Charter）立項決策評審時，IPMT成員應事先填寫好決策表；

² 全面了解產(chǎn)品線路標規(guī)劃和產(chǎn)品線業(yè)務計劃。

同時，PDT成員也要做好充分的會前準備，包括各種會議資料的準備，并準備回答IPMT成員的提問。如果準備不充分，IPMT成員在會前或者會中可以要求延期或者取消會議。

3) 決策評審是集成產(chǎn)品開發(fā)管理團隊（IPMT）管理產(chǎn)品投資的重要手段，在決策評審中，IPMT始終站在投資商的角度來進行評審；集成產(chǎn)品開發(fā)（IPD）流程中包括了四個主要的決策評審點：立項決策評審、計劃決策評審、上市決策評審和生命周期結(jié)束評審。

² 立項決策評審（DR2）

在規(guī)劃階段結(jié)束時要召開一個立項決策評審會。在這個會議上，PDT正式向IPMT報告初始的業(yè)務計劃，由IPMT來決定項目是繼續(xù)還是終止。在初始的業(yè)務計劃中，PDT將給出如下方面的內(nèi)容：針對給定目標細分市場存在的機會分析、目標客戶群、擬開發(fā)的產(chǎn)品描述、成本及風險估計、初始銷量預測及初始財務評估。若初始的業(yè)務計劃得到批準，IPMT將做出下一階段開始前所需的承諾，項目進入概念階段。

² 計劃決策評審（DR3）

在計劃階段結(jié)束時要召開一個計劃決策評審會。在這個會議上，PDT向IPMT展示最終的業(yè)務計劃以及決策合同，由IPMT來做出繼續(xù)/終止的決策。最終的業(yè)務計劃以初始的業(yè)務計劃為基礎(chǔ)，提供了更多的細節(jié)內(nèi)容及對計劃的承諾。若業(yè)務計劃獲得批準，則PDT與IPMT達成一致承認（IPMT承諾資源、培養(yǎng)人才， PDT承諾業(yè)績、呈現(xiàn)結(jié)果、貢獻價值）。項目進入開發(fā)階段，即每個主要部門都將支持項目以及給PDT必要的資源；另一方面，PDT將承諾按合同要求完成項目的交付目標。

² 上市決策評審（DR4）

產(chǎn)品正式公開發(fā)布及推向市場前的最終決策評審，需要IPMT明確做出繼續(xù)/終止的決策。上市決策評審應在任何主要的發(fā)布花費投入之前進行。這一決策評審的目的是證實在計劃階段制定的業(yè)務計劃中的估計和假設(shè)，并評估產(chǎn)品發(fā)布前用戶的準備情況。若PDT在計劃階段制定了合適的業(yè)務計劃執(zhí)行了開發(fā)工作，則在上市決策評審時所要做的工作應該是很少的。在上市決策評審會議上，PDT正式向IPMT給出他們的建議，由IPMT來做出繼續(xù)/終止的決策。若產(chǎn)品獲得批準，則由IPMT分配資金，項目進入上市階段。

² 生命周期結(jié)束評審（DR5）

在產(chǎn)品生命周期結(jié)束時，生命周期管理團隊（LMT）要向IPMT提交停止銷售、停止生產(chǎn)、停止服務的時間表建議，由IPMT做出繼續(xù)/終止的決策。IPMT必須要審核產(chǎn)品生命終止的發(fā)布是否與新產(chǎn)品戰(zhàn)略保持一致以及是否已很好地考慮了潛在的客戶滿意度方面的問題。

4) 決策評審怎么做

首先，要在產(chǎn)品開發(fā)過程中設(shè)置階段性的決策評審點。如IPD流程中設(shè)置了立項決策評審、計劃決策評審、上市決策評審、生命周期決策評審這4個決策評審點。按階段對產(chǎn)品開發(fā)項目進行審視，及時砍掉不再具備投資意義的項目，把資源分配轉(zhuǎn)移給能夠獲得較高投資回報的項目。

第二，制定決策評審的Checklist。從市場與競爭、項目方案、資源、投資估算、財務分析、風險評估等幾方面來設(shè)計Checklist。并且Checklist里要考慮現(xiàn)狀分析和未來判斷，在下個階段的決策評審時，要關(guān)注項目立項之初或上個階段的市場環(huán)境、競爭趨勢、客戶需求有沒有變化，分析當前產(chǎn)品的成熟度如何，以及未來有哪些風險。

第三，化決策為行動。再好的決策，如果不能夠去行動，那么任何決策都是沒有意義的。決策與想法不在于特別的英明，而在于能否實行，決策后需要立即行動起來。

第四，規(guī)范決策評審的運作制度。無規(guī)矩不成方圓，尤其是決策評審的評委們一般都是公司的高層管理者，如果都按照自己的意志來行事，沒有一個制度來規(guī)范他們的運作，那么很快決策評審就會變成“四不像”。運作制度要包括參與人員的選擇和要求，考核會議出席率；確定決策原則和決策的結(jié)論；制定決策評審的流程，計劃和準備階段的預審要求、提交議題和材料的時間要求；匯報和決策階段的記錄要求、節(jié)奏和內(nèi)容要求；發(fā)布和執(zhí)行階段的紀要、歸檔和遺留問題跟蹤的要求等。

滿足以上原則，可以保證各產(chǎn)品項目決策評審的有效性和充分性。

4. IPMT 和PDT關(guān)系

在IPD實施過程中，IPMT（Integrated Portfolio Management Team，集成組合管理團隊）和 PDT（Product Development Team，產(chǎn)品開發(fā)團隊）是兩個最主要的跨部門團隊，一般說來也是在IPD體系建立過程中，最先要建立和建設(shè)的團隊。IPMT是跨部門決策團隊，由各個功能部門主管構(gòu)成。PDT是產(chǎn)品開發(fā)跨部門團隊，由和產(chǎn)品開發(fā)相關(guān)的各個功能部門代表構(gòu)成。兩個團隊的職責、運作中的問題前面已經(jīng)述說，現(xiàn)將IPMT、功能部門和PDT的關(guān)系簡單介紹如下：

² IPMT通過項目任務書方式向PDT團隊下達開發(fā)任務，并在決策評審點進行決策（繼續(xù)/停止/重新調(diào)整方向），根據(jù)情況可增加臨時決策評審點；

² PDT團隊在PDT經(jīng)理領(lǐng)導下進行跨部門產(chǎn)品開發(fā)，向IPMT匯報并提供決策和過程信息；

² IPMT有義務協(xié)調(diào)公司功能部門和其他資源解決PDT運作中遇到的技術(shù)和管理問題；

² IPMT對PDT實施績效考核。

1. 任命合格的PDT經(jīng)理

在團隊運作中，團隊領(lǐng)導起著非常重要的作用，在PDT運作中也是如此。那么，IPMT應當選擇什么樣的人來擔任PDT的項目經(jīng)理呢？在實踐中，我們發(fā)現(xiàn) IPD體系運行中，尤其在IPD體系推行初期，IPMT往往傾向于選擇技術(shù)最強或者技術(shù)最全面的人擔任PDT經(jīng)理，產(chǎn)生這個問題的原因在于：

² 對IPD模式下產(chǎn)品開發(fā)團隊特征理解不清。產(chǎn)品開發(fā)團隊的結(jié)構(gòu)和工作目的完全不同于功能部門；

² 對PDT經(jīng)理的角色職責及其所需的技能要求理解不清，還是以功能部門經(jīng)理的要求來衡量PDT經(jīng)理，功能部門主管的職責是構(gòu)建卓越的功能；

² 對IPD推行初期的艱巨性理解不夠，IPD體系下，開發(fā)團隊以一種和以前完全不同的方式進行工作，這要求PDT經(jīng)理需要有很強的協(xié)調(diào)和資源整合能力，而這些不同于專業(yè)技術(shù)工作，需要特別的技能。

事實上，PDT是一個跨功能部門的重量級團隊，他們在PDT經(jīng)理的帶領(lǐng)下，以一種跨功能部門方式工作，各成員在所有的產(chǎn)品決策中代表本功能部門作出決策。這要求PDT經(jīng)理和核心組成員有較強的組織、協(xié)調(diào)和溝通能力。對PDT經(jīng)理來講，還需要掌握必要的市場、財務等方面的知識，尤其具備相當?shù)纳虡I(yè)意識，PDT經(jīng)理相當于是產(chǎn)品上市前的產(chǎn)品“小總經(jīng)理”。

一味強調(diào)技術(shù)水平，按照技術(shù)能力高低選拔PDT經(jīng)理并不一定利于團隊運作。PDT團隊中有系統(tǒng)工程師（SE）、各個功能部門代表，由他們來對整個系統(tǒng)和各種專項技術(shù)進行把關(guān)。在實踐中，PDT技術(shù)能力強而管理能力弱，往往反倒對項目運作不利，這樣的PDT經(jīng)理往往越位進行過細的技術(shù)指導，影響功能代表的積極性，并且忽略管理者應當做的事。

在IPD推行的初期，為了保證推行效果，對PDT經(jīng)理的要求一般為：

² 主要來自研發(fā)與市場；

² 崗位（職位）等級要有一定的要求（4A及以上）；

² 被任命前績效考評成績達到一定要求（B+及以上）；

² 有相當?shù)墓芾斫?jīng)驗。

2. 給PDT充分授權(quán)

IPMT通過體系文件、項目任務書、流程等方式對PDT團隊進行了充分授權(quán)，就應當嚴格按照規(guī)范進行運作：一般情況下，IPMT主要在決策評審點介入，其余事務由交給PDT團隊處理。

這樣處理的好處：

² 明確了授權(quán)的范圍，比如計劃變更在多少范圍內(nèi)PDT成員可以自行決策；

² 選擇公司非關(guān)鍵項目作為IPD試點，對IPD流程進行充分驗證。防止因為項目出現(xiàn)異常影響公司經(jīng)營，給IPMT成員直接介入開發(fā)工作提供理由；

² 提拔有能力的員工擔任PDT項目經(jīng)理，合格項目經(jīng)理的條件上面已經(jīng)討論過；

² 要求各個IPMT成員要深入理解IPD體系，明確自己的管理職能。對適合作PDT經(jīng)理的IPMT成員，也可以發(fā)揮所長擔任PDT經(jīng)理。

5. 總結(jié)

IPD提供的是一個系統(tǒng)的路徑，以及一整套被驗證過的、可落地的方法。首先是商業(yè)常識和管理常識的回歸。對外，一切以用戶為中心、以需求為驅(qū)動、以市場為導向，主要通過市場規(guī)劃(MM)、需求管理、投資決策幾個工具來落地；對內(nèi)，通過對產(chǎn)品、技術(shù)、流程和人進行結(jié)構(gòu)化、系統(tǒng)化的設(shè)計，分層分類，實現(xiàn)管理的系統(tǒng)化，主要實踐包括：異步研發(fā)、結(jié)構(gòu)化流程、平臺化。對于職業(yè)化程度較高的企業(yè)，大多已經(jīng)做得不錯，并隨著企業(yè)的不斷發(fā)展而持續(xù)改善。到今天為止，華為每年還花費數(shù)億美金，聘請世界頂級咨詢公司和管理專家，幫助其進行管理提升，因為華為知道，職業(yè)化和系統(tǒng)化是永無止境的過程。而對于那些靠摸爬滾打成長起來的制造企業(yè)，往往管理粗放，職業(yè)化程度遠遠不足。因此，IPD往往在很大程度上促進了他們的基礎(chǔ)管理建設(shè)，至少是開啟了管理提升的意識。

其次IPD更為重要的一個部分是其橫向協(xié)作機制。在傳統(tǒng)的科層制、職能制組織里，硬生生的拉出了一條線索，橫貫所有職能領(lǐng)域，用最靈活、最直接的方式去面對和響應客戶需求。這里面既有端到端流程的打通，也有對跨領(lǐng)域團隊的授權(quán)與賦能，同時在激勵機制上做深度變革，讓有追求有創(chuàng)造力的員工能夠圍繞客戶需求追求卓越，徹底釋放企業(yè)的創(chuàng)新活力。這讓所有的大企業(yè)，讓所有規(guī)模還不大就患上了大企業(yè)病的企業(yè)，讓所有希望成為平臺型組織的企業(yè)，看到了實實在在的希望。

產(chǎn)品開發(fā)的問題，是大多數(shù)大中型企業(yè)要走向規(guī)范化管理必須要解決的問題，變革引入IPD流程，是企業(yè)完善產(chǎn)品研發(fā)體系的最佳方式之一。用友每年業(yè)務都在持續(xù)增長，組織規(guī)模也越來越大；為推動《用友研發(fā)管理體系V3.0框架》有效運作，集團已經(jīng)成立IPMT和ITMT，對集團產(chǎn)品與技術(shù)發(fā)展的總體決策負責，以促進產(chǎn)品開發(fā)更好地滿足客戶需求，達成公司商業(yè)目標，同時加強對公共技術(shù)、基礎(chǔ)技術(shù)及其它關(guān)鍵技術(shù)的識別與抽取，構(gòu)建技術(shù)持續(xù)領(lǐng)先體系。

文章參考用友研究院、用友開發(fā)者大賽和 YonBuider開發(fā)中心資料

四、3 IPD介紹- IPD（Integrated Product Development，集成產(chǎn)品開發(fā)））

IPD概括介紹

狹義IPD：新產(chǎn)品開發(fā)，該文針對于這個定義進行展開

中觀IPD：包括產(chǎn)品開發(fā)（狹義IPD）、市場管理及產(chǎn)品規(guī)劃（marketmanagement，MM）和需求管理（requirementmanagement，RM），3大流程共同構(gòu)成產(chǎn)品創(chuàng)新管理體系

宏觀IPD：指的是端到端產(chǎn)品管理體系，除中觀IPD范圍外，宏觀IPD還包括技術(shù)和平臺規(guī)劃（technology＆ platformplanning，TPP）、技術(shù)開發(fā)（technology＆platformdevelopment， TPD）、產(chǎn)品生命周期管理（productlife-cyclemanagement，PLM），以及支撐它們的組織體系和績效激勵體系

產(chǎn)品研發(fā)的最終目的是要實現(xiàn)商業(yè)目標

IPD全流程環(huán)節(jié)專注兩條主線，決策團隊和開發(fā)團隊在每個決策點和全流程都關(guān)注產(chǎn)品包和O/SBP，關(guān)注這兩方面的交付，生命周期也是圍繞著兩個主線開展工作

IPD流程總體上遵循“V模型”

Charter DCP：立項評審，接受項目任務書

CDCP：概念決策評審（concept）

PDCP：計劃決策評審（plan）

ADCP：可獲得性/上市決策評審（availability）

EDCP：結(jié)束決策評審（end）

TDCP：臨時決策評審（temporary）

EOX：終止XX（end of xx）

EOL（end of life）

GA：通用可獲得性（general available）