收藏
回答

话题 全部话题

对于频繁更改的需求,程序员要如何“优雅反击”?

有时需求随着客户或产品的“心情”和“理论”反复变化,轻则小修小改,重则推倒重来......

你有过需求被频繁更改的经历吗?又是如何“优雅”应对的呢?🤔

写回答关注话题邀请回答

23 个回答

  • Stephen
    Stephen
    精选2019-12-02

    没改革之前,我们是产品说改就改,一天一个样,需求都没想清楚就让做,项目无限期顺延,开发整天加班改需求,那帮产品整天喝茶聊天的,真想在桌子上放把刀。


    后来改革了,老板要求需求必须出详细PRD,并且提前3个工作日邮件发给参与开发的人员进行了解需求,预订会议室进行评审。评审不通过,产品记录下来改PRD,等待下一次评审。评审通过后签字画押封版,开发预估开发工时,然后进行开发。如果在开发过程中出现需求变更,需要再出改动的PRD也是提前3个工作日发邮件评审,评审通过后预估工时,项目延期上线。那帮产品也开始整天加班画PRD了,哈哈哈哈哈哈哈哈哈哈哈!


    当然紧急需求还是得加班加点的改,特殊情况特殊处理


    贴个上次评审通过的表吧


    2019-12-02
    赞同 18
    回复 7
    • 少年啦
      少年啦
      2019-12-03
      表格能不能分享一下
      2019-12-03
      1
      回复
    查看更多(6)
  • 小满
    小满
    精选2019-12-02

    频繁更改的需求是一个产品不负责任的表现。🐶

    一个程序员跟产品交流的时间大于跟女票交流的时间。频繁的改动一般都是小公司吧,大厂咱也没去过,应该有严格评审标准的。讲一下今年跟产品爱恨情仇。

    初期

    也是刚立项没多久,这个时候频繁改需求的话建议不要“反击”。这个时间点老板定一切,程序员要改,产品也要改,设计也要改,人人平等。

    中期

    1.0:  产品期,一般频繁改动就在这个时间点。这个时候程序员一般是无法与产品抗衡的,产品呢说改就改,一天一个样,需求想一出是一出,业务逻辑有时候也不会考虑,都没想清楚就让做,一般做着做着发现MD,这里昨天改了逻辑变了,今天要改内页,结果就是哪哪都需要改动。加班加点。

    2.0: 项目期,这个时间段项目经理就要接手了,同样程序员无法跟项目经理抗衡。2.0的时候记住依靠在项目经理的大树下,这个时候产品改需求需要进行评审,项目经理是大腿,遇到个不会技术的项目经理那就要吹水,这就需要平时多关注论坛,多交流,同时日常抨击其他公司产品与技术。列举改动涉及的技术点,如果涉及没做过的领域,尽量多要点时间踩坑。这样项目经理一般会认真考虑需求,他害怕背锅。遇到会技术的项目经理,那就太舒服了,他会很认真的把各个需求点技术点给你总结指导的明明白白的。只要跟着他的节奏开发很舒服。

    3.0: 混乱期,各方大能齐发威,老板提需求,产品提需求,负责人提优化,正确的做法是明哲保身,如果只是普通开发那就好好开发,如果是负责人就要肛产品,给手下的兄弟争取合理的需求、待遇。

    后期:

    loaf on a job。改需求的时候可以优化下之前的代码,摸鱼有道。

    总结:

    遇到过叹为观止的开发老哥,核心就是一个词 “ 难 ” 。跟产品吹,技术太难,可以实现,but难,会影响现有业务,然后从各个角度吹,这个老哥不止一次的把后台的需求到了前端。时间处理不做、分页不做、跟前端讲算法,无敌。跟boss吹,技术可以实现,but难,不止一次的把boss需求到产品改方案。这应该是最优雅的方式,不骄不躁,他强由他强,清风拂山岗。不管前期敏捷开发,还是中期各种评审后开发、这是我有生之年见过最优雅的。前端熬夜加班,老哥已经撑起行军床入眠了😊。讲真的老哥技术不怎么样,很一般,but (理论扎实+吹水)=== 无敌。




    2019-12-02
    赞同 9
    回复 12
    • 🍑
      🍑
      2019-12-02
      说的太有道理了
      2019-12-02
      回复
    查看更多(11)
  • Code Weaver
    Code Weaver
    2019-12-02

    我一般是能动手尽量不bb,先打一架,打完再回来改需求。

    2019-12-02
    赞同 10
    回复 1
    • 铭锋科技
      铭锋科技
      2019-12-03
      和我一样
      2019-12-03
      回复
  • dio
    dio
    2019-12-02

    优雅的第一步,就是去除冗余内容

    2019-12-02
    赞同 8
    回复
  • 陈志国
    陈志国
    2019-12-04

    改需求其实不可怕,拿钱干活儿,随你怎么改 可怕的是,改了需求,项目还要按时上线,然后加班加成狗,完了项目延期,还要背一口项目延期的大黑锅。

    还有更加气人的,为了赶进度,负责人说,项目质量可以先放放,先把功能上去再说。

    等你熬完2个通宵,项目终于上线后,第二天下午,正当你在睡梦中恢复元气时,突然接到项目负责人急催的电话,接通后,劈头盖脸就是一顿数落,打了你好几个电话都不接,你干啥去了,项目上线一堆BUG,  界面又丑的要死,你是怎么干活的。。。。。

    你小声的抱怨了几句,说项目进度赶啥的,然后换来一句,“不要给我找借口,我要的结果”

    有这样经历的请点个赞,我看有多少人遇到过

    2019-12-04
    赞同 7
    回复
  • var 友原
    var 友原
    2019-12-02

    首先,我们的项目在开始前就已经有一个前期开会的评审了,在会上将一些疑问提出,哪些能做,哪些做不了的会给一些建议,最后会根据产品所需的功能大致给一个排期,确认了之后就严格按照这个排期来执行了。

    如果突然改需求的话看这个需求是不是必需的,如果是比较需要的看是不是会影响排期,在不影响排期的情况下可以考虑加入,如果是比较花时间的就建议下个版本再加入,如果是比较大的功能非要加的话那只能重新排期了。

    不过我一般是建议下个版本再加,毕竟突然改需求会影响我写代码的思路哈哈

    2019-12-02
    赞同 4
    回复
  • 祺爸💎
    祺爸💎
    2019-12-02

    分两种情况

    1、不限时间,不会因为修改而加班的。改就改吧,反正我按时间拿钱,钱是老板的

    2、已经谈好需求和时间,因为修改会增加工作量的。门都没有,要么加钱

    最近一次遇到这种情况,我的回复是:你说的功能这一期没有规划,要不一起放到下一期

    2019-12-02
    赞同 3
    回复
  • 鲤子
    鲤子
    2019-12-02

    经历过三天一小改五天一大改,苦不堪言。

    经理:我觉得这个需要改一下,我想做成……&*&%……%&dasfafadasfdaf*&*……*&*&¥%%#¥¥%¥@%&%&,你看下应该怎么改好点。

    我:改****,不改,滚。


    2019-12-02
    赞同 3
    回复 2
    • 2019-12-03
      经理:我觉得这个需要改一下,我想做成……&*&%……%&dasfafadasfdaf*&*……*&*&¥%%#¥¥%¥@%&%&。这么点儿东西,1天能改完吧
      2019-12-03
      1
      回复
    查看更多(1)
  • 老张
    老张
    2019-12-02

    给加班费就一定优雅。

    做啥不还是写代码吗?增加的工作量加钱就行。

    2019-12-02
    赞同 3
    回复
  • Listen
    Listen
    2019-12-07


    一刀见效

    2019-12-07
    赞同 2
    回复

正在加载...

登录 后发表内容