技术说这个需求搞不了,怎么办?

4 评论 6197 浏览 33 收藏 12 分钟

编辑导语:产品经理在日常工作中经常会与各部门打交道,比如在做项目时,会与技术部门进行交流沟通,提交需求等,但在沟通的过程中,不免遇到一些难题,比如技术无法实现,这时应该怎么办?本文作者就此进行了详细的分析,我们一起来了解一下。

需求讨论清楚了,方案评审通过了,策划和设计工作也完成了,项目已全面进入开发阶段……

你刚要松口气的时候,技术突然跑过来跟你说:“老哥,你这个需求搞不了啊。”

有项目经验的朋友,应该能够体会到,这个场景多么地令人奔溃!

前面所做的全部工作,可能都得推翻重来。项目进度将会受到巨大的影响。

这样的情况,说多不多,说少也不少。

负责的项目多了,其实还是挺常会碰到的。

如果是你,遇到这样的情况,要怎么办?

直觉上,应该马上暂停项目,然后赶紧召集相关干系人重新对项目进行评审。

这样的“答案”,逻辑上没有问题,挺合理的。

但是,在实操层面,我想说,先别着急,事情可能还远远没到那一步。

进入全面开发阶段之前,项目肯定已经经过了多方的评审。

我们是得到了“可以搞”的保证后,才开始搞的。

到了全面开发阶段,再发现“搞不了”,概率其实很低。

根据经验,大概有80%的概率,是个“假阳性”的误报。

01

那么,怎么判断项目是不是真的搞不了呢?

我猜,很多朋友可能已经联想到一个老生常谈的争论:

“产品经理需不需要懂技术?”

你可能会想,如果产品经理懂技术,那就可以和技术battle,甚至一开始就不会设计出“技术上实现不了”的方案……

首先,我的观点,向来都是“产品经理不需要懂技术”。

但是,在这里,我不想深入去讨论这个话题,也不希望各位朋友从这个角度去思考本文要讨论的场景。

上面说了,这个“搞不了”的反馈,有80%的概率是个“假阳性”的误报。

在这80%的情况里面,其实更多的是“人”的问题,而不是“技术”的问题。

所以,要甄别它们,靠的也不是“懂技术”。

02

在全面开发阶段,技术突然跟你反馈说:“这个需求搞不了。”

如果你项目经验比较少,或者对团队不够了解,那么,很可能就会被“唬住”。

因为很多时候,其实完全是搞得了的。

下面,我会罗列出现“误报”的几种常见情况。

你在重新召开评审会之前,不妨先看看,真实的情况会不会是下面这样的。

1. 技术没看清楚需求内容

“这个真搞不了。这里面很复杂,有A、B、C 3种情况。B和C因为某某原因,是不能这么搞的。”

“嗯,所以我PRD上写了‘仅针对情况A’。”

“……那没事了。”

你没有看错,就是这么低水平的乌龙。

老实说,这种情况出现的概率还不低。

所以,我一直强调“在真实的世界里做产品”。

当你不是架空地去想问题,而是真正地去开展工作时,你总能碰到一些意想不到的困难。

在真实的世界中,光是“准确完整地传达信息”,就很困难,经常出差错。

当然,解决方法也很简单。

反复说明,直到信息充分传达为止。

2. 技术没有正确理解项目的要求

曾经,有个需求是这样的:

“从3个题库里面随机抽取5道题,要保证每个题库至少要有1道题。”

然后技术跟我说,这个搞不了,里面需要很多判断,很复杂。

具体怎么个复杂法,他也没法表述清楚。

我思考了下,说,能不能这样:

“第1题从题库A中随机取,第2题从题库B中随机取,第3题从题库C中随机取,第4、5题则在3个库中随机取,但要去重。”

技术想了想,说这样搞可以。

为什么原来不能搞,现在又能搞了呢?

那是因为,技术以为,“每道题出现的概率要一致”,“题目出现的位置也要随机”。

然而,从业务上看,并不需要做到这个地步。

像这样的问题,无法像第一种情况那样,事先在PRD上完全说明清楚。

因此,需要与技术仔细沟通,并在沟通过程中,细心地甄别出双方在“理解”上的错位。

3. 技术他自己的确搞不了,因为还需要其他技术来配合

曾经,我想给某个小模块增加一个状态变化。

但是,负责的技术说没办法搞。

我非常困惑,这应该是非常简单的功能呀,怎么会没办法做呢?

“要增加状态变化,需要新增一个字段来控制。”

“那加就是啦。”

“可我这边只负责调用,没办法加字段。得某某组那边才能加字段。”

“我……”

这看起来,多少有点让人哭笑不得。

但,设身处地想想,其实也挺正常。

我们从外部看,会觉得技术部门就是一个整体,技术的问题他们内部理应自行沟通协商解决。

但是,每个人都有自己的分工,做着自己的工作。互相之间,关联性没那么强。

一个项目,往往需要技术部门不同分工的同事协同完成。

有时候,碰到涉及面较大的问题,更是需要让不同分工的同事聚在一起,从各自的角度出发,提出意见,讨论解决方案。

希望他们能自发地组织起来进行协作,其实是一种挺偷懒的想法。

在没有项目经理的情况下,产品经理应该有意识地成为“组织者”。

当发现需要多人协作时,主动地组织起各方,高效地达成合作。

当然,这就需要产品经理充分了解团队的工作分工。

4. 其实是技术没时间搞

这个情况是,虽然技术上可行,但是预计花费的时间过多。

如果真的这么去做了,很可能无法按期上线,或者影响到其他项目的上线。

那么,解决思路也很清楚。

要么调整方案,要么修改开发排期,给与更多的开发时间。

要注意的是,有一些比较老油条的技术,嫌麻烦,不想搞,会“欺负”产品经理不懂。

他不说”时间不够“,而是含糊其辞地说,“太复杂了,搞不了。”

这一点,产品新人要注意甄别。

5. 技术对项目的重要级认识不足

某种意义上讲,没有什么需求是实现不了的,只是成本的问题。

有时候,技术的意思,其实是:

“(因为没法把工作量控制在合理的范围内,所以,)这个需求搞不了。”

比方说,这个项目需要10个单位的工作量。

技术根据自己对需求的理解,认为以这个项目的价值,超过5个单位的工作量,就不合理了。

然而,因为这个项目重要级比较高,哪怕是花费10个单位的工作量,也是值得的。

当然,这个工作量的问题,需要在评审的时候提出来讨论,并且最终与领导达成共识。

不是产品经理自己单方面觉得“值得”就可以了。

这种情况下,产品经理需要把项目的重要级,以及领导已知悉并同意的情况,给技术传达清楚。

特别的,有时候,“搞不了”的意见,是技术组长给出的。

这时候,“纠缠”具体某个技术就没有意义了,应该直接和技术组长沟通。

03

有2种的态度,我认为是有问题的。

一种是,认为既然领导已经审批通过了,那么技术就应该按要求去完成。

有问题,不关我的事,你们内部自己协商解决。

我只关心结果。

另一种是,盲目地认为“专业的事情交给专业的人处理”。

既然技术说了不行,那就不行。

没必要去了解其中的细节,反正我也不懂。

这2种工作方式,我多少有碰见过。

个人觉得,至少作为产品经理,是不应该如此的。

04

上面列举的几种情况,需要产品经理具备不同的能力,分别用不同的方式妥当应对。

但是,无论哪种情况,一个不变的前提是,需要产品经理深入其中,充分调研,了解个中细节,敏感地发现问题所在。

从“搞不了”变成“搞得了”的过程中,产品经理的沟通协调工作,发挥了重要的作用。

换个角度来说,这也是产品经理的职责所在。

你是否也碰到过这样的问题?你是怎么处理的?

#专栏作家#

简明产品论,微信公众号:简明产品论(ID:JianMingPM),人人都是产品经理专栏作家。在真实的世界里做产品。

本文原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 我很喜欢你的写作风格哎

    来自北京 回复
  2. 不能拿老板来压开发的小朋友,开发说搞不了,那就打破沙锅问到底,有时你的“穷追不舍“、”孜孜不倦“也会让开发的小伙伴回你一句”好好好,你别问了,我想办法搞定“

    来自河南 回复
  3. 感谢分享

    回复
  4. 文中试题的例子很好欸,一下子就get到了~

    来自北京 回复