編輯導語：智慧客服機器人在日常生活中已經運用得愈發廣泛。本文結合智慧客服機器人需求調研例項，對需求設計研發進行了延伸。
在上一章《智慧客服機器人的需求與定位運營（1）》中，我們提到了優秀的智慧客服機器人需要滿足機器人所有服務干係物件的需求，並能在這些需求中達到平衡。本章我們將結合一些智慧客服機器人需求調研的例項，探討需求調研工作的實踐方法。
一、指令碼設計1. 調研指令碼設計方法開場白
設計一段開場白營造氛圍，打消被調研者的顧慮，使其樂於回答後面的調研問題。
措辭
由於不同的字眼會對被調研者產生不同的心理影響，因此往往看起來差不多的問題，會因措辭不同而使應答者做出不同的反應和不同的回答。故提問時所用的字詞必須非常小心，以免造成誤解，影響答案的準確性，甚至因措辭不當造成被調研者的反感。
一般來說，在設計問題時應留意如下幾個原則：
1）避免一般性問題
調研的本來目的是獲取某種特定資料，如果問題過於普遍化、一般化，就會使應答者所提供的答案資料無太大意義。例如，想要詢問客戶對於某個場景的應答方式是否滿意，因而進行以下詢問：
您對發票場景下線上機器人的回答是否滿意？
這樣的問題，顯然有欠具體。由於回答涉及準確和閱讀體驗兩個層面，故應該分別詢問：
你對發票場景下線上機器人回答的準確度是否滿意？/ 你對發票場景下線上機器人應答的知識內容形式或知識互動形式的體驗是否滿意?
注意：需要註明什麼是知識內容形式，如文字還是動圖；什麼是知識互動形式，如一問一答還是多輪對話。
2）問卷的語言要口語化，符合人們交談的習慣，避免書面化用詞，儘量降低交談的知識門檻，即要區分訓練師/AI產品用語與客戶理解用語。例如，多輪對話這專業用語，沒有相應知識背景的使用者是無法理解的。
3）確保專業術語的一致性，由於每個被調研物件的知識儲備不同，在涉及專業知識概念時，需要先進行解釋，確保調研雙方理解的一致性。這裡的專業術語解釋與口語化並不衝突，核心是確保被調研者理解的一致性。
4）要防止誘導性、暗示性的問題，以免影響被調研者的思考。
順序
指令碼的開頭重在啟發被調研者使其不受拘束，能充分發表自己的見解，使調研者與被調研者之間的陌生距離自然縮短。
不過要留意，最初安排的開放式問題必須能夠較易回答，不可具有高敏感性的問題。否則一開始就被拒絕回答的話，之後的問題就難以繼續了。被調研者的基礎資訊和敏感資訊若是未知，可嘗試將此類問題放置在問卷的後半段，若已知可在調研結束後整理調研資訊時新增。
結構
指令碼的一般結構包括標題、說明、主體、編碼號、致謝語和調研記錄等。
1）標題。每份指令碼都有一個研究主題。調研者應開宗明義定一個題目，反映這個研究主題，使人一目瞭然，增強填答者的興趣和責任感。
2）說明。指令碼前面應有一個說明。這個說明可以口述也可以是一段文字描述，說明這次調查的目的和意義，填答問卷的要求和注意事項，下面同時填上調研單位名稱和年月日。
問卷說明主要包含如下內容：
- 問卷開頭主要包括引言和註釋，是對指令碼的情況說明。
- 引言應包括調查的目的、意義、主要內容、調研的組織單位、調查結果的使用者、保密措施等。其目的在於引起受訪者對填答問卷的重視和興趣，使其對調查給予積極的支援與合作。
- 引言一般放在問卷的開頭，篇幅宜小不宜大。訪問式問卷的開頭一般非常簡短：自填式問卷的開頭可以長一些，但一般以不超過兩三百字為佳。
3）主體。調研指令碼的主體是調研內容的具體化，是指令碼的核心部分，包括問題和答案。從形式上看，問題可分為開放式和封閉式兩種，一般封閉式問題放置在指令碼前端，開放式問題放置在指令碼末尾。
4）編碼號。設定編碼號的目的是要保證調研指令碼及內容輸出的唯一性，便於調研機構管理。
5）致謝語。致謝語是為了真誠表示對調研物件合作的謝意。
6）調研記錄。調研記錄的作用是用以記錄調查的完成情況和需要複查、校訂的問題，調研者需要詳細記錄調研過程中的所有內容，包括調研過程中新發現的問題，將新問題歸檔至待解決事項中。
工具
在調研工作中，一般需要準備得力的記錄工具，包括膝上型電腦、筆記本、錄音筆等。
2. 調研指令碼設計注意事項調研指令碼設計一方面依賴於科學的指導，一方面也來自於訓練師們和AI產品的工作經驗。所以，在指令碼設計過程中訓練師們需要不斷思辨，以提高自身設計能力，確保調研目標的達成。
設計原則
1）調研要有明確的主題，根據主題從實際出發擬題，設計的問題應目的明確，重點突出，不要有模稜兩可的問題。
2）調研指令碼應結構合理、邏輯性強。調研表中問題的排列應按照一定的邏輯順序，符合應答者的思維程式，一般是先易後難、先簡後繁、先具體後抽象。
3）語言通俗易懂，避免使用專業術語，使調研者與應答者一目瞭然，並意如實回答。問卷中語氣要親切，符合應答者的理解能力和認識能力，對敏感性問題採取一定的語言技巧。問卷整體具有合理性和可答性，避免主觀性和暗示性，以免答案失真。
4）問卷的長度合適，回答問卷的時間應控制在20分鐘左右，問卷中的問題應仔細斟酌，既不浪費一個問題，也不遺漏一個問句。
5）收集的資料應便於校驗、整理和統計。
問答形式
每份指令碼設計完成，在使用過程中訓練師應該實時反思被調研物件回答的內容的準確性。準確性體現在兩個方面：一是答案的準確性，確保每個問題的答案是準確的；二是回答形式的準確性，謹記需要排除那些似是而非的回答。
問題形式可分為三種：開放式、封閉式、量表評分式。
開放式問題又稱為無結構的問答題，即引導受訪者自由回答問題；封閉式問題又稱有結構的問答題，即提前給出回答範圍和固定回答格式，要求受訪者在一定範圍中進行作答；量表評分式問題涉及的內容稍複雜，需要根據整體指令碼中不同的問題內容設定不同權重，讓受訪者依次作答，最終統計出得分。
調研指令碼例項參考
二、需求開發與管理需求調研的目的是透過調查與分析，獲取使用者需求，明確智慧服務價值鏈之上的各類使用者他們最期望的線上機器人是什麼樣的，並根據客戶需求定義智慧服務產品的需求，以及智慧服務產品的定位。
完成需求調研後，需求的轉化至關重要。因為客戶很多時候不能準確說出他們的真實需求。
有調研表明，一線客服的普遍需求是一個能夠提高服務效率的工具，在進行深度訪談後才發現客服的痛點是KPI要求下很難花費時間去瀏覽之前客服的服務記錄，轉化為系統需求是系統能自動結構化整理客服歷史聊天記錄，能讓客服在最短的時間內瞭解客戶在上一通服務中的主要內容。
訓練師尤其是訓練師團隊負責人或者是AI產品經理，需要額外注意需求轉化與分析、管理、開發的過程。這個過程又可分為需求開發與需求管理，它們是相輔相成的兩類活動，並共同構成完整的需求工程，如圖1和圖2所示：
需求管理工程框架-圖1
需求開發與需求管理-圖2
1. 需求開發需求開發可分為使用者需求調研和產品需求定義兩個階段，而需求分析則貫於上迷兩個階段。需求調研階段和需求定義階段在邏輯上存在先後關係，實際作中二者通常是迭代進行的。
產品需求定義
完成需求分析後需要對具體的需求進行詳細的定義，即根據需求調查和需求分析的結果，進一步定義準確無誤的產品需求，產生“產品需求規格說明書”，訓練師負責人員將依據“產品需求規格說明書”聯合研發團隊開展系統設計工作。
“產品需求規格說明書”的主要內容包括：
- 產品介紹；
- 描述使用者群體的特徵；
- 定義產品的範圍；
- 闡述產品應當遵循的標準或規範；
- 定義產品中的角色；
- 定義產品的功能性需求；
- 定義產品的非功能性需求，如使用者介面、軟硬體環境、質量等需求；
訓練師團隊負責人邀請同行專家和使用者（包括客戶和終端使用者）一起評審“使用者需求說明書”，盡最大努力使“使用者需求說明書”能夠正確無誤地反映使用者的真實意願。
① 結構化分析法是一種軟體開發方法，一般利用圖形表達使用者需求，強調開發方法的結構合理性及所開發軟體的結構合理性。
② 面向物件分析法是使用者需求調研。需求調研的目的是透過各種途徑獲取使用者的需求資訊（原始材料即調研問裝併產生“使用者需求說明書”）。
需求分析
需求分析是針對各類使用者調研問卷而產生的，目的是對各種需求資訊進行分析，消除錯誤，刻畫細節等。需求分析是在需求開發過程中，對所獲取的需求資訊進行分析，及時排除銷誤、彌補不足，確保需求文件正確地反映使用者的真實意圖。需求分析是需求開發過程中“最費腦子”的工作。
分析方法大體有兩類：“問答分析法”和“建模分杯法”。前者為常識性分析方法，簡單易用；後者技術性比較強，大多數軟體工程書籍都有相關操作流程及論述。
1）問答分析法。該方法即創根究底問問題，如果解答了這些問題，那麼需求也就分析清楚了。進行問答分析最重要的是瞭解“是什麼”和“為什麼”，目的是獲得正確、清楚的需求。每個需求都應當用陳述句說明“是什麼”，如果“是什麼”的內涵不夠清晰，則應補充說明“不是什麼”。如果“是什麼”和“不是什麼”都不能夠清楚地表達原因，那麼還應當解釋“為什麼”，以便加深讀者的理解。
常見的問題有：
- 需求存在歧義嗎？
- 需求文件的上下文有矛盾嗎？
- 需求完備嗎？
- 需求是必要的嗎？
- 需求可實現嗎？
- 需求可驗證嗎？
- 需求的優先順序確定了嗎？
2）建模分析法。建模是圖形化常用的一種方式，建模很多時候不是單純地 使用圖形來表達需求，而是使用模擬模型的方式將需求最逼真地刻畫出來，如一個工廠想要生產黑白兩種鬧鐘，為了讓使用者更加清晰地看到鬧鐘，就將鬧鐘的圖片擺在使用者面前讓使用者自由選擇，絕大多數使用者都選擇了白色鬧鐘，但當鬧鐘實際生產出來以後，情況發生了變化，使用者都轉向選擇購買黑色的鬧鐘。
這是因為實物可以觸發視覺、觸覺等多個感官，所以建模的本質不是用圖形代替文字，而是將產品最逼真地刻畫出來，讓使用者能夠真正感知實物，從而保證需求到開發之間轉化的正確性。訓練師和產品運營對於建模的使用要結合具體情況，對於某些容易產生誤解的問題，採用建模。對於常識性的，不存在理解認知不一致的需求採用需求文件的方式。
建模分析方法有一定的技術門檻，傳統建模分析方法主要有兩大類:結構化分析法和麵向物件分析法。在實際工作中，往往也可以採用PowerPoint、Axure RP、visio等視覺化軟體完成需求的建模。
在需求建模過程中，需要注意恰當地使用圖形符號，保證需求描述的準確性，無論什麼方法只要能夠讓人明白你的需求描述，那就是好的建模。在需求規格說明書中，文字描述是第一重要的，建模主要起分析、解釋的作用。確定需求或者業務的角度，按照面向物件的思想來分析業務。
3）Axure RP是一款專業的快速原型設計工具，讓負責定義需求和規格、設計功能和介面的專家能夠快速建立應用軟體或Web網站的線框圖、流程圖、原型和規格說明文。
需求管理
需求管理主要是對需求的確認。
AI訓練師團隊與所有智慧客服機器人設計研發人員共同對需求文件進行評審，雙方對需求達成共識後做出書面承諾。需求評審成功後的管理跟蹤也非常重要，透過比較需求文件與後續工作成果之間的對應關係進行需求跟蹤。可使用正向跟蹤，即檢查需求文件中的每個需求是否都能在後續工作成果中找到對應點：逆向跟蹤，即檢查設計文件、程式碼、測試用例等工作成果是否都能在需求文件中找到出處。可建立與維護需求跟蹤矩陣，如圖3所示。
矩陣單元之間可能存在“一對一”“一對多”或“多對多”的關係。由於對應關係比較複雜，最好在表格中加入必要的文字解釋。
需求跟蹤表-圖3
三、小結智慧客服機器人系統研發過程中，AI訓練師團隊負責人或者是智慧客服運營需要額外注意需求跟蹤矩陣的變化情況，用於確保智慧客服機器人開發結果與其設計目標之間的一致性。
因為智慧客服機器人的開發是一個動態執行的過程，在這個過程中需求的變動時有發生，需要進行需求的變更控制，具體可以依據“變更申請一審批一更改一重新確認”的流程處理需求的變更，應確保需求的變更不會失去控制而導致在智慧客服器人研發過程發生混亂。當需求文件或後續工作成果發生變更時，要及時更新需求跟蹤矩陣。
本文由 @F 原創釋出於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自 Unsplash，基於 CC0 協議