專案範疇管理-蒐集需求

蒐集需求
Collect Requirements

定義、記錄及管理利害關係人需要與需求，以符合專案目標的流程。
提供定義及管理專案範疇(含產品範疇)的基礎。

何謂「需求」
․專案必須符合的狀況或能力。
․產品、服務或結果必須滿足特定的協議或其他強制性的規範。
․贊助人、客戶及其他利害關係人可量化及文件化的需要和期望。經詳細敘述、
  分析和記錄，納入範疇基準中，並於專案開始後進行評量。
․為工作分解結構(WBS)，成本、時程及品質規劃，採購的基礎。

蒐集需求從分析專案章程、利害關係人登錄表及利害關係人管理計畫書的資訊開始。

需求種類
․營運需求
․利害關係人需求
․解決方案需求
功能需求，例：產品的特性。
非功能需求，例：產品正常運作所需的環境或品質。
․過渡需求，例：資料轉換及教育訓練需求。
․專案需求
․品質需求



蒐集需求 > 投入

範疇管理計畫書 Scope Management Plan
來源
「規劃範疇管理」流程的產出。
提供資訊
專案團隊需要蒐集哪些種類的需求。

需求管理計畫書 Requirements Management Plan
來源
「規劃範疇管理」流程的產出。
提供資訊
利害關係人需求的定義及記錄。

利害關係人管理計畫書 Stakeholder Management Plan
來源
「規劃利害關係人管理」流程的產出。
提供資訊
利害關係人的溝通需求及參與程度。

專案章程 Project Charter
來源
「發展專案章程」流程的產出。
提供資訊
專案產品、服務或結果的高層次說明。

利害關係人登錄表 Stakeholder Register
來源
「辨識利害關係人」流程的產出。
提供資訊
能提供需求資訊的利害關係人及其對專案的需求與主要期待。

蒐集需求 > 工具及技術

訪談 Interviews
目的
與利害關係人正式或非正式的直接交談來獲取資訊。有助於辨識及定義產品交付標的的特性與功能。
對象
․有經驗的專案參與者
․贊助人
․其他管理者
․領域專家
方式
向受訪者提出預先準備或即興的問題，並記錄其回答有經驗的專案參與者。

焦點團體 Focus Groups
目的
了解利害關係人及領域專家對產品、服務或結果的期望與態度。
對象
․利害關係人
․領域專家
方式
由主持人引導，進行互動式討論。

促進研習會 Facilitated Workshops
目的
將主要利害關係人集中討論來定義產品需求，並定義跨功能需求及協調利害關係人差異。有助於參與者建立信任、促進關係、改善溝通，達成共識。
對象
利害關係人
方式
※聯合應用設計/開發(Joint application design/development)研習會
在軟體業中，將營運領域專家及開發團隊集中在一起，改善軟體發展流程。
※品質機能展開(Quality function deployment，QFD)研習會
在製造業中，用來決新產品發展的關鍵性技術。
․收集客戶需要，即客戶聲音(voice of the customer，VOC)。
․對需要進行篩選和排序。
․為需要設定可達成的目標。
※使用者故事(User stories)
利用簡短文字說明所需的功能。常用於需求研習會及敏捷(agile)方法。
․角色：哪些利害關係人將獲利。
․目標：哪些需要被完成。
․動機：哪些利益被獲得。

集體創新技術 Group Creativity Techniques
腦力激盪(Brainstorming)
一種用來產生及蒐集有關專案與產品需求多種想法的技術。不含投票或排序，但常與其他技術一起使用。
標稱集體技術(Nominal group technique)
經由投票流程來強化腦力激盪的結果，找出最可行的想法，作為下一階段腦力激盪或優先排序之用。
心智圖法(Idea/mind mapping)
將腦力激盪所獲得的想法整合成單一圖表，反應想法間的共同性與差異性，並激發新的想法。
親和圖(Affinity diagram)
對大量意見進行分類的技術，以便審查和分析。此法為 Kawakita Jiro 所提出﹐又稱「KJ 分析」。
多目標決策分析(Multicriteria decision analysis)
經由決策矩陣提供有系統的分析方法，建立風險程度、不確定性及估價等目標，並對多種想法進行評估及排序。

集體決策技術 Group Decision-Making Techniques
一致性(Unanimity)
全部都同意。
過半數(Majority)
超過50%人員同意。(決策人數為奇數)。
最高票(Plurality)
最多票同意即可，就算未過半數人支持。常用於選擇方案多於2種。
獨裁式(Dictatorship)
只由一個人決定。

德爾菲法(Delphi technique)：由專家針對每一輪問卷以匿名方式作答並提供回饋意見，而該意見僅供主持人使用。並經過數輪問卷後，彙整出專家們的共識。

問卷與調查 Questionnaires and Surveys
利用一系列設計過的書面問題，向眾多受訪者快速蒐收集資訊。
使用時機
․眾多受訪者
․需要快速完成調查
․受訪者位置分散
․適合統計分析

觀察 Observations
又稱工作倒影(job shadowing)，由觀察者從外部來觀查營運專家如何執行工作。
由參與觀察者(participant observer)實際執行一個流程或程序，來體驗該流程或程序是如何執行，以便發掘隱藏的需求。

雛型 Prototypes
在實際製造預期產品前，先提供該產品的工作模型，以便即早獲得需求的回饋。
使利害關係人可藉由模型體驗最終產品，而不是以抽象的方式討論需求。
經由模型建立、使用者體驗、回饋收集到修改雛型的反覆循環，獲得足夠的需求資訊，從而進入設計或製造階段。
故事板(Storyboarding)：通過一系列的圖案或插圖來顯示順序或導航。

標竿學習 Benchmarking
將實際或計畫的做法(例：流程和作業)與相對等組織的做法進行比較，以辨識最佳實務(best practices)，產生改善想法，並作為衡量績效的基礎。

系統關聯圖 Context Diagrams
以視覺化的方式描繪產品範疇，顯示營運系統(流程、設備、電腦系統等)及營運系統與人或其他系統(角色)間的互動。
呈現內容
․營運系統的投入及其提供者
․營運系統的產出及其接收者

文件分析 Document Analysis
分析現有文件，辨識與需求相關的資訊，進而發掘需求。
文件來源
營運計畫，市場文獻，協議，需求建議書(RFP)，現行流程，邏輯資料模型，
營運規則資料庫，應用軟體文件，營運流程或介面文件，
使用案例(Use cases)，其他需求文件，問題/議題記錄，政策，程序，
法規文件(例：法令、準則、條例)。

蒐集需求 > 產出

需求文件 Requirements Documentation
需求必須明確(可衡量及測試)、可追蹤、完整、一致，並為主要利害關係人所接受，才能作為基準。文件內容如下：
營運需求
․可追溯至營運或業務目標
․執行組織的營運
․組織的指導原則
利害關係人需求
․對組織其他領域的影響
․對執行組織內部或外部單位的影響
․對利害關係人溝通及報告的需求
․可追溯至營運或業務目標
解決方案需求
․功能性及非功能性需求
․技術及遵循標準需求
․支援及教育訓練需求
․品質需求
․報告需求(文字或模型)
專案需求
․服務水準、效能、安全及遵循
․允收準則
․過渡性需求
․與需求相關的假設事項、依賴性及限制因素

需求追溯矩陣 Requirements Traceability Matrix
連結產品需求從其來源至滿足需求之交付標的的一種表格。
將需求與營運目標或專案目標聯結，確保需求都具商業價值。
提供在專案生命週期中追溯需求的方法，確保被核准的需求在專案結束時都能交付。
提供管理產品範疇變更的架構。
需求追溯內容
․營運需要、機會、目的及目標
․專案目標
․專案範疇/工作分解結構(WBS)交付標的
․產品設計
․產品開發
․測試的策略及環境
․由高層次需求至細部需求


---------------------------------------------------------------------------
參考資料
專案管理知識體指南 第五版(PMBOK® Guide Fifth Edition)
---------------------------------------------------------------------------
相關文章
張貼者：
標籤： , , ,

沒有留言 :

張貼留言

訂閱： 張貼留言 ( Atom )