上周著重講了講，如何去了解客戶真實(shí)的問(wèn)題和核心訴求，其本質(zhì)上說(shuō)的是業(yè)務(wù)需求（Business Requirement），業(yè)務(wù)需求通常提綱挈領(lǐng)的將項(xiàng)目的愿景和范圍作了很好的描述和規(guī)范，從一個(gè)2B端的項(xiàng)目而言，展示了這個(gè)組織做這個(gè)項(xiàng)目的目標(biāo)是什么。

了解完真實(shí)的問(wèn)題之后，下一步該怎么做呢？上周碰到一個(gè)客戶的問(wèn)題，我們一位產(chǎn)品顧問(wèn)為他規(guī)劃的內(nèi)容，他在執(zhí)行過(guò)程中認(rèn)為是和他對(duì)這個(gè)產(chǎn)品的理解有偏差，再短暫的暫停之后，將為該客戶重新安排需求的分析和變更。之后我和團(tuán)隊(duì)的同學(xué)一直在想什么地方出了問(wèn)題，就這周末去海邊放風(fēng)的空檔，認(rèn)真回顧了一下。

發(fā)現(xiàn)不光是從事外包的人員，非常大數(shù)量的產(chǎn)品經(jīng)理在對(duì)用戶的需求進(jìn)行了解的過(guò)程中，都會(huì)犯這樣的錯(cuò)誤，往往是將功能清單混淆當(dāng)做用戶需求來(lái)用。

不止在一篇文章中寫(xiě)過(guò)，大多數(shù)的委托方都是通過(guò)他看到可能的解決方案來(lái)提需求的，而需求的本質(zhì)其實(shí)就是用戶的預(yù)期和現(xiàn)實(shí)之間的差距和問(wèn)題的展現(xiàn)，功能則是這些問(wèn)題可能的解決途徑。

如果說(shuō)產(chǎn)品就是解決問(wèn)題的途徑，那么簡(jiǎn)單講這里面就兩道坎
a、問(wèn)題（需求）找錯(cuò)了
b、解決問(wèn)題的方法（功能）設(shè)計(jì)有問(wèn)題

太多的產(chǎn)品經(jīng)理壓根就是跳過(guò)實(shí)際問(wèn)題直接找解決方法，反過(guò)來(lái)推斷找到的解決方法所對(duì)應(yīng)的問(wèn)題是真問(wèn)題，這就是用戶需求（User Requirement）和功能需求（Functional Requirement）的區(qū)別。當(dāng)你聽(tīng)到委托方抱怨說(shuō)，你們寫(xiě)的這東西太復(fù)雜都把我繞進(jìn)去了的時(shí)候，有沒(méi)有考慮過(guò)，你的客戶真的理解你列的東西么？你列的東西和他要解決的問(wèn)題又是否契合呢？如果我們的目的是真實(shí)的將客戶的問(wèn)題去解決，那么什么樣的描述能夠更符合委托方的認(rèn)知和習(xí)慣呢？

所以問(wèn)題來(lái)了，上來(lái)不寫(xiě)功能清單，我們又該怎么做呢？

a、一定要分清用戶是誰(shuí)
既然是了解用戶需求，先對(duì)用戶有一個(gè)詳細(xì)的了解和分類(lèi)，他們是誰(shuí)，各自有什么樣的特點(diǎn)，處在整體業(yè)務(wù)或流程的哪個(gè)階段？

b、通過(guò)用戶故事來(lái)描述用戶需求
很多做過(guò)Scrum的同學(xué)都會(huì)了解用戶故事，它本身是一種輕量有效的用戶需求描述方式，一般而言我們的描述格式為

“作為xx（角色），希望通過(guò)xxx樣的方式（活動(dòng)），以便達(dá)成xxxx（目的）”

將解決方法放回到用戶實(shí)際的場(chǎng)景中去看，并且將真實(shí)的預(yù)期和現(xiàn)實(shí)之間的問(wèn)題暴露出來(lái)。

c、最后的功能清單的確定不止來(lái)源于用戶需求
到最終的一個(gè)項(xiàng)目實(shí)施，功能清單的來(lái)源則不僅僅是用戶需求和問(wèn)題的搜集解決，還要受系統(tǒng)設(shè)計(jì)、質(zhì)量要求、業(yè)務(wù)規(guī)則的實(shí)際影響，而這些常常被稱作是項(xiàng)目中的軟性需求，當(dāng)我們無(wú)法意識(shí)到它們的時(shí)候，給項(xiàng)目埋下的雷將在交付過(guò)程中無(wú)限倍的放大，甚至是重新開(kāi)始。