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