你好，我是張飛洪，本文共2094字，預估10分鐘讀完。
衝突是怎麼產生的？
我們見過很多類似的場景：
小飛：流程引擎做得咋樣了？（和顏悅色）
小洪：做完了，我給你演示一下。（心情愉悅）
小飛演示了一遍自己做的功能，小洪看上去很滿意。
小飛：不錯。不過，怎麼沒有支持流程審覈？（質疑）
小洪：爲什麼要做這個？（質疑）
小飛：這不就是流程的一部分嗎？（不舒服）
小洪：哪裏規定要做流程審覈了？（不舒適）
小飛：現在做流程哪有不用審覈的？（火藥味）
這個時候如果雙方都不能很好地控制自己的情緒，那接下來一場體力的較量可能就一觸即發了。
分歧
爲什麼會出現這種分歧呢？其中一個重要的原因是，開始實現這個需求之前，任務雙方都沒有清晰地定義好邊界，沒能把需求描述清楚。
需求規格
不知道大家接受的需求說明文檔都長成什麼樣，有沒有固定規格。我這裏先羅列我見過的需求文檔大綱：
需求大綱
我們再看看部分截圖：
功能描述
大概總結一下，有幾個核心內容是我們重點要關注的：
-
業務流程圖（數據流圖）
-
界面原型圖（靜態和動態）
-
原型圖功能描述
有些文檔還會提供用戶故事或者用例圖來輔助說明，總之對開發者來說，保證核心內容的基礎上，需求越規範當然是越好的，我們最不希望看到的是模棱兩可、碎片化的需求清單，因爲，通常這種功能列表只是一些簡單的描述，你並不能看到全局。
用戶故事
除了關注流程、原型和描述之外，用戶故事（User Story）是我喜歡的一種方式。它是站在用戶的角度來描述了一個用戶希望得到的功能，關注用戶在系統中完成一個動作需要經過怎樣的路徑。既然它是“故事”，它就需要一個完整的場景。
相比較需求列表清單，不知道你對用戶故事的感受是什麼？列表是一種碎片化的內容，內部邏輯和全景圖都是不清楚的；而用戶故事有角色，有流程，有因果鏈，邏輯性更加強烈。
在前面的例子中，小張和小王之所以會對需求是否完成產生分歧，是因爲大家對於需求完成的定義不同。
用戶故事採用的是以終爲始的交付方式，用戶故事的核心是驗收標準，它清晰地定義出產品的邊界。
驗收標準非常重要的一環是異常流程的描述。大部分程序員都擅長解決正常流程，而異常流程則是最容易忽略的，也是產生扯皮的關鍵環節。既然容易扯皮，我們就在一開始把它定義清楚。怎麼纔算做完需求呢？驗收標準說了算，達不成就不算任務完成。而且驗收標準可以由開發、測試、產品共同使用而不會產生歧義。
如果你的團隊採用用戶故事的格式進行需求描述固然好，如果不能，在功能列表中，補充驗收標準也會極大程度地改善雙方協作的效率。
用戶故事
角色定位
也許你會感慨需求規格和用戶故事很好，但是“臣妾做不到啊，我們是小公司”。首先我們要明確自己的定位，我是一個產品經理還是開發人員，還是無所不能的全棧人員，不要做越界侵權的事情。
產品和開發是兩種不同的角色，但是對一些小公司可能分得不是那麼清楚，開發會兼職產品經理的角色，產品經理也會兼職開發。對一些大公司來說，產品經理也會有技術背景。總之，這兩個角色分分合合，統一於軟件的生命週期。
用戶故事的驗收標準主要是業務上的，程序員最後不要越界，徒增浪費，我們的發揮空間應該是在技術實現上。
然而，在現實情況中，很多團隊做不到這種程度。
假如你們團隊沒有產品經理，用戶故事驗收標準來寫？
沒辦法，答案只能是你自己。雖然你名義上是程序員，但當拿到一個需求的時候，你要做的事不是立即動手寫代碼，而是扮演產品經理的角色，分析需求，圈定業務範圍。相信我，事前分析絕對比你拿一個寫好的系統給老闆，而他卻告訴你這不是他想要的，好太多了。
另外我想提醒你注意的是，扮演不同角色的時候，我們的思考模式是不同的。產品思考的是做什麼（方向），開發思考的是怎麼做（手段）。
另外，如果你要兼顧兩個角色，建議你先扮演好產品經理，多花點時間把驗收標準制定好，再回到開發人員的角色上去寫代碼。畢竟，最容易維護的代碼是還沒寫出來的代碼。
角色定位
總結
最後，我們總結一下：接到需求立刻開工是不成熟的表現，因爲你可能會南轅北轍，交付的產品是有歧義的，最後導致的結果是扯皮和爭吵，白白浪費資源。
在向目標行進的過程，我們要先想清楚自己想做什麼，先明確需求規格和用戶故事，特別是驗收標準，最後還要知道自己的角色分工和定位，避免該越界的不越界，不該越界的亂越界的混亂。
如果今天的內容你只能記住一句話，請記住：在做任何需求或任務之前，先定好驗收標準。最後，我想請你回想一下，在實際工作中，你接到需求後是如何開展工作的，或者你希望的需求規範應該長什麼樣？歡迎在留言區寫下你的想法。
感謝閱讀，我是張飛洪，如果你覺得這篇文章對你有幫助的話，也歡迎分享給你的朋友。