產品經理如何應對技術的「做不了」這樣的問題？

01-29

在做項目評估和項目開發的過程中，在詢問技術問題的時候，經常會得到這樣的回答「這個流程太複雜了，做不了！」、「目前我們的資料庫有問題，做不了這個功能」、「如果這樣做，要全改」。
作為產品經理怎麼應付技術這樣的回答？

簡單來說，產品經理是要有多方面的知識積累，技術也是其中一方面。這裡的技術積累並不需要你來寫代碼，但是需要能夠有共同語言，能夠交流下去。

然後，就深入的交流下去，打破砂鍋問到底，一點一點弄清楚，理解做不了到底是因為什麼原因，卡在哪裡？有職業精神的工程師不會說做不了，只是工作量和時間計劃的問題。弄清楚詳細的問題，然後看看如何能通過調整來找到平衡。

其實這裡隱含了一個必要的條件，你要有好的信譽和影響。

首先你要真的夠專業，能做好產品。如果多有幾次失敗，人品會很快耗光，然後… 所以自己的工作要能經得起考驗。

然後，要尊重大家的勞動，把大家的工作量放到真正有價值的地方。大家都不願意做無用功，我在和工程師合作時，如果因為我的概念或設計而讓大家浪費時間，我會非常難過。

還有，做人做事。建立信譽和影響是需要時間的。曾經在某大企業，一開始大家對和我合作很頭疼，因為他們真的挺累，經常加班，而且我又不好對付…半年後，大家已經兄弟相稱，能請我吃飯了，因為有個兄弟很久沒升職了，就是和我的合作做出了好的結果，成功晉級。得讓大家都能有收穫，而不是只想著自己，只麻煩人家，大家一起工作本身也是為人處事的過程。

不是這個問題的回答對象。但作為問題中主要面對的對象，可以說說技術是如何想的。

做不了絕對是個潛台詞，通常蘊涵以下幾層意思：

１.預期時間過於緊迫，現有技術架構限制、追加需求時最容易出現這類問題；

２.對這麼做的成本回報比不樂觀，不認同這麼做的價值，認為花大力氣做個功能是浪費時間；

３.雖然極少情況出現，但可能會有不懂物理的產品經理提出F!=ma這樣的需求；

４.因為沒做過或者太難而說這不了，這種態度其實在技術圈裡也是頗忌諱的。不能/拒絕解決未知或有難度的問題的工程師，產品和工程師同事都不會喜歡。真遇到這樣的同事可以通過技術Leader和人力的途徑解決，但千萬不要假設自己是在和這樣的人一起工作。

而作為工程師在以下情況會非常積極的配合：

１.耐心的讓工程師理解產品/功能的價值，如果是需要迅速解決的問題，說明其嚴重程度；

２.表明自己知道所有事情的輕重緩急；

３.儘可能的討論需求的每一個細節。

作為曾經的三流程序員，我一直認為「技術上不能實現」是有損程序員職業尊嚴的一句託辭，如果程序員向你說了這話，那不論怎麼溝通，怎麼協調，都一定是出了什麼問題

1. 是不是他壓根就不贊成你的產品創意，或者根本就不理解這產品的價值？

——產品經理的問題，沒有交代清楚或沒有足夠重視程序員的智慧價值，只把人家當代碼機器。

2. 是不是他口中的「不能做」只是代價太大，投入產出比太低？

——不知道誰的問題，不過可以請教能力更強的程序員，確定有沒有簡單方案，沒有的話重新評估這個功能到底有多重要。

3. 是不是他的技術能力不太紮實？

——程序員的問題，可以請教能力更強的程序員。

4. 是不是他們被項目壓榨得太嚴重，沒有足夠的日常時間保持不斷的代碼重構。

——產品經理、項目經理和團隊的問題，如果程序員沒有足夠的時間重構代碼和保持學習，那??

5. 是不是在維護歷史遺留系統，很多地方只能束手無策？

——我覺得這個問題處理方式可以同2

6. 是不是他們已經得過且過，只想混日子等退休了？

——換個人再問問。

在大公司這樣比較常見，大家都是打工的，彼此會權衡些私人利益。對產品經理來說，產品業績就是他的全部 KPI，所以會想多提一些需求，多做一些嘗試，很多需求毫無價值可言。而技術人員會希望把更多的時間用在提高個人水平上，產品業績只是他一部分的 KPI。對產品經理個人的不認可與對產品方案的不認可都可能產生推諉的態度，雖然這很不職業。

當然有一種情況是產品經理是打雜的，還有一種情況是開發是混飯吃的，這種都可以忽略不提。

在創業公司大家一起奮鬥的條件下，產品經理會深度思考產品價值，而技術人員則同時要為產品與技術負責，因為產品是大家共同的命脈。如果這個時候還不能坐在一起好好討論，共同尋找解決方案的話，那要不其中一方走人，要不公司就可以 GG 了。

我的看法：

1.找出已經實現了此細節的產品，大家一起商量

2.找出做不了的原因，fix他

3.自己平時也要了解一下技術，起碼要有基礎

4.盡量原型初期就要讓研發參與評估，避免出現這類情況

因為你的創意木有感動他。

這是一個真實的故事：

某工程師：這個技術上不太好實現。

馬化騰：你說什麼？

某工程師：好我再想想辦法

一周後，功能上線～

1、詢問靠譜的做技術的兄弟，看看那個技術是不是在忽悠你。如果不是忽悠，那就重新設計產品去。

2、收買人心，動用個人魅力。

3、動用政治手段。

4、自己學技術證明能實現。

5、以上幾點沒能力做到的話，改行。

這樣的問題可以從自己和對方兩個方面來分析。

自己的問題

自己是否完全清楚自己做的目標是什麼
自己是否完全講清楚了做這件事情的價值
自己是否理解了對方曾經提到過的問題和限制
對方提出的問題和限制，自己是否已經有解決方案

對方的問題

對方是否是回答這個問題正確的人
對方是否真的思考過這個問題，他的理由是什麼
他目前的情況是什麼，比如工作時間安排，知識結構
其他人怎麼看待這個問題。

其實這個問題很簡單就能解決。

上面很多哥們也都說過，就是找個大家都認的技術大牛評估下開發工作量。如果工作量確實很大，那就需要設計和開發做妥協，設計經過調整實現類似功能但是會大大降低開發工作。

最後將調整之後的開發方案，大牛程序員，你的程序員，你，開個圓桌會議討論下不就解決了。

除了性格確實彆扭的程序員，大部分都是樸實的，如果給他明確的思路，在他的能力之外，他是肯定會幹好這件事情的。

用梯子，一個梯子緊接著一個梯子，堆積起來，能登上月球么？

能的，可以的，可以論證的。

問題是，這麼做的代價有多高？

沒有技術「做不了」的

但是要考慮實際的成本

成本包括金錢上的和時間上的

最好還是和技術部門協商解決

自己是一個三流技術+四流PM。

兩年前跳槽，踏入國企保險箱，有很多自己的時間，常常接業務。

根據所在項目的不同，經常在兩個角色之間來迴轉換。

對於技術而言，不管自己是幾流的，對著對方說：沒法做。的確是一件非常丟臉的事情。

這句話的出現往往是幾個原因導致的：
1、基本功不紮實（根本不知道怎麼寫這樣的功能）

2、自己懶得做，PM又比較好虐（覺得他們反正不懂，虐幾次如果成功了真的會上癮，反正做何不做工資一樣）

3、PM催的太緊，時間不允許（給出自己的預估時間表，說明行業里這玩意一般要做多久，說的誠懇點，PM都會接受）

4、PM方的需求不明確，PRD沒看懂，不敢打包票。（這個可以和PM做溝通，一般都可以實現）

4條中：

1，2是技術自己的問題；

3，4是PM的表述問題，這個要看實際情況而定。

溝通的好，3，4都不是很問題，但是1，2就很成問題。

遇到1，2，解決方法只有一個：換人或者換團隊。
===============================================
廢話開始的分割線，心急的請右上紅叉
===============================================

這是個PM提出的問題，所以站在PM的角度上來說一下自己對這個問題的解決方法（主要是跳槽後的那段時間遇到的）

跳槽前，自己呆的公司其實很符合這個問題，PM強悍，技術卻只有大二水準。99%的PM不懂技術，基本天天被技術蹂躪了還不知道。

跳槽後，自己做項目。我再次發現，人的底線是不斷被刷新的。

最近遇到一個項目，是DZ論壇的遷移，大致是6個DZ論壇合併到一個DZ中，這個對於一般的技術來說，完全是小菜一碟的事情，甚至稱不上項目，只是一個日常級別的東西。

但是，我遇到的團隊里的技術卻告訴我，沒法做。

聽到這個結果，我傻了。晚上找技術吃夜宵，順道提起這事情。問原因後，差點把啤酒吐到地上：技術只會點滑鼠，出了DZ的UC後台，就啥都不會了。（找國企里的技術，做項目害死人，不是我招的人，沒辦法）

但是，事情還是要做的。

第一步：沒法做，變成了，很難做。

和所謂的技術聊了一晚上後，發現他們大致是擔心幾個問題：

1、不知道怎麼做，擔心做錯了有風險（PHP,MYSQL完全不懂的人，的確做這個有風險）

2、網上沒相關的插件做，收費免費的都找過，沒有。自己也不會寫。

3、這個做了有啥用，不明白。

4、康盛那邊的支持太貴

分析了他的話：

1、沒啥好說，這個基礎的話，的確有風險

2、值得慶幸的，他還是有探索精神的，至少會主動去找，在不能換人的情況下，的確是一個利好消息。

3、這個我覺得不是技術要考慮的事情，但是向他解釋也不難：領導說的（這句話在國企里，非常有效）

4、費用這塊，我可以去領導那邊爭取，也是一個希望。

這樣看來，結合2，4。如果找到了插件，或者有錢找康盛，事情還是可以做的。

第二步：可能性從0%到了80%

接下來，因為自己參與過康盛的外包項目，對它們的資料庫表結構和核心代碼還是有比較深刻理解的。自己分析了這個項目的技術難點，列出幾個攻克方向：

1、不同庫遷移合併的TID，FID重複問題

2、URL的分配問題

3、用戶庫的數據整合

4、用戶信息的整合

5、同用戶，信息差異的處理（合併前，分別註冊的用戶，他的密碼，個人資料如何合併）

。。。。。。

大概15條的樣子。

拆解後發現，其實還是有很多現成插件可以解決其中問題的。

第二天找技術，說自己的看法，技術很開心，馬上按照我列的15條去找相關的插件，一天里湊到了12條。

第三步：100%解決

接下來的3條，客觀的說，我自己寫個腳本就可以搞定了。不過我老東家的領導經常和我說：PM就要考慮PM的事情。

所以，站在PM的角度上，就不扯技術的東西了，直接找領導，寫了個方案（省略N萬字）

結果其實也簡單的，當領導看到一個玩意80%都搞定了，最後20%只要找點外援幫助一下就行，審批下來也是非常快的。

另外，因為80%是自己團隊搞定的，技術那邊的面子也照顧到了。不會讓技術太難看。

折騰了1周的公關，最後，康盛那邊的支持費用申請下來了。

這個事情，一波三折，但是我覺得這樣比較好通過事例來解釋這個答案。

當然，我還是一句話，如果遇到了懶得不想做，或者欺負外行不懂的技術，換人是唯一辦法，否則上帝都救不了。

作為一個PM，在跟研發人員探討（噴）「為什麼做不了」之前先自我反思一下，看看要加的功能是否能解決客戶的主要問題，滿足其迫切需求。查查你的主要競爭對手是否已經做了這個功能並且已經當賣點在大力宣傳。翻翻運維最近的反饋，看看是不是很多客戶都在抱怨產品缺少該功能。搜搜市場信息，有沒有潛在客戶對該功能發出了呼籲。

如果該功能符合上述任意要求，就可以跟開負責人談談（注意，此處一定是負責人，如果你覺得自己的level跟負責人談不上，那請escalate給你的老大）。一般情況下senior的developer不會直接說做不了，因為這樣顯得他們能力不行。如果他們直接表明這個功能做不了，那90%以上是他們認為你說的這個功能就是一個便便，完全沒必要花時間去想代碼如何實現。如果是這種情況，那你就得拿出「證據」來說服研發，讓他們明白功能的重要性，只要說通了，基本上就不會出現「做不了」這三個字。記住，重中之重是要拿出來「證據」說明問題，不要空想，因為你想客戶可能需要，可能在市場大賣，但是現實往往是很殘酷的。所以與其你吐沫星子滿天飛的跟研發描述功能如何如何重要，如何如何絢麗，不如直接拿出客戶的反饋，競爭對手的資料以及市場調研的結果來說明問題。做產品的前提一定是要跟研發統一成一條戰線，如果心不齊，做出來的東西註定失敗。

如果和研發在產品的重要性問題上達成共識，下一步你要了解一下他們完成當前這個需求有什麼困難，是缺人，缺時間，還是缺錢。

多數情況下研發都會說時間不夠，比如說你要下個月release，但是他們要3個月來完成這個功能，此時就需要你們之間進行博弈，雙方都進行一些妥協，比如說改成2個月後release，同時研發同事平時和周末加加班；再比如先把基礎功能實現，一些nice-to-have的先放一放；或者說通過另外一個功能的改進進而實現該需求等等。

如果是缺人（比如少UI工程師），可以想辦法幫忙做部門之間的協調，看看是否可以砍掉之前要開發的功能，釋放一部分人力資源。

如果是缺錢（通常指的是缺少相關開發設備），產品經理可以牽頭跟老闆說明情況，申請資金，幫忙協調等等。

當然，如果你提出的功能不滿足上面任意一種情況，那很有可能研發說「做不了」是有情可原的，這種情況你就沒有必要糾結了，抓緊時間提高業務能力吧。

所以說：

作為靠譜的工程師，他們是覺得說出「做不了」這三個字是一種恥辱的。所以更多還是沒有把「為什麼這樣做」說到位吧........ 或是他們覺得跟得到的比，收穫小於代價......

沒有功能在技術上不能實現！

無非是他不想做！

他的知識儲備里沒有做的方法

他的知識儲備里的方法太過繁瑣耗費巨大

贊同張恩澤的回答，再做些小的補充

——————————————————————————————————————

前提：技術的工作熱情沒有問題，無需置疑

那麼還有一種情況就是PM自己對需求的提出沒有進行長遠規劃，沒有遠景的思考，造成技術架構無法根據後續需求的變更進行調整，這個責任其實在PM自己啦，應該在後續的工作中養成做到「走一步想兩步」的思考習慣；

——————————————————————————————————————

前提：技術的工作熱情有問題，他經常這麼抱怨

那麼可以嘗試和他多溝通，看看他到底有什麼心裡障礙造成他工作熱情不高，多多鼓勵他，如果還是不起作用那麼只能向他的直接上司反應這個問題了，讓他的直接上司去敲打他；

把實現了類似功能的程序拿給他看。程序員大多很懶，可能會推脫看似麻煩的需求，但一般來說都有不服輸的特質。

之前 @和菜頭對程序員們有過這樣一段的描述：

(我個人覺得這段話描述得實在太準確了)

越來越喜歡IT工程師了。首先他們很直率，你提出任何非標類需求，他們都會說：你媽逼你瘋了，這個絕對做不了！然後，你拿出國外的或者別的團隊做出來的一樣的東西，馬上告訴你：哦，那我們可以試一下。過幾天甚至能拿出個更好的來。這種樸質的職業榮譽感在今天已經很少見了，非常可愛。
關鍵是有證據別人當真會認的，不會跟你扯什麼國情不同啦，系統不同啦，開發工具不同啦，中國互聯網特色啦。那種「既然別的工程師可以做到，那麼我也可以做到」的小勁頭，每次都能把我感動得嘩啦嘩啦的。

噢，對了，我是一個程序員（?▽? ）

做不了真不是問題，是可以通過溝通來確定到底該怎麼辦的。

特么做到一半兒跑過來告訴你做不了才是問題。。。。某以產品著名的互聯網公司里的真事兒。

我覺得這個問題有幾個方面可以說一下：

1、溝通問題。產品人員要儘可能的去跟開發人員去溝通，這樣的實現方式是為了解決什麼樣的問題，我覺得從解決問題的角度出發，開發人員不會給出「做不了」的答覆，有時候我們應該去傾聽一下開發人員的解決這類的方案。

2、流程或者邏輯目前的產品架構是否支持。很多時候產品人員會一味的想要做出什麼樣的產品出來，出發點沒有錯，但是很多時候我們應該需要考慮一下提出的功能改進或者新功能現有的產品架構是否能夠滿足。

3、溝通方式。我覺得很多時候都是在這個點上出現的問題，與人溝通的方式，技巧。語言的藝術就在於我們能夠用其他的話術來描述，可能會得到另外一個結果。

4、可行性分析。PM，RD，你們懂的。

5、時間問題。PM應該了解整個項目的時間進度。

6、PM是否需要了解一下技術知識？

做不了至少分2種情況

第一：真的技術上無法實現

再細分：

1.設計本身的問題

重新設計

2.目前的技術水平下無法實現

與技術溝通，一起找折中方案

第二：技術人員不想做或者自己的水平問題

溝通，了解技術人員真實的想法，問問他的意見

解釋，解釋你為什麼要這麼設計，收益是什麼，最好將收益量化

目標一致，想辦法讓技術人員覺得做這件不是技術人員在滿足PM，而是大家一起在做一件對產品有益的事兒，話有三說，巧說為妙

找其他技術人員介入，注意操作手段，誰都要面子。