V1.0：2022.12.15 以下是2022一整年在zxkj 管理系统组（内部测试、版本发布、mcu、fpga、Linux驱动）期间的总结和感想，如有新的体会，会更新加入。 一、背景： 0.公司是前装车载公司 1.公司不是靠卖产品赚钱，更想拉投资赚钱。 2.公司弱矩阵形式、有不成熟的PLM 二、问题解答 问题1： 吉利cms项目大坑： 1.产品/项目以为是做个demo，结果是做poc项目。时间、资源、要求严重低估。 --- 需求获取、需求导入、评估问题 2.开发时没有fae支持，PM只给时间节点，没有给资源 --- 没有根据资源评估时间 3.PM有强矩阵的权力，却只有若矩阵的能力《==其实我们就是弱矩阵模式 4.产品经理瞎定时间点 ---没有遵守研发流程，或者没有流程意识，时间应该是由下而上评估的，即由职能部门评估后向上汇总 问题2: 研发报的问题，测试、项目、产品都不知道，也没人跟进。 原因： 研发忙得本来就不想多找事情，上报问题如果还很麻烦，那他就会当做不知道，基本不会主动推进解决。 解： 定好流程，让研发或者其他人员，发现问题后，报给项目经理，项目经理整理到问题点清单或者tapd上面，再指定给相关责任人。 问题3： 研发看到TAPD或者问题单的时候，几乎都是摸不着头脑，不知道怎么回事，都要一个一个地去找相应的测试人员从新沟通 原因： bug管理和记录不规范 解： 对于所有的缺陷，都需要做到的是： 1，查看当前测试环境和测试数据，并记录下来。 比如，软件版本，什么机型，配置等 2，记录与该缺陷相关的配置等条件 3，记录出现缺陷时候log信息 4，描述尽量做到每个步骤最多两个动作，一连串的操作尽量分点描述。 6，缺陷出现时候的现象一定要描述详细，不要和步骤混在一起描述，一个步骤最好对应一个相应的输出结果 7，缺陷出现之后若可以继续进行操作，也尽量多做几个步骤，这样更容易发现当前缺陷周围的缺陷，8/2原则或许在这里可以起到作用。 8，尽量把缺陷出现时候的相关功能运行情况也都描述详细 9，对于一些比较难描述清楚、或者不能稳定重现的缺陷，在缺陷中需要添加出错时截图，所谓有图有真相。 10，缺陷描述的终极目的，先抛开缺陷记录的管理意义不说，主要是能让开发人员根据缺陷描述，轻松地重现缺陷 11，关闭bug之前，把修改方法写上去，可以作为知识沉淀的同时也可以让问题可追溯。 一句话，假如你来解这个bug，拿到bug信息，能否快速地复现bug，快速地定位问题. 看到别人改的bug，能确切地知道是怎么解决的。 问题4： 销售和产品的矛盾，销售卖的不是产品做的，产品做的又不听销售的，产品本身也无法把控整个方案 可能原因： 流程问题，导致产品和市场对接有问题 意识问题,IPD流程意识不足，自我意识太强，没意识到团队决策的重要性，自我决策的局限性。 问题5： 客户跟测试反馈的需求，没有经过产品经理和项目经理直接提到TAPD转到研发手中 原因： 项目前期的沟通规划没做好。项目初期没有定好问题对接人。 流程意识问题， 解： 初期定好沟通流程，确定对接人。客户有问题只能找某个人反馈，比如PM，PM经过过滤或组织评审后才能到研发部门 问题6： 供应链找不到强有力的技术支持，严重影响研发进度和成本。 1.客观原因： 量太小，谈判时不硬气。 做的平台、产品太杂，没法形成公共物料库 流程/制度上，研发成功与否，跟供应链没有利益（KPI）相连。供应链的工作也难以考核。 2.主观原因： 没有积极想办法利用现有资源去忽悠、去画饼、去争取（当然有些是不可以忽悠的） 解决/改善： 由供应链和研发一起去找供应商、跟供应商谈判，利用研发的积极性影响供应链推进？？ 做好产品规划，从而推进规划建立公共物料库，增加采购量，降低成本。 问题7： 吉利cms坏的板子没有及时安排维修，一遍一遍又一遍地流回到研发手中，结果以为是什么bug，浪费很多时间。 多人、多次反馈之后，到后期还不断出现这种问题。 原因： PM管理能力问题，工作没有章法。 问题8： 吉利cms样机严重不足，一线开发人员都要几个人用一台机器，测试、送样、联合调试的效率严重收到影响 原因： 前期评估对成本考虑过重，导致样机数量严重不足 样机评估能力、经验不足 解决： 项目细致统计所需样机数量，并乘以个大于1的系数，比如X1.2留几台备用。 问题9： 经典问题，FDM项目板子回来之后，物料还没买回来。 原因： 项目经理项目的整体意识不足 解： 物料购买的两个关键点 a.原理图出来之后，让供应链着手购买关键物料（一些公共物料原理图出来之前就要着手准备）. b.bom表出来之后，立刻马不停蹄采购其余非关键物料. c.要每天思考可能卡住项目进程的风险，并及时作出干预. 问题10： CV25平台的多个项目有很多一样的、很简单的问题，导致一次又一次的返修、升级，费时、费力。 原因： 1.产品规划，和平台规划有问题，平台没做好、做扎实，就匆匆推出多个项目 2.发现问题之后，没有平移到其他项目的流程、机制、负责人和意识。从而导致同样的问题多次流到客户现场。 解： 1.先规划好产品和平台，把平台做好再做项目，同时市场根据平台做营销，这样也可以提高市场和项目的成功率。 而不是不管公司现有什么平台，什么项目都接，搞到最后又辛苦又亏钱。 2.发现公共性的问题、平台性的问题，研发总监需要及时发现并督促相关研发人员留出时间，完善平台。避免问题一而再再而三出现。 问题11： 大多数是送样项目，花大量时间人力物力去做的项目，送完样就没结果了（项目做着做着就消失了） 造成研发资源浪费，研发成本增加 原因： 公司缺乏机会识别、商业分析的流程， 相关人员没有责任 解： 完善公司机会识别、商业分析的流程，完善项目评审流程，设置必要评审关口。 定时整理各个项目情况，对于没动静的，没利润的，耗时好资源的项目，启动评审流程，若发现项目不再有价值，及时停止 问题12： 软件分支、硬件版本号、项目编号、客户，难以对应上。拿到硬件，或者收到客户反馈的问题，无法迅速知道是哪套代码哪个代码分支。 原因： 硬件、软件、项目都有自己的编码和命名规则，三方未达成一致 解： 统一命名， 或者用一个表格维护，代码、硬件、客户、项目的对应关系。 问题13： 项目盲目投入，项目挡不住产品，RD挡不住项目 原因： 商业评估、需求评估、导入、评审流程不完善 问题14: 项目经理不够了解项目，无法及时识别项目风险，协调项目资源作出应对 原因： 产品复杂，单纯依赖PM的个人能力很难把握整体项目情况 解： 建立问题反馈流程，合理设置评审关口，通过夸职能团队评审会议，以及时发现项目风险，并作出应对。 问题15： 没有系统工程师，没有LPDT（研发产品经理） 没人对整体研发商业成果负责，没人对整体系统负责，导致项目做不好，或做好了也不赚钱。 问题16: 如何管理外包项目： 1.外包管理方式,内部成立由各个职能部门代表组成的项目组，对供应商进行设计评估，沟通。 2.把项目当做自己在做，只是具体实施是由供应商完成。所以内部该走的流程，该把的关，该做的评审一个不少，而且要更严格。 3.定时开项目，启动会报、周报机制，跟进进度，梳理问题，把控风险。 4.合同约束（范围、进度、成本、质量、沟通、风险、售后） 5.必要时集中办公 问题17： 评审不充分，导致很多项目的坑到开发时才发现，造成重大问题或变更。 比如：吉利cms项目，做好样机，送样之后，cms主控、摄像头都做了变更。 比如：本田DVR项目，因为前期ID(外观设计)评估没考虑结构大小，导致后来layout时板子太小放不下元器件，所以很多冗余设计和防护性措施（比如预留的mic回环）都删除了.这删除修改还导致严重的delay. 比如：阿里昂斯项目干了4个月，才知道摄像头无法满足客户要求。 榕 5-6 09:20:57 对于这个问题我想知道的是，摄像头拿到的时候所支持帧率是不是就已经知道了！是哪个环节出的问题？ xx榕 5-6 09:27:53 项目干了4个月！快结束了，才发现 原因： 1.评估不充分 <==评审有时候流于形式 <== 评审员准备不足 <== 责任不清晰 <== 流程不清晰，相关人员意识不足 2.相关人员没有系统地、长远地考虑项目问题 3.没有设置必要的评审关口 解： 利用IPD和门径管理的思想，评审时充分发挥各职能部门专业所长，并设置必要的评审关卡。 总结出确实可行的有利于长远规划且系统的评审流程。 指定职能代表， 评审前把评审资料&评审内容发给评审人员先行分析讨论。 评审完毕后，对评审结果无异议，则签字画押。 万一评审疏漏出现问题，需写总结并作报告（即评审员需要负责）。 问题18： 本田DVR项目，板子没回来，没什么事情的时候就安排加班到10点，周六计入上班时间，导致人疲马乏。最终从各个方面（比如工程师消极对待开发，引入风险，延长时间）影响项目。 原因： 1.项目管理能力问题 2.拍脑袋的不会设身处地为真正干活的考虑。 问题19: 本田dvr项目，因为硬件delay、系统设计在预研阶段产生很多跟之前wbs不一样修改（比如mcu电源管理、升级方式），却没有及时调整项目计划和系统设计文档。 原因： 1.项目管理能力不足，对项目整体理解不到位，不能及时洞察项目的变化 2.项目成员发现问题，一般不会积极反馈，因为没有反馈通道和机制，更没激励。 解： 1.pm不能像项目助理一样，只是跟进度，要培养自己理解项目整体框架的能力，这样才能更好跟项目相关方沟通，更容易更及时发现项目风险，并作出干预。 2.建立沟通计划/通道，项目会议上定时向项目成员收集问题，并给予积极反馈。 3.设置评审关口，通过夸职能团队评审及时发现问题、更新计划。 问题20: 为何从上到下辛苦一年了没有一个出货项目？ 1.市场萎靡，加上市场分析（成本、竞争对手、市场容量、政策等等）、客户调研/跟进有问题。 2.心态不够稳，一有项目就像抓救命稻草一样，然后瞎搞，没有按既有的流程和框架推进，并设置评审关口，没有价值的项目没有及时止损。 3.产品规划，和平台规划有问题，没有先规划好产品和平台，再做项目，然后市场根据平台做营销，这样可以提高市场和项目的成功率 问题21： 为何一有项目就加班加点，定一些不切实际的计划，匆匆忙忙地在引入很多潜在风险？(欣源流媒体FDM、本田DVR、长安FDM) 原因： 1.较难改变：RD <== pm要求 <== 产品要求 <== 客户（市场）要求 2.没经过评审，产品或研发的某人拍脑袋决定的 解： 1.RD根据实际资源和能力评估时间，反馈给产品（市场），从而反向影响客户，以争取更多的时间。而不是产品拍脑袋给客户瞎报一个时间点。 如果客户不接受，时间节点又相差不大，那可以先答应，然后根据项目所遇到的困难，慢慢往后延期（事缓则圆）。 2.重排项目优先级，从其他项目抽调人力和资源过来支持。 3.平衡风险和进度，做出比一般项目更可靠的进度和风险的评估，对风险提前作出评估、干预、应对。 4.不可为了进度而忽略风险，到最后风险结果由研发承担（因为表面看的结果是：研发没按进度和质量要求完成产品开发），最终损失其实是由公司承担。 三、经验教训： 别的DVR项目，guoliang分享的经验教训： 1. 双面胶增加底涂剂，这个看来是非常必要的；--@李俊仁 2. 如果设备有排线，最好设计一款接地的排线，不用包导电布，虽然排线成本上升，但生产流程简化了；-@唐燕 3. 线束如果有多个接口，要提前获取车身数据，评估线束安装方式及接口出线位置； 4. 图像质量要有明确的规格需求，摄像头现在我们有了工程师，提前走导入流程，切忌不要让产品自己拍； 5. 所有的需求由系统工程师主导梳理后，形成详细的需求分解，给客户签字画押； 6. 硬件开发如果我们依托外部供应商，一定要采购和供应商谈好，我们的硬件有设计决策权，最好不要找方案商这类的供应商，沟通从上到下是没办法达成基本的逻辑共识； 7. 供应链一定要强参与进来，DDP现在供应链有点心有余而力不足的问题，他们基本都没办法推动供应商； 8. 来料品质需要推动品质部尽快形成来料规范，现在我们的品质有点客户说啥就干啥，没有自己的专业判断。
标签：总结,产品,项目,流程,研发,问题,2022,评审 From： https://www.cnblogs.com/chip-tech/p/17057248.html