|
朱晓明按： 关于精益开发，华为也在内部学习和发起过，而且正在大规模推广的时候，“丰田”出了“刹车门”事件， 丰田汽车公司因为“刹车门”事件，宣布在全世界回收910余万辆汽车。 910万辆汽车对于丰田公司来说，意味着什么？ 这意味着这一家公司一年生产的汽车全部重新回炉还不够。且不说，这么多汽车的回收与修理需要支出多少庞大的费用？其实最糟糕的，无疑是“世界最高品质”的丰田车在全世界的威信扫地。 于是，后来“精益开发”在华为并没有大规模的推广和学习。如同，温州动车撞车之后，华为的高铁的安全计算机项目也就慢慢的消失了。这就是华为的优点：善于批评和自我批评。 关于精益开发还有个故事：华为某大业软的领导，跟硬件部说，你们怎么进度这么慢？画个PCB怎么还要30天？你们不是搞精益开发了么？不是可以快速交付了么?你们可以安排30个互连工程师（PCB Layout工程师），一天不就搞定了？不管什么管理方法，我们都需要充分理解，并且要与实际的客观规律相结合，否则就要闹笑话了。 但是不可否认：丰田是一家非常伟大的公司，精益开发也是非常伟大的管理方法。值得我们去学习。 正文： 英雄所见略同（IPD与精益）——这是我读完丰田精益产品开发体系十三个原则后想到的第一句话。 不能说每一条原则都是和华为IPD管理体系一致，但是可以说，大部分的思想都是一致的。成功总有相似之处啊。 对于精益产品开发体系也刚在学习之中，所以下面的解读仅仅是个人粗浅看法，欢迎大家一起探讨，更欢迎了解精益产品开发的高手来指点江山。 
上图为精益产品开发体系统模式，13个原则就是围绕“流程”“高技能员工”“工具与技术”三个子模块提出的。
今天我来给大家把精益开发的“流程子模块”与“IPD”流程做一个对比。 精益开发的“流程”子模块，原则1到原则4。 原则1：确立由消费者定义的价值，把增值活动与浪费区别开来 IPD流程体系中非常重要的一个组成部分就是需求管理流程。它定义了整个需求管理的过程，包括了需求的收集、分析、分发、实现、验证，哪一条需求是怎么来的，怎么实现，验证的结果是什么，都有清晰，可追溯的痕迹。 工程师容易犯的错误是什么？ 老子技术天下第一，但是你的技术再牛叉，你开发出来的东西不是客户需要的东西，有什么意义呢？所以一些产品开发的源动力，都应该来源于客户需求。 要真正做到“以客户为中心”也不容易。很多企业都喊着这个口号，但是实际做到的又有几家？ 大家可以盘点一下自己公司的产品，是不是所有产品的开发都是以客户需求驱动的？对于客户的需求，是简单的拿来就用，还是经过理解和澄清？有没有主动帮助客户挖掘深层次的需求？公司内部的所有部门，都是围绕“实现客户需求”在转吗？整个开发的过程中，有没有需求的跟踪？ 何为浪费？ 所有跟客户需求无关的是浪费，过度设计也是浪费。 HW有个例子，某个地方发生大地震，别人家的基站都倒了，华为的基站没倒，本来工程师们还在得瑟，结果老板发火了，该倒的时候不倒，这也是浪费，这是质量成本的浪费！ 不过请你们不要教条，客户层面看不见的基础功能的实现，那不叫浪费。修房子不打地基，能修好吗？但是修30层高的房子，打100层的地基，就是浪费。 原则2：在产品开发流程初期彻底分析各种可选方案，因为此时设计改变的空间最大 以硬件为例，华为的开发流程一般是这几个阶段：需求分析，概要设计，详细设计，原理图设计，PCB设计，调测与测试。整个开发的过程，前期的分析占了一半以上的时间，就是为了在开发前期进行充分的分析，避免前期的工作不充分，导致后期的返工重来。 总有人喜欢拿产品开发周期太短，当作不好好做设计方案、不写过程文档的借口。真的是这样吗？难道画原理图就真的只是在“画”原理图，不需要思考？芯片与芯片之间的管脚应该怎样连接，芯片的外围电路应该怎样设计，需要调整阻值、容值的地方该怎样调整，这些难道不需要好好分析之后才能出结果吗？分析的过程是什么？就是写技术方案的过程。别觉得写文档是负担，这是在帮你思考！ 再说回进度和成本的问题。首先是进度，我认为产品真正能够稳定量产的时候，才算开发周期结束，而且在整个开发周期内，质量问题是处于收敛状态的。千万别说产品都已经量产都已经发货给客户了，还不断爆问题，还需要修改设计。如果你的产品是这个情况，我只能说产品的开发质量不及格。在这样的状态下，光追求快又有什么用？再从成本的角度看，到底是开发初期进行充分分析讨论，把问题提早暴露出来耗费的成本少还是等到调试的时候发现一堆问题来改板成本少？ 有句话叫“出来混总是要还的”。需求阶段不分析清楚需求，方案设计阶段不好好做各种分析，到了调试的阶段，通通要还回来，而且是加倍的还。  原则3：建立均衡的产品开发流程 “尽管在某个项目中可能存在特殊或特有的设计问题，但是对于不同的项目来说，应该采取的步骤以及顺序基本上是相似的”这是原话。 从HW的角度来看，虽然后面分成了3大BG，开发流程也各有区别，但实际上除了终端产品确实比较特殊，有自己的一套开发流程外，其他两个BG的N个产品线，基本上还是遵循的同一套开发流程。有了共同语言，才有对话的基础，才能保证基本一致的输出，才能保证产品的成功。产品的成功不依赖于某个人，不因为人员的流程而产生巨大的波动，这就是流程的价值。 那么怎样对待开发过程中的不同点呢？这涉及到两个层次的问题，一个是流程的适配，一个是开发项目的质量策划活动。 流程的适配：当公司级流程发布以后，产品线会根据产品线的具体情况对于信发布的公司级流程做适配，看看这个版本变更的内容在产品线怎么落地，是全部推行，还是适配推行，还是不推行，这属于流程适配。同样，要对流程文档模板进行适配。 项目的质量策划：在项目初期进行，识别人与组织要求的差距，识别组织与流程匹配的差距，知识管理计划，进行团队阵型设计。其中，识别组织与流程匹配的差距，就包括项目开发过程的流程适配，在这个项目开发的过程中，要执行哪些流程活动，不执行哪里流程活动，理由是什么，都要在质量策划活动中明确，在开发的过程中尊重执行。 听过很多企业或则个人讲流程无用论，根本不是流程无用，而且没有把流程用起来！难道你认为画在纸上的流程图，写在文档里的流程说明文件，就算是流程了吗？如果没有理解，没有执行，那算什么流程，那就是一纸空文。不但要制定流程，还要适配流程，要推行流程，要优化流程，这样的流程才是能指导业务的流程。 原则4：利用严格的标准化降低变异，并建立高度柔性和可预测的产出。 丰田的三类标准化：1.设计标准化；2.流程标准化；3.工程技能集标准化（指跨工程团队和技术团队的技能与能力的标准化，换句话说，就是按照一套固定的标准培养人员的能力） 我认为设计标准化包括两方面的含义，一个是共用模块（CBB），一个是设计准则。使用CBB的好处是什么呢？我认为通俗点说就是前人栽树后人乘凉。前面的工程师把方案设计好了，原理图画好了，器件封装建好了，电路也调试过了，再共享出来，后面需要用到的工程师直接调用，何乐而不为？既降低设计风险和成本，也有利于器件的归一化。 设计准则，我的理解是一系列的指导书和checklist，让工程师在设计产品的过程中，有一条线在牵引，是设计出来的产品能够达成目标，不会出现太大的偏差。 今天先讲流程相关的4条原则吧。 罗马不是一天建成的，所以不要觉得你产品有多少问题，你的流程有多不完善，这些都不是核心。核心是你知道有问题，就要改进，要找突破点。总是嚷嚷着不行，又不想去改变，那才是最大的问题。 其他9条原则属于“高技能员工”和“工具与技术”子模块，后续在讨论。大家先自己看看。 原则5：创建自始自终领导整个项目开发的总工程师制度。 原则6：建立适当的组织结构，找出功能部门内技术专长与跨功能整合之间的平衡。 原则7：为所有工程师构造“塔尖”型知识结构。 原则8：将供应商完全整合到产品开发体系中。 原则9：公司内部学习和持续改进。 原则10：建立追求卓越、锐意进去的文化。 原则11：让技术去适应人员和流程。 原则12：运用简单、可视化的沟通来理顺你的组。 原则13：运用强大的工具来做好标准化和组织内学习。 作者：毛宇菲 来源：硬件十万个为什么 |
|
|
