如果你提的需求,技术同学“百般推诿”怎么办?

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

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

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

我对于这个问题的解法,整体分为三个步骤:
  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、有没有可能,你觉得是问题,领导并不觉得是问题?

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

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

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

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

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

四、写在最后

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

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

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

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

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

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

作者

不想延期,公众号:不想延期。半路转行的B端泛金融产品,坚持“以实践验证理论,以输出倒逼成长”的目标。点滴珍贵,重在积累

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部