程序員的做用不該該是幫助產品經理梳理業務邏輯

程序員的做用應該是窮盡其軟件開發和設計的技能，完成一個個可以提升效率、解放雙手、讓人們生活更便捷的工具和平臺，而不是幫助產品經理梳理業務邏輯。然而，實際如此嗎？恐怕諸多程序員都有話說，甚至是「有個馬賣批不知道當講不當講？」。

君不見不少程序員，一方面得寫代碼，一方面還得給無償輔佐產品經理這個小皇帝。給產品經理上業務課、幫助他們修改「比草稿還垃圾」的產品需求文檔。一般來說，只要是稍微複雜一點的項目，產品經理的第一版需求文檔只是提了一句話的需求，和百十字欠考慮的需求描述，和邏輯混亂沒法串通的流程圖。後面的內容都是拉着程序員進行需求評審——討論——修改——再評審——重複此步驟，而後定稿，而後開始開發，開發途中再調整需求……。一切的一切，程序員在「抗大旗」，需求的調研，可行性討論，歷史兼容性，將來拓展性，界面設計的用戶體驗問題都是程序員要考慮的事情和"本職工做"，問題弄清楚了以後，還須要給產品經理講懂。同時還須要承擔項目開發中延期的風險，項目上線中失敗的風險，項目上線後附帶的風險。而後上線以後，上線成功的郵件一般是產品經理來發：「通過1個月的艱苦奮鬥，咱們的xx功能終於上線了，感謝相關技術人員的付出，謝謝」。不管你付出了多少工做，你都是相關技術人員，一筆帶過。

我時常爲大多數程序員感到悲哀，他們就像一位託孤大臣，輔佐小皇帝治理朝政。小皇帝啥都不會，啥都不懂，一切都是託孤大臣要操心的事情，可是還得給小皇帝下跪，把奏摺寫好遞上去，請求他的旨意。等小皇帝長大了，江山仍是他的，他可否念你的好可不必定，他沒準還把你辦了。

是什麼造就了這樣的境地？我時常想起這個問題，我以爲本質仍是人的問題、門檻的問題、所處公司環境的問題。可是我感受很複雜，三言兩句又說不清楚，且每一個公司的狀況都不同。可是有一個很明顯的事實：「程序員有門檻，有衡量的標準，有可量化的標準；產品經理則否則」，什麼人都能轉行乾產品經理，只要他具備一個本科學歷。程序員則否則，一般咱們招聘一個程序員，會要求他是計算機相關專業畢業，面試的時候咱們會問不少專業問題，好比：編程語言特性問題，軟件框架問題，算法問題，緩存問題，事務問題，併發問題，冪等問題，一致性問題，高可用問題……這些問題都是確切的專業問題，不容你忽悠，不容你滿嘴跑火車，你會你就能回答好，不會就確定沒法隨便瞎說，瞎說只會掉價。

程序員須要掌握至關多的專業知識，須要不斷的學習和積累，要想掌握這麼多知識，可不容易，門檻仍是很高的。而產品經理呢？我認爲產品經理的門檻也很高，我以爲最起碼應該足夠聰明、具備很好的邏輯性、具有必定的審美能力、至少具有某一個行業的業務知識、具有必定的交互設計能力、具有較好的文字能力等、大體懂一點技術就更好了。而實際上呢？不少產品經理都是「拖後腿的」，這一點我不用多說什麼，垃圾的產品經理大家都碰到過。

我不是要貶低產品經理，我尊重每個工種，實際上我也有同事和熟人在作產品經理，他們有的設計了瑜伽APP，有的設計了運動方面的APP，有的設計了財務方面的網站，也有在銀行作產品經理的，他們都乾的不錯，設計的產品足夠簡單實用，界面美觀，佈局合理，操做便捷。我也不是說產品經理徹底沒有門檻，但現實是不少產品經理真的沒水平。我痛恨那些「小皇帝型的產品經理」，啥都不懂，啥都不會，就是看了幾本書背了一些入門概念，學會畫點簡單的axsure原型圖，而後PRD文檔就是垃圾草稿，原型圖就是個圖片流程都串不起來。跟他一塊兒工做，你得揹着他負重前行，疲憊不堪。

諸位猿人朋友們！程序員的做用不該該是幫助產品經理梳理業務邏輯啊！ 咱們不該該浪費時間去作無心義的扯皮，不該該浪費時間去幫他忙梳理不成熟的想法和產品初稿。若是說一個產品需求能正式啓動的時候，文檔大概是90分，那麼初稿我認爲至少的達到70以上。也就是基本不用改太多，也不須要開發補充太多內容，也不須要開一遍又一遍的會議去討論修改。

若是產品人員優秀一點，可以作好他的本質工做，需求明確，文檔詳盡，調研充分，邏輯清晰，設計合理，交互簡單良好。咱們看着這樣的高水平文檔，對咱們來講也是有學習的價值。若是產品的想法也比較好，能超過咱們技術人廣泛的技術思惟之上想事情，能讓咱們感覺到技術以外的好想法，那麼跟他們交流也能拓展咱們的思惟和眼界。

若是你所在的環境，產品經理很垃圾，我勸你離開。程序員的做用不該該是幫助產品經理梳理業務邏輯！。程序員的做用應該是，幫助優秀的產品經理實現他們卓越的想法，讓人們看到技術的價值。而不是沒日沒夜的幫助垃圾產品經理梳理業務邏輯，教他寫文檔，明明咱們已經都知道的事情，還要讓他明白，而後再讓他反過來告訴咱們作什麼。功勞也是他的，成果也是他的，你只是寫了一些將來還須要翻來翻去的爛代碼，你的收穫是什麼？成果是什麼？花在他身上的時間值得嗎？爲何不和更優秀的人合做呢？