講一個小王跟小李的故事，小李是程序員，小王是產(chǎn)品經(jīng)理。當(dāng)小李接到一個新的需求，讓他開發(fā)一個單點登錄。經(jīng)過幾天的奮戰(zhàn)，他順著寫完代碼，這時產(chǎn)品經(jīng)理小王路過他身邊，順便問了他一下。

小王：單點登錄做的咋樣了？
小李：做完了我給你演示一下。

小李演示了一遍自己的功能，小王看上去很滿意。

小王：不錯，不過怎么沒有支持驗證碼？
小李：為什么要做這個？
小王：這不就是登陸了一部分嗎？
小李：哪里規(guī)定要做驗證碼了？
小王：現(xiàn)在登錄哪有不用驗證碼的？

雙方的對話都充滿了火藥味，有可能控制不好情緒，那么就會一觸即發(fā)。在工作中你是否也會遇到過這樣的情況？他倆為什么會有這么大的分歧？其中一個重要的原因就是開始這個需求之前沒有把需求給定義好。

這在軟件開發(fā)的過程中是一個很重要的問題。我們一般如何去定義需求？有些需求你直接聽到還好，但是有些需求是他人轉(zhuǎn)述的，可能就會存在一些偏差，因為信息在傳遞的時候，它是呈衰減的。你不可能把你理解的信息的100%傳遞給另一個人，在傳遞的過程中它是存在衰減的。

如何處理這樣的問題，一般像產(chǎn)品經(jīng)理就會有比較詳細(xì)的需求文檔，具體到某一需求都會羅列出來相關(guān)功能列表。用功能列表式的需求描述方式，將一個完整的需求打成一個個碎片，按照類似于清單的方式，一條一條列出來。這樣開發(fā)人員再去開發(fā)的時候，就知道自己有到底有沒有把它給弄完。只有當(dāng)所有的功能完成后，然后將它對接在一起，才算是“破鏡重圓”的時刻。

那么，我們一般如何去描述一個新的描述需求。通常我們會“用戶故事”方式去闡述。簡單的說就是站在用戶的角度，你提供一個什么樣的功能？他要經(jīng)過什么樣的路徑？達(dá)到怎樣的結(jié)果，這就是一個完整需求的場景。

用戶故事大致分為四個部分：

第一個是標(biāo)題，這個需求是什么？就比如說注冊用戶使用用戶名和密碼登錄。

第二個是概述，概述的格式可以按照：你作為一個什么樣的角色？做的事情要達(dá)到怎樣的效果？比如說作為一個注冊用戶，我想通過用戶和密碼登錄，然后才可以使用注冊用戶的使用的服務(wù)，

第三個是詳述，就是把一些操作流程和用戶界面的信息展示出來，比如說我登錄成功之后跳到什么頁面，登陸失敗又是怎樣的效果？這些都是要描述出來。

第四個是驗收標(biāo)準(zhǔn)，它一般是一個正常的流程，同時我們還需要考慮一些異常的流程，這往往是我們比較欠缺的。

怎樣才算做完了需求？驗收標(biāo)準(zhǔn)說了算。驗收標(biāo)準(zhǔn)會給出這個需求的測試用例，他會保證開發(fā)人員完成需求的最基本的質(zhì)量。這就是我們所說的行為驅(qū)動開發(fā)，可以按照這樣的標(biāo)準(zhǔn)去給出測試用例。

實際工作中許多產(chǎn)品經(jīng)理的需求，把需求交給開發(fā)人員之前，很多細(xì)節(jié)沒有想清楚，那種功能列表式的需求常常只包含了正常路徑，而缺失的細(xì)節(jié)就是在后續(xù)過程中有開發(fā)人員補(bǔ)的。用戶故事就是一種固定的格式，讓他們把這些應(yīng)該想清楚的問題想清楚。所以，如果你的團(tuán)隊是采用用戶故事的格式進(jìn)行需求描述，固然如果不能在功能儀表中補(bǔ)充驗收標(biāo)準(zhǔn)，也會極大地程度改善雙方協(xié)作的效率。

至此，今天要聊的就這些，如果你只能記住一件事的話，那么請記住：在做任何需求和任務(wù)之前先定義好驗收標(biāo)準(zhǔn)。