Liga妙談 | 如何快速甄別、高效響應使用者反饋?

語言: CN / TW / HK

敏捷開發說要「擁抱變化」,在充滿不確定的環境中,唯一不變的正是變化。面對源源不斷的市場反饋和需求變更,敏捷團隊應該如何平衡「高效迭代」與「響應使用者」的關係,既快又好地完成研發任務,交付業務價值?

12 月 21 日,LigaAI 特別策劃了「敏捷三人行」直播活動,與優普豐首席敏捷教練申健、樂豆資訊 (Beansmile) 創始人杜立剛 (Leon) 一起探討、分享並總結了快速識別高價值反饋、高效響應使用者需求的經驗之道。直播全程高能,金句頻出,下面就隨 LigaAI 一起回顧精彩內容吧!

01 找準「話語權」,讓事情更順利

主持人:任何形態的軟體產品一旦面世,就會面對各種各樣的使用者反饋。B 端產品和 C 端產品在反饋關注點和處理流程上,都有哪些差異?

👉LigaAI - 張思: 產品釋出上線後,使用者反饋是瞭解客戶的重要渠道。B 端產品和 C 端產品在反饋的處理流程上沒有表現出明顯的差異性,大致環節是「收集 - 整理分類 - 優先順序篩選 - 轉化 - 計劃上線和釋出」。

但從業務特性來看,C 端產品注重打造產品「爽點」,讓使用者獲得極致的使用者體驗。因此,C 端產品的使用者反饋整體呈現更多的個性化和天馬行空,也更符合個人使用者的使用習慣

而 B 端產品的最大目標通常是賦能客戶更加成功,因此使用者反饋更加關注產品對目標企業/客戶的整體價值。它們圍繞業務目標展開,目的性和業務屬性會更強。

👉Beansmile - Leon: 我也贊同思哥的說法。整體看來,B 端產品的規則更明確,處理反饋時閃轉騰挪的空間相對較小;而 C 端產品通常極富創新性,其業務發展和法規監管有更強的探索性

我們之前服務過一個金融行業客戶,同期需要交付 To B 和 To C 兩個產品。B 端產品面向各大金融機構,受到證券、基金投資等行業法律法規的約束,幾乎不太能在規則上探索,研發過程最大要求就是保證功能穩定、資料安全、邏輯正確;

而面向個人理財的 C 端產品有許多內容可以一邊做,一邊調整、逐步完善。相比成熟的 B 端產品,更具創新的 C 端產品可以逐步參考行業頭部企業的做法,總結分析後再製定,這是一個比較明顯的差異。

👉優普豐 - 申導 我也想從決策角度補充一點。C 端產品的購買決策是短決策鏈的個體決策,通過打擊使用者「痛點」和「爽點」,激發使用者為產品和體驗付費的衝動與慾望。

B 端產品的決策複雜度則更高:決策路徑通常很長,而且不同環節的決策負責人通常不一樣,他們的決策影響力也不盡相同。因此只有找到決策鏈上的「關鍵強節點」,識別他們的真正需求,才能讓事情更順利。

主持人:談到決策複雜度,就少不了要提「決策權」。在敏捷團隊中,面對海量的使用者反饋,誰具有對使用者反饋拍板定案的決策權?

👉LigaAI - 張思: 在 LigaAI,使用者反饋的處理通常由產品負責人 (PO) 或者產品經理 (PM) 主導。他們會與客戶成功 (CSM) 夥伴一起,共同評估和分析使用者反饋的具體內容、價值排序,以及同當前目標的整體匹配度,綜合多個因素完成判斷和處理。

👉Beansmile - Leon: 對於純交付類的客戶專案,我們最重要的任務就是找準有決策權和最終影響力的產品負責人 (PO)  。他們通常是企業老闆或者高階負責人,能對產品的投入產出比負責,具有接納或拒絕需求的能力和魄力。

如果是技術入股的專案,我們更注重於維護技術自主權。在挑選合作伙伴時,我們更傾向於選擇 理解技術、願意為技術放權、不干涉技術或研發過程的夥伴,以此避免過程中不合理的時間線或者產品路徑加重研發負擔。

👉優普豐 - 申導 在敏捷開發裡,產品負責人之所以稱為 Product Owner,是因為他們天然要承擔決策拍板權 (Ownership)。

好幾年前,我與朋友一起參加一個 O2O 創業專案。第一次開會面議時,我發現朋友和甲方領導都不太懂技術,於是我花了一些時間跟甲方領導介紹網際網路的玩法和 O2O 產品。領導聽了覺得很不錯,我便乘勝追擊地說:“要不這個產品您就聽我的?”結果對方答應了。這樣,我將原本屬於甲方的決策責任,經過授權,攬到了乙方身上,讓研發過程順利很多

理論上,B 端產品的反饋決策權一般只在(最)高階負責人身上。許多與我們直接聯絡的產品負責人或者專案經理,他們不一定擁有最終拍板權,而找不到專案中真正的「話事人」也會導致專案最終推倒重來。

02 提出反饋的人,往往不清楚自己想要什麼

主持人:剛剛三位都提到使用者反饋過程中產品負責人 (PO) 的重要性。在應對海量的使用者反饋時,PO 該如何透過反饋,洞察真正的使用者需求?

👉LigaAI - 張思 使用者的反饋總是很主觀。想要找到使用者的真實需求,便要求產品負責人對客戶群體、行業模式、具體的消費場景和使用場景有較深的理解 ,才能對充滿隨機性的使用者反饋做出相對準確的判斷

使用者反饋總會指向一個「問題」,傳遞的資訊是「使用者需要什麼」和「希望產品如何解決問題」。產品負責人需要根據已知的資訊,提供一個良好的解決方案。在理解和分析反饋時,一定要深挖問題背後的原因,區分「Want」和「Need」的區別,找到使用者完成目標的路徑中真正「Need」的部分,才能洞悉有效的使用者需求。

具體的做法是,基於對客戶和業務的整體理解,多問自己「為什麼」。產品負責人經過反問和反推,逐步整理出使用者反饋背後更深層的原因;當出現明確的可驗證想法,再進一步與使用者對話,探索更多方案的可行性。

👉Beansmile - Leon 一個很有意思的現象是,很多提出反饋的使用者往往不清楚自己想要什麼,而初級的產品經理則很容易被這些資訊誤導。就像幾乎所有主流的視訊會議軟體都預設帶有視訊美顏功能。儘管沒有使用者會明確指出自己需要美顏,但他們都不會拒絕美顏帶來的更好的視覺效果。

而同樣的功能發生在另一個場景,則完全不一樣。一個受傷的使用者想將傷口拍下,上傳供網際網路醫生診斷,而手機自帶的不可關閉的相機磨皮功能,卻將疤痕完全磨平了。這個場景中,使用者就無法達成自己的目的。

不難看出,想要透過使用者反饋,瞭解背後真正的需求,關鍵在於理解業務、理解場景、理解人性。需求分析人員需要具備相當的同理心和換位思考能力,才能以更真實的使用者視角考慮使用場景,設計出優秀的產品和功能。

👉優普豐 - 申導: 使用者洞察是相對複雜的事情。有的使用者嘴上說的是 A,腦子裡想的是 B,潛意識裡想要 C。中國有句老話,聽話聽音。我自己也一直在研究,如何更好地洞悉人的訴求和意圖。總結下來主要有三點。

第一,學會觀察和傾聽,只有靜下來才能聽進去別人在說什麼。產品負責人不能沉浸在自己的想法世界裡,而是應該在拿出可驗證的產品測試之前,安靜且專注地做好使用者調研,觀察使用者行為,瞭解真實狀態下的使用者表現。

第二,正如 Leon 提到的,關注人性。人性就是最基本的需要,七宗罪、貪嗔痴、酒色財氣這些都是人性。有的使用者反饋和需求為業務服務,也有的僅為了面子工程存在。產品負責人需要在歷練中積攢和沉澱,你必須見識過很多的場景,才能洞察反饋背後反映出來的「真需求」。

第三,借用喬布斯的一句名言:不要聽使用者的,因為他們不知道自己想要什麼。

主持人:敏捷團隊如何通過分工協作,將源源不斷的使用者反饋轉換為迭代中的使用者故事?

👉優普豐 - 申導 「使用者故事」顧名思義是從使用者角度講故事:通過對場景、人物和事件的描述,試圖找出使用者訴求背後真正的、感性的、情緒性的需求意圖。使用簡單的「Who - What - Why」三段式結構,講清楚待完成的特性或功能、背後的價值,以及為什麼要實現這個功能。

國內有一些團隊會僵化地使用使用者故事,認為過去寫 PRD 文件,現在就寫使用者故事文件。這是錯誤的。使用者故事的作用是讓大家交流和思考需求所提的場景裡面有誰,要做什麼以及意圖是什麼。 所以,技術團隊不要著急跳進解決方案裡,要先研究清楚需求意圖,這個特別重要。

使用者故事通過更頻密的對話達成團隊內部的一致,消除不同角色的理解差異。從使用者反饋到使用者故事,一般會使用三個思考框架。

首先是業務問題域的影響力地圖 (Impact Mapping),它可以幫助團隊挖掘原始的需求。具體的做法是,從業務目標開始找到目標使用者,找準用戶痛點和產品價值點,最後為此提供解決方案。

圖片

第二,利用解決方案域的使用者故事地圖 (User Story Mapping) ,將交談中產生的使用者故事拆分、歸類、簡單排期,幫助團隊找到真實需求全貌,並查漏補缺。

圖片

第三是技術實現域的產品待辦列表 (Product Backlog) 和迭代待辦列表 (Sprint Backlog) 。 落到具體的實現層面,就必須有先後順序,所以我們需要待辦列表將排隊過程落地,將地圖式的二維資訊,轉變為列表式的一維資訊。

圖片

👉Beansmile - Leon 與合作方一起挖掘使用者故事時,我們喜歡使用「電影製作」做場景類比。軟體定製研發就像是雙方合作製作一部電影,討論階段就是在研討劇本:故事需要涉及哪些角色、他們分別有哪些故事、需要做什麼、每個角色在具體場景中的使命是什麼……

通過將使用者故事總結、羅列出來後,我們就能將很多細節資訊研究清楚,比如不同角色的管理許可權、不同故事場景的具體操作和限制條件等等。在聊天中,一步步引導合作方「聊」出更多的細節,識別更多的關鍵路徑,後續的研發工作才會順利。

還有一點比較重要,也是敏捷開發裡強調的 「Deploy Early, Deploy Often」——早點部署,頻繁交付。我們發現相比 Staging 環境,部署到 Prod 環境的交付成果,客戶關注得更多。因此,可以早一點將功能放到 Prod 環境裡跑,儘早地讓客戶看到、體驗到實際的產品。

👉LigaAI - 張思 我們在處理小型需求和反饋時,經常使用待辦列表工具進行排期和排序。除了申導提到的三種框架外,LigaAI 團隊還會使用 JTBD 理論 (Job To Be Done) 分析使用者故事。

JTBD 理論指出,使用者使用一款產品,本質上是為了達成一個工作目標。因此,在 LigaAI 團隊中,我們會逐級拆解使用者要實現的「大目標」,及若干個指向最終目標的小工作 (Job) 。這個我們有個標準的協作流程:

圖片

並且在這個流程中,我們和很多 LigaAI 的客戶都用上了 LigaAI 的智慧助理、跨專案流轉等自動化工具。比方說:從提交反饋 - 分析設計 - 迭代排期 - 開發上線 - 使用者通知,全流程通過機器人自動推送、實現無縫銜接;避免了溝通中的資訊差和時間差,讓整個團隊能夠基於對使用者反饋的共識,快速推進迭代開發。

另外,我也非常贊同 Leon 提到的應該「儘早部署,頻繁交付」。LigaAI 團隊在研發過程會使用 MVP (Minimum Viable Product) ,嘗試先將一些 MVP 功能實現交付,讓客戶提前體驗;再根據客戶的反饋意見,做進一步的完善和優化,逐步交付更大的價值。

03 只有變化,是唯一不變的

主持人:今天的三位嘉賓都(曾)是技術團隊的負責人。那麼在管理角度,敏捷團隊應該如何打造積極擁抱變化、快速響應變化的團隊文化?

👉LigaAI - 張思 對任何團隊而言,人都是最重要的。 讓研發團隊適應敏捷,就一定需要打造資訊流通、自主交流的團隊氛圍。 讓團隊內部自然地形成協作的默契,一起擁抱變化,這是團隊建設的大前提。常規的團建活動、內部分享或者非正式會談,都是比較好的低負擔的文化建設手段。

第二,敏捷團隊的管理者需要為團隊提供更多賦能的後勤保障和支援。 在適當的時候,提供敏捷方法論的指導,保障物理層面的需求。

👉Beansmile - Leon 打造擁抱變化和快速響應變化的團隊文化,可以從思維方式和技術操作兩個層面入手。

首先,大家一定要意識到,變化是永遠不變的。尤其是交付型團隊,幾乎沒有任何一個客戶的需求是一成不變的。所以,敏捷團隊要從觀念上接受變化,才能真的擁抱變化

其次, 產品負責人要做好預期管理,包括調節需求、把控進度等想法。不要試圖向客戶傳遞要創造鴻光偉業的想法,儘量將產品預期壓低,務實一些,將研發過程持續維護在可控的範圍內。

比如,通過每日站會將風險粒度最小化、使用量化手段監控成員的工時或者點數、將子任務拆細更清晰地完成過程管理。 只有當可量化的研發工作經受得起每日的定期同步,過程管理才不容易出錯。

風險始終存在,我們不能消滅風險,但是可以控制風險的粒度。在技術操作層面,建立嚴格的 Code Review 標準,應用 CI/CD 等自動化部署工具,介入人工測試等等,也可以在一定程度保障團隊擁抱變化的能力和信心。

👉優普豐 - 申導: 在軟體開發領域,敏捷開發為變化而生。在充滿創造性和探索性的工作中,我們要不斷地驗證,不斷地拿產品說話。擁抱變化也不是一蹴而就的事情,也要在不斷地磨合和迭代優化中,逐步驗證更好的方式。

第二,技術管理者要充分發揮「培養人」的職責,把團隊發展起來。 培養成員的心智、認知領導力和擁抱變化的勇氣,不斷地磨鍊、打造一個更加敏捷的團隊。

中層管理幹部打造自組織團隊的關鍵在於不斷地磨鍊成員,手把手帶領成員成長;而中層管理者的成長則要親自接受市場和客戶的打擊與挑戰,親臨實地地瞭解市場和客戶需求。管理者必須自己經歷風暴,才能快速成長。


隨著組織走向成熟,團隊規模不斷擴大,外部與內部變化也將生生不息,沒有休止。敏捷團隊只有擁抱變化、快速響應變化,才能在變化中找到組織穩步發展的生存之路,否則就會被市場和競爭淘汰。

而在一次次擁抱變化與響應變化的敏捷實踐中,如同優普豐和 LigaAI 般的敏捷踐行者也將持續以更優秀的產品與服務,助力每一位踏上敏捷轉型之路的朋友,成就敏捷。

瞭解更多敏捷開發、專案管理、行業動態等訊息,關注我們 LigaAI@oschina 或點選LigaAI - 新一代智慧研發協作平臺,線上申請體驗我們的產品。