研发说做不到,产品经理怎么办?

点击上方[全栈开发者社区]右上角[...][设为星标⭐]

如果研发跟你说“这个方案实现不了”,请再想一想。不要马上否决方案,身为产品人,应该发挥缜密思维,想想研发为何这么说。找到原因之后,再想办法解决,一一击破。

产品经理设计的方案最终都需要研发来实现,如果我们的方案被研发评估为“无法实现”,该怎么办?

一、判断真伪

“无法实现”有几种可能:

  • 研发明确知道无法实现;

  • 研发不知道能实现;

  • 研发不知道是否能实现;

  • 研发明确知道可以实现却说无法实现。


1. 研发明确知道无法实现

这是比较常见的情况,研发用自己的专业能力评估了方案,确实不能实现并诚实地做了反馈。

这种情况不用多说废话,赶紧改方案。一定是我们设计方案过程中缺少了必要的技术可行性研究,这个锅咱得自觉背起来。

2. 研发不知道可以实现

研发评估之后,以为不能实现,然而实际上是可以实现的。

出现这种误判一般不会是故意,原因很可能是能力、视野的限制。这时候,产品经理可以协助寻求上级或技术专家帮助,或给予现成案例参考等,去帮研发正确评估。

3. 研发不知道是否能实现

在不知道能否实现的情况下,却告知我们“无法实现”。不管是因为没有时间去评估,根本不想评估,还是评估无结论,都不是健康的现象,这说明研发主观上可能不太想做这个方案。

4. 研发明确知道可以实现

明确知道可以实现却告知无法实现,很明显,这方案研发极度不想做。

当然,正常情况下,这种情况比较少出现。

二、真实评估

从上面的分析中可以看出,有些情况下并不是真的“无法实现”,而是判断失误、评估能力不足、非有效评估、无评估等情况下给出的错误结论。

产品经理作为团队的一份子,应尽力和研发一起去解决这些问题。技术评估不是研发一个人的事,可以考虑从以下几个角度去得到真实评估:

1. 评估意愿

评估方案往往也需要花大量的时间,并不是读一遍PRD或看一遍原型就能给出结论的。研发不愿意评估可能因为评估工作的性价比低(比如有的公司评估不计工作量)、没有足够时间(比如有些团队的迭代流程中没有规划评估阶段)、个人意愿等。

产品经理要在项目周期中合理安排时间,让研发有足够的时候去做评估;提供方案时也要讲述项目背景、目的、价格。

当做一件事有价值的时候,才有更大的动力去做好,切不可把研发只当作资源方,把方案一扔就完事了。

2. 评估能力

正确评估一下方案需要技术、经验、视野缺一不可。

产品经理在提供方案时,可以同时提供现有案例、相似产品给研发。在必要的时候,产品经理可以协助研发寻求更高一级的技术支持,从侧面帮助提高研发的评估能力。

3. 评估结论

评估后给出不真实的结论,俗称“忽悠你不懂技术”。

不考虑人品问题的话,说明这位产品经理已经失去了研发的信任,他已经不愿跟我们说真话。

三、明确原因

经过技术评估后,产品设计方案确实无法实现时,应明确无法实现的原因,以寻找对应的解决方案。

技术无法实现的原因一般有以下几种:

1. 方案原因

方案不合理、异想天开,当前没有技术可以做到。比如,“让手机壳根据UI自动换色”。

2. 能力原因

方案需要的技术能力当前团队达不到。

有的产品经理看到别的产品的功能很厉害,就想自己也做一个,却忽略了团队能力的差异。比如芯片、5G等,不是谁都能复制的。

3. 技术原因

不同技术框架有不同的特点,也有不同的不足之处。一款产品的技术框架一般不会更改,有时候会遇到技术框架限制而无法实现的功能方案。

4. 人力原因

方案合理、能力够、也没有技术限制,但没有足够的人来做。

四、解决方案


1. 短期方案

当我们设计好的产品方案被评估为无法实现后,当务之急就是根据实际原因来修改这个方案:

  • 不合理方案是产品经理的工作失误,应好好反省自己,重新梳理需求,多请教研发技术知识,重新设计方案以达到合理。

  • 能力原因短期内无法解决,产品经理应有看菜下饭的能力,根据团队的能力水平去设计合理的替代方案。

  • 技术原因也需要产品经理妥协,可适当了解当前产品的技术特点,扬长避短。

  • 人力原因本质是研发难度问题,也是成本问题。达到需求目标的方案往往不止一个,并不一定要选效果最好的,而应尽量选择效果较好成本较低的。


2. 长期方案

产品设计方案因无法实现而不得不重新修改,耗时耗力。在如今飞速发展的时代,浪费时间很可以会耽误产品的商业机会,也会降低自己在团队中能力信任,我们应长远地解决这类问题

1)懂点技术

虽然产品经理不需要写代码,但不能不懂技术,至少要了解技术的原理、自己产品的技术框架、团队的技术能力水平等。

产品设计要建立在技术可行性基础上,但也不要被自己有限的技术能力限制(自己觉得不能实现就不做了)。

2)考虑研发可行性

产品设计过程要考虑研发可行性,不可随意发挥。

我给团队制定的SOP中,有一步是“初步方案”,目的是在进入详细之前先确认掉技术疑点,设计过程中有不确定的地方也需要随时与研发沟通。

3)默契与信任

产品经理要用自己的专业能力和职业态度建立起团队中的信任,在一次次的项目过程中建立起默契。

信任和默契是事情推进最好的润滑剂,有时候我们苦思冥想得不出的好方案,也许研发从技术角度很轻易地就给出了答案。

觉得本文对你有帮助?请分享给更多人

关注「全栈开发者社区」加星标,提升全栈技能
本公众号会不定期给大家发福利,包括送书、学习资源等,敬请期待吧!
如果感觉推送内容不错,不妨右下角点个在看转发朋友圈或收藏,感谢支持。
好文章,我在看❤️
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值