如何评估一个需求？需求做不完，怎么办？

如何评估一个需求？

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

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

需要对接第三方系统
对接第三方系统，沟通成本很大，往往会有不可控的情况出现。尤其是作为下游，容易受上游的影响。
需要用到多个数据源。
数据源越多，往往越复杂。有些数据要怎么取，可能都得想半天。
参数特别多。
在调用第三方的接口时，参数越多，越复杂。
一定要搞清楚，每一个参数，每一个字段，是怎么取数的。
怎么输入，怎么输出的。
有时，某一个参数没有搞清楚，就需要花费好几天的时间去处理。
大型业务重构
如果对原来的业务不熟悉，又没有老员工指导。重构会非常麻烦。遇到问题，定位起来也很困难。
数据量大
数据量越大，遇到的技术挑战会越大。评估需求时，一定要注意数据量。
并发高
是否高并发，评估时一定要多注意。
陌生的技术栈
技术栈不熟悉，踩到坑不知道怎么解决，花费的时间就会非常多。
倒排需求
宽松评估需求，拒绝倒排需求！！！与其最后加班加到死，还做不完，还要被怼，不如早点拒绝倒排！！！
好好评估，不要一被挑战就怂了，哪怕是多了一天的开发时间，都能让自己少加班一会。
倒排需求，时间基本就是倒推的了，没法宽松地评估，一般也没什么buffer，一旦遇到开会多，沟通多，那时间就非常紧张了。
并行需求
并行越多，一般效率会变得越低。最好能先专注一个需求，做完了再做其他的需求。

需求做不完，怎么办？

拆解工作项，向上级要人力和时间，砍需求
拆解工作项，颗粒度一定要细，如果一个工作项评估是3天，那领导可能会问，为什么这一个工作项就要3天？
拆解出来的工作项，最好是1天。
拆解完工作项，就向上级暴露风险，要资源，加人力，或者加时间、砍需求。
提前暴露风险
风险越早暴露越好。不要等到最后的时刻才暴露，那可能没法挽回了。
不要害怕暴露风险，提前暴露风险，是水平高的表现。
分批转测
分批转测，听起来不错，实际效果不会很好。因为一边开发新的功能，一边又跟测试沟通，改bug，效率会很低。
按优先级处理
优先级不高的问题，或者改不完的小bug，可以先上线，再优化。
完成大于完美
如果实在要不到人力和时间，那就不必过分追求代码的规范了，怎么快怎么来，及时交付才是最重要的。完成大于完美。