原则
典型的情况是，评估的精确度越高，所需的细节就越多，所需时间也越多。
考虑的因素包括
> 将系统按模块划分，每个模块需要多少时间，加上沟通的时间和测试、实施的时间，综合在一起的时间多算上30％，是系统总时间。
> 人员水平有高低，按平均算。如果有技术难点和需求变更，还多需要时间
> 加上项目管理时间, 一般说来，增加15%的工作量用于工程管理。
评估模型的关键在，评估要素的选取, 要素之间关系
1.确定涉及到多少模块，针对每个模块列出设计、开发、测试时间，组成这一模块的时间。
2.确定现场的需求澄清，设计，开发测试，配置，部署，集成的时间
3.项目管理时间，也就是耗损在开会，沟通，协调上的时间。
4.
( RD design （各个模块的时间相加）
RD dev
RD test
Onsite Requirement clarification
Onsite dev (可选项)
Onsite testing
Onsite Deployment
Related document update(可选项)
)
*1.3(风险系数，也就是意外事故时间，包括人员的调配, 返工)
项目管理时间 (有些需求，客户也不懂需要回去问其他team)
举例：
客户要求一个订购产品和取消订购的功能。
首先，走需求变更流程。 我们会问这个业务是哪里来的，是老系统已经存在的，还是新的要求？业务是否有合理的场景和理由支撑。还要检查这个系统是否符合我们的OOTB范围。然后审查之后觉得要求是合理的，也是现在需要必须现在就实现的。
第二步，引导出需求细节：
1.是否需要支持账户级别还是用户级别订购，还是都要涉及到
2.一次只能订购一个产品，还是多个产品。因为这个涉及到不同的方案。比如CRM可以发多个工单来实现多个订购。也可以发一个工单，多个产品。来实现订购多个产品。
3.订购的产品是否需要收取手续费，这个涉及到账务。
4.是否需要发短信，涉及到notification模块和信息模版的配置。
5.还需要标识是否是主产品订购，如果是，需要同步给华为的SCP侧。
-形成初步的需求文档，包括需求描述，Message flow，给各个模块的影响。
- 然后发给研发（信息管理，告警模块，华为，账务扣费）讨论解决方案。
-分别形成方案后，再开会形成统一方案。最后反馈到AIS，review我们的方案。
12345 这个部分要循环，往复好几次。
第三步，
> 需求文档的生成
> 解决方案文档的生成。
> 研发工作量的评估 现场工作量的评估
( RD design （信息管理，账务，告警，华为）
RD dev
RD test
Onsite Requirement clarification
Onsite dev (可选项)
Onsite testing
Onsite Deployment
Related document update(可选项)
)
*1.3(风险系数，也就是意外事故时间，包括人员的调配, 返工)
项目管理时间 (有些需求，AIS也不懂需要回去问其他team)
最后，由研发安排实施计划
