消除假確定性並解決實際問題
很多時候,客戶對他們想要解決的問題提出的是一個“假的確定性”需求。他們可能沒有定義真正的問題需求,而是經常定義解決方案。
風險在於如果將其誤以為需求我們可能構建錯誤的系統。軟體團隊希望能夠探索問題的不確定性,以便建立一個出色的解決方案。當產品所有者與客戶合作定義問題時,然後再與團隊合作定義解決方案,每個人才可以獲勝。
以下是一位產品經理如何學會接受不確定性並建立實際解決問題的解決方案。新來的產品經理保羅開始沒有識別出真正需求,被假需求誤導了,後來才發現真正需求是透過捆綁銷售更多許可證。
讓關鍵隊員在一起
產品經理保羅很沮喪。他之前曾在保險公司工作過,所以他非常清楚他們可能會做些什麼來改變他們賣保險的方式以及賣什麼樣的保險。但他無法讓銷售副總裁同意。
他與銷售副總裁進行了電話會議。銷售副總裁無法與保羅就該團隊應該解決的問題達成一致。保羅認為他們應該關注那些購買更多保險產品的客戶。這意味著改變產品的建議引擎。
老闆認為他們都設定好了建議引擎。他想突出他們的產品高於對競爭對手的特點。
老闆對頁面上的徽標位置感到興奮。他認為這是一個品牌問題。
培訓副總裁希望確保能夠在產品上培訓內部人員和客戶,她怎麼能幫助內部人和客戶意識到他們有更多選擇?
保羅認為老闆沒有明確說明團隊需要解決的實際問題。
首先,保羅自己工作了幾天,試圖寫小故事。但他不明白這項努力的目標。他不再寫故事,於是決定再次與大家見面。
分享問題的不確定性
保羅設法讓銷售副總裁進入會議室,並解決了他對業務成果缺乏瞭解的問題。最初,銷售副總裁似乎對他很惱火:“你不知道你在做什麼嗎?”他們問道。他依然繼續推動,並依次再次詢問他們,“業務將如何從建議的變更中獲益?”
他聽到了下面有關的建議,帶著一點點的嗤之以鼻:
- “我們會增加銷售額”
- “我們將有一個有吸引力的網頁”
- “我們將能夠培訓我們的客戶”
保羅解釋說,他想要一種衡量變革成功程度的方法。“我們怎麼知道我們提出的建議是否有效?”
這個問題困擾了他們。
他們沉默地坐著,思索著。最後,培訓副總裁說:“如果我們能夠及早和經常培訓客戶,他們可能會購買我們想要出售的附加產品。他們可能會鼓勵更多人為他們的組織購買許可證。“
銷售副總裁同意了。“這就是我們想要出售的產品:透過捆綁銷售更多許可證。”
保羅現在瞭解整體業務問題:能夠銷售更多許可證,因為更多的人捆綁了更多的保險。
他向小組重複了這個目標。他們都點了點頭,暗示了一些協議和理解。
分享定義不確定性
現在保羅理解了他們想要解決的問題,他已經準備好與團隊合作來定義和完善這個問題的定義:故事。
他並不喜歡“故事”的概念,儘管他確實喜歡考慮顧客幫助他描述問題的方式。
在過去,保羅已將要求分解為用例。他使用了很多年的用例,並且喜歡他可以創造快樂的路徑和替代路徑。但他並沒有因為不得不像團隊所希望的那樣將用例分開,而是對那些惡劣的使用者故事感到興奮。
他帶著一大杯黑咖啡開始工作。使用VPs對問題的定義,他寫了一系列用例。幾個小時後,他帶著一堆卡片離開了辦公室,準備好在早上送給團隊。
分享答案不確定性
第二天早上,保羅帶著同樣大的咖啡坐下來與團隊一起向總裁提出問題。
他沒有討論他是如何與團隊達成這些答案的。當他解釋,他聽到了這些擔憂:
- “好吧,這永遠不會奏效”
- “這是不可能測試的”
- “這不符合我們的架構,所以它不會起作用”
- “這些故事或案例或其他任何你想稱之為甚至可以解決問題的方法?”
每個團隊成員一直在研究該產品至少兩年。然而,保羅只在這個組織工作了六個月。團隊成員對產品和客戶更加熟悉。
從需求不確定性轉向實驗
保羅很累,很沮喪。他問團隊,“那麼,你會做什麼呢?”
其中一位資深開發人員表示,“讓我們考慮實驗,這樣我們可以從我們的副總裁那裡獲得反饋。我認為你已經用你擁有的資料完成了所有工作,但我認為你沒有足夠的資料。“
其他團隊成員插話。他們建立了一個可能的實驗列表:
- 紙質原型檢查保險包的流程如何運作
- A / B測試驗證徽標定位的有效性
- 在最初的紙張原型之後,收集使用資料長達一週,以檢視訂購保險包的使用者介面是否會對銷售產生影響
他們又做了幾個實驗。當團隊透過假設時,他們發現瞭解決問題的更多機會。例如,該團隊發現訂單有所不同:如果他們以增加的價格顯示附加元件,人們更有可能在其捆綁包中新增更多產品。
沒有全部的答案
我們經常要求產品經理提供所有答案。他們無法知道一切,PO必須依賴解決問題的人。他們可能不是識別問題的專家,但他們是解決問題的專家。
尊重問題識別符號和問題解決者的能力。當每一方都相互尊重時,他們會進行有用的對話並經常做出更好的決定。
提出解決方案既是有功的,但也是創造假的確定性。解決方案一詞意味著確定不存在。
當您向客戶提供解決方案時,您可以圍繞團隊如何解決問題建立共享的確定性。您無法保證團隊將以這種方式解決問題。當你承諾時,客戶相信他們會得到你所承諾的。
當你向團隊提出解決方案時,它會更加危險。當你說怎麼你想有一個團隊來解決一個問題,你妨礙他們的想法和可能性。您可能最終會在團隊建立程式碼時不再需要這樣做。
實際上,在您找到解決方案之前,你只會遇到問題 - 解決客戶問題的工作成品。在此之前,你所擁有的只是一個假設。圍繞假設建立確定性的唯一方法是進行實驗和學習。
偉大的團隊在實驗方面非常出色,這是問題發現的核心。讓他們努力解決你帶來的問題,並告訴他們你尊重他們的想法。而你最終可能會得到一些輝煌的東西。
相關文章
- 區塊鏈的確定性問題區塊鏈
- 減治法解決假幣問題
- 玩遊戲的本質是消除不確定性遊戲
- 公司也說明剩餘41億商票問題解決存在重大不確定性
- 詳解 Flink 實時應用的確定性
- 碼教授問你一些不確定性的基本問題
- PHP+Redis解決實際問題一:訂單限流PHPRedis
- PHP+Redis解決實際問題二:快取擊穿PHPRedis快取
- 工程中實際問題解決兩例——基於C#C#
- 並查集在實際問題中的應用並查集
- 正負消除問題
- 幽默:程式設計中困難的不是解決問題,而是確定要解決的問題 - Paul程式設計
- OOM問題解決實踐OOM
- 編譯rocketmq-console並解決RejectedExecutionException問題編譯MQException
- 確定性推理
- “某寶”支付服務架構演進之路,解決實際問題!架構
- python bottle框架 解決跨域問題的正確方式Python框架跨域
- Servlet3:從根源瞭解並解決編碼問題Servlet
- 以實際情況切入,檢視MySQL複製問題的解決方案MySql
- 智慧數字經營的出現能夠解決哪些實際問題?
- 如何運用TRIZ解決實際問題?這篇文章講的很清楚
- 【docker專欄1】docker解決的實際問題及應用場景Docker
- 順豐慢其實並不是現實問題,做好這兩點可以輕鬆解決
- IT職場:用TRIZ解決實際問題的一般流程是什麼?
- 10倍程式設計師確實存在,並非神話,生產力最高的開發人員正在解決大問題! - payne程式設計師
- Sqlserver並行等待CXPACKET、CXCONSUMER問題的解決思路和案例SQLServer並行
- 解決Ubuntu虛擬機器佔用空間與實際空間不符問題Ubuntu虛擬機
- redis實現分散式鎖---實操---問題解決Redis分散式
- 解決drf_yasg中的SwaggerAPI無法正確分組問題SwaggerAPI
- pyecharts地圖功能,並解決顯示不全或只顯示南海諸島問題解決Echarts地圖
- MFC軟體國際化的幾個問題及其解決方案
- 淺談系統的不確定性與穩定性
- 提問題比解決問題更重要
- 確定性函式改造sql函式SQL
- 移動APP卡頓問題解決實踐APP
- NodeJS 實戰系列:DevOps 尚未解決的問題NodeJSdev
- 「KDOI-06-S」消除序列 題解
- 使用並查集解決的相關問題並查集