Please enable JavaScript.

Coggle requires JavaScript to display documents.

Pro (Requirement (Tips (conference (Facilitated Sessions…

- - - - 方式
        一對一訪談
        團體訪談
        受訪者
        1人
        2人以上
        內容
        受訪者只有一人。
        受訪者兩人以上。
        相較於一對一訪談，團體訪談需要更多的事前準備(例如：建立表格以收集資訊)。
        優點
        即時性高、互動性高
        缺點
        倘若無事情準備，將使得訪談深度與廣度不足。
        無紙本記錄，口說則無憑，若訪談中有重大決議，無相關文件可追溯。
        建議
        訪談常用於初步收集需求，也就是尚未簽約之前，一切仍屬洽談階段
        建議可在訪談後將訪談內容寫在mail上，一則是double check，二則是讓客戶檢視自己的需求。
    - - Facilitated Sessions
        
        當與專案有關的利害關係人(Stakeholders)人數較多時，基於時間考量，我們沒有辦法與利害關係人逐一開會，在有共同目標的情況下，我們將這些人全部聚集起來，從他們之中收集一組共同的需求，這樣的手法即是Facilitated Sessions的應用之一。
        Facilitated Sessions是一種高度結構化的會議方式，所有的facilitated session都有一個可達成的特定目的或結果，Facilitator會在事先設計好一連串的步驟、活動等，並引導所有會議成員參與，透過這樣的方式產出某種結果，而這個結果是所有與會成員都可以了解及接受的。
        Facilitated Sessions特別適用在極具爭議的討論、多方向的溝通、具有複雜利益關係者的情況下。
      - JAD Sessions, Joint Application Development
        
        Joint Application Development (or Design) 簡稱JAD。
        JAD在軟體工業稱為聯合應用發展(或設計)，原本是用於設計電腦系統的開發方式，但也可以被應用在任何的開發過程，是一種召集軟體使用者和開發團隊共同來改善軟體開發的流程，JAD Sessions用於收集需求上與此有異曲同工之妙，藉由不斷召開一系列的會議，讓專案所有相關人員(例如：執行人員、利害關係人、user等)直接溝通，直到需求被文件化
        (白話文：需求被白紙黑字寫下來)及經過同意後，會議才算真正意義上的結束。
        以實務經驗來說，不論運用何種技巧，開會的目的都是為了達成共識，經過協調後，取得一個多方都可以接受的結果，PM在這要做的就是「同步」客戶需求，確認客戶講的就是你想的，你所提供的是客戶要的，降低認知差異，如此才能為專案打下成功的基礎。
    - - 當利害關係人的距離較遠或是人數很多時，問卷會是一個非常合適的工具用以收集需求，不記名的問卷方式，也可以讓user暢所欲言，表達難言之隱，此外也可以將問卷與前面所提的「訪談」及「會議」做結合使用。
    - - 您可以將可行的解決方案、產品等利用製作原型的方式呈現給客戶，讓客戶直接用眼睛看到東西，會比用講的方式更讓客戶有感覺，避免抽象化的呈現方式，運用原型確認需求，將大幅降低認知差異發生的可能性，而客戶也能根據您提供的原型，回饋更精準的資訊給您。
    - - 隱性需求
        
        隱性需求是我們所不知道的需求，客戶可能也不知道、也可能是客戶沒想到、或是客戶忘記提到，這些在實務上都有可能發生，然而影響專案成敗的往往就是隱性需求，PM的工作就是要盡可能的收集需求，將隱性需求顯性化，而這也是上述技巧最重要的目的>>挖掘隱性需求。
      - 顯性需求是我們已經知道的需求
  - - - a.與既有客戶或未來可能的客戶進行訪談或意見調查，將客戶建議的事項視為需求，逐一列出。
        
        收集需求的最佳方式，永遠都是由客戶端獲得。但由於套裝軟體的客戶群並不固定，因此最好能依照應用領域、運用方式、使用頻率、對電腦系統的熟悉程度、地理位置、職位階層等各種客戶特性，區分出多個目標客戶群，然後針對最重要的幾個目標客戶群進行意見調查或訪談。
      - 參考與軟體產品相類似的專案之建議書、功能規格書或需求變更表，將可能成為需求的部份逐一列出。
        
        開發套裝軟體產品最佳的策略，便是以專案養套裝，也就是在開發初期，利用專案收集需求（同時也可獲利），之後再集結這些需求開發出套裝軟體。因此如果公司已有類似的專案，直接拿來參考即可省下不少需求收集的時間。
      - 逐一過瀘類似專案或舊版軟體之客戶問題反應單，思考問題的原因，並將可成為需求的部份逐一列出。
        
        客戶反應的問題中，有一小部份是客戶要求的新功能或功能規格變更，這些問題都意味著客戶的隱藏性新需求。然而在收集需求時，不能直接把客戶要求的新功能直接視為需求列出，而要先去了解客戶提出這項功能的動機與目的。因為客戶在有需求時，往往會先自行想出做法，然後才要求軟體開發商新加功能，此時這項功能已和原來的需求有所差異，若是客戶自行想出來的做法很爛，那麼將它視為需求開發出來的結果，往往便會成為一項雞肋功能（食之無味、棄之可惜）。
    - - 向行銷企劃部或業務部拿取競爭廠商相關資料，找出可成為需求的部份逐一列出。
        
        行銷企劃部在進行市場調查與研究，或業務部在推展業務時，往往都會研究競爭廠商的動態，以及相互間產品的特性。直接找他們拿取資料，最是方便省時。
      - 由競爭廠商公布的產品規格書、白皮書、廣告稿與網站資料，找出可成為需求的部份逐一列出。
        
        由於行銷企劃部或業務部的競爭廠商資料大都已經過分析，未必適於收集需求，因此還是必須直接閱讀競爭廠商的實際產品資料來加以研究。至於有那些競爭廠商，則可從行銷人員與銷售人員處取得，或是經由入口網站搜尋取得。而且只要是與產品目標市場與功能特性有沾上邊的廠商，都應視為競爭廠商加以研究。