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