如果你提的需求，技術同學“百般推諉”怎麼辦？
技術不願意接產品經理提的需求，該怎麼辦？這不僅僅是面試中經常被問到的問題，也是實際工作中常碰到的情況。作者從爲什麼開發不願意做、怎麼做展開了，最後也挖掘了個人之外的因素，來看看能否給你帶來啓發吧~
———— / BEGIN / ————
這個問題，在產品經理面試時的“出鏡率”是比較高的，我之前也經常問，但是沒有遇到過比較滿意的回答。
而且這個問題對於實操性的要求非常強的，能否順利解決，不僅考驗着這位產品人的基本能力，如溝通、權衡、協同，也決定了他的思維能力、全局思考和透過現象挖掘本質的能力。
同時，類似的問題不僅限於產品和技術之間的協同，很多其他工種之間也會存在相似的困惑。
所以今天簡單總結我的做法，希望能夠在面試或者實際工作中爲大家帶來一點幫助。當然，我的解法都是從工作中積累而來，可能存在一定的侷限性和行業性，因此希望讀者能夠以小見大、舉一反三、不吝賜教。
我對於這個問題的解法，整體分爲三個步驟：
先分析常見的推諉原因，並對號入座；
再思考原因背後的故事，找到應對方式；
最後挖掘個人之外的因素，即是否存在“治標治本”的方法。
這個問題可能有很多原因，整體區分爲以下幾類：
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. 態度欠缺的選手爲什麼會招進來、留下去？
這個問題，是我近兩年也很困惑的問題，以現在的視角來看，主要是兩個原因：
團隊的招聘+用人制度，或執行層面遇到了難題
“食之無味，棄之可惜”
首先，從面試到轉正，這個過程沒有統一標準，或者缺少一些考覈或可量化標準。
不過這個問題比較大，如果細說可能又需要一篇長文。去年我也整理過一些面試、試用期培養/考覈之類的經驗，可以查看歷史文章。
相信各個公司、團隊都有相關的流程制度，很多領導也想提升這方面的管理和效率，但真正推進之後的效果，以及人員的執行情況，確實相差甚遠。
畢竟，很多團隊都是在解決看起來“重要且緊急”的事情，從而忽略了“重要但不緊急”的事情，導致惡性循環。
另外，當我們發現有些團隊成員在某些方面存在問題，或者無法達到繼續留用的標準時，也會很難選擇淘汰。
我們暫且不說淘汰相關的利益問題，僅從團隊用人角度來看，經常會出現“這個人雖然有很多問題，但是也能解決一些問題，總比沒有強”、“下一個也許還不如這一個”諸如此類的想法。
因爲人的問題，導致事的問題，又因爲事的問題，導致沒有精力解決管理的問題，從而惡性循環，疲於奔命。
所以，從上述的需求難以推進，我們可以分析出團隊成員的問題，而團隊成員的問題均來自於團隊管理的問題。
我想，正是這些表象背後反映的深層次問題（當然，如果再去深挖管理問題背後的問題，那又要大書特書，本文就到此爲止吧）。
2. 資源爲什麼一直不足？
解決問題時，比如在優先級確實排不開，技術人員確實沒時間，但你又很着急的情況下，我們會很容易想到協調資源。
但是往往這些資源很難協調到，可能我們將長期面臨着在資源不足的情況下開展工作的現狀。
那麼，我們可以進一步思考，資源爲什麼一直不足？是你所處的團隊問題，還是自己負責的需求沒有那麼重要？亦或是公司本身的運營模式問題？不同的問題也對應着不同的態度和解法。
並不是一句資源不足，就能解釋這些問題，因爲資源只是表象，其背後的底層原因，纔是真正的問題所在（我發現最後這四條，每一條都能展開單獨寫一篇長文）。
3. “准入準出”的流程是否完善？
其實這裡又涉及到整個項目管理或者研發管理的流程，只不過從產品和技術對接過程來看，主要在於需求分析、系統設計的准入準出條件。
需求池的哪些需求計劃歸入下一個迭代版本？不在最初選擇時就挑一個不可能完成的任務，或者對於團隊而言價值不高的任務；
需求分析完成後，如何規範需求評審流程，從而保證評審通過的需求能夠順利進入系統設計階段，而非在設計階段質疑需求的合理性並進行推翻；
系統設計階段如何保證能夠滿足本次需求的目標，保證最終的交付物儘量不打折扣，保證具體的技術人員能夠理解自己的設計流程和規範
還有很多其他相關的問題，而這些問題背後所反映的則是流程中的准入準出條件不規範，或者執行不足。當這些規範性制度存在之後，也能夠減少在對接過程中的推諉扯皮。
所謂治本，則是從這些方面下手，而不是遇到問題解決問題。
當然，沒有絕對完善的流程，也沒有能夠把完善流程不打折扣落地的執行者。很多流程的推進受阻，除了流程本身的不適用，也存在團隊與流程之間的“水土不服”，這又是一個非常複雜的問題。
我提出這個觀點，並不是說一定要通過流程才能提升效率，而是讓大家提升對於“流程”、“規範”的重要程度，避免在日常工作中僅在思考大量的執行，僅是不斷陷入事務的海洋裡，而缺少了探出頭思考習慣。
4. 有沒有可能，你覺得是問題，領導並不覺得是問題？
領導並不覺得這是問題，這句話要兩面看：
第一反應可能覺得是領導沒有察覺，進而覺得這領導水平不行，這麼明顯的團隊管理問題都不知道，長此以往還有沒有必要長期幹下去？
而另一層意思，則是這些問題在領導的意料之中，他採用了“無爲而治”的方法，在問題處於可控範圍內時，讓其任意發酵，同時在發酵的過程中，歷練、磨合、篩選團隊成員，從中尋找誰能主動擔責，適合委以重任，誰只能作爲一塊磚來使用，誰又不適合團隊現狀。
讓團隊經歷一些困難與磨鍊，後續的戰鬥力往往會更強。畢竟自己摸索出來的解法，比領導直接安排的流程要更容易被遵循。
如果遇到第一種領導，我覺得還是早遛爲上；如果遇到第二種領導，那麼恭喜你，你的成長空間還有很多。
所以說，很多問題背後的原因並不是真正的原因，透過表象看本質，本身也是產品經理在進行需求洞察時的必要能力。而運用到團隊協作等領域時，這種能力依然可以發揮着重要的價值。
解決問題，既要治標，又要治本，有時揚湯止沸立竿見影，有時釜底抽薪效果更佳。
最終面對今天提到的問題，原因有很多，解法也有很多，更重要的是不帶入主觀情緒，結構化思考，拆解出一個又一個可執行方案，然後在實踐中總結。
畢竟，產品經理是要真正解決問題的人。
今天的分享，有些方法可以直接用於日常工作，有些思維可以幫助我們建立更全面的分析和洞察能力，而且將本文的內容進行提煉精簡，再融入自己工作中的例子，應該能做到一個不錯的面試回答。
希望能爲各位帶來一點幫助。
本文來自微信公衆號：不想延期，作者：不想延期
每天都有新機會，別等被卷才後悔！掃碼進羣，掌握產品 AI前沿第一手情報。