技術不愿意接產品經理提的需求，該怎么辦？這不僅僅是面試中經常被問到的問題，也是實際工作中常碰到的情況。作者從為什么開發不愿意做、怎么做展開了，最后也挖掘了個人之外的因素，來看看能否給你帶來啟發吧~

這個問題，在產品經理面試時的“出鏡率”是比較高的，我之前也經常問，但是沒有遇到過比較滿意的回答。而且這個問題對于實操性的要求非常強的，能否順利解決，不僅考驗著這位產品人的基本能力，如溝通、權衡、協同，也決定了他的思維能力、全局思考和透過現象挖掘本質的能力。

同時，類似的問題不僅限于產品和技術之間的協同，很多其他工種之間也會存在相似的困惑。

所以今天簡單總結我的做法，希望能夠在面試或者實際工作中為大家帶來一點幫助。當然，我的解法都是從工作中積累而來，可能存在一定的局限性和行業性，因此希望讀者能夠以小見大、舉一反三、不吝賜教。

1. 先分析常見的推諉原因，并對號入座；
2. 再思考原因背后的故事，找到應對方式；
3. 最后挖掘個人之外的因素，即是否存在“治標治本”的方法。

一、他為什么不愿意做？

這個問題可能有很多原因，整體區分為以下幾類：

1、個人態度問題，習慣躺平

雖說這兩年行業整體風氣有些下滑，但很多人只是在網上吐一時之快，真正在工作時還是能夠認真負責。但自始至終存在一部分人的工作態度有問題，尤其是面對一些需要“共進退”的階段性挑戰時，團隊的整體戰斗力則受限于這塊最短的木板。

• 這個我干不了，你找別人吧；
• 這個不是我負責的，你找別人吧；
• 這段代碼不是我寫的，我也不知道怎么改。

諸如此類，很容易讓你情緒出現波動。

2、工作難度問題，確實不好干

產品經理經常會苦于領導/客戶的“一句話”需求，會覺得領導把問題想簡單了，這個需求做下來真的不容易啊。類比到技術同學也是同樣的道理。

有時我們認為不就是加一個狀態嗎？不就是多了一步操作嗎？怎么就不好改了?？赡苓€真的就不好改哦。里面涉及到很多技術層面、架構層面、關聯業務層面的改動，可謂牽一發而動全身。

所以很多同行會說，產品經理懂技術的話，是否能夠更有助于工作？關于這個問題去年我也寫過一篇看法（辯證難題 | 產品經理要不要懂技術）。

面對這個問題時，如果懂技術，則可以區分出來這個難改，到底是真的難改，還是對方夸大其詞，或者困在其中。

3、職責劃分問題，擔心背鍋

有時技術同學不愿意做，可能是擔心做不好：

• 比如中途接收別人的項目，現在又要在項目的基礎上進行迭代，他內心慌得一批；
• 比如最開始需求范圍定了10個功能，結果在討論的時候衍伸出來了3個，那他可能就不愿意做多余的內容；
• 也可能存在相反的情況，在最終分析的時候，發現了一些功能隱患，他覺得需要做。雖然產品說可以先不管，但他依然覺得應該做。

諸如此類，都是在執行的過程中出現了一些偏差，讓他擔心這些工作按照產品的想法推進之后，會對自己產生一些不利的影響。

4、優先級排列問題，沒時間搞

無論是個人，還是技術小組，大多數都不會只做一件事。當涉及到多個任務并行時，就要考慮優先級的問題。

可能你需要他支持的工作很重要，但是他手上有自己的直屬領導安排的其他任務，也可能有自己覺得比較重要的任務。這些任務都還沒做完，產品又來加塞，那我肯定不愿意搞咯。

5、個人性格問題，執拗不聽勸

這一類問題，雖說很多人可能都會出現，但更難協調的是一些技術水平不錯的伙伴。他們有自己對技術的追求，也有自己對業務的見解，經常會覺得你的設計不合理。

也許是你的設計真的不合理，也許是他在鉆牛角尖。而解決鉆牛角尖的情況，則不太容易。

6、我的問題，需求本身沒搞明白

我們往往會忽略自身的原因，就像前幾天我和同事溝通時說的一樣：

我們很多時候的關注點都在外界，喜歡挑別人的毛病，卻很難保證自己的任務不出大的偏差，時而忽略自己工作的完整性和合理性。

其實有很多產品同行，在最初定需求的時候并沒有把這個場景搞明白，或者沒有把系統現狀搞明白，所以提出來的新需求確實缺少合理性。

當我們不覺察這些問題時，輕易去向下一個節點推進，不僅會困難重重，也將為自己后續埋下一些不好填的坑。

7、工作模式問題，逐漸崩塌的信任感

如上一條所言，當自己的工作缺少完整性時，很容易讓其他同事缺少對自己的信任感，后續即便自己提出合理的需求，也可能會先被質疑，從而形成惡性循環。

同理，技術同學也是這樣。當有些人推諉的緣由被你識破之后，即便以后真的有難題，你也會習慣性的以為他又在找理由。

所以，這種現象不僅是個人問題，也可能是團隊內部工作模式的問題。

二、方法總比困難多

以下提及的方法并不與上述問題一一對應，在實踐過程中，往往是多種方式一起組合，效果才會更好（你還有哪些好的辦法，歡迎一起分享）。

1、維護好私人關系，哪里都有人情世故

“人情世故”四個字是咱們的傳統文化，工作生活方方面面都離不開。所以在這個問題上依然可以采用。

私下和同事多聊聊天，一起吃吃飯，喝個奶茶啥的，一定要自己主動，因為技術同學，更多比較直爽，而且都很單純，內心并不像其他崗位那么復雜。所以你對他好，他大概率會對你好（當然，并不是所有人都值得我們付出，相信這一點大家也都能理解）。

前些年，在這個問題上我非常有感受。因為和大多數同事的關系還不錯，當我需要幫助時，電話打過去都能收到快速的支持。同時我也會這樣回饋對方。

久而久之，你會發現有些人值得你做到100分，甚至值得做到120分，當然也有很多我只會付出60分或者80分。

自己尚且如此，何況對方呢？

但是這又可能會引起另一個問題：公司內部的“小團體”作風。當然這是另一個問題，不在今天的討論范圍之內。

所以，第一個解法便是“適度、適當的維護好私人關系”。

2、“擦干凈”共同的目標

產品經理所負責的需求，有哪些價值，要達成什么目標，自己是清楚的。但是技術同學并不清楚，或者不覺得你的目標也是我的目標。

所以，如果想讓對方盡力配合，第二個解法則是梳理雙方的共同目標。

• 比如技術同學可以通過此次迭代承接團隊內重要的模塊，可以接觸更新的技術，更完整的架構，可能會涉及到性能問題需要他解決
• 比如這件事做好之后，在領導那里是加分的，對后續的職業發展有好處，或者有重要客戶提出來的問題，我們及時響應之后對團隊會有哪些利好

隨著被諸多繁雜事項的干擾，我們很容易陷入每件事的局部思維中，恰恰缺少了對于做這件事的目標認知。所以和對方溝通需求的重要性，需求的價值，以及做完之后我們的收獲，你的收獲，試著點燃對方心中的火種。

當然，這種方式不能濫用，否則容易變成“畫餅”，技術同學比產品同學更煩“畫餅”，因為他們的思維更直接，思想更單純。

我也不建議在自己沒有準備好，或者自己沒有想清楚之前使用，容易被對方給懟回來，反而得不償失。

但是，畢竟產品經理的溝通能力理應能夠搞定這個問題，否則將來如何面對客戶、面對上級的各類更加復雜的場景呢？

3、把“令箭”包裝成“雞毛”

古有“拿雞毛當令箭”的俗語，而我今天的第三個解法，則是把“令箭”包裝成“雞毛”。這種方法屢試不爽。

比如，之前客戶提出了一個有點難度的需求，我們設計好方案之后，技術負責人覺得改動太大，于是設計了一個新的方案。

新方案的工作量將近少了一半，大多數場景也能解決，但是拓展性不好。如果這時我們采取較為強硬的態度與其溝通，對方很可能陷入“牛角尖”的情緒，你們爭執一通并沒有效果，反而傷了和氣，于是我們可以采用“緩兵之計”。

之后我苦思冥想，想到了一個特殊場景，這個場景現有的設計無法支持，而此場景雖說頻次不高，但確實存在。剛巧，過兩天我要和技術負責人一起出差，于是我便在出差任務完成后，大家都很放松的時刻提起了這件事。

通過場景描述，再進一步說明這個客戶多么重要，現在雙方合作越來越好，新版本發布之后能夠收到怎樣的效果，讓對方通過場景來發現現階段設計的不合理性。

最終，我沒有說讓他改，他說這玩意得改啊。我反倒“裝起來”問他：這好改嗎？工作量不小吧？他說，一會兒回去6個小時的高鐵，只要沒人打擾我，下車就弄完了。

所以啊，很多時候，工作也是套路和反套路的過程。

4、適度示弱，激發對方的善意

類似的情況，還有一種解法，則是主動“示弱”。

很多人不善于在職場上示弱，會覺得這樣有損形象，但殊不知“越是張牙舞爪的人，內心越脆弱”，主動示弱的人，則是真正的有自信。

記得初入職場的那幾年，有一次在客戶現場做攻堅項目，我負責需求但并不熟悉這個需求，客戶卻是一位老江湖，我始終被牽著鼻子走。在開發階段需求依然經常變更，而且很多變更我都無力反駁，造成團隊內部開發人員也是怨聲載道。

在聯調測試后期，客戶把之前的一個需求變更又改回去了，這次修改浪費了我們兩周的時間。散會之后我不知道如何向兄弟們說這件事，最后采用了主動示弱的方法。

我和開發的兄弟們表達這段時間的委屈和無奈，同事主動過來安慰說：算了，沒事，反正也快上線了，咱們再最后改一次，改完也就熬過去了。

這次的經歷，雖然把當下的問題解決了，但我始終處于自責之中，也為我后續的需求、產品、項目管理等工作積累了一些經驗，這些經驗并不是今天所說的主動示弱，而是在需求把控、進度把控、客戶溝通上的技巧。

所以，每一次失敗，并不是讓自己放棄的理由，從失敗中收獲，整理背包再次上路，才是我們更應該堅持的選擇。

5、一起解決他的問題

如果技術人員確實遇到了難題，我們首先要做的不是“嫌棄”，而是主動伸出手來幫助。畢竟，這是你負責的需求，你也要為最終的結果負責。

所以我們經常會和技術團隊一起分析業務場景和處理邏輯，或者主動梳理系統現狀，從中尋找問題的難點，并試著找出可以解決的思路。

這時，則需要我們對業務場景理解的更透徹，對于功能操作之后的“業務處理邏輯”有清晰的認知。比如我們通過查日志，畫出此功能的現狀流程圖，對照著流程圖進行修改，同時分析出這次變更的關聯功能。

總之，要拿出一個積極的態度和主動的行為，一起解決問題。這樣體驗一段時間之后，不僅自己對于業務的理解更加全面，在同事中的信任度也會逐漸增強。

6、把對方“騙”上一條船

在需求正式開始推進之前，對于系統中涉及的現狀、修改難度、迭代合理性等問題，我們可以提前、非正式、多次和技術人員溝通，其中的一些小問題也可以拋出來。比如現在系統只能支持A場景，如果后續客戶想要支持A+的場景，我們有哪些方式可以拓展呢？

通過技術同事主動幫忙分析建議，最終整理出來的方案，起碼從可行性上不會受到排斥。而且這個過程中又體現了他的價值，開會的時候也可以說，之前通過張三的幫助，幫我們設計出了一個比較可行的方案，下面我們一起來評估一下。

這樣即給了張三面子，又把他拉上船。

7、協調新的資源

這個方式，是大多數同學都會想到的，我把它放到最后，而且也不打算展開介紹。

因為很多時候，資源不會那么容易協調到位，更多的情況還是需要利用現有資源來解決問題。而且上述的6個方法已經能夠解決大多數情況。

自古真情難留住，偏偏套路得人心。

談戀愛如此，推進工作依然如此。畢竟每個人都不是一個獨立存在的個體，也不是說拼到一起就能成為牢固的積木。

每個人都有自己的訴求，每個團隊都有自己的核心利益和目標，每個領導也都有自己更加看重與追求的方向。

所以在這樣一種復雜的環境下，經常會讓我們推進乏力。但只要我們放平心態，冷靜思考，逐個擊破，終究會找到很多種解法。畢竟我們的工作內容和難度，在高水平選手看來并不值得一提。

也許我們追求的技巧，只是別人的基本功罷了。所以這些困難，并不是真正的困難。

三、也許是團隊管理的綜合問題

1、態度欠缺的選手為什么會招進來、留下去？

1. 團隊的招聘+用人制度，或執行層面遇到了難題
2. “食之無味，棄之可惜”

首先，從面試到轉正，這個過程沒有統一標準，或者缺少一些考核或可量化標準。

不過這個問題比較大，如果細說可能又需要一篇長文。去年我也整理過一些面試、試用期培養/考核之類的經驗，可以查看歷史文章。

相信各個公司、團隊都有相關的流程制度，很多領導也想提升這方面的管理和效率，但真正推進之后的效果，以及人員的執行情況，確實相差甚遠。

畢竟，很多團隊都是在解決看起來“重要且緊急”的事情，從而忽略了“重要但不緊急”的事情，導致惡性循環。

另外，當我們發現有些團隊成員在某些方面存在問題，或者無法達到繼續留用的標準時，也會很難選擇淘汰。

我們暫且不說淘汰相關的利益問題，僅從團隊用人角度來看，經常會出現“這個人雖然有很多問題，但是也能解決一些問題，總比沒有強”、“下一個也許還不如這一個”諸如此類的想法。

因為人的問題，導致事的問題，又因為事的問題，導致沒有精力解決管理的問題，從而惡性循環，疲于奔命。

所以，從上述的需求難以推進，我們可以分析出團隊成員的問題，而團隊成員的問題均來自于團隊管理的問題。

我想，正是這些表象背后反映的深層次問題（當然，如果再去深挖管理問題背后的問題，那又要大書特書，本文就到此為止吧）。

2、資源為什么一直不足？

解決問題時，比如在優先級確實排不開，技術人員確實沒時間，但你又很著急的情況下，我們會很容易想到協調資源。

但是往往這些資源很難協調到，可能我們將長期面臨著在資源不足的情況下開展工作的現狀。

那么，我們可以進一步思考，資源為什么一直不足？是你所處的團隊問題，還是自己負責的需求沒有那么重要？亦或是公司本身的運營模式問題？不同的問題也對應著不同的態度和解法。

并不是一句資源不足，就能解釋這些問題，因為資源只是表象，其背后的底層原因，才是真正的問題所在（我發現最后這四條，每一條都能展開單獨寫一篇長文）。

3、“準入準出”的流程是否完善？

其實這里又涉及到整個項目管理或者研發管理的流程，只不過從產品和技術對接過程來看，主要在于需求分析、系統設計的準入準出條件。

• 需求池的哪些需求計劃歸入下一個迭代版本？不在最初選擇時就挑一個不可能完成的任務，或者對于團隊而言價值不高的任務；
• 需求分析完成后，如何規范需求評審流程，從而保證評審通過的需求能夠順利進入系統設計階段，而非在設計階段質疑需求的合理性并進行推翻；
• 系統設計階段如何保證能夠滿足本次需求的目標，保證最終的交付物盡量不打折扣，保證具體的技術人員能夠理解自己的設計流程和規范

還有很多其他相關的問題，而這些問題背后所反映的則是流程中的準入準出條件不規范，或者執行不足。當這些規范性制度存在之后，也能夠減少在對接過程中的推諉扯皮。

所謂治本，則是從這些方面下手，而不是遇到問題解決問題。

當然，沒有絕對完善的流程，也沒有能夠把完善流程不打折扣落地的執行者。很多流程的推進受阻，除了流程本身的不適用，也存在團隊與流程之間的“水土不服”，這又是一個非常復雜的問題。

我提出這個觀點，并不是說一定要通過流程才能提升效率，而是讓大家提升對于“流程”、“規范”的重要程度，避免在日常工作中僅在思考大量的執行，僅是不斷陷入事務的海洋里，而缺少了探出頭思考習慣。

4、有沒有可能，你覺得是問題，領導并不覺得是問題？

領導并不覺得這是問題，這句話要兩面看：

第一反應可能覺得是領導沒有察覺，進而覺得這領導水平不行，這么明顯的團隊管理問題都不知道，長此以往還有沒有必要長期干下去？

而另一層意思，則是這些問題在領導的意料之中，他采用了“無為而治”的方法，在問題處于可控范圍內時，讓其任意發酵，同時在發酵的過程中，歷練、磨合、篩選團隊成員，從中尋找誰能主動擔責，適合委以重任，誰只能作為一塊磚來使用，誰又不適合團隊現狀。

讓團隊經歷一些困難與磨煉，后續的戰斗力往往會更強。畢竟自己摸索出來的解法，比領導直接安排的流程要更容易被遵循。

如果遇到第一種領導，我覺得還是早遛為上；如果遇到第二種領導，那么恭喜你，你的成長空間還有很多。

四、寫在最后

所以說，很多問題背后的原因并不是真正的原因，透過表象看本質，本身也是產品經理在進行需求洞察時的必要能力。而運用到團隊協作等領域時，這種能力依然可以發揮著重要的價值。

解決問題，既要治標，又要治本，有時揚湯止沸立竿見影，有時釜底抽薪效果更佳。

最終面對今天提到的問題，原因有很多，解法也有很多，更重要的是不帶入主觀情緒，結構化思考，拆解出一個又一個可執行方案，然后在實踐中總結。

畢竟，產品經理是要真正解決問題的人。

今天的分享，有些方法可以直接用于日常工作，有些思維可以幫助我們建立更全面的分析和洞察能力，而且將本文的內容進行提煉精簡，再融入自己工作中的例子，應該能做到一個不錯的面試回答。

希望能為各位帶來一點幫助。