程式設計師的作用應該是窮盡其軟體開發和設計的技能，完成一個個能夠提高效率、解放雙手、讓人們生活更便捷的工具和平臺，而不是幫助產品經理梳理業務邏輯。然而，實際如此嗎？恐怕諸多程式設計師都有話說，甚至是“有個馬賣批不知道當講不當講？”。
君不見很多程式設計師，一方面得寫程式碼，一方面還得給無償輔佐產品經理這個小皇帝。給產品經理上業務課、幫助他們修改“比草稿還垃圾”的產品需求文件。通常來講，只要是稍微複雜一點的專案，產品經理的初版需求文件只是提了一句話的需求，和百十字欠考慮的需求描述，和邏輯混亂無法串通的流程圖。後面的內容都是拉著程式設計師進行需求評審——討論——修改——再評審——重複此步驟，然後定稿，然後開始開發，開發途中再調整需求……。一切的一切，程式設計師在“抗大旗”，需求的調研，可行性討論，歷史相容性，未來擴充性，介面設計的使用者體驗問題都是程式設計師要考慮的事情和"本職工作"，問題弄清楚了之後，還需要給產品經理講懂。同時還需要承擔專案開發中延期的風險，專案上線中失敗的風險，專案上線後附帶的風險。然後上線之後，上線成功的郵件通常是產品經理來發：“經過1個月的艱苦奮鬥，我們的xx功能終於上線了，感謝相關技術人員的付出，謝謝”。無論你付出了多少工作，你都是相關技術人員，一筆帶過。
我時常為大多數程式設計師感到悲哀，他們就像一位託孤大臣，輔佐小皇帝治理朝政。小皇帝啥都不會，啥都不懂，一切都是託孤大臣要操心的事情，但是還得給小皇帝下跪，把奏摺寫好遞上去，請求他的旨意。等小皇帝長大了，江山還是他的，他能否念你的好可不一定，他沒準還把你辦了。
是什麼造就了這樣的境地？我時常想起這個問題，我覺得本質還是人的問題、門檻的問題、所處公司環境的問題。但是我感覺很複雜，三言兩句又說不清楚，且每個公司的情況都不一樣。但是有一個很明顯的事實：“程式設計師有門檻，有衡量的標準，有可量化的標準；產品經理則不然”，什麼人都能轉行乾產品經理，只要他具有一個本科學歷。程式設計師則不然，通常我們招聘一個程式設計師，會要求他是計算機相關專業畢業，面試的時候我們會問很多專業問題，比如：程式語言特性問題，軟體框架問題，演算法問題，快取問題，事務問題，併發問題，冪等問題，一致性問題，高可用問題……這些問題都是確切的專業問題，不容你忽悠，不容你滿嘴跑火車，你會你就能回答好，不會就肯定無法隨便瞎說，瞎說只會掉價。
程式設計師需要掌握相當多的專業知識，需要不斷的學習和積累，要想掌握這麼多知識，可不容易，門檻還是很高的。而產品經理呢？我認為產品經理的門檻也很高，我覺得最起碼應該足夠聰明、具有很好的邏輯性、具備一定的審美能力、至少具備某一個行業的業務知識、具備一定的互動設計能力、具備較好的文字能力等、大致懂一點技術就更好了。而實際上呢？很多產品經理都是“拖後腿的”，這一點我不用多說什麼，垃圾的產品經理你們都碰到過。
我不是要貶低產品經理，我尊重每一個工種，實際上我也有同事和熟人在做產品經理，他們有的設計了瑜伽APP，有的設計了運動方面的APP，有的設計了財務方面的網站，也有在銀行做產品經理的，他們都乾的不錯，設計的產品足夠簡單實用，介面美觀，佈局合理，操作便捷。我也不是說產品經理完全沒有門檻，但現實是很多產品經理真的沒水平。我痛恨那些“小皇帝型的產品經理”，啥都不懂，啥都不會，就是看了幾本書背了一些入門概念，學會畫點簡單的axsure原型圖，然後PRD文件就是垃圾草稿，原型圖就是個圖片流程都串不起來。跟他一起工作，你得揹著他負重前行，疲憊不堪。
諸位猿人朋友們！程式設計師的作用不應該是幫助產品經理梳理業務邏輯啊！ 我們不應該浪費時間去做無意義的扯皮，不應該浪費時間去幫他忙梳理不成熟的想法和產品初稿。如果說一個產品需求能正式啟動的時候，文件大概是90分，那麼初稿我認為至少的達到70以上。也就是基本不用改太多，也不需要開發補充太多內容，也不需要開一遍又一遍的會議去討論修改。
如果產品人員優秀一點，能夠做好他的本質工作，需求明確，文件詳盡，調研充分，邏輯清晰，設計合理，互動簡單良好。我們看著這樣的高水平文件，對我們來說也是有學習的價值。如果產品的想法也比較好，能超過我們技術人普遍的技術思維之上想事情，能讓我們感受到技術之外的好想法，那麼跟他們交流也能擴充我們的思維和眼界。
如果你所在的環境，產品經理很垃圾，我勸你離開。程式設計師的作用不應該是幫助產品經理梳理業務邏輯！。程式設計師的作用應該是，幫助優秀的產品經理實現他們卓越的想法，讓人們看到技術的價值。而不是沒日沒夜的幫助垃圾產品經理梳理業務邏輯，教他寫文件，明明我們已經都知道的事情，還要讓他明白，然後再讓他反過來告訴我們做什麼。功勞也是他的，成果也是他的，你只是寫了一些未來還需要翻來翻去的爛程式碼，你的收穫是什麼？成果是什麼？花在他身上的時間值得嗎？為什麼不和更優秀的人合作呢？
