作為一個程序員，最重要的職責就是：按時保質保量地完成需求開發。
像開發新業務這樣的復雜需求，PM （Product Manager，產品經理）一般會寫出詳細的PRD （Product Requirement Document，產品需求文檔），甚至可能會制作高保真原型。
而像調換兩個按鈕順序這樣的簡單需求，PM有可能只會口頭通知一下，最多在JIRA之類的項目管理平臺上創建一條只有標題的ISSUE。
如果是有和用戶交互的需求，負責設計的部門或人員一般會提供設計圖。專業一點的話還會幫你把圖都裁好，并準備不同屏幕分辨率下使用的多個尺寸版本。
當然，如果你在一個剛剛成立的創業公司，很有可能是創始人在白板前（或者是飯桌上）講了半個小時，然后就問你：“需要多長時間把它做出來？”
撕紙的需求
不管提出需求的是PM還是創始人，他們的腦海中一定為這個需求設想好了一個自洽的邏輯和形態。PRD也好，口頭宣講也罷，都是在描述這個邏輯和形態。他們提出需求，就是希望程序員能夠最大程度地還原他們的設想。
說起來簡單，做起來難。我們可以通過一個小實驗來揭示這一點。
首先，你需要找一張長方形的紙。如果你在辦公室，那就找一張A4紙；如果你在家，那就找一張紙巾。然后按照下面的步驟進行操作：
- 把紙對折，再對折
- 把左上角撕下來
- 旋轉180度
- 把右上角撕下來
- 把紙展開，完成
你的作品是什么樣子？中間開洞了嗎？邊上呢？角上呢？如果再做一次，你能完成同樣的作品嗎？
你可以拿著同樣的紙去找你的家人、同事或朋友，請他們來完成同樣的操作。在你不施加影響的前提下，他們完成的作品極有可能和你截然不同。
為什么會這樣呢？
如果你仔細觀察他們操作的過程，就會發現：
- 有的人會沿長邊對折，有的人會沿短邊對折
- 在對折時，有的人會把紙旋轉90度，有的人不會
- 在旋轉180度時，有的人會沿中心旋轉，有的人會把紙翻面
由于每次對折都會可能產生兩種不同結果，在撕第一個角時紙的朝向有四種可能性，旋轉180度時有兩種可能。所以僅僅兩個撕角的位置，就至少有 2 x 2 x 4 x 2 = 32 種不同的可能性。
就這樣，我們還沒有考慮撕角的大小、角度的區別，還有極少數人是會沿對角線對折的……
該怎么對待PRD？
上面撕紙的需求，其實是我自己拿了張紙隨意擺弄，然后記錄下來的操作流程。我照著這個流程，可以十分輕松地做出完全相同的作品。但是如果讓別人來做，結果就完全不一樣。其原因就是，我在完成作品的過程中，不光是按照流程進行操作，還隱含了自己的一些小習慣，卻并沒有把這些細節記錄下來。
如果把所有細節都完整地記錄下來的話，需求應該是這樣的：
- 拿著紙的短邊，沿長邊對折
- 再次拿著短邊，沿長邊對折
- 讓折過兩次的角朝向右下方，沒有折過的角在左上方（必要時翻面）
- 把左上角撕下來大約一公分的扇形
- 沿中心旋轉180度（不要翻面），使撕過的角處于右下方
- 把右上角撕下來大約一公分的扇形
- 把紙展開，完成
同樣，PM在寫PRD時，很有可能會漏掉一些自己認為應該是「常識」，無需再進一步說明的內容。比如「把一張紙對折」，我們很容易想當然地認為，應該是沿著長邊對折，但事實上并非所有人都是這么理解「對折」的。
由于每個人的成長經歷不同，其認知結構之間必然存在差異，因此對同一概念未必持有相同的理解。 你所認為的「常識」，我可能并不知道，或者擁有和你截然不同的理解。所以程序員在看PRD時，一定要把自己對需求的理解復述出來，跟PM確定是不是這么回事。否則就容易出現開發中、提測甚至上線后發現邏輯性錯誤，需要緊急修復甚至返工的情況。
此外，很多問題在設想階段是發現不了的，只有到了具體實施時才會暴露出來。PRD不可能真正做到完備，也不能保證沒有錯誤和遺漏。比如一個表單需求，很可能在做的過程中發現某個非法數據case是PRD里沒考慮到的，這時的用戶交互怎么做？文案怎么定？這都要和PM溝通來解決，而不能自己拍腦門決定。
PRD只是需求的一個快照性描述文檔，并不是需求本身。程序員應該對需求負責，而不是對文檔負責。 只有和PM保持溝通，不斷地細化需求，才能讓需求真正落地。當發現PRD里有不合理或者有疑問的地方時，一定要提出來讓PM進行解釋。千萬別視若無睹，甚至干脆將錯就錯，等著看PM笑話。
該怎么對待需求？
如果我們拿到了一份圖文并茂、十分詳盡的PRD，是不是應該馬上照著文檔開工呢？那可不一定。
一位優秀的程序員，應該在開工之前把下面這些問題想清楚：
- 為什么要做這個需求？是為了達成怎樣的目標？
- 想達成這個目標，有沒有明顯更合理的方案？PM是否知曉并評估過？
- 當前的方案是否會產生一些不良影響和副作用？PM是否知曉并評估過？
- ……
程序員有責任對需求方案進行review，并協助PM改進設計。要知道，PM一般不會從技術角度對需求進行考慮，所以往往提出的并非最優方案。有時只要做一點點調整，技術實現的難度就會大大降低，卻不影響目標的達成效果。
比如某個業務需要用到日期選擇器組件，PM為此專門設計了一個，而你知道系統中某個功能頁面里有現成可用的同類組件。這時就應該和PM溝通是否可以直接復用，或者在原有組件的基礎上進行功能擴展。這樣既節省了開發資源，又保持了用戶體驗的一致。
程序員要對整個產品的可用性負責，全面評估需求可能導致的不良影響，謹慎對待有破壞性的需求。 PM由于不了解系統的底層實現和實際數據的組織方式，所以很可能無法全面地評估需求的影響面。如果程序員忽視在這方面的思考，只是機械地按部就班地執行方案，就很可能導致嚴重的線上事故。
比如要對某數據進行批量修改，在做的過程中時發現該數據有多個業務正在使用。這時就應該必須停下來和PM溝通，因為PM可能只了解自己負責的那一塊業務，不知道修改可能會對其他業務產生影響。此類需求要和相關各方溝通協商，確認修改沒有不良影響后才能繼續。
程序員要有魄力去拒絕那些明顯不靠譜的需求。 有的時候，PM提出需求的動機不是為用戶創造更多的價值或提升用戶體驗，而是為了沖績效完成自己的KPI。為此拆東墻補西墻，從兄弟業務手里搶流量入口；甚至殺雞取卵，以嚴重破壞用戶體驗的方式拉量。遇到這種事，程序員一定要堅持自己的原則，守住自己的底線。
思考
- 需求文檔和需求的關系是什么？
- 和口頭講述相比，需求文檔的優點和缺點是什么？
- 在PM提出需求之后，程序員都應該做些什么？
