ASPICE_MAN.3项目管理之基本实践解析

这个实践应该很好理解，实践中大家也都会去执行，毕竟拿项目前还是要掂量一下自己的公司的实力的，但是执行方法上还是要注意如下几点：Do0ednc

1. 技术可行性，虽然大家都会执行，建议写上可行的理由，如果只有结论，客户审核或者评估时都可能记不起来当时说可行的逻辑或假设是啥了。Do0ednc

2. 资源可行性，资源包括但不限于人员工作小时、工具及license、分供方成本，且不能仅凭计算的投入产出比来说是可行的，一定要考虑组织能否提供足够的资源，比如去年公司做了两个项目，今年来了10个，若要做，可能要有招聘和设施采购计划来支撑，才可以说资源可行。Do0ednc

3. 时间可行性，所有项目都有时间要求，这方面的可行性也要考虑，涉及供应商时，一定要考虑供应商的时间计划。Do0ednc

4. 法律法规可行性，在欧美汽车行业，要求的法律法规较多，中国相对会少些，但是不能不考虑，尽管最后分析出来可能没有相应的法律法规要求。Do0ednc

5. 形式上最好表格化或通过工具把项目要求一一分析并做好链接关系，要不然客户在SOW里提了30条项目要求，我们用一页A4纸张完成可行性分析，半年后客户来审核时问第23条要求的可行性分析记录在哪里，或判断它可行的逻辑是啥，从回忆里找就不见得找得到了。Do0ednc

6. 如果某需求不是完全可行，也不是完全不可行，则需要记录风险。

1. 因为在在定义项目进度计划时，首先要考虑的就是就要定义项目要执行多少活动，并且对应哪个里程碑，可以从项目范围的工作包分解到颗粒度更小的活动，然后建立各个活动之间的依赖关系，比如：哪个活动在某个活动完成之后开始，哪个在某个活动开始的同时可以开始；Do0ednc

2. 项目范围一旦确定后，定义项目资源或者叫做估算的事情将与项目进度的定义并行开始；资源定义和进度定义很多时候会交织在一起，比如，汽车动力系统计划在7月份的吐鲁番做高温标定，即使4~6月份有很多标定工程师的资源，但是也不能用，因为温度不够高，所以资源和进度可能受到相同的客观因素影响，而7月又有很多车型同时进行高温标定，那是进度提前或者推后两周呢，还是安排标准工程师加班呢，这对资源成本的影响是不一样的，所以说项目资源定义和进度定义往往是交织在一起的，资源和进度相互影响，而没有额外约束的活动则根据资源分配量定义活动周期，最后项目进度和资源达成一致后同时完成定义；Do0ednc

3. 活动、资源、进度的监控和调整也是同时发生的，因为他们三者都是相互影响的，比如资源减少，那进度基本要延期，活动结束时间推迟，或者活动被分解为多个间断性的活动来执行。

   根据个人的评估经验，在这三个BP（BP4、BP5、BP8）中，有如下要点注意：Do0ednc

   1. ＢＰ４定义的项目活动应该包含所有活动，如评审，问题管理，变更管理，发布等，且活动周期不要超过４０个小时；Do0ednc

   2. 项目进度计划中的活动都要定义产出工作产品，因为每项活动都是为了产出特定的工作产品而执行的。Do0ednc

   3. BP５资源的估算方法是评估的重点，会展开讨论，但ASPICE不指定那类估算方法，只要能自圆其说，逻辑合理即可，比如经验估算，三点估算，COSMＩC估算等；Do0ednc

   4. 首次定义的项目计划中分配的资源一定要和初版估算保持一致；
   5. 监控调整中进度进化中的活动及其计划、实际日期要和项目周报，活动的实际日期保持一致。
   MAN.3.BP5:定义、监控和调整项目估算和资源。基于项目目标、风险、动机和边界，定义、监控和调整项目工时和资源的估算。
   此BP已在BP４处一并展开讨论。
   MAN.3.BP8:定义、监控和调整项目进度表。分配资源给活动，并安排整个项目各活动的进度计划。在项目的整个生命周期内，须持续更新进度表。
   此BP已在BP４处一并展开讨论。

   Do0ednc

   图6 定义、监控和调整活动、资源、计划

   MAN.3.BP6: 确保所需的技能、知识和经验。基于估算，识别项目所需的技能、知识和经验，并确保所选择的项目成员具备或者能及时获得所需的技能、知识和经验。

   该要求容易理解，基本大多数组织都有技能矩阵来定义和评估所需的知识、技能和经验，但做到经得起推敲，需要考虑如下几点：Do0ednc

   1. 定义的技能、知识和经验是具体可衡量的，比如：对单元测试工程师要求JIRA的技能达到level3,这就很容易误解，JIRA可以做需求管理，变更管理，问题管理，测试用例管理等，这个level3包括需求管理的功能吗？Do0ednc

   2. 知识、技能和经验的评估，通常需要考虑以下几个方面：产品领域，过程领域，相关工具，软技能等需要具备的完成被分配角色和任务的所需的知识技能和经验。Do0ednc

   3. 如果评估的水平与期望的水平有差距，通过培训可以改善，但是高级别的差距通过培训是不够，需要考虑实操练习来提高。
   MAN.3.BP7: 识别、监控和调整项目接口及约定的承诺。识别项目与其他项目（子项目）、组织单元及其他受影响的利益相关方的接口，对识别的接口达成一致，并监控约定的承诺，按约定例行沟通。
   约定的承诺可以理解为简要职责，如哪个接口人员负责干啥，比如客户接口中有项目接口、技术接口、质量接口、采购接口，不定义清楚就不知道谁负责批准供应的变更请求，也不知道谁负责发布，谁负责接受并确认发布。
   接口的定义需要全面，如项目团队成员，公司内部管理层，客户，供应商等相关方。
   MAN.3.BP9: 确保一致性。确保项目的估算、技能、活动、进度表、计划、接口和承诺对各受影响方的一致性。

   这个一致性其实易懂难做，因为要保持一致的地方太多了，此处仅列举如下三个不一致的案例作供参考：Do0ednc

   1. 项目管理计划其实评审了两次，可在项目进度计划中只有一次评审活动；Do0ednc

   2. 项目管理计划是在2023.12.25评审通过了，可在配置工具的检入时间戳是2023.1.3;Do0ednc

   3. 项目进度计划是用Project工具做的，可以在技能表中未对项目经理有Project的技能要求。
   MAN.3.BP10:评审和报告项目进展。依照估算的工时和工期，定期评审和报告项目状态和活动完成情况给所有受影响方。预防已识别问题的重复发生。

   项目周报、内部汇报、客户汇报都定期执行即可，然后项目周报的监控要全面，包括近期的已完成事项和代办事项，问题，变更，资源，风险。Do0ednc

   3  输出工作产品Do0ednc

   ASPICE为每个过程都定义类似下图所示的输出工作产品，但仅为参考目的，各家企业都可以定义自己的工作产品，包括名称、数量、文档格式，以及如何在信息系统或者工具中体现，只要覆盖了基本实践（BP）要求即可。