一、项目验收及总结
产品在开发完成，正式量产以前还有一项重要的工作，那就是项目和产品的验收。其实产品的验收不是某一个时间点，而是贯穿于整个产品的开发过程中的，比如说，咱们产品在A样、B样、C样；装车的M1、VP、TT等阶段其实都会有阶段性的验收。包括对产品功能和性能的验收，同时还会有跟项目相关的交付物的验收。
咱们这里说的验收，是整个产品的开发完成后的最终验收工作。自然是包括产品功能和性能的验收，也包括与项目相关的交付物的验收工作。也就是要做项目最后的收尾工作。
按照PMP等项目管理体系的说法是项目的收尾是一个正式的工作，也要有验收的计划，还要进行组织过程资产的归类整理和提交，项目物质物质的处理以及团队的解散等。但是实际在操作中因为各种原因，可能做的不会那么正规，通常是一个项目接着一个项目就这做着。虽然很多公司实际的项目不像PMP等体系那样去正规的操作，但是个人觉得，一个项目或产品开发完成后，产品的指标性能的评估、项目交付物的整理归档、项目开发过程中的经验教训的总结，不管是什么项目还是有必要做的。
1、产品验收
那什么是产品验收呢？
对于我们主机厂而言，产品验收就是站着我们的角度，以前期产品的技术要求为依据，评估供应商开发完成的产品是否符合其要求，是否达到了可以验收交付的标准。一般情况下，对于汽车产品，整车有明确的上市时间，虽然是要求产品在上市之前要达到SOP的标准，但是，如果因为技术原因、时间原因、或者其他原因等导致产品的某一项或者几项性能指标无法达到要求，而整改又需要投入很长的周期或者投入不少成本的时候，这个时候大概率会选择偏差认可。咱们在实际的项目中偏差认可常常碰到。
对于供应商来讲，产品验收就是站在客户的角度对产品的性能或者项目交付物满足于产品定义的程度进行评审。而验收一般都不是研发自己来做，而是由公司独立的质量部门或者专门的QA来评审。
对于车载电源产品，从主机厂的角度，咱们做最后的验收主要验收哪些方面呢？概括起来主要包括以下几个方面：
（1）、产品的性能指标；
（2）、与整车布置的匹配性；
（3）、DV、PV测试报告及测试结果；
（4）、与整车测试的结果以及报告；
（5）、历史问题的规避情况，是否还有历史遗留问题。这里的历史文艺包括包括以往项目历史问题和本项目开发中发生的问题。 一般公司都会有历史问题库和产品开发问题库，但是项目一般的历史问题库其实都不是很全或者说都经过了层层过滤后的。 而要全面的评估历史问题整改规避的情况，这个时候咱们前面提到的《产品开发过程中的问题记录清单》就可以发挥作用了。因为如果之前的清单记录的相信的话，会包括供应商产品开发中的问题和整车不同阶段装车验证中发现的问题，这是研发人员自己的记录，一定是要比项目的历史问题清单详细的。
（6）、产品功能开发的完整性。随着OTA的逐渐普及，如果是某些软件功能不完全，经评估对用户不会抱怨的话，而整车又急着上市的话，那咱们是可以通过后期的OTA来优化的。这样的软件功能不完整其实也是可以接受的。
……
2、项目交付物的整理归档：
说到项目的整理归档，不是说到了项目结束时才去整理，才去归档。如果真是等到项目结束时才整理归档，可能很多文件都找不到的。在实际的项目中大部分都是在项目的不同阶段进行一次项目交付物的整理归档，即使这个阶段有些数据或指标不那么漂亮也没关系。而到项目的最后阶段，整理归档交付物会更加全面，除了整理最后的写阶段的交付物以外，可能还要梳理以前主要项目阶段的交付的情况，做后做整理的整理归档，并作为项目的过程资产供后续项目调用和借鉴。
这里常常会有一个问题，很多时候，咱们在做新项目时却发现很难借鉴以往项目的数据，甚至进行关键词的搜索都搜不到，这其实就是在进行项目的交付物整理时没有统一的标准和没有继承性。这样也是蛮可惜的，以往的经验不能未我所用，每个新项目又从头开始经验积累，这对公司而言，也是很大的损失。 所以，每个公司一定要有统一的交付物标准和流程，甚至要细化到交付物内部内容的大纲、命名规则都要一致，方便查找。同时还要留有一定的可扩展性，为后续项目的交付整理留够足够的扩展接口。就像电脑的内存空间一样，很多电脑在出厂时都会多留一个内存条接口，如果后面要加内存条也是很方便的。
至于交付物内容，公司不一样、产品（车载、非车载）不一样、研发流程不一样都会有一些差异，这里就列举了。
3、项目总结
这里咱们说的项目总结并不等同于像那种简单的包括项目概括、项目过程的一些介绍、预算执行的情况等。而是应该比这些更详细的，主要侧重于经验的总结和提炼。可以包括从技术要求到产品开发完成的整个过程中咱们做到比较好的和做到不好的。可以包括技术要求的合理性，是要求高了还是低了还是比较合理？与供应商交流过程中哪些做的还不到位或者做的比较好的？供应商的选择标准有定的全面或者不全面的？产品开发管控环节有哪些好的做法和不好的做法？对做的好的，应该怎样保持并提取为团队的经验，做的不好的后续项目应该这样改进？等等。
咱们也可以根据实际情况，把产品和项目开发经验总结成好的“红色 案例”和不好的“黑色案例”库，以便于开发经验的积累和继承。
同时，项目总结也不是在项目结束以后才做，耳朵应该是根据产品和项目的开发阶段，分阶段进行，这样总结也比较及时和全面。
至于项目总结报告的模板和内容，可以参考自己公司的模板即可，当然咱们根据产品的特点体现一些特殊的内容也是可以的。这里就不展开说了。
最后，就是要特别强调一下的是，项目的总结会还是要开一下，最好所有项目成员都参加一下，也对上对下都有个交代。也需要这样一个仪式感。很多将项目管理的书里都说，项目总结要进行项目成员的奖励，其实我觉得，最好的总结会，重要的是经验的萃取。奖励最好放的平时对次进行，别憋大的，这样让项目团队也有掌控感，做起事来可能也会投入一些。
二、项目转产及支持
项目总结完以后也就意味着产品的开发工作结束了。按理说这个时候，研发团队就可以完全撤出来做新的项目了。但实际情况是，即使车辆上市以后，出现了质量问题和市场投诉，很多时候依然是需要研发进行支持的，而且支持的时间可能不仅仅是SOP+6，甚至是车辆的生命周期。
这样的情况，在国内大部分的主机厂都存在。究其原因，一是研发对了解产品，说实话，就是这“研发最了解产品”增加了研发多少的工作量，谁干谁知道啊；二是很多公司的售后人员对新能源产品不了解，有一些还是做传统燃油车的售后人员转过来的，专业性差了点；三是现在客户投诉市场问题的渠道更加的灵活，你要反应太慢，处理不好，立马网上的问题“小作文”到处乱飞。这些都需要研发的深度参与，否则完全靠售后的话，那删除“小作文”都要花很多的人力物力啊。
要做好SOP的支持，可不仅仅是量产后的技术支持和参与问题分析，而是应该是产品设计的前期就要求相关的售后人员参与进行，释放相关的产品技术要求和产品介绍文件，同时及早对售后人员进行相关的培训。这在产品开发中可能会增加研发人员的工作量，但是为减少SOP之后的“麻烦”，建议还是提早做一些工作比较好。当然，这也需要售后人员的配合，他们要愿意早点参与进来才行。很多时候可能需要从制度上去解决一下，避免售后人员前期“躺平”，后期只做“二传手”。
这里其实还涉及到公司的项目移交的流程，需要研发、产线、售后等相关人员的共同参与，产品的移交以及售后问题的处理才会更加地顺畅。
总之，短时间来看，研发是很难在SOP之后完全放手。咱们也只能提前做好心里建设，该分析的该处理的还的咱们搞，谁叫咱们最懂产品呢，是吧。
最后也希望在车载电源产品的开发中，主机厂与供应商能实现合作 、双方平等相处，共同进步，做好产品开发，服务好项目。
声明：以上仅代表个人观点。如有不当之处，欢迎各位同行批评指正。谢谢。
ND
希望对您有用！
请点击订阅关注
