如果你告訴你家的產品經理：「你認為代碼好改，那怎麼不轉行當技術？」

大概率上，又是一場宮斗大戲。

都是老闆的妃子，產品何苦為難開發，開發何苦為難產品。

既然產品認為代碼好改，那基本可以斷定，這個產品是一個不怎麼合格的產品，既然是一個不合格的產品，為什麼你要為別人的傻x買單，在那裡生氣？

產品認為代碼好改，很正常，畢竟是一個外行人。我們又何嘗不對其他的職業，有過錯誤的認知。所以，還是得多多鍛煉溝通能力，而不是吐槽，畢竟吐槽一時爽，一直吐槽...

畢竟吐槽解決不了問題。多多和產品溝通吧。

要是實在帶不動，那就say good bye嘍。

代碼好改，結構難變。

這個問題經常遇到，有時候也並不是產品經理認為，可能是總經理認為，客戶認為，總之，有人認為，不就小改一下嘛。

首先，作為一名小公司的技術負責人，有責任保障我們開發的東西能長期穩定、安全地運行下去。因此，任何需求，都要考慮可維護性。加好說，改麻煩，哪怕是簡單地換個欄位、換個第三方 API，都要詳細考慮其破壞性。不改結構，用邏輯繞過去，讀寫效率怎樣；改變結構，歷史數據如何轉換——這些，都要詳細談清楚，才能動手，拒絕拍腦袋/屁股決定。大部分情況，優先保障讀的效率，那麼結構可能就必須要改變。數據量大時，要求排額外的數據轉換程序開發、測試時間；當數據量不是很大時，讓產品自行編輯數據——就這麼任性，嘿嘿！

改不好就成屎山，已經有幾個屎山了，就問還想再要一個嗎？我是無所謂，不就未來再開個新項目嘛，美其名曰大版本更新，有代碼寫、有工資拿。

不光產品認為代碼好改，你的領導，客戶或者其他崗位的同事都認為代碼好改。

為什麼這麼說，大部分人了解點寫代碼的工作，然後盲目的自信的認為自己也會。

在我看來這叫能力幻覺，就像你覺得那個女生喜歡你，然而別人並不鳥你。

我在做產品的時候，開發很喜歡站在他們的角度提一些問題，其中有一個很杠的開發同事，經常提些討論很久的問題。後來我找到機會培養了一下他的產品思維，再後來我們站在統一戰線。

有時候我也喜歡給開發提意見，後來發現這麼做是不對的，因為你要提，就需要了解裡面很多細節，明確到每個技術點。如果做不到這點，還不如聽專業人士的建議。

首先這個問題本身就有點問題，一杆子直接打死一片，並不是所有產品都理所當然當然的認為代碼好改，一般稍微資深一點的產品即使沒有技術背景也會大概了解一些代碼技術實現的難度問題，不至於完全無概念，如果真的有這種，那只是因為那個產品有點水；

另外就是屁股決定腦袋了，就像也有少部分研發會認為做產品很容易，天天劃划水；

利己主義思想在職場中很常見，真正在職場中能非常理性客觀的處理問題的人是很難能可貴的，如果真的碰到，請珍惜這樣的同事；

產品經理門檻相對於研發低很多，能夠選擇產品經理的專業文理科都可以。沒有技術背景，不了解研發難度很正常。

同時也意味著研發並不完全了解產品的工作內涵。

可能因為大家都覺得人人都是產品經理，但是不是人人都是開發，手動dog……

因為他們沒有把技術當成用戶。如果他們把技術當成上帝，技術就算寫的在差，他們也會忍受。這話反過來同樣，技術也沒有把用戶當成用戶。如果技術站在產品的角度，開發前期就酌情參與到了解用戶過程中，就能減少團隊磨合的時間成本。

技術開發只是個壘磚的

產品是個設計大樓的

你也覺得磚好搬吧？你怎麼不去當民工呢？

這個容易理解，屁股決定腦袋，如擠公交車，在下面時心裡想，這幫孫子就不能往裡擠擠嗎？一旦擠上去了，望著下面的眾人，心裡想，擠什麼擠，等下一輛吧。產品經理考慮用戶多一些，開發考慮工作量多一些。話說回來，開發出來的產品有人喜歡用是硬道理，所以開發有產品思維，等次就不一樣了。如果覺得確實不合理，要站在用戶或者成本角度懟產品方為上策。

無論前端還是後台，寫代碼都需要耐心和細心，需要特別關注細節。

但是作為運營或者業務部門，只關心實現，沒有人真正關心細節。

產品經理就是站在中間和稀泥，在兼顧業務的同時，平衡細節。

開發有開發的難處，不認為代碼好寫！

改代碼不容易，寫需求也不容易。

每個崗位都有自己的挑戰。

一般來說，普遍認為寫代碼比寫需求容易。你說的可能是一少部分人的想法。

在公司里，不要肆意揣摩其他職位的工作難度，這對大家都好

如果一個人在公司里總是信口開河胡說八道

那只有兩個結果

第一，他走人

第二，員工全走光剩他老哥一個，公司破產。

講道理，能不能有個大佬寫本《人人都是技術開發》，我也想轉啊……關鍵是轉得了嘛 T﹏T

言歸正傳，你以為這是產品經理以為的，殊不知這可能是老闆讓產品經理以為的……如果真的是產品經理以為的，那你就一句「可以，加排期」就能讓他哭出聲了……

這個問題就好比為什麼開發總覺得產品經理很閑，或者就是個傳話筒一個道理

沒有能力！！！

有產品思考和技術實現能力，那麼就會去自己創業了。

其實產品覺得代碼好改，可能是忽略了管理類型的工作量。

舉個產品的例子，你們可能覺得文檔原型也好改，但是改完要重新看一遍文檔原型，看下是否有重複的問題。

更新完後，就要更新svn，郵件通知到相關的開發及測試同事。

雖然只是文檔改了一句話，或者原型稍微改動了一下，但是管理型的工作就耗了半個小時。

類比成開發工作，我猜也是同樣道理。

所以有需求優化時，即使我覺得再小的優化，也是先讓開發評估，如果我覺得不合理的工時評估，那我可能多問下原因

互聯網的產品經理，主要做市場、競品等分析，原型設計，各種溝通等，但一般他們是不懂技術的。

所謂不懂技術，就是他們不知道技術人員所使用的框架是什麼，有什麼特點，能達到什麼效果，不能達到什麼效果。以及，目前系統的架構情況，改哪些比較容易，改哪些不容易……當然，他們一般也不懂資料庫。 他們對這些是沒有什麼概念的。

舉個例子：比如PM想在某一處加一個欄位。他們認為那還不簡單，在資料庫中加個欄位，界面上展示出來就完了。

實際情況是，如果沒有備用欄位的情況下，除了要在資料庫加欄位，還要改很多代碼，因為使用了框架，要遵循框架的套路，而不是自己寫代碼直接從資料庫拿數據並展示到前台。——這點是大部分PM認識不到的，也是最容易起衝突的地方。

開發認為PM就是白痴，完全不懂，還瞎XXBB。而PM呢，會認為開發故意不配合，明明很簡單的事情，非要說的那麼難。於是乎，幹起來了……

至於說為什麼PM不轉開發：

首先他們沒有那個能力，我認為99.9%的產品經理是做不了開發的。

其次，產品經理一般認為開發沒意思，就是IT界的搬磚師，又累又死板。而他們，產品經理，則是改變世界的人，最低也要做到CEO的人，怎麼可能做開發，那不是大材小用了嘛，不能夠的。

因為他們寫不了代碼

因為那個產品經理不懂你，哈哈哈哈

分兩種情況

一是產品經理完全不懂代碼，不就是改段代碼嗎？那麼他不會所以不轉。

二是產品經理本身就懂代碼，甚至是個大牛，比你的水平要高，所以認為好改。他本身就是轉的，為啥還要回去呢？

推薦閱讀：
相关文章