建设网站东莞,百度外推排名代做,羽毛球赛事策划方案,server 2008 架设网站如何评估一个需求#xff1f;
需求的背景是什么#xff1f;为什么要做这个需求#xff1f;这个需求有什么价值#xff1f;这个需求对比人力的性价比怎么样#xff1f;提前看需求文档#xff0c;不懂得及时向产品提问哪些功能是新增的#xff0c;哪些功能是修改的需求的…如何评估一个需求
需求的背景是什么为什么要做这个需求这个需求有什么价值这个需求对比人力的性价比怎么样提前看需求文档不懂得及时向产品提问哪些功能是新增的哪些功能是修改的需求的流程是怎样的 在脑子里面过一遍整个需求的流程是怎样的。写技术文档工作项拆解 整个需求的功能包括哪些子功能拆分为多个工作项。 要写多少个接口/页面要设计多少张表。工时评估 拆解完工作项可以给每个工作项评估1-2天的时间。 如果一个工作项的工时超过了2天那就继续拆解。 简单的功能可以把1张表的增删改查评估1天的时间。 或者是简单的接口一个接口可以评估1天的时间。尽量多留些buffer 开发过程中经常会有各种破事比如开会线上问题同事打扰之类的。。一定得留buffer。 比如一个功能需要半天最好就评估一天。 在转测时间上面留些buffer。数据量多大是否影响历史数据
哪些需求可能风险会比较大 需要对接第三方系统 对接第三方系统沟通成本很大往往会有不可控的情况出现。尤其是作为下游容易受上游的影响。 需要用到多个数据源。 数据源越多往往越复杂。有些数据要怎么取可能都得想半天。 大型业务重构 如果对原来的业务不熟悉又没有老员工指导。重构会非常麻烦。遇到问题定位起来也很困难。 数据量大 数据量越大遇到的技术挑战会越大。评估需求时一定要注意数据量。 并发高 是否高并发评估时一定要多注意。 陌生的技术栈 技术栈不熟悉踩到坑不知道怎么解决花费的时间就会非常多。 倒排需求 倒排需求时间基本就是倒推的了没法宽松地评估一般也没什么buffer一旦遇到开会多沟通多那时间就非常紧张了。 并行需求 并行越多一般效率会变得越低。最好能先专注一个需求做完了再做其他的需求。
需求做不完怎么办 拆解工作项向上级要人力和时间砍需求 拆解工作项颗粒度一定要细如果一个工作项评估是3天那领导可能会问为什么这一个工作项就要3天 拆解出来的工作项最好是1天。 拆解完工作项就向上级暴露风险要资源加人力或者加时间、砍需求。 提前暴露风险 风险越早暴露越好。不要等到最后的时刻才暴露那可能没法挽回了。 分批转测 分批转测听起来不错实际效果不会很好。因为一边开发新的功能一边又跟测试沟通改bug效率会很低。 按优先级处理 优先级不高的问题或者改不完的小bug可以先上线再优化。 完成大于完美 如果实在要不到人力和时间那就不必过分追求代码的规范了怎么快怎么来及时交付才是最重要的。完成大于完美。
