OR管理培訓 2013年11月07日 Internal Page2 目錄 需求和包需求介紹客戶需求管理流程需求管理的基本階段銷售項目需求管理需求管理組織結構需求質量管理產品包需求分層模型需求管理電子流 Page3 需求的演變 客戶如此描述需求 項目經理如此理解 分析員如此設計 程序員如此編碼 商業顧問如此詮釋 項目文檔如此編寫 安裝程序如此簡潔 客戶投資如此巨大 技術支持如此膚淺 實際需求原來如此 需求管理常見問題 對產品需求的理解 選擇和定義不足市場需求的收集和分析沒有成為一個例行的活動市場需求僅側重功能 忽視了服務 性能 可靠性等市場人員反映了許多需求卻得不到及時響應 打擊了需求提交的積極性市場人員反饋的需求模糊不清 也無法得到進一步的回復無法在大量的信息中發掘用戶的潛在需求用戶 部門之間 員工之間對需求的理解無法得到統一需求不斷的變化 調整使得產品始終難以定型對需求的分析 驗證缺乏系統的工具 大家抱著走一步看一步的態度在需求管理問題上 市場與研發扯皮 Page4 需求的定義 Page5 IEEE工程標準詞匯表 1997年 中定義需求為 1 用戶解決問題或達到目標所需的條件或能力 2 系統或系統部件要滿足合同 標準 規范或其它正式規定文檔所需具有的條件或能力 3 一種反映上面 1 或 2 所描述的條件或能力的文檔說明 IEEE的定義包括從用戶角度 系統的外部行為 以及從開發者角度 一些內部特性 來闡述需求 其關鍵的問題是一定要編寫需求文檔 定義隱含了需求的三個影響因數 問題域 范圍 干系人 目標 Page6 什么是需求 需求 問題 解決方案 需求在產品開發工程中的變遷 Page7 產品包需求 OR 管理流程 需求實現及驗證子流程 概念階段 計劃階段 開發階段 理解市場 組合分析 業務計劃 書面標準事實標準 質量屬性DFX 客戶需要 市場需求 內部需求 標準約束 產品包需求 設計需求 系統構架 產品概念 設計規格 模塊設計 功能需求非功能需求 客戶needs wants 各類需求的定義 Page8 什么是產品包需求 Page9 客戶需要的不僅僅是軟硬件而是一個完整的交付這也是OR OfferingRequirement 名稱的由來 產品包需求從另一個角度看就是客戶為什么購買產品的理由 保修建議 融資發貨 企業形象 品牌 其它客戶的評價 感知的質量 功能 性能包裝 價格 產品包 售前售后售中 無形影響 可獲得性 Page10 APPEALS是描述產品包需求的推薦方法 它關注客戶在購買競爭性產品時是如何做決定的 Page11 客戶購買標準分析 APPEALS Page12 目錄 需求和包需求介紹客戶需求管理流程需求管理的基本階段銷售項目需求管理需求管理組織結構需求質量管理產品包需求分層模型需求管理電子流 Page13 需求管理的目標 需求管理的目標 建立公司范圍內統一 分層 協調一致的需求管理體系 支持持續獲得成功牽引瞄準靶心需求 準確把握機會點使版本火車更加有序化 Page14 OR管理的目的和原則 需求管理流程的目標 統一需求管理 實現端到端的可視化主動收集需求 準確把握市場機會點逐步降低緊急需求比重 提高版本交付質量提高中長期需求比重 為市場管理提供需求來源需求管理流程的原則和要求 所有需求必須被錄入電子流電子流需求必須得到及時處理鼓勵全員參與 并對高價值需求進行獎勵 Page15 OR在IPD體系中的定位 SP BP 路標 Charter OR需求管理 需求 長期需求 中期需求 產品包需求 緊急需求 技術 商業戰略 歷史數據 市場評估 市場細分 機會點分析 制定業務計劃 整合業務計劃 業務計劃管理 績效評估 計劃 開發 驗證 發布 生命周期 概念 IPD流程 MM市場管理 PCR 做正確的事 正確地做事 MM MarketManagementOR OfferingRequestSP StrategyPlanningBP BusinessPlanningPCR PlanChangeRequest 需求管理的基本階段 Page16 驗證需求 需求跟蹤 需求變更控制 需求納入 業務計劃 路標規劃 產品開發項目任務書 產品開發項目組的需求說明書 開發需求 新方案 新產品 新版本 變更正在開發的產品 收集需求外部需求內部需求 外部來源客戶行業分析競爭對手展覽雜志 需求過濾 解釋 過濾 檢視 需求分析 分類 排序 證實 驗證 實現 收集 分析 分發 業務計劃 產品線 路標規劃 項目任務書 在研產品 變更 需求 分發 決策 內部來源公司管理層PDTPMT售后服務預研營銷研發其它部門 需求管理的基本階段 收集 目的收集子流程確定并生成可能的產品包需求 為后續的分析 篩選和執行做準備 需求可能來自各種內部和外部渠道 收集子流程應采用市場和客戶驅動的方法 生成高價值的客戶需求 輸入通過子流程的活動 收集子流程收集來自各個渠道的輸入 外部渠道客戶 現有的和潛在的客戶 行業分析 競爭對手 展覽會 期刊雜志內部渠道即公司的內部部門 例如市場 辦事處 研發 技服 PDT 預研 營銷等外部和內部渠道并不是互相獨立的 來自外部渠道的需求由公司內部功能部門收集 并輸入需求管理流程 之所以將這兩個渠道區別開來 主要是為了明確外部渠道 支持使用更為面向市場和客戶的方法來收集需求 Page17 需求管理的基本階段 收集 活動收集子流程不單只是一個步驟或活動 它包括了公司各組織日常進行的一系列活動 例如 市場管理流程中產品線級別的競爭分析便是一個需求收集的渠道 而PDT進行的產品線級別的競爭分析則是另一種收集需求的渠道 呼叫中心也是一個典型的收集渠道 輸出活動輸出可能的產品包需求 IT工具 電子流 的支撐在需求遞交活動中起非常重要的作用 應在電子流中記錄可能的需求 隨后處理 Page18 需求管理的基本階段 收集 直接從客戶收集需求 一般公司的大部分需求來自于內部渠道 必須通過外部渠道 尤其是客戶這一渠道 提供公司未來大部分需求 收集可提前預測客戶需求的長期需求 目前的大部分需求都是短期需求 實現這些需求的產品必須在6個月或更短的時間內交付 將來公司應該有一大部分需求是那些交付時間為一年或一年以上的長期需求 這樣公司便可以及時開發出高質量產品 而不是在最后時刻匆匆交付低質量產品 Page19 Page20 需求管理的基本階段 收集 收集什么樣的需求如何收集需求誰來收集需求 Page21 需求管理的基本階段 收集 收集什么樣的需求客戶需要的不僅僅是軟硬件而是一個完整的交付收集的需求不僅僅只考慮功能和性能方面還要考慮易用性 價格 可安裝 可服務等方面的需求 售前售后售中 Page22 需求管理的基本階段 收集 如何收集需求 展會 行業會議 客戶簡報 決策支持中心 研發高層交流 解決方案團隊 標桿研究 試驗局 用服高層交流 現場支持 服務熱線 客戶顧問委員會 客戶滿意度 推薦的主動需求收集方法 Page23 需求管理的基本階段 收集 誰來收集需求Marketing銷售人員技術服務人員研發人員UCD專家 OM專家 標準研究專家 所有人都應該收集需求 Page24 需求收集的有關規定 所有的需求必須以統一的渠道提交需求類型多樣 數量巨大 提交人分散匯集某個產品的所有需求是后續分析處理的基本要求畢竟我們需要的是一個五臟俱全的產品 而不是零件的拼湊混亂的提交渠道曾經造成一系列的問題 需求該提交給誰 Page25 客戶需求收集過程 客戶分析 收集策劃 需求收集 市場細分客戶 用戶 干系人分析決策分析關注點分析 多種收集途徑收集途徑選擇需求訪談設計調查問卷設計電子流設計 需求收集技巧全方位收集需求客戶需求十問聽的技巧從需要 問題出發一線需求收集及管理需求收集質量控制構建例行化收集機制 Page26 客戶分析 客戶類型劃分 廣義的 客戶 customer 包括 購買者 buyer 狹義的客戶 用戶 或 最終用戶 userorenduser 干系人 stateholder 如提議者 渠道 合作關系等 客戶 狹義的 與用戶可能是同一個人也可能不是同一個人 Page27 客戶分析 選定初步的細分市場 初步的細分市場 描述 價值和選擇的理由 A B C D E F G H Page28 客戶分析 確定不同類型的客戶 Page29 客戶分析 決策影響分析 Page30 客戶分析 關注要點分析 Page31 客戶需求的收集途徑 市場活動 銷售活動 用服活動 公開信息 商業伙伴 專業數據 一手信息 二手信息 需求庫 需求整理分析 報告交流 競爭者信息 統計報告 新聞剪報 訂閱的報告 專家顧問團 高層交流 原型測試 用戶訪談 客戶大會 銷售 投標 現場支持 標桿研究 需求調研 高層交流 售后反饋 Page32 十種常用采集途徑的特點 Page33 需求采集途徑 行業會議 展會 簡介 行業會議和展會是該行業及相關行業的重要展示平臺 匯集國內外各知名品牌的信息 行業會議一般會邀請行業內龍頭企業做產品介紹 參加會議和展會有助于獲得業界的認知 提高公司知名度 吸引新的客戶 它提供了與客戶交流一對一交流 除帶來直接與間接的銷售以外 更為公司提供了收集業界與競爭對手情報的機會 產品與時間范圍 會議更適用于了解技術的發展趨勢 國外知名企業的動向 國家政策的引導方向 行業的具體要求等 展會能更直接的接觸客戶與潛在客戶 大批量收集各類客戶的各種淺層次需求 了解競爭對手推出的新產品 新技術 Page34 需求收集要點 行業會議 展會 需求收集要點 政策導向 政策導向往往可以帶來很大片市場 通過挖掘政策 做行業解決方案 行業特點 有無特殊需求 不同的行業有其特殊要求 一個行業的成功代表一個市場的成功 競爭對手技術發展 行業會議中能夠了解到目前競爭對手的狀態 也是了解競爭對手技術實力的一個重要手段 會議通訊錄 會議通訊錄中一般會有與會企業的聯系名錄 并且是該行業內的知名企業 通過收起會議通訊錄能夠收集客戶信息 并為后續需求的收集帶來方便 老客戶反映的問題 老客戶反映的問題是重要問題 是實踐中出現的問題 需盡快解決 為短期需求 新客戶提出的問題及需求 新客戶可能代表一個行業的需求 通過收集的分析新客戶的問題及需求 能夠分析出行業的需求 一般為短期及中期需求 會議 展會后 會議 展會后 需求收集人應盡快整理需求 分析有效需求與無效需求 需求分析小組應組織專門會議及該次需求進行評審并提交 Page35 需求采集途徑 一線銷售 投標 簡介 一線銷售走在市場的第一線 能夠接觸到各種客戶與競爭對手 通過產品推廣獲得客戶的各種需求 通過投標可以了解到其他投標企業的技術特點 產品與時間范圍 直接獲得客戶需求 在銷售項目 投標過程中系統了解當前產品與客戶要求的差距 但日常銷售獲得的需求比較散亂 模糊 失真現象較多 投標競爭方式下難以對客戶需求進行有效的引導 需求為短中期 當前版本 Page36 需求收集要點 一線銷售 投標 需求收集要點 一線銷售收集客戶短期需求通過客戶對產品的不滿分析客戶內在的要求通過客戶將公司產品與競爭對手產品的比較 收集客戶的真實需求通過招投標的成功與失敗 收集客戶的真實需求 要求 一線銷售人員每次出差報告中添加需求收集項 將需求收集作為日常工作的重要組成部分 需求采集途徑 中長期需求調研 目的系統 針對性地收集并分析某細分市場或某領域的需求 調研類型產品線 產品需求調研某細分市場 如區域市場 需求調研某領域 如可服務性 需求調研預研需求調研等優點能夠全面 系統地收集中長期需求缺點成本高需要的技能較高 管理難度較高特點需求為中長期 當前版本 未來版本 Page37 應用 APPEALS方法進行需求訪談 Page38 識別客戶群 識別決策單位 識別參與訪談的客戶 制作訪談計劃 準備 包括訪談公司內部人員 一對一訪談或群組訪談 對客戶公司成員 分析數據 輸出調研報告 與客戶確認 需求錄入電子流 交付件歸檔 內部評審 更新 appeals子要素并進行優先級排序 客戶需求訪談要點 舉例 Page39 包裝 機柜設計 布線 噪音 外觀 運輸包裝 機柜設計 標準機柜尺寸 承重 易拆卸 易擴容 抗震性 布線 布線整齊 符合客戶布線規范和業界標準 噪音 低噪音 外觀 人性化設計 拉手條 顯示燈 與現有設備的協調性 機柜標志和標簽指示明顯 運輸包裝 包裝箱環保 易打開 防受傷 保護機柜 包裝箱上麥頭標志易識別 易運輸 易儲存 易用性 易于維護 兼容性 業務包 可擴展性 高集成度 統一網管 環境適性 安全性 易于維護 易于學習和理解 自動故障檢測和恢復 遠程維護 熱插拔 兼容性 與現有設備兼容 前向 后向 業務包 個性化解決方案 可編程 可擴展性 易于功能升級 在線擴容 配置靈活性 高集成度 系統集成度 單板端口密度大 統一網管 以相同的風格對所有部件進行管理的能力 系統具有分級管理權限 提供上一級開放的網管接口 環境適應性 對環境的溫度 濕度 電壓不穩 電磁干擾等的適應能力 安全性 防止獲取未授權用戶信息 調查問卷設計 Page40 封閉式問卷是非法 是與否 多項選擇 三個以上答案供選擇 李克量表 在堅決同意和堅決不同意間選擇 語義級差 在最好和最差之間選擇 重要量表 在最重要和最不重要之間選擇 開放式問卷自由格式 無任何引導 暗示或限制 填充式 在不完整的語句中填入有關內容 聯想式 對于給定的詞匯 情節等進行聯想 圖示式 給予一幅圖畫 增添內容或進行聯想 Page41 需求收集技巧 從需要 問題出發理解客戶需求 話機聽筒的電纜應該有10米長 客戶需求 Why 而客戶真正的意圖是 可以拿著電話在房間的任何一個地方通話 10M 要真正理解客戶的意圖 Page42 十種需求采集途徑的總結 著眼全局 中間站點 可能路線 反復確認 廣泛征詢 亡羊補牢 Page43 構造例行化需求收集機制 構建需求收集IT系統形成需求收集報告機制組建需求收集分析專業團隊與員工任職資格 績效掛鉤控制神經末梢 出差 展覽 招標等 需求管理的基本階段 分析 目的收集子流程通過市場和客戶驅動的方法生成高價值需求后 分析子流程的重點確保必要的要素 可以對其進行分析和解釋轉化 目的在于在以后的子流程中可以分發 執行并驗證分析過的需求 輸入分析子流程的輸入來自收集子流程 主要的提供人同收集子流程 活動分析子流程包括以下主要活動 篩選提交的需求 確保需求創建人記錄了所需的分析要素 將需求分類 例如 功能性需求與非功能性需求 單個產品需求與跨產品 跨產品線需求等 將需求按照優先級排序 例如 客戶的優先級 公司的優先級 輸出所提交的需求經過分析子流程的處理后 輸出分析和解釋轉化后的需求 在分發子流程中分配給各利益相關人 由他們決定如何處理需求 Page44 Page45 需求管理的基本階段 分析 4個基本步驟 解釋過濾分類排序 Page46 需求管理的基本階段 分析 步驟1 解釋各種源頭來的需求 需要進一步提煉 以正式的語言描述 解釋 Page47 需求描述的5原則 以產品必須做什么 而非應該怎樣做像陳述原始數據那樣詳細表達需要使用肯定句而非否定句把需要表達成產品的屬性避免使用必須和應該 Page48 客戶陳述 需求描述 Page49 需求管理的基本階段 分析 步驟2 過濾收集到的信息 有可能不是需求 例如 一線向總部提出的要人 要貨的請求商務 法律方面的請求等這些信息需要被過濾出來 Page50 需求管理的基本階段 分析 步驟3 分類需求有很多種分類的維度 需要針對性的處理 功能性能可靠性可維護性包裝 跨產品線需求 短期中期長期 產品特性包需求設計需求設計規格 按時間 按類型 按層次 Page51 需求管理的基本階段 分析 步驟4 排序在成本 時間受限的前提下 需要對需求進行取舍 常用的排序方法有 APPEALS方法Delphi方法 成本 價值 Page52 需求管理的基本階段 分析 步驟4 排序Delphi方法 目的分發子流程的目的在于派發已分析的需求到對應部門決策 該需求應當被接納實施 還是拒絕 或推遲 輸入分發子流程接受分析子流程分析過的需求作為它的輸入 活動分發子流程決定了分發需求的最合理路徑 可能有以下的分發路徑 市場管理流程 IPD流程 技術開發流程決策流程不在需求管理流程范圍之內 例如 對于PDCP后分配給PDT的需求 PDT負責提交PCR 假設雖然需求會引起GA日期的變化 PDT仍要支持它 就需要提交產品線IPMT決定進行支持或拒絕 這一決策機制 標準和權力 不在需求管理流程的范圍之內 輸出分發子流程決策出需求應當被接納實施 還是拒絕 或推遲 如果需求被接納 就會確定后續流程的責任人 Page53 需求管理的基本階段 分發 Page54 需求管理的基本階段 分發 根據需求的類型把需求分發到對應的下游環節 需求 PDT RMT 1 當前產品的單產品需求 2 中長期需求 3 跨產品需求 協調跨產品需求 實現接納的需求必要時發起PCR 納入BP 路標 Charter 市場管理流程 Page55 需求分發的角色與職責 RMT RAT確定進來的需求所應該去的路徑 例如MM流程 IPD流程或技術平臺開發流程 管理分發到PDT的單產品需求 如果存在 管理分發跨產品 跨產品線的需求參與跨產品線需求的解決方案 PDT決定需求是否接納支持跨產品 跨產品族 跨產品線需求的解決方案對PDCP后的需求使用PCR流程將需求狀態反饋給RMTTDT與PDT類似 但是只應用于技術 平臺需求 技術 平臺需求管理管理分發到TDT的技術平臺需求 如果TDT已運行 協調技術平臺需求進入平臺路標規劃 如果相關的話 協調公司內部部門 如市場 研發 決定是否接納和優先級 PMT決定需求是否接納對于接納的需求納入到業務計劃 路標規劃或PDT項目任務書支持跨產品線需求的解決方案將需求狀態反饋給RMT Page56 分發到市場管理 MM 流程 到達市場管理 MM 的需求必須由PMT處理 如果被接納 可能分發到 年度業務計劃產品路標規劃PDT任務書當PMT創建業務計劃 路標規劃或charter時 他們需要使用需求管理流程作為他們的需求來源之一瀏覽市場需求同時考慮被接納和被拒絕的需求 Page57 一 概述使命 愿景及目標績效 機會差距二 市場及業務評估A 了解市場 見解宏觀環境分析行業及市場評估競爭對手分析產品包分析客戶分析B 業務設計與支持原理客戶選擇細分與組合分析價值陳述總結活動范圍獲取價值 價值鏈戰略控制增長管理 三 業務計劃A 業務計劃要素產品包價格 條款銷售渠道集成營銷宣傳技術支援訂單履行B 績效 機會差距C 建立組織的能力關鍵任務與流程正式的組織機構人力 技能及文化四 績效評估A 財務評估B 風險分析總結整體風險評估風險管理計劃 五 運作子計劃A 集成營銷宣傳子計劃B 技術支持子計劃C 分銷渠道管理子計劃 納入到年度業務計劃 Page58 典型的路標規劃的內容包括以下部分 V版本啟動時間 生命周期及主要特性 R版本啟動時間 上市時間及主要特性 每個V版本及R版本的技術需求計劃 每個V版本及R版本的人力資源需求計劃 每個V版本及R版本的投入產出分析 產品線1 平臺產品11 平臺產品12 平臺產品13 產品線 平臺產品 主版本Version 產品 子版本Release 納入到產品路標規劃 Page59 案例分析 某公司軟件產品管理部正在制定網絡數據管理平臺未來的版本路標規劃 需求數據庫中顯示 在對客戶進行調查時 客戶提出需要 數據加密上傳功能 產品經理李明在分析時建議在下一版本增加這項功能 在路標規劃討論時 項目經理王磊提出 客戶上網帶寬小 文件又大 傳輸等待時間長已經打擊客戶使用平臺的積極性了 如果再對數據進行加密上傳 勢必進一步降低傳輸速度 這樣雪上加霜 客戶滿意度肯定會降低 銷售主管趙亮 客戶有一些機密文件 如合同 財務報告等 如果被復制或修改 會造成巨大損失 他們強烈要求高度安全的數據傳輸方式 產品管理部經理陳東偉打斷爭論 問題看起來是在功能方面 實際上是客戶背景資料不清 請問 有多少客戶在工作中主要上傳工程文檔和圖紙 多少客戶主要上傳機密文件 調研專員張兵答道 我們已經了解清楚 主要是商務部和財務部需要上傳機密文件 雖然只有兩個部門 但他們都是重要部門 對是否采用我們的系統有很大的發言權 Page60 案例分析 續 看來客戶確實有加密上傳文件的要求 問題是如果在下一版本增加這項特性 會明顯影響數據傳輸速度 而且會增加較多的開發時間 陳東偉犯愁了 他問項目經理王磊 以你過去對客戶業務的了解 他們過去是如何傳遞加密文件的 王磊 合同一般是書面存檔管理 即使有電子版本 實際流轉時也是用打印件 而且是不允許復制的 財務報表只有幾位高層領導才可以查閱 陳東偉想了想 似乎有了決定 您認為他應該如何決策 Page61 正式啟動項目指導PDT初步市場情況的總結和產品定位對項目提出高層要求和主要指標任命PDT成員 PDT任務書由PMT編制 主要作用是 編制PDT任務書的同時 一般需要根據分發的需求包編制初步的產品包需求列表 與PDT任務書一道作為IPD開發流程的輸入 納入到項目任務書 Charter Page62 分發到正在開發的項目 需求可能在產品開發的任何階段產生 但是OR分發子流程的關注焦點是在前期傳遞到概念階段 在PDCP前 各領域來的需求通過端到端產品包需求模板匯集為未來產品包需求 PDT必須確保他們有關于該產品需求的完整清單他們必須 持續地 依據需求管理電子流更新此清單 確保清單中包含有最近錄入電子流的需求他們必須檢查作為基線的需求是否也被錄入了需求管理工作流這些變更必須進行 即使變更控制尚未引入在PDCP后 新的 改變的需求必須通過PCR流程 從需求到PCR的關聯會安排變更轉化為正確需求的路徑 通過這些關聯確保更新相關需求和產品 Page63 將需求狀態反饋給RMT 需求狀態需求處理結果預期的需求滿足日期擱置 拒絕的原因修改產品包需求需求PCR 需求管理的基本階段 實現 執行 目的執行子流程的目的是將接受的需求納入到產品開發中 給予實現 需求管理流程的主要貢獻是使得實現過程更容易 依賴于 提升接收到的需求質量 保證需求在開發過程中流動時 可以被向前 否則向后進行追溯輸入分發子流程所分發的需求是執行子流程的重要輸入 活動執行子流程的活動遵循IPD流程的開發活動 主要活動有 修正 執行開發計劃 以適應新需求 對項目文檔 要遵從需求變更控制的規則輸出執行子流程的輸出是在產品中實現所分配的需求 供驗證 Page64 Page65 需求管理的基本階段 實現 從客戶的需求到最終研發完成 需求會不斷的轉化和分解例子 乘客對飛機的需求很簡單 更快 更安全 更便宜 Page66 需求管理的基本階段 實現 航空公司的需求會復雜的多飛行控制起飛巡航降落緊急處理航程 油耗 速度 噪音 維修 Page67 需求管理的基本階段 實現 飛機制造廠的需求則極為復雜飛機總成的需求 數千條 發動機的需求 近千條 通訊系統的需求 近千條 控制系統的需求 近千條 Page68 產品包需求實現與系統工程 產品包需求 OR 管理流程 概念階段 計劃階段 開發階段 IPD開發流程 客戶needs wants 理解市場 組合分析 業務計劃 MM 書面標準事實標準 質量屬性DFX 客戶需要 市場需求 內部需求 標準約束 產品包需求 設計需求 系統構架 產品概念 設計規格 模塊設計 功能需求非功能需求 系統工程 Page69 產品包需求的劃分 環保需求 UCD需求 安全性需求 可靠性需求 標準約束 可維護需求 性能需求 其他需求 非功能需求 屬性需求 內部需求包括 可測試性 可制造性 可維護性需求 可用性需求等 這些需求需要通過不斷積累 建立數據庫 形成基線需求 在Charter編制或產品開發流程概念階段選擇確定 分為功能需求 非功能需求 分為市場需求 內部需求 Page70 產品包需求的樣例 產品包需求A 提供業務端口報文的統計功能 某網絡安全設備 產品包需求C 主機業務軟件要實現系統不間斷補丁功能 某大型電信網絡設備 產品包需求D 提供軟件調試 支持debugmonitor和DSU調試模式 某RSIC嵌入式處理器芯片 產品包需求B 減輕臂架自重 載荷能力提高20 某機械設備 產品包需求E 提供測試報告的自動生成與保存 某性能測試工具 Page71 高質量產品包需求的標準 產品包需求 可行性 明確性 一致性 可驗證性 完整性 有 殺手锏 Page72 做法1 主要由PMT RMT負責PMT RMT在編制Charter時進行產品包需求分析 規整 輸出初始的產品包需求 關注客戶的價值需求 Charter后 由PDT SE MKPDT等 細化并補充其它需求 零散需求后 并經RMT評審后 輸出完整的產品包需求 做法2 主要由PDT SE MKPDT等 負責PMT RMT在編制Charter時主要關注高層次產品包需求 問題 特性 輸出包特性列表 Charter后 由PDT SE MKPDT等 進行產品包需求分析 經RMT評審后 輸出完整的產品包需求 誰來完成產品包需求定義 Page73 舉例 項目任務書開發流程 CDP 做法1 編制Charter時的需求分析 Page74 CDP和IPD之間的工作界面 Charter開發團隊向PDT傳遞的產品包需求要分層描述 必須包括客戶問題 系統特性 系統需求及其各層之間的跟蹤關系 Charter開發團隊依據產品包需求架構 重點關注與投資決策相關的關鍵價值需求 在charter匯報時交付初始產品包需求 PDT對Charter開發團隊移交的初始產品包需求 依據產品包需求架構對其他未納入的需求進行完善 并對產品包需求基線化 Charter開發團隊與PDT 以及各級組織 如Marketing和研發 應遵循產品包需求架構進行需求管理職責的分工與協同 Page75 做法2 PDT完成產品包需求分析 包特性 針對外部客戶 PMT 需求專家負責 測試需求測試專家負責 制造需求制造專家負責 服務需求服務專家負責 產品包需求SE LPDT負責 整合 折衷 Charter Charter包特性列表 舉例 Page76 形成產品包需求列表或說明書 需求編號領域需求標題需求描述必須的功能優先級改進目標衡量需求帶來的利益 產品包需求 Page77 需求管理的基本階段 實現 包需求 軟硬件規格 設計規格 軟硬件規格 軟硬件規格 設計規格 設計需求 轉化 轉化 SE主導 MKPDT等參與 RMT評審 SE指導 各專業組及工程師負責 端到端的需求跟蹤和變更管理成為必須 采用系統工程方法將產品包需求分解為設計需求 設計規格 需求管理的基本階段 驗證 目的驗證子流程重點關注于實現需求后的需求驗證 是對產品決定性的驗證和確認 此外 該子流程生成了吸取的經驗教訓 在需求管理流程 收集子流程 中收集 將來傳遞給PDT 輸入所執行的需求是驗證子流程的輸入 活動主要的活動有需求驗證和確認 作為開發流程的一部分 通過系統測試進行需求驗證 通過用戶接受性測試進行需求確認輸出驗證子流程的輸出是驗證 確認了所執行的需求 Page78 需求管理的基本階段 驗證 備注雖然驗證子流程是端到端需求管理流程中的最后一個子流程 但它并不是一項單獨的活動 它實際上是IPD流程所管理的開發活動的一部分 需要重申的是需求驗證活動可以在開發周期內的任何時間進行 實際上 提早驗證 確認需求是一種可靠的做法 可以準確地了解需求 新成立的PDT可以在IPD的概念 計劃階段同目標對象 客戶 召開需求驗證會議 然而 這需要平衡所需要的努力 時間與追求的潛在價值間的關系 Page79 Page80 需求管理的基本階段 驗證 并不是一個嚴格意義上的階段 而是貫穿整個需求演化 分解 實現的一系列質量保證活動 包括 評審 測試等 客戶所需 原始需求 包需求 設計需求 設計規格 測試 GA Page81 RAT 需求管理的基本階段 驗證 RAT代表客戶參與各TR點評審 TR1 TR2 TR3 TR4 TR4A TR5 TR6 Page82 端到端需求變更必須同步 如何保證變更鏈的同步 總部RAT 客戶 想法變了 一線 項目取消 一線 環境有變 市場一線 總部 策略調整 研發 技術困難 研發 人力不足 公司總部 Page83 目錄 需求和包需求介紹客戶需求管理流程需求管理的基本階段銷售項目需求管理需求管理組織結構需求質量管理客戶 APPEALS設計產品包需求分層模型需求管理電子流 Page84 銷售項目需求管理 隨著業務拓展的加快 因需求處理不當導致了很多嚴重的問題案例 合同取消 市場拓展 草率承諾曲解客戶需求未深入分析可行性需求傳遞遺漏 失真對待合同文本不嚴肅 滿意度下降 交付困難 賠款 Page85 銷售項目需求管理 為何會出現這些問題 最終導致上述各種問題 投標人員不具備專業的需求分析答復能力 Page86 銷售項目需求管理的總體原則 需求承諾的接納處理責任主體是各區域RMT 今后各PDT無權接受來自公司各行業部 國際國內銷售體系 包括銷售部及各辦事處 技術服務體系 包括公司及各辦事處技術服務部 等各部門直接反饋的需求 所有需求承諾必須錄入到客戶需求 承諾電子流 以規范的方式傳遞給RMT 郵件 電話 傳真等方式只可以作為必要的溝通手段 所有需求的對外答復必須以面向市場發布的產品功能清單 也包括市場技術指導書 業務簽單附件等 為基礎 對于功能清單未包括的需求 必須經過RMT給出答復口徑 才能對外答復和承諾 凡未經RMT批準的答復和承諾 各產品線不承擔提供的責任 發生任何客戶投訴時 由辦事處自行負責 Page87 Page88 銷售項目需求管理 RMT RAT PDT RMT RAT 各CCM 產品營銷部研發總部其它代表 產品營銷部行業部 Page89 重大銷售項目需求管理 方法 RAT初選RMT評審以分析報告形式提交 Page90 需求爭議解決機制 RMT RAT團隊達成一致 PMT審核 IPMT決策 IRB決策 日常需求處理 重大需求決策 Page91 需求快速決策通道 長期議而不決的需求 Page92 目錄 需求和包需求介紹客戶需求管理流程需求管理的基本階段銷售項目需求管理需求管理組織結構需求質量管理客戶 APPEALS設計產品包需求分層模型需求管理電子流 Page93 需求管理涉及的角色 按需求的處理順序 涉及的角色有 收集 分析 分發 實現 驗證 Marketing 銷售人員 技術服務 研發 UCD專家 OM專家 法律法規專家 標準化研究專家 其余員工CCM RMT RAT IRB IPMT PMT RMT RAT PDT 需求收集者 需求分析者 實現者 Page94 需求管理的組織結構 PL PMT PL RMT CCM RAT RAT CCM CCM Page95 目錄 需求和包需求介紹客戶需求管理流程需求管理的基本階段銷售項目需求管理需求管理組織結構需求質量管理產品包需求分層模型需求管理電子流 Page96 需求質量管理 需求確認需求提交質量標準需求答復質量標準 Page97 需求質量管理 需求確認 需求確認做正確的事與客戶交流我司的解決方案 確保雙方理解無遺漏 無偏差不是所有的需求都需要確認PDCP前至少要做一次需求確認 Page98 需求質量管理 需求確認執行過程 RMT RAT評審哪些需