小編見過的程序員和產品經理之間產生的矛盾大多是因為一個叫“需求文檔”的東西，有這麼一種讓人頭疼的需求文檔，產品經理將這樣的文檔轉交給程序員的時候，程序員的內心一定是崩潰的，他一定會
問若干個“如果”：如果發生A情況，該怎麼處理；如果發生意外，產生了B情況，又該怎麼處理。
產品經理收到反饋再來更新需求文檔，你問，我改，再問，再改，等大家都疲憊了，需求文檔也成熟了。最後誰都看不懂，一份文檔束之高閣，沒有任何價值。
需求文檔中的“優先級”選項也是令程序員很頭疼的，優先級分為高、中、低三個選項，大多數產品經理會說，高優先級必須上線，中低優先級也是需要做的。那還分什麼優先級呢？或者說中低選做，這種模稜兩可的感覺還不如抽象成做或者不做。當然，這需要產品經理提升能力，能夠清晰地評估出一個版本能否涵蓋這麼多的內容。
程序員需要的是一份大家都認可的清晰的交互圖，其關鍵位置需要有一些邊界條件的說明。這份交互圖不一定非要用專業的原型工具輸出，一張草紙加鉛筆描述清晰即可。
小編認為由產品經理和程序員一起討論功能的關鍵路徑，並一起確定每一個流程，然後簡單地畫出草稿，才是效率最高的方式，並且可以少開很多會議。若僅一個人想好了就發起評審，結果往往是需求被改得面目全非，不如大家在初期就一起討論得出結論。
當然，程序員是很高傲的，產品經理沒叫他參與討論時，他會抱怨：“什麼都不叫我，亂決策，現在一團糟，根本實現不了。”
產品經理叫他的時候，他又會說：“整天跟產品經理在一起討論問題，技術上都沒有長進，沒有積累。”或者抱怨說：“白天跟產品經理討論，只有晚上加班才能寫點代碼，筋疲力盡，還總被批評效率不高。”
分享到:
閱讀更多 鄧鋤頭 的文章
