今天我們要針對造成“需求不明確”的主因之一—— 場景不明，來詳細(xì)討論在需求討論階段，如何鎖定“場景”，讓sprint的具體內(nèi)容能夠緊扣需求本身，避免不必要的開發(fā)資源浪費(fèi)。

在互聯(lián)網(wǎng)產(chǎn)品開發(fā)領(lǐng)域，產(chǎn)品經(jīng)理與開發(fā)團(tuán)隊(duì)間的有效協(xié)作是決定項(xiàng)目落地階段的關(guān)鍵，這里不僅包含了討論溝通，還包含了大家對“需求”的理解。雖然有產(chǎn)品文檔或Sprint ticket來保障大家對同一個需求的理解，但是實(shí)際工作中依然逃不開有需求不明確的時候，這個系列就來詳細(xì)討論如何破解需求不明確，多了解些思考方式，應(yīng)用在工作中，讓自己或團(tuán)隊(duì)不再因?yàn)椤靶枨蟛幻鞔_”而買單（付出時間精力）。

不管是產(chǎn)品和開發(fā)都要重視對“需求的場景”具體是什么，通常會用用戶故事（User stories）來描述場景，可以借助“5W1H”來思考，即What（用戶需要什么）、Why（為什么需要）、Who（服務(wù)于哪類用戶）、Where（在產(chǎn)品哪個環(huán)節(jié)使用）、When（何時會選擇使用）和How（如何操作以解決問題）六個維度來精確描繪用戶需求的全貌。但實(shí)際操作起來還要避免忘記了目標(biāo)，只按照模版來描述場景的內(nèi)容。比如user stories的描述是：因?yàn)槟硞€原因，A要在什么時候，什么環(huán)節(jié)，需要使用B功能，從而解決C問題。

從描述的模版的角度來說，沒有什么問題。但是還要注意：

• 這個場景和當(dāng)前的核心目標(biāo)的完成度關(guān)系怎么樣？比如這個場景的問題被解決了之后，對于目前產(chǎn)品的目標(biāo)完成的幫助有多大？如果大的話，自然ok，但如果不是很大，是否可以先放一放，看看是否有跟目標(biāo)關(guān)聯(lián)較大的場景需要先開發(fā)。例如：“新增功能是否契合目前每月新客戶10%增長的首要目標(biāo)？如果有更高優(yōu)先級的需求，該如何調(diào)整資源的分配？”?通過將需求與業(yè)務(wù)目標(biāo)相掛鉤，我們可以合理分配資源，優(yōu)先滿足關(guān)鍵性需求。
• 這個場景中描述的“解決了某個問題”，對于客戶（繼續(xù)或新）使用我們的產(chǎn)品起到了多大作用。只有客戶留存下來了或帶來了更多新客戶，產(chǎn)品才有更多的盈利可能性。需求的場景可能是使用者的一個小困擾，但是對于他們的續(xù)約或繼續(xù)使用的影響有多大，需要認(rèn)真調(diào)研并討論。如果解決了這個問題可以讓用戶對我們的產(chǎn)品提升更多的信心，從而繼續(xù)幫我們拉新或自己留存下來，自然是極好的，如果不能，只是一個錦上添花的功能（不是說錦上添花不能有，只是要看優(yōu)先級），那就要看下是否有其他更重要的場景需要先解決問題了。
• 這個場景中描述的某個原因是否是真正的原因或核心動機(jī)（學(xué)習(xí)柯南的動機(jī)法，對動機(jī)要進(jìn)行驗(yàn)證），如果動機(jī)分析的不對或由于信息的調(diào)研傳遞過程中，誤解了動機(jī)，那在解決方案的制定時也會走偏方向，結(jié)果不盡如人意。多問些為什么，可以更深入的挖掘場景中的真正動機(jī)。比如，“用戶下載內(nèi)容的真正目的是什么？下載格式的選擇是否因用戶的目的不同而有所差異？”通過不斷地提問和深挖，可以幫助團(tuán)隊(duì)發(fā)現(xiàn)需求背后用戶的真實(shí)動機(jī)，避免在需求不明晰（或表象清晰）的情況下盲目開發(fā)，從而保護(hù)寶貴的開發(fā)資源，提升團(tuán)隊(duì)的整體效率。
• 這個場景中解決問題的方法只有用戶故事中的一種方法嗎？是否有替代的更簡單、更快速的方案？有時候我們在聽用戶故事的描述時，就像看電視劇一樣容易被已有的劇情帶著往下走，只是像看故事一般的看著用戶故事，但如果用戶故事里的結(jié)局（解決方案）不是團(tuán)隊(duì)在有限資源下可執(zhí)行的方案，那劇的結(jié)局（解決方案）也很難及時被拍攝出來。所以，時不時地從用戶故事的描述中，跳脫出來想想對于用戶的這個場景，更簡單、快速（更具性價比）的方案是不是還有？要知道，如果有人能提出更簡單的方案，對于研發(fā)的資源和大家的精力（不管是產(chǎn)品、開發(fā)、測試）都是一件大好事。生活和工作能平衡的關(guān)鍵所在，就靠“好鋼用在刀刃上了”，節(jié)省精力，做最重要、最具影響力的事情才是提升效率的關(guān)鍵。這一點(diǎn)，建議開發(fā)人員積極參與到需求討論中，提供專業(yè)的技術(shù)意見和建議。這不僅包括對需求解決方案的可行性評估，還涉及到可能的技術(shù)限制和挑戰(zhàn)。通過團(tuán)隊(duì)共同探討需求的實(shí)現(xiàn)方式、所需的資源，可以挖掘更具性價比的場景解決方案。
• 這個場景中出現(xiàn)的頻率有多高？需求所對應(yīng)的使用場景進(jìn)行頻率分析也是一個很重要的維度。針對低頻場景的需求，研發(fā)團(tuán)隊(duì)需要審慎對待，通過提問來促使自己的反思：“此功能是否確實(shí)是用戶頻繁使用的必需功能？若僅為偶爾發(fā)生的特殊情況，是否有其他臨時解決措施或現(xiàn)有的低成本工具可以替代？” 例如，在處理少數(shù)的退款情況時，可以提議先采用人工加內(nèi)部工具的組合方式，待該場景頻次提升后再做系統(tǒng)開發(fā)升級。通過量化場景發(fā)生的頻率和影響范圍，可以幫助我們從迷霧中走出來，看清團(tuán)隊(duì)真正應(yīng)該要做的是什么。

總的來說，鎖住“場景”，既要圍繞場景本身來詳細(xì)分析需求，還要跳出場景，看場景與業(yè)務(wù)目標(biāo)，研發(fā)成本，用戶動機(jī)等的關(guān)聯(lián)如何，從而真正鎖住緊扣市場需求的“場景”，進(jìn)而付出的研發(fā)精力才可最大限度地避免成為“試錯成本”。

還等什么，收藏起來，后面在工作中練習(xí)下吧！