技术不愿意接产品经理提的需求，该怎么办？这不仅仅是面试中经常被问到的问题，也是实际工作中常碰到的情况。作者从为什么开发不愿意做、怎么做展开了，最后也挖掘了个人之外的因素，来看看能否给你带来启发吧~

这个问题，在产品经理面试时的“出镜率”是比较高的，我之前也经常问，但是没有遇到过比较满意的回答。而且这个问题对于实操性的要求非常强的，能否顺利解决，不仅考验着这位产品人的基本能力，如沟通、权衡、协同，也决定了他的思维能力、全局思考和透过现象挖掘本质的能力。

同时，类似的问题不仅限于产品和技术之间的协同，很多其他工种之间也会存在相似的困惑。

所以今天简单总结我的做法，希望能够在面试或者实际工作中为大家带来一点帮助。当然，我的解法都是从工作中积累而来，可能存在一定的局限性和行业性，因此希望读者能够以小见大、举一反三、不吝赐教。

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、有没有可能，你觉得是问题，领导并不觉得是问题？

领导并不觉得这是问题，这句话要两面看：

第一反应可能觉得是领导没有察觉，进而觉得这领导水平不行，这么明显的团队管理问题都不知道，长此以往还有没有必要长期干下去？

而另一层意思，则是这些问题在领导的意料之中，他采用了“无为而治”的方法，在问题处于可控范围内时，让其任意发酵，同时在发酵的过程中，历练、磨合、筛选团队成员，从中寻找谁能主动担责，适合委以重任，谁只能作为一块砖来使用，谁又不适合团队现状。

让团队经历一些困难与磨炼，后续的战斗力往往会更强。毕竟自己摸索出来的解法，比领导直接安排的流程要更容易被遵循。

如果遇到第一种领导，我觉得还是早遛为上；如果遇到第二种领导，那么恭喜你，你的成长空间还有很多。

四、写在最后

所以说，很多问题背后的原因并不是真正的原因，透过表象看本质，本身也是产品经理在进行需求洞察时的必要能力。而运用到团队协作等领域时，这种能力依然可以发挥着重要的价值。

解决问题，既要治标，又要治本，有时扬汤止沸立竿见影，有时釜底抽薪效果更佳。

最终面对今天提到的问题，原因有很多，解法也有很多，更重要的是不带入主观情绪，结构化思考，拆解出一个又一个可执行方案，然后在实践中总结。

毕竟，产品经理是要真正解决问题的人。

今天的分享，有些方法可以直接用于日常工作，有些思维可以帮助我们建立更全面的分析和洞察能力，而且将本文的内容进行提炼精简，再融入自己工作中的例子，应该能做到一个不错的面试回答。

希望能为各位带来一点帮助。