2022/07/25
在报价，人力(MM)和工时上，我们会列出两张表格。第一张是开发列表对应MM的维度。第二张是MM列表对应的开发工时的维度。
1. 开发列表对应MM
纵坐标是客户需求，也就是开发任务，一般份两个阶梯，一个是大的开发项目，另一个是拆分出来的子开发模块。
横坐标对应几个维度的报价：产品+项目,GUI,UX,CDR(server+APP/设备),开发内容(server/APP/设备),测试(server+APP/设备)
- 产品+项目就是产品经理+项目经理投入的MM
- GUI是用户图形界面设计的MM
- UX是交互设计的MM
- CDR是开发路径说明文档的MM，在大客户的流程中，他们希望先明确开发路径，形成文档，讨论没问题再进行开发，避免开发到一半发现需求要更改或者实现不了从而造成没必要的扯皮和返工。一般来说，云端，APP和设备端都分开报
- 开发内容就是具体开发需要的MM，一般来说，云端，APP和设备端都分开报
- 测试就开发后测试的MM，一般来说，云端+APP报价，设备端单独报
- total
- comment是每一轮报价中，双方对有异议的点提出自己的观点，之后根据对方观点内部再各自进行商讨
根据我的习惯，每一个不同开发项目，我会用不同底色标出来。而每一个谈判迭代，我都会用不用的颜色更替，从而方便客户知道更新了哪一部分。最终呈现的结果如下图。
注意点
- 需求以”开发任务“罗列，拆解到“子模块”，颗粒度尽量拆分每项开发子任务的全部MM是0.25MM以下 (交互/UI的页面设计，可以按0.05MM为最小单元)
- 一个项目的关键任务，涉及后端Server定制的，一定要考虑CDR，CDR一般针对特定的功能/接口，需编写call-flow
- APP的开发和测试，一定要考虑到两个端(AOS & IOS)
- 开发工时(APP&Server) v.s 测试工时(Functional Test)，可考虑按2：1或者3：1，测试的工时别忘记datalog
- 涉及到硬件或者固件，要把对方的安全需求和企规以文档需求列表的形式提供过来确认。这部分要求很容易遗漏而且整改付出会很大（比如G3的固件安全整改）
- 交付过程中的整改测试不算MM
- 客户验证阶段需要的样机数量也需要先明确， 看是否有必要找客户收费（也可以另立补充合同）以及安排内部试产数量
MM列表对应的开发工时
纵坐标是客户需求，也就是开发任务，一般和上面一样，就是对应拆分出来的子开发模块
横坐标分两个维度的信息，一个是需要开发的日程，一个是需要投入的工程师人数和每位工程师的MM（此项非必须，根据客户需求）
注意点
- 工时上，要把硬件内部的DVT考虑在内。因为我们开发完成后，还要进行试产，同时把试产的机器寄给客户，客户才能有足够的设备进行测试
- 要注意第二页项目最后核算出来的MM数要和第一页对应得上
- 不同级别工程师对应的MM要和客户先确认。此页中也可以体现工程师的级别。若钱涉及到汇率换算，记得要先确认清楚
- 如因外部压力等必须并行开发的，需将以下因素纳入整体考虑：
- 不超过2个项目同时开发
- 项目与项目之间的DVT验证时间，要错开
- 每个项目的开发环境，要错开
- 1个项目DVT和另一个项目的DVT之间，不要紧密衔接，需要预留缓冲时间，至少预留1~2个双方验证周期为宜