如何评估一个需求？

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

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

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

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

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

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

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

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

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

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

需求做不完，怎么办？

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

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

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

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

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