开发说这个需求做不了,你会如何应对?

3 评论 4916 浏览 43 收藏 12 分钟

编辑导语:作为产品经理,在和开发对接需求的时候,可能会遇到开发说需求做不了的情形,这种时候该怎么解决呢?是砍掉需求或者暴力沟通吗?本文作者认为,本质是问题模型的问题,并分为三步进行了分析,一起来看一下吧。

这是一个历久弥新的产品话题。

镜同学相信,几乎每个产品经理在和开发对接需求的过程中,都遇到过这样的情形,根据我的观察,不少产品经理最后都选择了被动妥协。

这里面主要有两个原因:

一是,某些产品经理客观上懒于深入思考,想着既然开发都说实现不了了,那就没办法了呗,更有甚者就以此为尚方宝剑,二话不说就调整需求或者砍掉需求。

二是,产品和开发沟通时没有优势壁垒,沟通视角天然对立,又或者开发讲的技术逻辑产品同学压根听不懂,自然就觉得他们说的很有道理,要么就走入暴力沟通的死胡同:

  • 别人家能实现为啥你就实现不了?
  • 技术我不懂,反正这就是业务需求。
  • 反正我就要五彩斑斓的黑。
  • 明天要上线,怎么实现我不管。

不管是哪种原因,最后造成的结果都是需求分歧无法得到妥善地解决,遗憾的是,这种情况竟然十分普遍,以至于在某些组织环境下,开发形成了惯性认知,导致稍显复杂的需求,开发都会说技术实现不了。

技术心想,反正你又不懂技术,这样就造成产品经理很被动,并且,这与“我们要做难而正确的事”这个理念相违背。

这就似乎陷入了解决问题的瓶颈:产品经理不懂技术,根本无法解决这些问题,这直接带来了,产品的生态土壤的加速变坏

事实真的如此吗?

我在之前的文章中说过很多次:任何一个问题都有一个本质解和N个现象解,我们只有找到本质解才能从根本上解决这个问题

在我看来,懂不懂技术只是现象解,并不能从根本上解决这类问题,这个问题的本质仍然是问题模型的问题

那么,什么是正确的方法呢?

我觉得主要可以分为三步,而这对于刚入门的产品经理尤其适合,因为他们有空杯心态,还没有形成固化的工作方法,更容易从底层养成正确的方法论。

一、你要有专家效应

专家效应对外表达的是你的权威,我一直建议产品经理要对基础的产品专业能力要熟练掌握,比如,在没有准备好的情况下,不要轻易发表意见或者组织需求评审,只有在组织内形成了专家效应,后续的工作才能更有利。

产品经理一旦失去权威,就会对后续的需求沟通极为不利。

我举个产品小案例:

我们团队之前有个产品经理在设计产品需求时,将”性别“这个字段做成了输入框,而不是下拉选择(男/女),结果被开发广为吐槽,后来他的需求开发都不怎么重视。

这虽然是个很小的细节,但会极大伤害你的专业能力,很容易失去开发的信任,类似于这样的事情,我们一定要避免,比如,常见的坑还有“原型设计”缺乏基础的交互,需求评审不讲业务场景,需求说明没有功能定义等等,这些之前文章都有过分享。

总之,产品同学一定要注重专业能力,这是产品硬实力,是产品职场工作晋升的底层基础。

关于产品经理系统化的专业能力体系,我在之前的问题提到很多次,有兴趣的同学也可以翻看或关键词搜索之前的文章,比如,就在上一篇文章“敏捷五步,手把手教你画产品架构图。”中就提到,产品架构设计就是展示你专家效应的有效手段之一。

二、多元化思维,拓展能力边界

产品经理是一系列产品思维的表达载体,综合能力集中体现在问题的解决上,这就需要跨学科学习,多元化思维,这中间就包括“技术思维”。

上周我们在设计客户关系管理时,关于“公海规则”的一个需求,开发说实现不了,当时技术同学建议客户隶属于公海,产品经理反馈给我后,我在群里发了消息,后来问题得到了妥善的解决。

究其原因在于我有一些浅薄的技术积累,加之同理心思维,站在技术角度去思考并将产品语言翻译成技术语言去说服他们。

我是这样回复的,分享给你,希望能对你理解“多元化思维对产品的价值”有帮助:

关于“客户管理系统中,同一个客户同时满足并触发多条公海规则,如何流入处理”的建议:

1、公海的主要业务场景是依据规则收回客户,用以提高业务效率,其本质上其实是数据权限管理,即成为某个或多个公海成员的用户,有权限查看并领取该公海里的客户。

2、明白了这个业务场景,若客户A同时属于公海①、公海②,当规则同时触发时,应该同时流入公海①、公海②,比如集团事业部场景,客户A属于危化企业,智慧环保为公海①,安全科技为公海②,两个事业部都可以推进集团业务,此时应该允许公海①、公海②下的成员有权查看并领取。

3、客户应该为实体类,唯一标识应该是客户ID,不应该为负责人或者隶属公海,负责人或隶属公海都是该客户数据的两个静态字段。

处理建议:

  1. 方案一:当客户同时满足多条公海规则时,应该流入两个公海,当在某个公海中被领取之后,同时在另一个公海中也同步移除,不再展示,客户数据是同一个数据(应优先按这个逻辑处理)
  2. 方案二:当客户同时满足多条公海规则时,流入最新创建的那条公海(指定公海规则即可)

我的这个产品经理没能说服开发本身,主要在于这个产品经理没有技术思维,又缺乏深度思考和沟通的方法,所以把开发的反馈被动当成了本质解决方案,没能有效解决这个需求。

当然,不同岗位工作本身有边界,产品经理并不需要深入技术本身,不过,适当懂一些技术思维和基本知识,在产品工作中能进行有效结合和融合思考,就能极大的提高需求传递效率

这也是我在之前文章中,反复推荐的一本书《领域驱动产品设计》的原因。

三、聚焦问题本身,注意沟通方法

很多时候,沟通都是有方法的,说服别人的关键在于聚焦问题本身,不要情绪对抗,就事论事,试着找到已有解决方案的案例,往往比苍白的沟通更有说服力

我想起了多年前在之前公司做的一个小需求,当时的需求是要在“组织机构设计时”增加了搜索功能,因为我们集团使用这个系统,组织机构是每个事业部的业务单元,比如,每个城市区域可能都是一个组织机构。

这就会导致有上百个组织机构,因此,对业务运营来说,可以搜索到某一个组织机构就显得很有用,这也是业务本身的需求。

当时我是和一个前端开发对接,那个开发同学反馈说不太好实现,可能他也是刚入门技术能力有限,也可能是项目时间太紧了。

但是,我知道这个需求是很有业务价值的,我还知道:单一的沟通问题本身,远远不如找一个案例更有说服力

于是,我和他说,咱们不着急,先一起想想办法,后来,我直接搜索“可搜索的树形组件”,很快就找到了一个产品案例:

拿着这个案例,我们沟通很快就达成了共识,并且,他不会认为你是浅薄的需求翻译官,当你从业务场景讲述需求价值,用同理心理解他的岗位技能,试图和他同频共振,再找一个产品案例去沟通交流,很快就能说服他。

而且,这种事情还会不断增加你的专家效应

说到这里,让我们总结下,为了有效应对开发反馈说技术实现不了,从产品工作一开始我们就有必要执行三部曲:确立专家效应→找到根本原因→使用沟通软技能

其实,最重要的还是要找到背后真正的原因,因为,很多时候开发反馈技术实现不了,并不一定就是技术瓶颈。

我们在解决这些问题时,只有找到了背后真正的原因,才能更高效地解决问题,因为,背后真实的原因往往是本质解,但这其实有时候很难识别。

不信,你试着回想斯宾格勒的一句话:秒针这一秒指向59,下一秒指向60,59就是60的原因吗?

最后,真的希望本文对你能有产品启发。

#专栏作家#

产品大峡谷,公众号:产品大峡谷,人人都是产品经理专栏作家。七年B端产品经理,供应链物流与金融领域,擅长需求设计、业务指导、商业观察等。

本文由@公众号:产品大峡谷 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 核心还是找根本原因。实现不了有很多种,时间范围成本。很多时候开发都不是轻装上阵,背着各种历史遗留问题,牵一发而动全身。

    来自北京 回复
  2. 《领域驱动产品设计》 请问这本书和《实现领域驱动设计》是一本么

    来自韩国 回复
    1. 同问,想问问具体是哪本书,作者是哪个👀

      来自北京 回复