最新消息:

程序员有必要知道为什么做某个功能吗?

学习 eben 620浏览

本问题及回答节选自知乎,用于记录,以后经常翻阅

程序员有必要知道为什么做某个功能吗?
今天和产品经理对了一个功能,搜索中增加模糊搜索,我事先又问了年薪60万的大佬这个功能好不好做。

大佬说如果你们的研发说她做不了,你可以打她。

结果不出意外被研发怼了回去,她说可以做,但是这个功能没必要,所以不做。

反复给她解释这是运营必须用到的功能,她就炸毛了,说她可以做,但是以后不会提出任何建议了,你们爱做啥做啥。

给产品经理气得不轻。

其他网友在本回答下面的评论

什么鬼?
需求写不明白,怪人理解不到位吗?
根本不是不愿意想,而是好的需求做到既满足,不好的需求才会倒闭实操的人去猜目的。

范围蔓延就是太多的功能写不明白,全靠人猜,产品动动嘴,不到一百个字描述了个”需求”,做出来各种加这改那。

专业的产品可以很明确的给出背景,目的,时限,场景,基需,特需,根据需求做出来的产品只需要小型修改即可。

如果是模糊的定义,要程序员来自己想,那最要命的就是各种返工,不乏架构过简推翻重做,架构过繁浪费资源。


你怕不是没做过ui决定需求的东西,前后端程序猿看着ui设计图连蒙带骗的猜需求,连个几百字的文档都是奢求


别说我,都是泪,让写个需求文档,产品说有原型图还不够明确吗?就一堆饼图折线图还没标题坐标单位我能看出个基尔


从码农的角度,程序员不需要知道需求,只需要直到如何实现需求。很多程序员自己自作聪明加了自己的想法,其实是没有必要的,有想法应该在需求评审的时候提,甚至有问题找产品经理提。由他们给解决方案才是最恰当的。程序员多做点单元测试,保证自己的代码高效,无bug即可,多余的事只会让自己背锅


作者:羽翼丰
链接:https://www.zhihu.com/question/509917281/answer/2300283718
来源:知乎

场景一

老板:小伙子,给我做一个图片显示的功能,我APP上要能显示图片。

程序员:好的,老板,图片我给你放服务器渲染,再让客户端下载。

程序员有必要知道为什么做某个功能吗?-2

场景二

老板:大程子,给我做一个图片显示的功能,我APP上要能显示图片。这个图片是咱们城市的健康码

程序员:好的,老板,那这个图片访问量应该很大,并发量也很大,实时性要求也高。我生成图片时压缩一下,我再把整个请求流程优化,提高响应速度。老板,我建议我们升级系统配置,增加带宽,扩大集群,目前咱们这边有些特殊情况,访问量会非常巨大,对服务器和数据库的压力比以往要多几倍。并且,我们做好测试工作避免上线之后遇到问题。这可是关系到民生的大事,我会再尝试客户端渲染的方案,这样可以让服务器这边和带宽的压力减小。

老板:好,就这么干。

就多说一句话,所有的隐性需求都被充分的挖掘了出来,请问,这么做有必要吗?



作者:牛客网
链接:https://www.zhihu.com/question/509917281/answer/2300304839
来源:知乎

分享几个“拒绝一个合理需求”的方法。

(因为,连合理的需求都能够坦然拒绝,更何况不合理的呢?哈哈哈哈,仅供娱乐…

1、这个需求的价值是什么?这是对产品经理的灵魂拷问,应对菜鸟级的产品经理,足够让他菊花一紧,两腿哆嗦。碰到老鸟产品经理,他会跟你秒天秒地秒空气,这时候,你就静静地看着他装逼。

2、我们的目标用户是谁?用户量多大?如果产品经理提了一个小众需求,这个提问就是直拍软肋,杀伤力巨大,你是在质疑产品经理是个傻子,把他的智商按在砂纸上摩擦。

3、这个功能解决了用户什么痛点?有数据支撑吗?产品经理立刻被问得捂着胸口,沉默不语。程序员有所顿悟,哦,我懂了,你是不是想说,这是来自用户内心深处的呼唤。产品经理说,不是,我以前也是程序员,产品经理就是这样被我问挂的,现在我来顶替他。

4、原型图画了吗?设计文档写完整了吗?原型图、设计文档是程序员唯一可以挑剔产品经理的地方,千万要珍惜做甲方的时光,因为享受完,权利立马反转。人生就是这样,不停地变换姿势,伤害彼此。有时候想想,职场当中,大家都是狗,反正20年后都要一起去跳广场舞的,何必撕扯得这么投入?

5、设计文档确定不改了吧?行,我给你排期。设计文档不再改了?认真你就输了,改到第10次,还是觉得第1个是最好的,就问你酸爽不?先答应他,开始盘资源排期,“哦,我看了一下,你这个需求可能要排到下辈子了”。

6、你就告诉我,要抄哪家吧。当产品经理说出10个定理,5个推论,3个数据来证明这个功能的必要性。你就回他一句,别扯了,你就告诉我,要抄哪家的。产品经理的遮羞布瞬间被扯掉,就问你尴尬不?让你装逼,装逼遭雷劈。

7、我这里没问题了,让项目经理去立项吧。立项可是个漫长的工程,等他走完立项流程,半年过去了,然后再跟他谈资源的事情,回到第5条,此处可以有N个死循环,N无限大。

8、这个需求对架构影响蛮大的,拉上架构师再讨论下。刚解释清楚的需求,再花上几天给架构师讲清楚,架构师再提出10个疑问,再拉上其它产品线的架构师来论证,两个月又过去了。这时你又回到第一个问题:这个需求的价值是什么?如果真的非常急,非常有价值,现在已经过去两个月了,好像没有它也没那么大影响嘛。binggo!又气吐血一个产品经理,打完收工。

9、工作量主要在前端,让前端一起评估下吧。前后端分离以后,以前一个人的工作,现在两个人来干,以前一个开发应付产品经理,现在两个开发一起上,内耗也耗死他,逻辑放在前端还是后端?校验放在前端还是后端?这TM都是问题。

10、这个功能很有创新性啊,让老板也来头脑风暴一下吧。最高级的扯皮,就是把老板拉进来。老板懂个屁啊,还要在下属面前装懂,天马行空,扯些有的没的。凡是老板亲自抓的项目,大概率要失败,他TM整天提出问题质疑,又给不出方向,团队就更不知道该怎么做了,不失败才就奇迹。

程序员有必要知道为什么做某个功能吗?-1

以上都属于基本打法,是时候表演些真正的高阶玩法了:

11、假装同意后,拒绝。先是假装同意,给他希望,“嗯,我觉得可以做的”。然后,再拒绝他,但是要表现出真诚,产品经理不怕被拒绝,但是怕被瞧不起,“其实,你是有能力的产品经理,只是这个方案不太适合落地,你会遇到一个更好的开发。。。”,你说他的方案不行,不就是侮辱他的能力吗?没错,狠狠羞辱他。

12、若有所思后,拒绝。他讲了2个小时的产品方案,完全讲嗨了,主要是自嗨。口干舌燥,头晕眼花的时候,你假装若有所思,产品经理完全被你的演技征服了,他认为他就是伯牙,你是子期,他是牛郎,你是织女,你们琴瑟和鸣,莫不静好。他深情地注视着你,眼里好像有些类似爱情的东西,你立刻无情地拒绝他,“做不了”。

13、反问后,再拒绝。经过第12条的折磨,产品经理已经心力交瘁,处在崩溃边缘,看不到任何希望了。这个时候,你再点燃他的希望之火,此时最好站在阳光直射的窗户前,让耀眼的光线刺痛他的眼睛,你像神一样来到他面前,复述一遍他的方案,问他是不是这样?正当他满怀欢喜,以为你已经完全领悟到了方案的真谛时候。你立刻无情地再次拒绝他,“做不了”。

14、然后,开始踢皮球。经过以上步骤,你和产品经理之间那点信任已经荡然无存了,这时候你可以开始踢皮球了,“这个需求,更适合XX产品线团队来做”,“这个需求,应该由创新部来主导,找他们聊聊看。”

15、Never Say No。总之,不要直接拒绝,Never Say No。要时刻给产品经理一种若即若离、暧昧、朦胧的感觉,让他觉得既充满希望,又没有十足把握。在他感觉到马上要修成正果的时候,立刻把所有希望在他面前摔得粉碎,虐心啊。

总之,奉劝各位程序员,不要为了拒绝而拒绝,你不做这个需求,还有更难受的需求。

最后,愿天下的程序员和产品经理,都能善待彼此,拍砖也选块轻的,做不成敌人,就做朋友,一起联手对付需求方,敌人的敌人就是朋友嘛

转载请注明:落伍老站长 » 程序员有必要知道为什么做某个功能吗?