我所見過的程序員和產品經理之間產生矛盾大多是因為一個叫「需求文檔」的傢伙。

有一種噁心的需求文檔,我曾經見過,甚至再見到會覺得更噁心,請看下圖:

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

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

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

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

當然程序員是很「賤」的,你沒叫他一起參与討論的時候,他會抱怨說:“TMD,什麼都不叫我,亂決策,現在亂的一坨屎,根本跑不通”,你叫他的時候,他又會說:“整天跟產品在一起討論問題,技術上都沒有長進,沒有積累,或者又抱怨說,唉,每天白天跟產品討論,只有晚上加班才能寫點代碼,累的像條狗,還總被人家說效率不高”。

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

所謂能力越大,責任越大,明白的程序員早就想明白了,他每天的工作不是給他的老大幹活,也不是給他的老闆幹活,每天其實都是在給自己干,無論在哪裡干,都當是創業。

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

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

#專欄作家#

給產品經理講技術,微信公眾號(pm_teacher),人人都是產品經理專欄作家。資深程序猿,專註客戶端開發若干年,對前端、後台技術略懂,熱衷於對新的科技領域的探索。

本文原創發佈於人人都是產品經理。未經許可,禁止轉載。