小程序
小游戏
企业微信
微信支付
扫描小程序码分享
有时需求随着客户或产品的“心情”和“理论”反复变化,轻则小修小改,重则推倒重来......
你有过需求被频繁更改的经历吗?又是如何“优雅”应对的呢?🤔
23 个回答
加粗
标红
插入代码
插入链接
插入图片
上传视频
没改革之前,我们是产品说改就改,一天一个样,需求都没想清楚就让做,项目无限期顺延,开发整天加班改需求,那帮产品整天喝茶聊天的,真想在桌子上放把刀。
后来改革了,老板要求需求必须出详细PRD,并且提前3个工作日邮件发给参与开发的人员进行了解需求,预订会议室进行评审。评审不通过,产品记录下来改PRD,等待下一次评审。评审通过后签字画押封版,开发预估开发工时,然后进行开发。如果在开发过程中出现需求变更,需要再出改动的PRD也是提前3个工作日发邮件评审,评审通过后预估工时,项目延期上线。那帮产品也开始整天加班画PRD了,哈哈哈哈哈哈哈哈哈哈哈!
当然紧急需求还是得加班加点的改,特殊情况特殊处理
贴个上次评审通过的表吧
你好,麻烦通过点击下方“反馈信息”按钮,提供出现问题的。
频繁更改的需求是一个产品不负责任的表现。🐶
一个程序员跟产品交流的时间大于跟女票交流的时间。频繁的改动一般都是小公司吧,大厂咱也没去过,应该有严格评审标准的。讲一下今年跟产品爱恨情仇。
初期:
也是刚立项没多久,这个时候频繁改需求的话建议不要“反击”。这个时间点老板定一切,程序员要改,产品也要改,设计也要改,人人平等。
中期:
1.0: 产品期,一般频繁改动就在这个时间点。这个时候程序员一般是无法与产品抗衡的,产品呢说改就改,一天一个样,需求想一出是一出,业务逻辑有时候也不会考虑,都没想清楚就让做,一般做着做着发现MD,这里昨天改了逻辑变了,今天要改内页,结果就是哪哪都需要改动。加班加点。
2.0: 项目期,这个时间段项目经理就要接手了,同样程序员无法跟项目经理抗衡。2.0的时候记住依靠在项目经理的大树下,这个时候产品改需求需要进行评审,项目经理是大腿,遇到个不会技术的项目经理那就要吹水,这就需要平时多关注论坛,多交流,同时日常抨击其他公司产品与技术。列举改动涉及的技术点,如果涉及没做过的领域,尽量多要点时间踩坑。这样项目经理一般会认真考虑需求,他害怕背锅。遇到会技术的项目经理,那就太舒服了,他会很认真的把各个需求点技术点给你总结指导的明明白白的。只要跟着他的节奏开发很舒服。
3.0: 混乱期,各方大能齐发威,老板提需求,产品提需求,负责人提优化,正确的做法是明哲保身,如果只是普通开发那就好好开发,如果是负责人就要肛产品,给手下的兄弟争取合理的需求、待遇。
后期:
loaf on a job。改需求的时候可以优化下之前的代码,摸鱼有道。
总结:
遇到过叹为观止的开发老哥,核心就是一个词 “ 难 ” 。跟产品吹,技术太难,可以实现,but难,会影响现有业务,然后从各个角度吹,这个老哥不止一次的把后台的需求吹到了前端。时间处理不做、分页不做、跟前端讲算法,无敌。跟boss吹,技术可以实现,but难,不止一次的把boss需求吹到产品改方案。这应该是最优雅的方式,不骄不躁,他强由他强,清风拂山岗。不管前期敏捷开发,还是中期各种评审后开发、这是我有生之年见过最优雅的。前端熬夜加班,老哥已经撑起行军床入眠了😊。讲真的老哥技术不怎么样,很一般,but (理论扎实+吹水)=== 无敌。
我一般是能动手尽量不bb,先打一架,打完再回来改需求。
优雅的第一步,就是去除冗余内容
改需求其实不可怕,拿钱干活儿,随你怎么改 可怕的是,改了需求,项目还要按时上线,然后加班加成狗,完了项目延期,还要背一口项目延期的大黑锅。
还有更加气人的,为了赶进度,负责人说,项目质量可以先放放,先把功能上去再说。
等你熬完2个通宵,项目终于上线后,第二天下午,正当你在睡梦中恢复元气时,突然接到项目负责人急催的电话,接通后,劈头盖脸就是一顿数落,打了你好几个电话都不接,你干啥去了,项目上线一堆BUG, 界面又丑的要死,你是怎么干活的。。。。。
你小声的抱怨了几句,说项目进度赶啥的,然后换来一句,“不要给我找借口,我要的结果”
有这样经历的请点个赞,我看有多少人遇到过
首先,我们的项目在开始前就已经有一个前期开会的评审了,在会上将一些疑问提出,哪些能做,哪些做不了的会给一些建议,最后会根据产品所需的功能大致给一个排期,确认了之后就严格按照这个排期来执行了。
如果突然改需求的话看这个需求是不是必需的,如果是比较需要的看是不是会影响排期,在不影响排期的情况下可以考虑加入,如果是比较花时间的就建议下个版本再加入,如果是比较大的功能非要加的话那只能重新排期了。
不过我一般是建议下个版本再加,毕竟突然改需求会影响我写代码的思路哈哈
分两种情况
1、不限时间,不会因为修改而加班的。改就改吧,反正我按时间拿钱,钱是老板的
2、已经谈好需求和时间,因为修改会增加工作量的。门都没有,要么加钱
最近一次遇到这种情况,我的回复是:你说的功能这一期没有规划,要不一起放到下一期
经历过三天一小改五天一大改,苦不堪言。
经理:我觉得这个需要改一下,我想做成……&*&%……%&dasfafadasfdaf*&*……*&*&¥%%#¥¥%¥@%&%&,你看下应该怎么改好点。
我:改****,不改,滚。
给加班费就一定优雅。
做啥不还是写代码吗?增加的工作量加钱就行。
一刀见效
正在加载...
关注后,可在微信内接收相应的重要提醒。
请使用微信扫描二维码关注 “微信开放社区” 公众号
没改革之前,我们是产品说改就改,一天一个样,需求都没想清楚就让做,项目无限期顺延,开发整天加班改需求,那帮产品整天喝茶聊天的,真想在桌子上放把刀。
后来改革了,老板要求需求必须出详细PRD,并且提前3个工作日邮件发给参与开发的人员进行了解需求,预订会议室进行评审。评审不通过,产品记录下来改PRD,等待下一次评审。评审通过后签字画押封版,开发预估开发工时,然后进行开发。如果在开发过程中出现需求变更,需要再出改动的PRD也是提前3个工作日发邮件评审,评审通过后预估工时,项目延期上线。那帮产品也开始整天加班画PRD了,哈哈哈哈哈哈哈哈哈哈哈!
当然紧急需求还是得加班加点的改,特殊情况特殊处理
贴个上次评审通过的表吧
频繁更改的需求是一个产品不负责任的表现。🐶
一个程序员跟产品交流的时间大于跟女票交流的时间。频繁的改动一般都是小公司吧,大厂咱也没去过,应该有严格评审标准的。讲一下今年跟产品爱恨情仇。
初期:
也是刚立项没多久,这个时候频繁改需求的话建议不要“反击”。这个时间点老板定一切,程序员要改,产品也要改,设计也要改,人人平等。
中期:
1.0: 产品期,一般频繁改动就在这个时间点。这个时候程序员一般是无法与产品抗衡的,产品呢说改就改,一天一个样,需求想一出是一出,业务逻辑有时候也不会考虑,都没想清楚就让做,一般做着做着发现MD,这里昨天改了逻辑变了,今天要改内页,结果就是哪哪都需要改动。加班加点。
2.0: 项目期,这个时间段项目经理就要接手了,同样程序员无法跟项目经理抗衡。2.0的时候记住依靠在项目经理的大树下,这个时候产品改需求需要进行评审,项目经理是大腿,遇到个不会技术的项目经理那就要吹水,这就需要平时多关注论坛,多交流,同时日常抨击其他公司产品与技术。列举改动涉及的技术点,如果涉及没做过的领域,尽量多要点时间踩坑。这样项目经理一般会认真考虑需求,他害怕背锅。遇到会技术的项目经理,那就太舒服了,他会很认真的把各个需求点技术点给你总结指导的明明白白的。只要跟着他的节奏开发很舒服。
3.0: 混乱期,各方大能齐发威,老板提需求,产品提需求,负责人提优化,正确的做法是明哲保身,如果只是普通开发那就好好开发,如果是负责人就要肛产品,给手下的兄弟争取合理的需求、待遇。
后期:
loaf on a job。改需求的时候可以优化下之前的代码,摸鱼有道。
总结:
遇到过叹为观止的开发老哥,核心就是一个词 “ 难 ” 。跟产品吹,技术太难,可以实现,but难,会影响现有业务,然后从各个角度吹,这个老哥不止一次的把后台的需求吹到了前端。时间处理不做、分页不做、跟前端讲算法,无敌。跟boss吹,技术可以实现,but难,不止一次的把boss需求吹到产品改方案。这应该是最优雅的方式,不骄不躁,他强由他强,清风拂山岗。不管前期敏捷开发,还是中期各种评审后开发、这是我有生之年见过最优雅的。前端熬夜加班,老哥已经撑起行军床入眠了😊。讲真的老哥技术不怎么样,很一般,but (理论扎实+吹水)=== 无敌。
我一般是能动手尽量不bb,先打一架,打完再回来改需求。
优雅的第一步,就是去除冗余内容
改需求其实不可怕,拿钱干活儿,随你怎么改 可怕的是,改了需求,项目还要按时上线,然后加班加成狗,完了项目延期,还要背一口项目延期的大黑锅。
还有更加气人的,为了赶进度,负责人说,项目质量可以先放放,先把功能上去再说。
等你熬完2个通宵,项目终于上线后,第二天下午,正当你在睡梦中恢复元气时,突然接到项目负责人急催的电话,接通后,劈头盖脸就是一顿数落,打了你好几个电话都不接,你干啥去了,项目上线一堆BUG, 界面又丑的要死,你是怎么干活的。。。。。
你小声的抱怨了几句,说项目进度赶啥的,然后换来一句,“不要给我找借口,我要的结果”
有这样经历的请点个赞,我看有多少人遇到过
首先,我们的项目在开始前就已经有一个前期开会的评审了,在会上将一些疑问提出,哪些能做,哪些做不了的会给一些建议,最后会根据产品所需的功能大致给一个排期,确认了之后就严格按照这个排期来执行了。
如果突然改需求的话看这个需求是不是必需的,如果是比较需要的看是不是会影响排期,在不影响排期的情况下可以考虑加入,如果是比较花时间的就建议下个版本再加入,如果是比较大的功能非要加的话那只能重新排期了。
不过我一般是建议下个版本再加,毕竟突然改需求会影响我写代码的思路哈哈
分两种情况
1、不限时间,不会因为修改而加班的。改就改吧,反正我按时间拿钱,钱是老板的
2、已经谈好需求和时间,因为修改会增加工作量的。门都没有,要么加钱
最近一次遇到这种情况,我的回复是:你说的功能这一期没有规划,要不一起放到下一期
经历过三天一小改五天一大改,苦不堪言。
经理:我觉得这个需要改一下,我想做成……&*&%……%&dasfafadasfdaf*&*……*&*&¥%%#¥¥%¥@%&%&,你看下应该怎么改好点。
我:改****,不改,滚。
给加班费就一定优雅。
做啥不还是写代码吗?增加的工作量加钱就行。
一刀见效