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