需求的描述問題
軟件開發中，程序員的工作一般由需求來定義。不同的需求描述方式，可能會對程序員理解需求產生影響。很多公司開發模式基於功能列表，這個列表裏面的規定了產品功能，各開發組從產品經理那裏領開發列表，然後“照單抓藥”進行開發。但通常這個功能列表只是一些簡單的描述，不能看到全局。
很多時候，程序員都只知道要開發的功能是什麼，但這個功能是誰在什麼樣的場景下使用，卻不清楚。因爲這種功能列表的方式，是將一個完整的需求分割成諸多碎片，每個程序員只負責其中一部分功能，只見樹木，不見森林。
還有一些新的需求描述方式，比如：用戶故事（User Story）。它是站在用戶角度來描述用戶希望得到的功能，關注用戶在系統中完成一個動作需要經過怎樣的路徑。以一個完成的場景來講述功能。User Story包含以下部分：
- 標題
簡要說明用戶故事的主要內容
- 概述
簡要描述用戶故事的內容，格式如:As a (Role),I want to (Activity),so that(Business Value).
- 詳述
詳細描述用戶故事的完整流程
- 驗收標準
描述一個正常的使用流程，以及各種異常流程系統是如何給出響應的
你的角色
你可能會想，如果產品經理使用User Story將需求實現細節都描述的非常清晰明瞭，那程序員的發揮空間在哪裏？其實，驗收標準中給出的實現細節應該是業務上的，程序員在這種問題上思考纔是真正浪費時間，我們的發揮空間應該是在技術實現上。
實際工作中，你會發現功能開發會有很多“丟三落四”的問題。很重要的一個原因，在開發特性的時候，因爲一些環節的缺失，我們不得不扮演很多角色，比如產品經理。有的公司可能沒有專門的產品經理的職位，有的可能是其他角色兼任，如SE。有時你拿到的用戶故事可能比較粗糙，這時你要分析需求，審視當前用戶故事是否合理，是否修改補充。