編輯導語：年齡在職場上是一個很敏感的話題，很多職業都與年齡相關。提到轉行，首先不得不考慮年紀的問題，其次就要考慮自己是否具備另一個行業相關的能力要求。接下來，本文作者圍繞著“40多歲不懂技術，轉行做產品經理可行嗎”這個問題，為我們展開了他的分析。

前兩天，“人人都是產品經理”10周年慶上，最后一個提問者的壓軸問題是問：“40多歲，不懂技術，是否可以轉行做產品經理？”

場上大咖給到答案基本都是肯定的。

年齡這個問題，似乎沒有阻礙到這位40多歲的提問者，讓他覺得不安的，是自己不懂技術這件事。

在對這位提問者敬意的同時，也如嘉賓所反問的：產品經理為什么要和“懂技術”這件事掛鉤呢？

筆者看來，開發人員之于產品經理，好似“乙方”之于“甲方”，而“懂技術”這個籌碼，就成了乙方“套路”甲方的獨家秘訣。

因此，當開發告訴你“這個需求實現不了”、“起碼要開發一個月”、“you can you up”的時候，掌握了對技術邊界的了解、客觀分析的能力、以及理性溝通的誠意，就成了繼續推進項目前進的關鍵。

一、從一個案例說起

曾經，有個商品管理后臺。

在商品列表里，有庫存和價格，可以分別被鎖定。鎖定庫存或價格后，就不被下游的WMS系統更新。該功能在操作界面上，庫存和價格的鎖定按鈕是在一起的，如圖：

1. 需求

為鎖定操作增加記錄：當鎖定狀態變化的時候，記錄變動的信息。

要求庫存和價格的鎖定記錄，分開展示，即：用戶點擊庫存列的數值，顯示庫存的鎖定記錄；點擊價格列的價格值，顯示價格的鎖定記錄。

然而，開發說不好實現。并補充說：庫存和價格兩項的鎖定狀態變更，只能放一起展示，不能分開展示。

事實上產品經理要求各自展示鎖定記錄，是有原因的：

1. 場景：通常用戶要追查價格或庫存的變更時候，都是目標性比較強比如發現價格不對；
2. 交互：價格和庫存本身就是兩列，獨立的數據，分別下鉆到自己的詳情記錄也符合用戶心理；
3. 頻率：價格的改動頻率低，若放在一起，那么會出現一些行，價格始終沒變，只是跟著空跑，無效信息。

所以雙方進一步討論，后來發現開發的障礙來自表結構：價格和庫存的鎖定狀態，是放在一個表字段了。

表結構是這樣：

因此，若是實現起來，就要對這四個狀態id進行解析（比如狀態1解析為：庫存鎖定，價格不鎖定），還要計算從一個狀態到另一個狀態的種類組合（12種）。

略懂技術的人都看得，這個表結構設計得是不符合第一范式：兩個可再分的屬性（庫存和價格），為什么放在一個字段里？

2. 正確的設計應該是這樣的

但開發說是前任的鍋，現在改不動……巴拉巴拉。

后續的處理辦法就不細說，但從這個簡單的案例看出：

1. 若產品經理不追查到底，那么就不會知道實現困難的原因；
2. 若底層代碼這么不規范，就會影響后面其他功能；
3. 如果這個開發就這么摞代碼下去，那么很明顯代碼會很大冗余；
4. 同時也說明了，開發說難實現的原因，并不一定是真的難實現，而是各有各的無奈。

二、哪些情況是真的實現不了

從這個案例看出，開發說難實現的原因，并不一定是真的難實現。萬物皆來于創造，程序本身就是一種創造體。如果開發說實現不了，作為產品經理，得了解大概都是哪些原因，比如：

1. 軟件的瓶頸所限

計算機能解決的問是有邊界的：

比如，屏幕顏色隨手機殼變化，現階段讓做出來，可能還是會被打。

2. 缺少底層的軟硬件支持

這種情況表現在性能（安全性、穩定性、可用性、可靠性等）不能滿足。進而用戶體驗糟糕，直接面對用戶“疾風”的還是產品經理。

但實際的解決，不是一兩個月的代碼就可以的，而是要加硬件或者改底層結構。

3. 實現起來復雜

繞一大圈，做一個功能，只解決個黃豆大小的問題，或者用戶使用頻次少，都屬于低ROI的需求。

這類問題，建議找替代方案，否則開發不愿意做也是正常的。

4. 原代碼設不合理導致改不動

重構是開發的夢想，但是真正重構的并沒有幾個人，比如下圖這個發誓再也不為 Oracle工作的程序員：

5. 沒想清楚怎么寫邏輯

有一個需求是：多組重量區間之間，不能有交叉，開發想了很久不知道怎么用代碼表達……

三、“實現不了”背后深意是什么

最快的擺脫一件事情的方式就是否定它，比如：“不知道”、“沒見過”、“沒有”、“不行”等。

因此，開發說“實現不了”可能只是個表層信號。如果你確定這需求站得住腳，勢在必行，那么就要想辦法找到本質，而問題本質可能是這樣的：

1. 短期內技術天花板所限

技術之外的人來看技術，都會產生一種錯覺，覺得一段自然語言能夠描述的功能實現起來的難度就和這段自然語言的長度差不多。

自動賺錢程序、輸入錯誤自動糾正的功能、分析圖片內容的功能、自動決策功能、滾動播放彈幕不要遮擋正在說話的人、把抓取的圖片中的水印去掉……

這些真要實現起來，可要費好大勁了。但是，從提需求的角度來說，真的就是一句話，所以容易造成錯覺。要知道，程序連個單細胞生物的自動功能都實現不了，如繁殖下一代、進食補充能量、敵我模式識別等。

2. “待遇”實現不了

一個月開5000，說實現不了；一個月開1萬，那就說研究一下；一個月2萬，那就做一下試試；一個月5萬會說應該可以；一個月10萬，那就說通一個月宵也幫你搞出來。

天下沒有實現不了的需求，有，那就是錢不夠。

3. 這是拍腦袋定的吧，不想做

很多公司都被產品經理（老板）天馬行空的想法玩死的。想象力是好事，但要考慮成本。

比如為了一個像素，你可以推來翻去折磨程序員，而用這個產品的受眾呢？

——最多不超過兩百人。時間也是錢，試錯有成本。

4. 資源不夠

抄大廠的產品，看著簡單，可能人家背后是由幾百個人、幾年時間才做成現在這個樣子的。并且人家后端開發完的程序都部署在linux機器，負載均衡一般至少三臺機器。

而自己的老板，為了省錢，為了所謂的私有部署，要求客戶可以傻瓜式點擊exe在window上部署。

這情況下，早上讓程序員優化，下午就問為什么不能用，怎么可能？

——程序員卒。

四、產品經理當如何應對

1. 產品經理要懂實現原理

相比于各種細分產品經理，后端產品經理對技術的要求是普遍的。不僅邏輯思維強，而且起碼要懂一些技術塊，比如數據庫、接口、頁面機制等。

因為，如果做前端產品還好：直接整一個UI原型，而且抄的大公司的就可以；但是后端的需求，可能別人家的產品你看都看不到，所有邏輯、機制、風險、性能等問題，都需要產品和開發合力完成的。

對于技術的了解，只要懂共性的原理就可以了。

2. 尋找其他途徑繼續推進

如果開發能夠了解你的需求，說明真的可能是有難度。

那么就和開發綁定為一個共同體（參考SCRUM團隊），可以嘗試：

1. 讓開發定方案；
2. 讓開發評估時間；
3. 與開發協調，確定是否實現？是否延期？是否推到下個版本？
4. 尊重人，不要動不動就用下面的話懟開發：“我不要你覺得，我要我覺得；你做不了嗎，很難嗎，那別人怎么能做出來；你是不是技術不行；你和老板說，我不管；你們就按最簡單的方式做就行了，你們怎么方便怎么來；懟，只會激怒partener。
5. 不加班，即使加班你也要跟著一起加。還有一定要讓開發參與產品研討，挑明技術難點，評估開發時間。

五、總結

1. 產品經理無所謂必須要懂，或者不需懂技術：因為他要和各個職位打交道，你能說他不需要了解運營、了解用戶、了解UI嗎？同理，對技術的了解業是一樣。
2. 因為開發是整個功能實現的核心，所有開發若說實現不了，那么產品經理需要了解為什么，避免錯失合理的需求。
3. 開發堅持說實現不了的時候，產品經理要試著去了解他的畫外音是什么？以便協助，和開發綁成共同體，繼續想辦法推進項目。
4. 筆者認為，產品經理不用寫代碼，但要懂技術實現的共性原理，否則，“雞同鴨講”效率太低。

事實只要和開發共事久了，潛移默化得到的技術知識，基本就夠用了。

六、寫在最后：了解一點技術共性

筆者新書《后端產品經理寶典》，從產品經理角度，整理了共性的技術實現原理，推薦學習下。

了解技術原理后的好處，能看透技術的套路，被質疑的時候，不再心虛，甚至提出自己的建議，同時也會被開發信任。

購買鏈接：http://996.pm/MEyRg

#專欄作家#

唧唧歪歪PM，公眾號：唧唧歪歪PM（ID：jjyypm），人人都是產品經理專欄作家，2019年年度作者?！逗蠖水a品經理寶典》作者，藥學碩士轉行互聯網產品多年；熟悉跨境電商業務，醫藥領域；擅長大型后臺體系，社交APP。

本文原創發布于人人都是產品經理，未經作者許可，禁止轉載

題圖來自Unsplash，基于CC0協議