我所見過的程序員和產(chǎn)品經(jīng)理之間產(chǎn)生矛盾大多是因為一個叫「需求文檔」的家伙。

有一種惡心的需求文檔，我曾經(jīng)見過，甚至再見到會覺得更惡心，請看下圖：

這張圖應該會交給交互射雞濕，交互看著這么長的文字，應該是崩潰的，畫出交互圖。交給程序員的時候，程序員看著這樣的需求描述再來生產(chǎn)的時候，就會問若干個「如果」問題，如果×××情況下，該怎么辦呢？產(chǎn)品經(jīng)理再來更新需求文檔，又問，又改，再問，再改，大家都疲憊了，需求文檔也成熟了，最后誰都看不懂，一份文檔束之高閣，沒有任何價值。

請產(chǎn)品經(jīng)理不要再浪費時間生產(chǎn)這樣的文檔了，程序員其實根本不需要這份文字式的需求告白書，程序員喜歡「看圖」，這種文字式的文檔應該是產(chǎn)品同學腦中的思路，而不應該直接把思路描述成文字交出來。

程序員需要的是一份清晰的交互圖，這份交互圖上在關(guān)鍵位置有一些邊界條件的說明，這份交互圖不一定非要用什么visio或者亂七八糟的工具輸出，一張草紙加鉛筆描述清晰即可，但是要還原出需求所描述的所有元素，雖然沒有UI設(shè)計，但是程序員就可以開始開發(fā)demo了。

由產(chǎn)品、交互和程序員一起討論出feature的關(guān)鍵路徑，并大家一起腦補好每一個流程，然后簡單的畫出草稿，我認為是效率最高的方式，并且可以減少很多會議，凡是一個人說想好了，發(fā)起評審，基本最后都被改的面目全非，還不如初期就大家一起得出結(jié)論。

當然程序員是自我感覺很良好的，你沒叫他一起參與討論的時候，他會抱怨說：“什么都不叫我，亂決策，現(xiàn)在亂的很，根本跑不通”，你叫他的時候，他又會說：“整天跟產(chǎn)品在一起討論問題，技術(shù)上都沒有長進，沒有積累，或者又抱怨說，唉，每天白天跟產(chǎn)品討論，只有晚上加班才能寫點代碼，累的像條狗，還總被人家說效率不高”。

程序員大多認為自己有些“武功”，跟不同的程序員交流要用不同的辦法，例如多請他吃飯或按摩。

所謂能力越大，責任越大，明白的程序員早就想明白了，他每天的工作不是給他的老大干活，也不是給他的老板干活，每天其實都是在給自己干，無論在哪里干，都當是創(chuàng)業(yè)。

再說下需求文檔中的「優(yōu)先級」這個選項，也是令程序員很頭疼的，優(yōu)先級分為高、中、低三個選項，大多數(shù)產(chǎn)品經(jīng)理會說，高的必須上線，中低優(yōu)先級也是需要做的，那還分什么優(yōu)先級呢？或者說中低選作，這種模棱兩可的感覺不如抽象成，做或者不做，當然需要產(chǎn)品經(jīng)理能力的提升，清晰評估出一個版本能否涵蓋這么多的事情。

轉(zhuǎn)回到正題，程序員其實不需要任何需求文檔，只需要一份清晰的流程圖即可。

#專欄作家#

給產(chǎn)品經(jīng)理講技術(shù)，微信公眾號（pm_teacher），人人都是產(chǎn)品經(jīng)理專欄作家。資深程序猿，專注客戶端開發(fā)若干年，對前端、后臺技術(shù)略懂，熱衷于對新的科技領(lǐng)域的探索。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。