如何评估一个需求?需求做不完,怎么办?

如何评估一个需求?

  • 需求的背景是什么?为什么要做这个需求?这个需求有什么价值?这个需求对比人力的性价比怎么样?
  • 提前看需求文档,不懂得及时向产品提问
  • 哪些功能是新增的,哪些功能是修改的
  • 需求的流程是怎样的
    在脑子里面过一遍,整个需求的流程是怎样的。
  • 写技术文档
  • 工作项拆解
    整个需求的功能包括哪些子功能,拆分为多个工作项。
    要写多少个接口/页面,要设计多少张表。
  • 工时评估
    拆解完工作项,可以给每个工作项评估1-2天的时间。
    如果一个工作项的工时超过了2天,那就继续拆解。
    简单的功能,可以把1张表的增删改查评估1天的时间。
    或者是,简单的接口,一个接口可以评估1天的时间。
  • 尽量多留些buffer
    开发过程中,经常会有各种破事,比如开会,线上问题,同事打扰之类的。。一定得留buffer。
    比如一个功能,需要半天,最好就评估一天。
    在转测时间上面留些buffer。
  • 数据量多大
  • 是否影响历史数据

哪些需求可能风险会比较大?

  • 需要对接第三方系统
    对接第三方系统,沟通成本很大,往往会有不可控的情况出现。尤其是作为下游,容易受上游的影响。

  • 需要用到多个数据源。
    数据源越多,往往越复杂。有些数据要怎么取,可能都得想半天。

  • 大型业务重构
    如果对原来的业务不熟悉,又没有老员工指导。重构会非常麻烦。遇到问题,定位起来也很困难。

  • 数据量大
    数据量越大,遇到的技术挑战会越大。评估需求时,一定要注意数据量。

  • 并发高
    是否高并发,评估时一定要多注意。

  • 陌生的技术栈
    技术栈不熟悉,踩到坑不知道怎么解决,花费的时间就会非常多。

  • 倒排需求
    倒排需求,时间基本就是倒推的了,没法宽松地评估,一般也没什么buffer,一旦遇到开会多,沟通多,那时间就非常紧张了。

  • 并行需求
    并行越多,一般效率会变得越低。最好能先专注一个需求,做完了再做其他的需求。

需求做不完,怎么办?

  • 拆解工作项,向上级要人力和时间,砍需求
    拆解工作项,颗粒度一定要细,如果一个工作项评估是3天,那领导可能会问,为什么这一个工作项就要3天?
    拆解出来的工作项,最好是1天。
    拆解完工作项,就向上级暴露风险,要资源,加人力,或者加时间、砍需求。

  • 提前暴露风险
    风险越早暴露越好。不要等到最后的时刻才暴露,那可能没法挽回了。

  • 分批转测
    分批转测,听起来不错,实际效果不会很好。因为一边开发新的功能,一边又跟测试沟通,改bug,效率会很低。

  • 按优先级处理
    优先级不高的问题,或者改不完的小bug,可以先上线,再优化。

  • 完成大于完美
    如果实在要不到人力和时间,那就不必过分追求代码的规范了,怎么快怎么来,及时交付才是最重要的。完成大于完美。

你可能感兴趣的:(项目管理,java)