作為一名程式設計師，你真的理解需求嗎？

作為一個程式設計師，最重要的職責就是：按時保質保量地完成需求開發。

像開發新業務這樣的複雜需求，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提出需求之後，程式設計師都應該做些什麼？