你好铐然，我是張飛洪蔬崩，本文共2094字，預(yù)估10分鐘讀完锦爵。
沖突是怎么產(chǎn)生的舱殿？
我們見過很多類似的場景：
小飛：流程引擎做得咋樣了？（和顏悅色）
小洪：做完了险掀，我給你演示一下沪袭。（心情愉悅）
小飛演示了一遍自己做的功能，小洪看上去很滿意樟氢。
小飛：不錯冈绊。不過，怎么沒有支持流程審核埠啃？（質(zhì)疑）
小洪：為什么要做這個死宣？（質(zhì)疑）
小飛：這不就是流程的一部分嗎？（不舒服）
小洪：哪里規(guī)定要做流程審核了碴开？（不舒適）
小飛：現(xiàn)在做流程哪有不用審核的毅该？（火藥味）
這個時候如果雙方都不能很好地控制自己的情緒，那接下來一場體力的較量可能就一觸即發(fā)了潦牛。
為什么會出現(xiàn)這種分歧呢眶掌？其中一個重要的原因是，開始實(shí)現(xiàn)這個需求之前巴碗，任務(wù)雙方都沒有清晰地定義好邊界朴爬，沒能把需求描述清楚。
需求規(guī)格
不知道大家接受的需求說明文檔都長成什么樣橡淆，有沒有固定規(guī)格召噩。我這里先羅列我見過的需求文檔大綱：
我們再看看部分截圖：
大概總結(jié)一下，有幾個核心內(nèi)容是我們重點(diǎn)要關(guān)注的：
業(yè)務(wù)流程圖（數(shù)據(jù)流圖）
界面原型圖（靜態(tài)和動態(tài)）
原型圖功能描述
有些文檔還會提供用戶故事或者用例圖來輔助說明逸爵，總之對開發(fā)者來說具滴，保證核心內(nèi)容的基礎(chǔ)上，需求越規(guī)范當(dāng)然是越好的师倔，我們最不希望看到的是模棱兩可构韵、碎片化的需求清單，因?yàn)椋ǔ＿@種功能列表只是一些簡單的描述贞绳，你并不能看到全局。
用戶故事
除了關(guān)注流程致稀、原型和描述之外冈闭，用戶故事（User Story）是我喜歡的一種方式。它是站在用戶的角度來描述了一個用戶希望得到的功能抖单，關(guān)注用戶在系統(tǒng)中完成一個動作需要經(jīng)過怎樣的路徑萎攒。既然它是“故事”，它就需要一個完整的場景矛绘。
相比較需求列表清單耍休，不知道你對用戶故事的感受是什么？列表是一種碎片化的內(nèi)容货矮，內(nèi)部邏輯和全景圖都是不清楚的羊精；而用戶故事有角色，有流程囚玫，有因果鏈喧锦，邏輯性更加強(qiáng)烈。
在前面的例子中抓督，小張和小王之所以會對需求是否完成產(chǎn)生分歧燃少，是因?yàn)榇蠹覍τ谛枨笸瓿傻亩x不同。
用戶故事采用的是以終為始的交付方式铃在，用戶故事的核心是驗(yàn)收標(biāo)準(zhǔn)阵具，它清晰地定義出產(chǎn)品的邊界。
驗(yàn)收標(biāo)準(zhǔn)非常重要的一環(huán)是異常流程的描述定铜。大部分程序員都擅長解決正常流程阳液，而異常流程則是最容易忽略的，也是產(chǎn)生扯皮的關(guān)鍵環(huán)節(jié)宿稀。既然容易扯皮趁舀，我們就在一開始把它定義清楚。怎么才算做完需求呢祝沸？驗(yàn)收標(biāo)準(zhǔn)說了算矮烹，達(dá)不成就不算任務(wù)完成。而且驗(yàn)收標(biāo)準(zhǔn)可以由開發(fā)罩锐、測試奉狈、產(chǎn)品共同使用而不會產(chǎn)生歧義。
如果你的團(tuán)隊采用用戶故事的格式進(jìn)行需求描述固然好涩惑，如果不能仁期，在功能列表中，補(bǔ)充驗(yàn)收標(biāo)準(zhǔn)也會極大程度地改善雙方協(xié)作的效率。
角色定位
也許你會感慨需求規(guī)格和用戶故事很好跛蛋，但是“臣妾做不到啊熬的，我們是小公司”。首先我們要明確自己的定位赊级，我是一個產(chǎn)品經(jīng)理還是開發(fā)人員押框，還是無所不能的全棧人員，不要做越界侵權(quán)的事情理逊。
產(chǎn)品和開發(fā)是兩種不同的角色橡伞，但是對一些小公司可能分得不是那么清楚，開發(fā)會兼職產(chǎn)品經(jīng)理的角色晋被，產(chǎn)品經(jīng)理也會兼職開發(fā)兑徘。對一些大公司來說，產(chǎn)品經(jīng)理也會有技術(shù)背景羡洛」夷裕總之，這兩個角色分分合合翘县，統(tǒng)一于軟件的生命周期最域。
用戶故事的驗(yàn)收標(biāo)準(zhǔn)主要是業(yè)務(wù)上的，程序員最后不要越界锈麸，徒增浪費(fèi)镀脂，我們的發(fā)揮空間應(yīng)該是在技術(shù)實(shí)現(xiàn)上。
然而忘伞，在現(xiàn)實(shí)情況中薄翅，很多團(tuán)隊做不到這種程度。
假如你們團(tuán)隊沒有產(chǎn)品經(jīng)理氓奈，用戶故事驗(yàn)收標(biāo)準(zhǔn)來寫翘魄？
沒辦法，答案只能是你自己舀奶。雖然你名義上是程序員暑竟，但當(dāng)拿到一個需求的時候，你要做的事不是立即動手寫代碼育勺，而是扮演產(chǎn)品經(jīng)理的角色但荤，分析需求，圈定業(yè)務(wù)范圍涧至。相信我腹躁，事前分析絕對比你拿一個寫好的系統(tǒng)給老板，而他卻告訴你這不是他想要的南蓬，好太多了纺非。
另外我想提醒你注意的是哑了，扮演不同角色的時候，我們的思考模式是不同的烧颖。產(chǎn)品思考的是做什么（方向）弱左，開發(fā)思考的是怎么做（手段）。
另外炕淮，如果你要兼顧兩個角色科贬，建議你先扮演好產(chǎn)品經(jīng)理，多花點(diǎn)時間把驗(yàn)收標(biāo)準(zhǔn)制定好鳖悠，再回到開發(fā)人員的角色上去寫代碼。畢竟优妙，最容易維護(hù)的代碼是還沒寫出來的代碼乘综。
總結(jié)
最后，我們總結(jié)一下：接到需求立刻開工是不成熟的表現(xiàn)套硼，因?yàn)槟憧赡軙限@北轍卡辰，交付的產(chǎn)品是有歧義的，最后導(dǎo)致的結(jié)果是扯皮和爭吵邪意，白白浪費(fèi)資源九妈。
在向目標(biāo)行進(jìn)的過程，我們要先想清楚自己想做什么雾鬼，先明確需求規(guī)格和用戶故事萌朱，特別是驗(yàn)收標(biāo)準(zhǔn)，最后還要知道自己的角色分工和定位策菜，避免該越界的不越界晶疼，不該越界的亂越界的混亂。
如果今天的內(nèi)容你只能記住一句話又憨，請記状浠簟：在做任何需求或任務(wù)之前，先定好驗(yàn)收標(biāo)準(zhǔn)蠢莺。最后寒匙，我想請你回想一下，在實(shí)際工作中躏将，你接到需求后是如何開展工作的锄弱，或者你希望的需求規(guī)范應(yīng)該長什么樣？歡迎在留言區(qū)寫下你的想法耸携。
感謝閱讀棵癣，我是張飛洪，如果你覺得這篇文章對你有幫助的話夺衍，也歡迎分享給你的朋友狈谊。
