1樓：易觀數科
在定義並找到自己產品早期使用者畫像之後，我們就需要識別出這些早期使用者未被滿足的需求，以此確定產品的切入點。
一般在描述使用者需求時，我們習慣使用使用者故事（User Stories）來描述使用者的想法，方便我們站在使用者角度來審視需求本身。
乙個好的使用者故事通常遵循這樣的格式：
1.我是「某種使用者型別」，
2.我希望「做某件事情」，
3.從而使我「得到某種期望的收益」。
比如，我是一家電商公司的某品類運營主管，我希望每天能夠實時了解品類的銷售情況，並能夠被告知銷售異常的 SKU，而不是需要我自己來分析資料，從而使我能夠快速制定優化策略。
由此你會發現，完善並且符合敏捷思想的使用者故事，都是從使用者的角度來編寫的，使用者得到的收益代表著價值交換，使用者希望通過在產品上投入的時間成本來換取對應的解決方案。通過盡可能的描述出使用者期望獲得的價值，我們可以相對客觀的來衡量產品日後的功能表現，所以，在明確了一系列的使用者故事之後，我們需要再次和使用者進行驗證，以保證描述沒有任何偏差。
在同使用者進行使用者故事驗證的過程中，我們可以通過一系列有技巧的提問，來驗證該故事是否完善並清晰地描述了產品的潛在價值：
1. 你是否理解這個故事所表達的含義？
2. 這個解決方案對你有多大的幫助？
3. 假如有乙個產品能夠提供類似的價值，你覺得對於你來說，這個產品的價值如何？
4. 為什麼你覺得它有價值或沒有價值？
通過一系列的問題，可以幫助你判斷是否在用一種清晰的方式向使用者描述產品價值，同時了解使用者的真實想法以及背後的原因。下一步，我們就可以將驗證後的結果總結為下表，幫助我們選擇產品的切入點。
在我們同使用者明確了他們的需求之後，下一步我們需要針對這些需求進行機會評估。
如下圖，我們將產品機會劃分到 4 個不同的象限，在這個象限中，橫軸代表使用者對當前解決方案的滿意程度，縱軸代表需求的重要程度，由此我們可以發現，產品的目標在於滿足對使用者而言重要且當前解決方案滿意度較低的需求。
1.需求重要程度高，當前解決方案滿意度高：意味著這是乙個高度競爭的產品空間；
2.需求重要程度高，當前解決方案滿意度低：產品機會；
3.需求重要程度低，當前解決方案滿意度高：使用者價值有限且產品新機會較低，不值得投入；
4.需求重要程度低，當前解決方案滿意度低：因為重要程度低，即使再優秀也無法創造更多的使用者價值，不值得投入。
在對需求進行機會評估的過程中，我們當然不能根據感覺來決定，需要採用定量測量的評估手段，下面簡單介紹下如何通過調研的方式將需求的滿意程度和重要程度進行定量評估。
在前面，我們已經將客戶的需求和現有的解決方案整理完畢，那麼我們需要通過提問的方式來直接獲得使用者對於現有方案的直觀感受。
對於重要程度，我們可以試圖讓使用者在以下選項中選擇：
1. 一點都不重要；2. 不怎麼重要；3. 一般程度重要；4. 很重要；5. 極其重要
對於滿意程度，我們可以設計如下選項：
1. 完全失望；2. 大部分時候都是失望的；3. 有些失望；4. 中規中矩；5. 還算滿意；6. 大部分時候都是滿意的；7. 非常滿意
在測量滿意程度和重要程度的過程中，可以採用 5 分制或 7 分制，但是在測量滿意程度的時候可以採用負分制，代表使用者的不滿；最佳實踐是在重要程度測量中使用 7 分制，在滿意度測量中使用 5 分制，如上面提到的測量方法。
當我們獲得了使用者的評分後，我們就需要來正確評估乙個需求的潛在機會，通過【機會潛力 = 重要程度 x （1 - 滿意程度）】這個公式，可以定量地估計每個需求的潛在機會，並將它們合理的分布到對應的象限中。比如：
1.機會 A 的潛力分 = 70% -（1 - 40%）= 0.1
2.機會 B 的潛力分 = 75% -（1 - 30%）= 0.05易觀方舟Argo。
2樓：CCGI
故事點這個概念大家應該很了解了，實際上就是對在sprint裡面要開發的user story進行乙個粗量級的估算，以便於團隊能夠知道這個user story的複雜度（工作量），但是這裡有個容易引起混淆的地方，就是傳統意義上的敏捷，是用來度量規模和複雜度。
使用『規模』和『複雜度』這兩個詞，是要表達『用完成任務所需時間來表示難度』。
從上面可以看出，由於故事點是對於規模和複雜度的估算，所以，第一它是乙個不精確的值，第二，它應該是乙個相對的值。由此來看，故事點是乙個粗略的相對估算而不是精確估算。
1故事點的估算目的是什麼呢？
作為PO來講，他在梳理ＰＢＩ和ＳＢ的時候，可能是想知道團隊多久能交付產品，每個迭代能夠交付多少使用者故事，所以故事點可以解決ＰＯ的這個困惑。我們可以通過估算故事點，然後統計多個迭代團隊交付的故事點數，以此相對的得到乙個團隊的交付能力，比如說每個迭代交付２０個點的使用者故事，那麼如果PO有乙個由100點使用者故事組成的產品，那麼可以得知5個迭代完成這個任務。
也可以得到團隊的交付速率和交付能力的歷史資料，用來進行團隊回顧的資料依據。
在估算的過程中，因為所有團隊成員都要參與，大家對於故事的理解不一樣會造成估算的不同，這樣就需要PO和團隊成員之間進行需求的澄清，也是乙個分析使用者故事需求和澄清的過程，能夠讓大家更好的理解使用者故事。
2故事點的估算的到底是工作量還是複雜度？
在實際開發環境中，大家往往會有乙個理解上的難點，到底故事點估計的是工作量還是複雜度呢？
從PO角度來講，肯定需要得到的是工作量，這樣也能第一時間知道產品開發的進度還有風險，但是如果估計的是工作量的話，和實際開發的人是有關係的，因為同樣乙個特性，對於熟練工和新手的工作量是完全不同的。
如果只是作為複雜度來估計的話，那麼產生的問題是：產品開發的複雜度在不同團隊和不同人員之間也是不一樣的，而且在現實開發環境中，對於複雜度的操作很難進行，有的時候大家會覺得費時費力。
從我個人來講，在敏捷不斷演進的過程中，現在故事點實際上是乙個綜合的對於使用者故事的複雜度，規模，甚至還要加上承諾時間的乙個度量了。
也就是說團隊可以不必過度糾結在使用者故事的度量上，而是重點放在當前迭代裡能否按照該使用者故事的接收條件和團隊定義的ＤｏＤ來完成這個使用者故事，如果不能完成，給出理由，由ＰＯ來決定是否拆分或者重新設計使用者故事。
這樣帶來的乙個問題可能是ＰＯ在梳理ＰＢＩ的時候無法得知整個產品的全部完成時間，因為團隊的歷史交付資料可能不是乙個穩定的速率（每個ｓｐｒｉｎｔ交付的點數差別會比較大，因為更注重使用者故事本身和交付承諾）
3怎樣在計畫會議中更好地運用故事點估計？
如果是乙個新的團隊，那麼建議針對使用者故事進行估點，這樣能夠使得團隊盡快熟悉起來，澄清需求，建立很好的溝通機制。
如果是乙個很成熟的團隊，對於產品比較熟悉，那麼這個時候故事點估計就不是十分必要了，因為大家都很熟悉產品特性，所以對於所需的工作量也是相對準確的，這個時候可能就需要團隊給出工作量的估計，讓ＰＯ對於產品的開發更好地進行進度和風險控制。
如果可能的話，針對不同的使用者故事型別設計不同的基準故事點，比如說開發的故事基準和測試的故事基準，實際上的工作量和複雜度是完全不一樣的。
3樓：張磊
搜尋不是乙個故事，但是很多人會在用搜尋的時候發生很多故事，把他們捕捉，抽象，放大，你的故事就有了。
N年前雅虎搜尋不是請三位國師拍過三段廣告嗎？翻出來瞧瞧吧，自行搜尋：雅虎搜尋廣告大片
4樓：Aling Chou
我覺得乙個產品在做互動設計的時候，會有設定的角色、場景和目標，可以在此基礎上進行加工潤色以形成乙個靠譜的使用者故事。完整的使用者故事我覺得會是使用者使用過產品之後的UGC，但這樣優質的UGC需要採取一定的激勵手段讓使用者願意花時間講出來，而不是使用過後的寥寥數語。再不濟將產品團隊孵出這個產品的辛酸史和背景添油加醋的講一講。。
如何編寫乙個使用者體驗優秀的軟體使用者手冊？
澤眾雲測試 使用者體驗測試 使用者體驗 Alltesting 澤眾雲測試 通過使用者的角度使用產品，針對產品的舒適性 易用性 友好性 吸引性 可靠性等特性進行測試，並基於提出的問題給出優化建議，提公升客戶的滿意度。技術經驗不足 思維定勢，不能從多維度進行體驗測試 不具有yhtycs的專業技能 沒有合...
產品經理怎麼去做乙個完整的專案
半半 我個人認為乙個好的產品規劃可以 1 讓產品經理對產品的整個生命週期有清晰的認知和了解，清楚地知道不同階段的使命 2 讓產品經理知道該做什麼，不該做什麼，什麼時候該做什麼，什麼時候不該做什麼 3 讓產品經理可以提前對資源的分配有個了解，優先順序的排序可以心中有數，不至於臨時抱佛腳 4 讓整個團隊...
如何構建乙個完整的培訓體系？
在企業內部進行一次培訓需求調查，分為中高層和基層員工調查，其中中高層管理人員全員面談，基層員工抽樣調查，明確以下兩點 1 明確企業培訓的定位 在明確企業戰略管理 運營協調 組織機構職能定位的基礎上，建立規範的培訓管理體系。作為企業的人力資源部，在承擔企業人力資源管理職能的同時，還應承擔企業整體培訓職...