技术不愿意接产品经理提的需求，该怎么办？这不仅仅是面试中经常被问到的问题，也是实际工作中常碰到的情况。作者从为什么开发不愿意做、怎么做展开了，最后也挖掘了个人之外的因素，来看看能否给你带来启发吧~
这个问题，在产品经理面试时的“出镜率”是比较高的，我之前也经常问，但是没有遇到过比较满意的回答。而且这个问题对于实操性的要求非常强的，能否顺利解决，不仅考验着这位产品人的基本能力，如沟通、权衡、协同，也决定了他的思维能力、全局思考和透过现象挖掘本质的能力。
同时，类似的问题不仅限于产品和技术之间的协同，很多其他工种之间也会存在相似的困惑。
所以今天简单总结我的做法，希望能够在面试或者实际工作中为大家带来一点帮助。当然，我的解法都是从工作中积累而来，可能存在一定的局限性和行业性，因此希望读者能够以小见大、举一反三、不吝赐教。
这个问题可能有很多原因，整体区分为以下几类：
虽说这两年行业整体风气有些下滑，但很多人只是在网上吐一时之快，真正在工作时还是能够认真负责。但自始至终存在一部分人的工作态度有问题，尤其是面对一些需要“共进退”的阶段性挑战时，团队的整体战斗力则受限于这块最短的木板。
诸如此类，很容易让你情绪出现波动。
产品经理经常会苦于领导/客户的“一句话”需求，会觉得领导把问题想简单了，这个需求做下来真的不容易啊。类比到技术同学也是同样的道理。
有时我们认为不就是加一个状态吗？不就是多了一步操作吗？怎么就不好改了。可能还真的就不好改哦。里面涉及到很多技术层面、架构层面、关联业务层面的改动，可谓牵一发而动全身。
所以很多同行会说，产品经理懂技术的话，是否能够更有助于工作？关于这个问题去年我也写过一篇看法（辩证难题 | 产品经理要不要懂技术）。
面对这个问题时，如果懂技术，则可以区分出来这个难改，到底是真的难改，还是对方夸大其词，或者困在其中。
有时技术同学不愿意做，可能是担心做不好：
诸如此类，都是在执行的过程中出现了一些偏差，让他担心这些工作按照产品的想法推进之后，会对自己产生一些不利的影响。
无论是个人，还是技术小组，大多数都不会只做一件事。当涉及到多个任务并行时，就要考虑优先级的问题。
可能你需要他支持的工作很重要，但是他手上有自己的直属领导安排的其他任务，也可能有自己觉得比较重要的任务。这些任务都还没做完，产品又来加塞，那我肯定不愿意搞咯。
这一类问题，虽说很多人可能都会出现，但更难协调的是一些技术水平不错的伙伴。他们有自己对技术的追求，也有自己对业务的见解，经常会觉得你的设计不合理。
也许是你的设计真的不合理，也许是他在钻牛角尖。而解决钻牛角尖的情况，则不太容易。
我们往往会忽略自身的原因，就像前几天我和同事沟通时说的一样：
我们很多时候的关注点都在外界，喜欢挑别人的毛病，却很难保证自己的任务不出大的偏差，时而忽略自己工作的完整性和合理性。
其实有很多产品同行，在最初定需求的时候并没有把这个场景搞明白，或者没有把系统现状搞明白，所以提出来的新需求确实缺少合理性。
当我们不觉察这些问题时，轻易去向下一个节点推进，不仅会困难重重，也将为自己后续埋下一些不好填的坑。
如上一条所言，当自己的工作缺少完整性时，很容易让其他同事缺少对自己的信任感，后续即便自己提出合理的需求，也可能会先被质疑，从而形成恶性循环。
同理，技术同学也是这样。当有些人推诿的缘由被你识破之后，即便以后真的有难题，你也会习惯性的以为他又在找理由。
所以，这种现象不仅是个人问题，也可能是团队内部工作模式的问题。
以下提及的方法并不与上述问题一一对应，在实践过程中，往往是多种方式一起组合，效果才会更好（你还有哪些好的办法，欢迎一起分享）。
“人情世故”四个字是咱们的传统文化，工作生活方方面面都离不开。所以在这个问题上依然可以采用。
私下和同事多聊聊天，一起吃吃饭，喝个奶茶啥的，一定要自己主动，因为技术同学，更多比较直爽，而且都很单纯，内心并不像其他岗位那么复杂。所以你对他好，他大概率会对你好（当然，并不是所有人都值得我们付出，相信这一点大家也都能理解）。
前些年，在这个问题上我非常有感受。因为和大多数同事的关系还不错，当我需要帮助时，电话打过去都能收到快速的支持。同时我也会这样回馈对方。
久而久之，你会发现有些人值得你做到100分，甚至值得做到120分，当然也有很多我只会付出60分或者80分。
自己尚且如此，何况对方呢？
但是这又可能会引起另一个问题：公司内部的“小团体”作风。当然这是另一个问题，不在今天的讨论范围之内。
所以，第一个解法便是“适度、适当的维护好私人关系”。
产品经理所负责的需求，有哪些价值，要达成什么目标，自己是清楚的。但是技术同学并不清楚，或者不觉得你的目标也是我的目标。
所以，如果想让对方尽力配合，第二个解法则是梳理双方的共同目标。
随着被诸多繁杂事项的干扰，我们很容易陷入每件事的局部思维中，恰恰缺少了对于做这件事的目标认知。所以和对方沟通需求的重要性，需求的价值，以及做完之后我们的收获，你的收获，试着点燃对方心中的火种。
当然，这种方式不能滥用，否则容易变成“画饼”，技术同学比产品同学更烦“画饼”，因为他们的思维更直接，思想更单纯。
我也不建议在自己没有准备好，或者自己没有想清楚之前使用，容易被对方给怼回来，反而得不偿失。
但是，毕竟产品经理的沟通能力理应能够搞定这个问题，否则将来如何面对客户、面对上级的各类更加复杂的场景呢？
古有“拿鸡毛当令箭”的俗语，而我今天的第三个解法，则是把“令箭”包装成“鸡毛”。这种方法屡试不爽。
比如，之前客户提出了一个有点难度的需求，我们设计好方案之后，技术负责人觉得改动太大，于是设计了一个新的方案。
新方案的工作量将近少了一半，大多数场景也能解决，但是拓展性不好。如果这时我们采取较为强硬的态度与其沟通，对方很可能陷入“牛角尖”的情绪，你们争执一通并没有效果，反而伤了和气，于是我们可以采用“缓兵之计”。
之后我苦思冥想，想到了一个特殊场景，这个场景现有的设计无法支持，而此场景虽说频次不高，但确实存在。刚巧，过两天我要和技术负责人一起出差，于是我便在出差任务完成后，大家都很放松的时刻提起了这件事。
通过场景描述，再进一步说明这个客户多么重要，现在双方合作越来越好，新版本发布之后能够收到怎样的效果，让对方通过场景来发现现阶段设计的不合理性。
最终，我没有说让他改，他说这玩意得改啊。我反倒“装起来”问他：这好改吗？工作量不小吧？他说，一会儿回去6个小时的高铁，只要没人打扰我，下车就弄完了。
所以啊，很多时候，工作也是套路和反套路的过程。
类似的情况，还有一种解法，则是主动“示弱”。
很多人不善于在职场上示弱，会觉得这样有损形象，但殊不知“越是张牙舞爪的人，内心越脆弱”，主动示弱的人，则是真正的有自信。
记得初入职场的那几年，有一次在客户现场做攻坚项目，我负责需求但并不熟悉这个需求，客户却是一位老江湖，我始终被牵着鼻子走。在开发阶段需求依然经常变更，而且很多变更我都无力反驳，造成团队内部开发人员也是怨声载道。
在联调测试后期，客户把之前的一个需求变更又改回去了，这次修改浪费了我们两周的时间。散会之后我不知道如何向兄弟们说这件事，最后采用了主动示弱的方法。
我和开发的兄弟们表达这段时间的委屈和无奈，同事主动过来安慰说：算了，没事，反正也快上线了，咱们再最后改一次，改完也就熬过去了。
这次的经历，虽然把当下的问题解决了，但我始终处于自责之中，也为我后续的需求、产品、项目管理等工作积累了一些经验，这些经验并不是今天所说的主动示弱，而是在需求把控、进度把控、客户沟通上的技巧。
所以，每一次失败，并不是让自己放弃的理由，从失败中收获，整理背包再次上路，才是我们更应该坚持的选择。
如果技术人员确实遇到了难题，我们首先要做的不是“嫌弃”，而是主动伸出手来帮助。毕竟，这是你负责的需求，你也要为最终的结果负责。
所以我们经常会和技术团队一起分析业务场景和处理逻辑，或者主动梳理系统现状，从中寻找问题的难点，并试着找出可以解决的思路。
这时，则需要我们对业务场景理解的更透彻，对于功能操作之后的“业务处理逻辑”有清晰的认知。比如我们通过查日志，画出此功能的现状流程图，对照着流程图进行修改，同时分析出这次变更的关联功能。
总之，要拿出一个积极的态度和主动的行为，一起解决问题。这样体验一段时间之后，不仅自己对于业务的理解更加全面，在同事中的信任度也会逐渐增强。
在需求正式开始推进之前，对于系统中涉及的现状、修改难度、迭代合理性等问题，我们可以提前、非正式、多次和技术人员沟通，其中的一些小问题也可以抛出来。比如现在系统只能支持A场景，如果后续客户想要支持A+的场景，我们有哪些方式可以拓展呢？
通过技术同事主动帮忙分析建议，最终整理出来的方案，起码从可行性上不会受到排斥。而且这个过程中又体现了他的价值，开会的时候也可以说，之前通过张三的帮助，帮我们设计出了一个比较可行的方案，下面我们一起来评估一下。
这样即给了张三面子，又把他拉上船。
这个方式，是大多数同学都会想到的，我把它放到最后，而且也不打算展开介绍。
因为很多时候，资源不会那么容易协调到位，更多的情况还是需要利用现有资源来解决问题。而且上述的6个方法已经能够解决大多数情况。
自古真情难留住，偏偏套路得人心。
谈恋爱如此，推进工作依然如此。毕竟每个人都不是一个独立存在的个体，也不是说拼到一起就能成为牢固的积木。
每个人都有自己的诉求，每个团队都有自己的核心利益和目标，每个领导也都有自己更加看重与追求的方向。
所以在这样一种复杂的环境下，经常会让我们推进乏力。但只要我们放平心态，冷静思考，逐个击破，终究会找到很多种解法。毕竟我们的工作内容和难度，在高水平选手看来并不值得一提。
也许我们追求的技巧，只是别人的基本功罢了。所以这些困难，并不是真正的困难。
首先，从面试到转正，这个过程没有统一标准，或者缺少一些考核或可量化标准。
不过这个问题比较大，如果细说可能又需要一篇长文。去年我也整理过一些面试、试用期培养/考核之类的经验，可以查看历史文章。
相信各个公司、团队都有相关的流程制度，很多领导也想提升这方面的管理和效率，但真正推进之后的效果，以及人员的执行情况，确实相差甚远。
毕竟，很多团队都是在解决看起来“重要且紧急”的事情，从而忽略了“重要但不紧急”的事情，导致恶性循环。
另外，当我们发现有些团队成员在某些方面存在问题，或者无法达到继续留用的标准时，也会很难选择淘汰。
我们暂且不说淘汰相关的利益问题，仅从团队用人角度来看，经常会出现“这个人虽然有很多问题，但是也能解决一些问题，总比没有强”、“下一个也许还不如这一个”诸如此类的想法。
因为人的问题，导致事的问题，又因为事的问题，导致没有精力解决管理的问题，从而恶性循环，疲于奔命。
所以，从上述的需求难以推进，我们可以分析出团队成员的问题，而团队成员的问题均来自于团队管理的问题。
我想，正是这些表象背后反映的深层次问题（当然，如果再去深挖管理问题背后的问题，那又要大书特书，本文就到此为止吧）。
解决问题时，比如在优先级确实排不开，技术人员确实没时间，但你又很着急的情况下，我们会很容易想到协调资源。
但是往往这些资源很难协调到，可能我们将长期面临着在资源不足的情况下开展工作的现状。
那么，我们可以进一步思考，资源为什么一直不足？是你所处的团队问题，还是自己负责的需求没有那么重要？亦或是公司本身的运营模式问题？不同的问题也对应着不同的态度和解法。
并不是一句资源不足，就能解释这些问题，因为资源只是表象，其背后的底层原因，才是真正的问题所在（我发现最后这四条，每一条都能展开单独写一篇长文）。
其实这里又涉及到整个项目管理或者研发管理的流程，只不过从产品和技术对接过程来看，主要在于需求分析、系统设计的准入准出条件。
还有很多其他相关的问题，而这些问题背后所反映的则是流程中的准入准出条件不规范，或者执行不足。当这些规范性制度存在之后，也能够减少在对接过程中的推诿扯皮。
所谓治本，则是从这些方面下手，而不是遇到问题解决问题。
当然，没有绝对完善的流程，也没有能够把完善流程不打折扣落地的执行者。很多流程的推进受阻，除了流程本身的不适用，也存在团队与流程之间的“水土不服”，这又是一个非常复杂的问题。
我提出这个观点，并不是说一定要通过流程才能提升效率，而是让大家提升对于“流程”、“规范”的重要程度，避免在日常工作中仅在思考大量的执行，仅是不断陷入事务的海洋里，而缺少了探出头思考习惯。
领导并不觉得这是问题，这句话要两面看：
第一反应可能觉得是领导没有察觉，进而觉得这领导水平不行，这么明显的团队管理问题都不知道，长此以往还有没有必要长期干下去？
而另一层意思，则是这些问题在领导的意料之中，他采用了“无为而治”的方法，在问题处于可控范围内时，让其任意发酵，同时在发酵的过程中，历练、磨合、筛选团队成员，从中寻找谁能主动担责，适合委以重任，谁只能作为一块砖来使用，谁又不适合团队现状。
让团队经历一些困难与磨炼，后续的战斗力往往会更强。毕竟自己摸索出来的解法，比领导直接安排的流程要更容易被遵循。
如果遇到第一种领导，我觉得还是早遛为上；如果遇到第二种领导，那么恭喜你，你的成长空间还有很多。
所以说，很多问题背后的原因并不是真正的原因，透过表象看本质，本身也是产品经理在进行需求洞察时的必要能力。而运用到团队协作等领域时，这种能力依然可以发挥着重要的价值。
解决问题，既要治标，又要治本，有时扬汤止沸立竿见影，有时釜底抽薪效果更佳。
最终面对今天提到的问题，原因有很多，解法也有很多，更重要的是不带入主观情绪，结构化思考，拆解出一个又一个可执行方案，然后在实践中总结。
毕竟，产品经理是要真正解决问题的人。
今天的分享，有些方法可以直接用于日常工作，有些思维可以帮助我们建立更全面的分析和洞察能力，而且将本文的内容进行提炼精简，再融入自己工作中的例子，应该能做到一个不错的面试回答。
希望能为各位带来一点帮助。
专栏作家
不想延期，公众号：不想延期，人人都是产品经理专栏作家。半路转行的B端泛金融产品，坚持“以实践验证理论，以输出倒逼成长”的目标。点滴珍贵，重在积累
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。