菲洛嘉青春动能素135HA FILLMED® NCTF 135HA LED指示灯的常见故障分析 智微智能 Elkhartlake K075终端,零售产业新选择 天空蓝拓客管理系统详细介绍版 muso公链项目 天使计划 是什么?[秘] 独家揭秘最前沿的家装“黑科技”——掌赋 天博体育欧洲杯特辑,东道主法兰西的失意2016 亚马逊的送货侦察员 学习听起来像挡泥板 Google Comics Factory使ML变得容易 笑着说-男性或女性 Amazon Rekognition中更好的人脸检测 关于Spaun的真相-大脑模拟 两个聊天机器人彼此聊天-有趣又怪异 GANPaint:将AI用于艺术 WCF和WF给予社区 从耳朵到脸 所有神经网络的深层缺陷 蠕虫在尾巴上平衡杆子 Kickstarter上的OpenCV AI套件 TensorFlow-Google的开源AI和计算引擎 众包取代新闻工作者 Google的DeepMind学会玩街机游戏 哑机器人V智能机器人 .NET与.NET 5融为一体 Google的深度学习-语音识别 LInQer将.NET LINQ移植到Javascript 机器人TED演讲-新的图灵测试? GAN的发明者加入苹果 您的智能手机会监视您键入的内容 人工智能帮助改善国际象棋 Zalando Flair NLP库已更新 TensorFlow 1.5包含移动版本 AlphaGo输了一场比赛-比分3-1 虚拟机器学习峰会 Microsoft开源AI调试工具 SharePoint走向移动 F#4.0发出文化变革的信号 克里斯蒂拍卖AI艺术品 人工智能如何区分 Facebook在蒙特利尔的新AI实验室 Mozilla想要您的声音 微软使用极深的神经网络赢得ImageNet 建立AI合作伙伴关系 .NET Core 3-Microsoft几乎回到了起点 神经网络-更好的销售商? Google使用AI查找您的住所 虹膜-适用于Android的Siri证明苹果没有优势 TensorFlow 2提供更快的模型训练 深度学习研究人员将为Google工作
您的位置:首页 >开发 >

成熟的产品经理如何应对“这个需求不合理”

在项目的研发过程中,经常会遇到开发拒绝需求三连击:“这个需求不合理”、“这个需求没必要”、“这个需求做不了”。

作为一位成熟的(习惯了被怼的)产品经理,切忌被开发的言语带偏,陷入当前的对话中。此时脑袋中应该响起一句话:凡事先问是不是,再说对不对——也就是常说的要具有批判精神。

综合本人的项目经验,开发拒绝需求,追究到底层的原因,可能有几种场景,我们可以拆分来看。

一、认为产品设计不合理而拒绝做需求

产品设计不合理,我们也需要辩证的去看待:

1. 是否开发从另外的角度思考,观点和产品不一致,认为产品设计有问题?

一个人对事物的认知,与他所处的环境、位置,所经历过的生活,接受的知识有关。

有些问题上,可能并没有存在明确的对错与是非之分。一千个读者就有一千个哈姆雷特,同样的产品文档给到不同的研发人员,他们的理解也会有些许差异。

若开发从其他的角度对产品设计提出质疑,我认为产品可以持有欢迎的态度。这起码说明了研发人员有代入到项目中思考问题,而不是机械的对照PRD文档敲代码。

C端产品可以有A/B测试,用数据结果去验证哪一种方案更适合;但是B端产品做A/B测试的成本太高,业务流程上也不适合变动。

这种情况需要产品经理从用户的实际业务需求出发,多做现实场景的模拟分析,选择一个高效、灵活而优质的方案。对业务思考的越透彻,越容易说服开发,不,应该是开发越容易对你产生认同感。

2. 是否开发只看到了局部业务,片面的认为产品设计有问题?

曾经做过一个项目,需求方要求的是企业派发订单之后,会指派固定的个人接单,然后进行结算。相应的移动端的自由职业者登录账号后,只能看到自己被指派的订单信息,进行接单。

当时研发人员认为,应该设计为自由职业者登录之后,可以看到所有企业派发的订单,但是只能接被指派到订单。

理由是这样自由职业者登录之后,可以看到大量的不同企业的订单信息,感觉有很多任务可以做,而且小程序的页面也很丰富,方便后期的运营。

但是实际的情况是:项目有指派模式、委托平台模式、抢单模式的,指派订单是为了保护企业的特殊订单信息而存在。这些订单的总价、被指派人的单价信息,只对被指派的自由职业者开放,属于相对私密的信息。

产品相对于研发的优势是,产品人员前期会经过大量的调研和分析,能更全面、更长远的了解业务的全貌,更清楚用户的需求和痛点。但是项目的研发,通常是分模块、分功能、分业务进行合作开发的,在认知上容易陷入局部了解的陷阱。

为了避免这种问题,产品首先应该坚持自己的立场,不能因为被质疑而陷入自我怀疑;其次可以在项目的评审中,日常的沟通中,细致全面的和研发人员说明业务的完整流程、未来的发展方向、实际的业务场景,避免因为不了解而产生片面否定的情况。

是否真的是产品的逻辑设计、业务闭环上有问题?

如果确认是产品的设计问题,首先感谢研发人员发现了漏洞,然后及时纠正产品设计、补充产品文档并告知其他相关人员变动内容;其次要反思问题出现是因为对业务了解不够,还是工作状态的问题,“日三省吾身,久卓尔不群”。

另外有这样和你统一战线的队友,你们一定会齐头并进,共同成长。

二、研发时间超出预期,无法按时上线而拒绝做需求

研发时间超出预期,如何辩证的看待呢?

1. 品项目排期不合理,导致需求无法按时完成

1)主观原因

产品自身的项目管理经验不足,或者对团队人员的情况了解度不够。

这种情况需要在日常项目中多积累经验,在项目研发过程中多沟通、多跟进研发人员的开发进度(有专门的项目经理安排项目周期不在讨论范围内)。

2)客观原因

领导层对项目难度认识不足或者市场竞争激烈,给予的开发时间和研发资源太少,不少公司的996福报大致就是出于此原因吧。

客观原因很无奈,产品人员只能尽量加强团队的凝聚力,提升项目的研发效率,同时将心比心向上争取研发资源。

2. 研发人员技术能力有限,实现起来麻烦不愿意做

能力有限而不愿意改变现状,反而推诿责任的人,实在是不靠谱。

既有损团队合作,又耽误项目进度,只能对上反映寻求解决办法了(要求换人,不一定能成功,但是领导层必须知晓团队的情况)。

三、技术边界问题,存在暂时无法解决的技术难点。

在笔者所做的项目中,很少有遇到当前的技术无法解决的需求。如果真的遇到了,那就是公司层面愿意投入的时间成本多少和团队资质优化的情况了,这一点也超出了产品经理能处理的范畴了。

总结:研发人员拒做需求,可能是产品自身的能力短板,也可能是团队的思考角度不同,也可能是研发人员技术有限。

但是无论哪种情况,我们也要保持谦逊自省,共求解决方案的心态。

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。