精华内容
下载资源
问答
  • 智能硬件设计开发流程

    千次阅读 2021-01-28 15:45:52
    一、总体流程说明 由于硬件部分研发周期长、成本高...在纵向上(按时间特性)我将智能硬件项目流程分成了8个阶段:市场阶段、立项阶段、EVT阶段、DVT阶段、PVT阶段、MP阶段、销售阶段和产品维护阶段,如下图所示: ...

     

    一、总体流程说明
    由于硬件部分研发周期长、成本高的特性,不太可能进行快速的迭代更新,也无法忍受需求的反复变更,所以偏向传统的瀑布式流程可能是更适合的,实际过程中多个部分可以同时进行。
    整体流程如下图所示:



    以上流程也只是在实际产品开发过程中的一种应用案例,根据公司和产品的不同情况,具体流程可能不太一样,但总体上表现出一种阶段性。
    在纵向上(按时间特性)我将智能硬件项目流程分成了8个阶段:市场阶段、立项阶段、EVT阶段、DVT阶段、PVT阶段、MP阶段、销售阶段和产品维护阶段,如下图所示:
     


    实际产品研发中会发现有些工作模块的工作在穿插在整个流程中的不同阶段,所以抛开工作的阶段性,按照角色特性在横向上我将智能硬件项目分成了6个部分,分别是:产品项目、外观结构、嵌入式、互联网平台、工厂试制和销售。这几个部分之间,可能同步进行,也可能先后进行,需要根据实际情况进行灵活调整。如下图所示:



    下面先从纵向上介绍一下每个阶段的大概内容,然后再针对其中重复的模块进行横向的说明,希望这样能够把整个流程说的更清楚一些。


    二、纵向流程
    1、市场阶段
    硬件产品和软件产品一样,当我们有了一个关于产品的创意或大概的判断后,需要进行市场研究,这个阶段最重要的目标是确定这个产品创意靠不靠谱?以及市场价值大不大,值不值得做?
    不同的是,做一款硬件产品需要投入更多的人力物力财力和时间,如果产品不被市场认可,不仅打击团队的信心,也容易错失市场机会。而软件产品可以用极小的成本做一个MVP进行市场验证,如果产品不行,只需要半个月甚至更短的时间就能调整方向直到获得成功。所以做智能硬件时更需要做好市场调研。如下图所示:



    比如我在做智能车充产品的市场阶段:

    • 通过行业报告了解每年的新车销售数量和汽车存量规模;

    • 通过淘宝等销售渠道统计车充类产品的功能、价格和销量;

    • 和车充供应链中的模具厂、电源板方案商、五金厂等产业链供应商聊聊市场需求量;

    • 和不同用户(企业客户、滴滴司机、白领、老板、女性用户、货车司机等)针对产品的概念(包括对充电协议、位置、驾驶行为、保险、违章、SOS等方面)进行测试,了解其使用产品功能的动机;

    最终,在立项之前,通过对市场的综合分析产出一份市场需求文档,这份文档至少应该包括目标市场描述、用户特征、用户需求列表、产品价位、利润空间、上下游供应商、营销策略等信息。

    2、立项阶段
    经过市场阶段的各种调研分析之后,产品创意经过了重重考验,终于要开始要立项开动了,没有什么比做新产品更让人激动的事情了。市场需求有了,那么接下来就需要拉团队来做了吗?其实在立项阶段还有很多事情要做,如下图所示:



    在市场阶段,我们得到的需求更多的是用户需求,我们需要将用户需求转化为产品需求,其中首要考虑的就是转化过程中的需求可行性。记得之前某手机公司产品经理提了一个需求就是手机的主题跟随外壳的颜色自动适应,差点没被程序员拍死。这可能是个笑话,但我们在做实际产品过程中遇到的这样的问题不少,有些需求可能技术上暂时无法实现,或者实现的成本太高,我们需要对产品设计方案进行调整或让用户对产品进行妥协。
    这个阶段的需求分析包括了嵌入式软硬件和互联网平台(App和Web后台)的需求分析,最终形成一份产品需求规格说明书,并对产品的各种软硬件功能、性能、成本、安全性、外观结构等做出明确的要求。
    在一般的互联网产品团队里面,主要成员为产品经理、UI设计师、后台开发、IOS开发、Android开发、测试工程师、运维为数不多的几个角色,就可以完成一个App或网站等互联网产品的开发。产品研发流程分为产品规划、产品设计、技术研发、测试调整、提审发布5个阶段产品设计。
    那么智能硬件呢?智能硬件除了包含了互联网软件的部分,还涉及ID、结构、包装、硬件、软件、生产、认证和销售等环节,所以一个完整的硬件团队需要ID设计师、结构工程师、嵌入式硬件工程师、嵌入式软件工程师、硬件测试工程师、认证工程师、品质管理、FAE工程师、采购、项目经理等。
    出于对成本、周期和质量的考虑,其中ID、结构、模具外包给一家实力比较强的模具厂,嵌入式和互联网平台由自己研发,成品的生产和组装由代工厂负责、包装找了一家包装厂进行设计和生产,认证部分找了专业的检测代理机构。
    通过综合分析最后要产出一个项目分析报告,包括项目所需资金、人员、周期、利润、营销方案以及产品迭代计划等,然后组织相关人员召开立项会议正式进入研发阶段。

    3、EVT阶段
    EVT(Engineering Verification Test)指工程验证,此阶段是针对工程原型机做验证,对象很可能是一大块开发板,或是很多块开发板,关键是要有足够时间和样品。
    通常,如果是新平台,需要花的时间和精力可能更多,会有很多问题要解决,甚至有很多方案要对比;而修改既有产品的话,这个阶段会简单很多。
    这一阶段的重点是尽可能多的发现设计问题,以便及早修正,或者说设计可行性的验证。同时检查是否有规格被遗漏。一般不会开模,但会做外观设计,通过3D打印的手模进行验证, DVT开始才是模具品验证。


    EVT阶段外观结构(ID、结构、模具)、嵌入式软硬研发、互联网软件研发开始同步进行,如下图所示:


    需要注意的是:

    • ID、结构设计封板后就可以开始嵌入式硬件的layout了,在此之前,硬件部分可以做方案设计和原理图设计;

    • EVT阶段可以不投模,毕竟模具的成本不菲,等待工程验证通过后再进行投模,可以降低项目风险;

    • 嵌入式软件则不完全依赖硬件,可以在模拟环境中实现嵌入式应用开发;如果硬件部分完成就需要立即转移到在硬件部分继续开发固件或进行调试;

    • 互联网平台部分可以完全独立进行开发,只是在于硬件通信的部分需要在方案设计阶段定好数据协议,并通过模拟终端实现设备端和互联网平台之间开发的解耦。

    这个阶段需要确定好外观结构并打印出3D打印的结构手模,完成嵌入式软硬件开发,互联网平台也完成了1.0版本,然后烧录程序,组装样机并进行测试,包括:

    • 功能测试(测试不通过,可能是有BUG);

    • 压力测试(测试不通过,可能是有BUG或哪里参数设计不合理);

    • 性能测试(产品性能参数要提炼出来,供将来客户参考,这个就是你的产品特征的一部分);

    • 其他专业测试:包括工业级的测试,例如含抗干扰测试,产品寿命测试,防潮湿测试,高温和低温测试(有的产品有很高的温度或很低的温度工作不正常,甚至停止工作)。

    测试完成后需要将测试过程中的结果和问题记录到《样机整机测试报告中》,下个阶段可以参考这个报告进行调整优化。


    无论何时,建议尽早找一些真实用户对产品进行真实场景中的使用测试,也许能够发现一些之前没有想到的问题,从而避免后续发现问题后推倒重来。
    如果顺利的话,整机的测试效果理想,结构上、硬件性能上、固件功能逻辑上可能还有一些小问题,但是方向上是对的。项目经理可以组织大家对这个阶段进评审,总结一下外观结构、硬件PCB、BOM表、固件和互联网平台目前发现的问题以及后续优化的建议,开始进入下一阶段;如果不顺利的话,可能发现结构上的大问题需要改结构设计,或硬件需要重新打板验证、固件和互联网平台存在较大的bug,那么则需要再次进行EVT阶段个各项工作,直到通过样机的整机验证确认无方向性问题和重大问题为止。


    4、DVT阶段
    DVT(Design Verification Test)设计验证测试,是硬件生产中不可缺少的一个检测环节,包括模具测试、电子性能、外观测试等等。
    上一阶段已经看到产品的稚形了,这一阶段要继续完成各部分的研发,包括模具、嵌入式软硬件和互联网平台,验证整机功能的完整性和设计的正确性,并可作出可以进入生产的结论。因为生产意味着更大的投入,所以,这将是最后的查错机会,你需要把设计和制造的问题全部考虑几遍。


    这个阶段可开始进行包材的设计与生产了,包括外包装、内托和说明书,如果离真正出货时间还较远的话可以先完成设计验证,等到量产时再进行生产。
    这个阶段会继续对结构模具和嵌入式软硬件进行优化调整,可能会多次试模或打板,直到通过整机验证达到可进入生产环节的标准。
    整机验证时需要按照生产标准进行组装和测试,并产生全面的测试报告,当然也要找真实用户使用产品,看一下用户对产品外观结构、品质、功能上有什么感受和意见。
    如果经过测试发现产品有问题,那么一定要优化完成后再次进行整机验证,直到能够达到生产要求,同时要输出《生产指导书》给代工厂进行参考。


    5、PVT阶段
    PVT(Process Verification Test)生产过程验证测试,属于硬件测试的一种,主要验证新机型的各功能实现状况并进行稳定性及可靠性测试。
    上一阶段我们应该已经完成了产品的设计验证,也就是说外观结构、嵌入式软硬件已经完成了,互联网平台也完成了对应的1.0版本。这一阶段将严格按照该产品生产时的标准过程来进行,包括仪器、测试工具、生产工具等都需要到位。测试得出的结论,是大规模生产的重要基础,包括工序是否太复杂,零部件是否容易损坏、烧录工具和产测工具是否好用等Design for Manufacturering Fact的考量。

    如下图所示:


    理想情况下,在PVT阶段嵌入式、结构模具和互联网平台已经完成了,不需要任何调整,但也可能在小批量之前或过程中发现一些小问题,比如结构接合处不平整,按键手感不佳,硬件板框调整、某些元器件位置调整或替换等,需要重新进行小批量生产验证,直到达到量产要求为止。
    小批量完成后,我们已经有了一小批可量产的产品了,这时候就可以进行相关的认证了,一般认证时间都需要比较长的时间,可能3-8周,所以能够越早进行越好。
    PVT阶段完成后需要进行对这一阶段进行总结评审,确认量产需要的模具、PCB、BOM表、生产作业指导书、零部件签样等。


    6、MP阶段
     


    经过试产也就基本没有什么问题与工厂也都应该磨合好了,下面就按照生产排期进行生产即可。不过在这个过程中还是需要相关同事进行驻场监督,以免出现问题不能得到有效及时的解决。
    在这里需要对产品的加工处理、员工的操作标准、以及质检的规范程度等方面进行有效的监督和保证,只有这样才可以保证产品不会出现质量问题。


    7、销售阶段


    在生产过程中产品经理还有一个重要的工作要开始执行了,那就是与产品销售相关的工作。这一部分主要包括产品销售材料的制作,比如宣传文件或宣传视频等资料。
    同时也要对销售同事进行培训,帮助他们理解产品在市场的定位以及自家产品的优劣势,同教授产品的使用,便于他们进行宣传和销售,配合市场部门和销售部门对产品的营销推广活动。
    此时还要和售后、技术支持等同事进行培训,告诉他们产品使用方法和可能出现的问题以及应对的方法和话术,并对技术支持进行维修和故障诊断进行培训。
    销售阶段主要是跟进产品问题,当市场和销售在遇到产品问题时,及时地帮助解决,也可以请FAE同事处理一些简单的产品问题,保持持续的关注。

    8、产品维护阶段
     


    在产品的前期生产和销售后,基本上这个产品进入了一个稳定的状态,只需要跟进生产相关问题即可。


    智能硬件区别于传统硬件的地方是智能两个字,所谓智能就是让机器具有一定的理解能力,知道用户想要如何使用它。这离不开对设备运行数据和环境数据的收集与分析,设计更好的算法,对嵌入式软件部分进行更新。所以产品维护阶段需要保持的产品使用数据的关注,不断优化用户体验,迭代产品,提高App的使用率等。


    另外一个重要的事情就是对项目进行整体的复盘总结,分析在项目进行中的各项问题以及后续规避方案,提取研发过程中通用模块减少再次开发的时间,完善设计规范减少犯错误的几率、维护各个阶段的自检表,维持供应商关系等。


    最后,要开始规划下一代的产品了,也许早已经开始了。。。。。

    三、横向管理


    在整个纵向流程中关于产品项目、工场试制、销售部分已经在各自的阶段进行了详细的说明,而外观结构、嵌入式、互联网平台在EVT、DVT、PVT阶段中都有相应的工作要做,为了将流程说的更清楚一些,这里有必要对这几个部分进行单独说一下。


    1、外观结构
    我这里说的外观结构部分包括ID、结构、模具和包装,一般新产品开发顺序如下:



    流程说明:

    • 新产品一般是先有ID、后做结构设计,结构设计封板后再进行模具制作的;也有情况是产品模具使用公模或已有产品模具,只需要改一下ID和包装即可;

    • 包装设计一般比较简单,所以可以在ID阶段一起做了或者在DVT阶段完成,如果包装设计完成后离量产时间还有一定距离的话,只需要完成设计即可,等量产阶段再进行生产,减少包装损坏或更改的风险;

    • 结构设计时结构设计师需要多跟硬件工程师交流结构问题,讨论电子元器件的摆放和板框尺寸厚度等结构问题;设计完成后一定要3D打印出来反复组装零部件确认结构问题,这也是EVT阶段需要完成的任务;

    • 投模后,至少需要3~5次试模和修模,由于模具费用比较高且周期长,一般进入DVT阶段后才会开始投模,当然如果对结构比较有信心,也可以在EVT阶段投模,提前完成外壳部分;首次试模时最好采用透明壳料,这样方便观察结构上的问题,然后采用黑白双色,最后做表面工艺处理,不断优化外观。

    2、嵌入式
    组建团队时,一度很纠结,嵌入式软件部分到底属于硬件还是软件(互联网软件)团队,考虑到嵌入式软件跟硬件的联系非常紧密,嵌入式应用一般更新次数极少,且嵌入式软件开发人员对互联网软件部分了解不多,所以将嵌入式软件和嵌入式硬件放在一起,统称为嵌入式部分。
    实际嵌入式开发时,硬件部分和软件部分是同时进行的,前期嵌入式软件可以在开发平台上虚拟硬件环境进行应用开发,但后面还是要基于真实的板子进行开发,需要调试驱动,实现一些虚拟环境中没有功能。一般开发流程如下:


    在EVT阶段,前期的硬件设计方案非常重要,不仅关系到项目的成本、周期,甚至是成败,所以在设计时很有必要注意一下几点:

    • 正确、 完整地实现《产品需求规格说明书》中各项功能需求的硬件开发平台,充分考虑项目要求、性能指标及其它需求;

    • 方案设计过程中需要对产品需求规格说明书中的规格要求进行补充完善,如果尝试各种方法有无法实现的地方或指标相差很多时要及时反馈给产品项目方,对产品需求进行调整;

    • 综合对比多种实现方案,选择适合本项目的设计方法。若系统使用了新技术,为了确认该新技术,可以采用搭建实验板方法或购买开发板进行技术预研;

    • 考虑从成熟产品中进行复用,吸取以往设计的经验教训,避免重新出现同样或类似的问题;

    • 对于重要的和复杂度较高的部分要参考其它同类产品的实现方法或要求有相当经验的设计人员担任;

    • 进行对外接口的设计,考虑运行的安全性、用户使用的方便性与合理性。

    同样进行嵌入式软件设计时,也需要遵循一些通用的要求和原则:

    • 正确、完整地反映《产品需求规格说明书》的各项要求,充分考虑其功能、性能、安全保密、出错处理及其它需求。

    • 保证设计的易理解性、可追踪性、可测试性、接口的开放性和兼容性,考虑健壮性( 易修改、可扩充、可移植)、重用性;

    • 采用适合本项目的设计方法。若系统使用了新工具和新技术,需提前进,行准备;考虑选用合适的编程语言和开发工具;

    • 吸取以往设计的经验教训,避免重新出现同样或类似的问题;

    • 对于重要的和复杂度较高的部分要求有相当经验的设计人员担任;

    • 考虑从成熟项目中进行复用。

    好的设计是成功的一半,特别是在嵌入式开发过程中,一定不要急于动手,先想清楚,做好设计和评审,再依据设计行动,不说事半功倍,最起码不会走冤枉路,降低项目风险。

    3、互联网平台
    我这里说的互联网平台主要是指配合硬件的App、小程序、H5和Web等应用,有些硬件互联平台只是个辅助,必要时用户才会想到去使用,比如行车记录仪App;有些硬件的互联网平台提供了丰富的内容供用户配合硬件进行使用,比如智能音箱。不管这样,企业总希望能够提高App的打开率,跟用户有更多互动,挖掘更多的商业价值。
    关于互联网平台产品开发流程,网上的内容很多,这里也简单说一下,如下图所示:
     


    需要强调的是,产设计完成并评审通过后,研发部门最好对产品实现方案进行设计,并和产品一起评审。需求评审时,研发人员往往在短时间内很难消化需求的细节,产品也无法确定研发人员是否完全理解了需求内容。而方案设计是研发人员反客为主地跟产品经理从技术上对产品的理解,这样就很容易消除了需求的歧义,从而也让产品经理对产品的质量更加有把握。
    顺便贴一张日常工作的流程示意图:



    四、过程文档
    文档在产品开发过程中非常重要,需要引起足够的重视。写文档是深入思考的过程,有写逻辑和场景以为想清楚了,但是进行书面表达的时候往往发现没想清楚。如果这篇总结文章一样,在写的过程中发现了很多问题,反复整理了很多次才觉得稍微满意了一些,这块我会持续优化。
    产品过程中的常见文档如下图所示:



    如果还有其他需要的过程文档,欢迎在公众号内留言补充。。。

    五、项目里程碑
    一款硬件产品往往需要4~6个月时间,这比互联网产品的周期要长多了,互联网产品开发通过一个一个版本控制节奏,硬件开发时也可以为整个相对比较长的周期建立几个里程碑,这样不仅更方便项目管理,对团队也是一个很好的激励方式。


    我这里主要立了8个里程碑供大家参考,如下图所示:



    六、总结
    以上就是我从互联网行业转做智能硬件6个月后的总结,由于对硬件技术和流程的不熟悉,这个过程中也踩了不少坑。另外互联网思维和做硬件的思维存在很大的不同,总结几点自己的经验教训,希望能够给大家带来一些启示:


    1、欲速则不达:做互联网软件讲究敏捷,小步快跑,效率至上;做硬件虽然也讲究效率,但必须踏踏实实一步一步做好,解决好当前问题再开始下一步,不然很有可能会全部推倒重来,得不偿失;
    2、强依赖设计:项目进行过程要遵循前期的外观结构设计和软硬件方案设计,不要轻易改动,一个小的改动可能会起到连锁反应,拉长项目周期;
    3、在寻找供应商的时候,要找已经有做过类似产品的供应商合作,尤其是我们第一次做硬件的时候,供应商能够帮助提供很多建议,可以少走很多弯路;
    4、在互联网行业,如果需要寻找一些系统和服务的供应商,需要对方有一定的规模,但是在硬件领域,提供方案的公司规模并不那么重要,只要方案稳定可靠就可以合作;
    5、做硬件不像软件那样,硬件的利润很薄,市场越成熟,价格降的越快,这也是为什么硬件对成本特别敏感,所以要选择出货量比较大的产品,同时想各种办法降低整体成本;
    6、在硬件的定价上,可以像效率至上的小米那样永远只保持5%的利润率,但是小公司最好在推出新产品的时候选择合理偏上的价格,等市场铺开同类产品涌入后再不断降低售价,将无可降的时候再推出第二代产品,这样既能保持充足的利润,也能保持一定的市场领先;
    7、硬件产品如果对品质要求高的话需要把握三个关键点,首先是设计公司的工业设计水平,然后是选择靠谱的模具长,最后找一家品控做的很好的组装工厂,任何一个环节出现问题对产品的影响都非常大;
    8、不管硬件产品还是互联网产品,都是一个妥协的过程,高标准肯定会带来高成本、长周期,面对市场的压力有时候需要做一下妥协;
    9、硬件产品相比互联网产品整个链条要长很多,需要打交道的角色也多很多,有很多坑在等你,所以最好有一个比较懂硬件产品流程的人,不管是产品经理还是项目经理,对项目交付来说都是一个很好的保证。

    关注公众号,并回复“流程”二字可以,获取文中的思维导图源和图片源文件和其他相关资料。

     

    展开全文
  • 增量交付开发 敏捷开发 当操纵金属和塑料而不是一和零时,是否有可能进行敏捷开发过程? 还是敏捷开发硬件的想法是错误的? 事实是,越来越多的组织给了瀑布式的支持,并转向基于scrum , lean和看板的模型,因为...

    增量交付开发 敏捷开发

    当操纵金属和塑料而不是一和零时,是否有可能进行敏捷开发过程? 还是敏捷开发硬件的想法是错误的?

    事实是,越来越多的组织给了瀑布式的支持,并转向基于scrumlean看板的模型,因为它们使敏捷开发硬件成为现实。 快速原型制作,模块化设计和仿真测试相结合,使硬件开发的敏捷性成为现代技术制造的真正可能性。

    从敏捷软件到敏捷硬件

    在敏捷软件开发中,创新流程是框架的基石,而不断变化则是日常工作。 预计更改将连续发生。 相对而言,与软件的不断变化相关的成本很低,因为它仅需要时间,知识和键入某些代码的能力。 但是,物理世界并不像数字世界那样容易改变。 硬件变更会带来高成本和巨大的阻力。

    但是,根据UT Dallas的产品开发项目经理和客座讲师Curt Raschke的说法,用于硬件开发的敏捷并不是一个真正的新主意。 实际上,敏捷最初起源于制造业。 他说:“这些想法来自精益和增量产品开发。” 从这个意义上讲,这个概念已经形成了一个完整的圈子,而敏捷已经出现在硬件开发中也就不足为奇了。 只是需要重新审视现有的最佳实践。

    对于FusePLM(使用基于卡的方法进行开发的全云产品生命周期管理系统)的首席执行官Shreyas Bhat来说,问题不在于是否可以进行敏捷的硬件开发,而是如何进行 ? 他说:“硬件往往是自包含的,并且有太多依赖关系。” “如何将其分为可交付使用的部分? 您需要能够对项目进行分区,并为客户提出里程碑。”

    原型设计和敏捷硬件开发

    快速原型是如何解决问题的一部分。 Bhat说:“如今,您可以廉价而又早地构建原型,以使客户对最终的功能有所了解。” “借助3D打印 ,原型制作的成本已大大降低。” 在成本始终是驱动因素的行业中,合同制造商已将原型变成商品。 能够求助于原型供应商进行快速,廉价的建模,可以为以后的实际制造商节省时间和金钱。

    如Bhat所述,由于更换工具会增加成本,因此对硬件的要求必须稳定。 原型设计有助于尽早确定合适的工具。 “您对生产需要什么有了更好的了解。 这样一来,您就可以为生产线预先获得正确的工具,而不必在途中进行重新配置。”

    但这并不意味着原型可以解决所有问题。 Raschke解释了主要限制之一。 他说:“从外形角度来看,它可用于产品开发。” “您可以使用它来提前获取外观方面的反馈。 但是,不能将3D打印单独用于带有需要组装的活动部件的东西。”

    敏捷硬件设计中的实践思维

    设计本身的性质是对用于硬件开发的敏捷问题的一种答案。 项目的模块化程度越高,任何给定组件中涉及的依赖关系越少,进行更改的难度就越大。 同样,选择尽可能少的材料类型来完成工作也是使硬件朝着更加灵活的方向发展的关键方面。 同样,这些都是制造业中的知名实践,非常适合在敏捷框架内实施。

    仿真或其他类型的迭代硬件评估是该过程的一部分时,明智的选择是在进行测试时进行设计。 只要知道模拟环境的局限性和功能,就可以将测试驱动开发(TDD)轻松地合并到硬件中。 跨功能团队最适合以这种方式开发硬件,并着眼于通过迭代测试来验证设计功能。

    实际上,Raschke透露这是与敏捷性相关的硬件面临的主要挑战之一,特别是在预测试和系统集成方面。 他说:“设计,开发和交付并不总是由同一团队来完成。” “即使可以由同一团队开发作品,他们也是不同的主题专家。 在硬件产品中,有电气,机械和软件工程师以及固件专家,等等。” 为了创建更快,更迭代的硬件开发方法,必须将这些不同的专家聚集在一起。 对于任何Scrum Master来说,这都是一个壮举。

    敏捷开发硬件的未来

    初创公司和快速发展的公司具有出色的构想,它们准备好应对敏捷开发方面的挑战。 尽管这可能有风险,但仍有可能获得高额回报。 在巴特看来,“有创新的​​地方就存在不确定性。 那是敏捷的最佳选择。 您可以做很多“假设”场景来尝试点子并Swift将其发布给客户。”

    但是,敏捷确实具有Raschke所解决的一个明显局限性。 他解释说:“硬件产品是逐步开发的,但不能以这种方式发布。” 确实是这样。 鉴于大量客户无视工厂召回和日常消费品的升级,因此很难想象他们对不断更新硬件的需求感到满意,特别是涉及到本地供应商的旅行或在安装过程中收到的套件的安装时。邮件。 因此,尽管用于硬件开发和设计的敏捷在行业中可能扮演着越来越重要的角色,但交付仍将是一个固定的点,几乎没有反复试验的余地。

    翻译自: https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/Using-Agile-for-hardware-development-to-deliver-products-faster

    增量交付开发 敏捷开发

    展开全文
  • 智能硬件(1)--- 智能硬件开发流程

    万次阅读 多人点赞 2018-03-24 12:46:09
    1、智能硬件选择首先,没钱,就别去做智能硬件产品了。买成品就好了。我们现在去京东、淘宝上买个手环也就是几十块钱,做多一两百块钱就搞定了而如果你要自己做呢?投二三十万进去,开一套模出来,找别人定制一套...

    1、智能硬件选择

    首先,没钱,就别去做智能硬件产品了。

    买成品就好了。我们现在去京东、淘宝上买个手环也就是几十块钱,做多一两百块钱就搞定了而如果你要自己做呢?投二三十万进去,开一套模出来,找别人定制一套电路板,然后生产一千台出来,你算算单台成本有多少呢?一台至少也要两三百块钱的成本。这个还是不包含你的利润的。如果你不打算投入这么多钱去做,那你就没有必要自己去做一个。买成品就已经足够了。

    所以说,大家有一个好的想法的时候,先去网上搜一搜,看一下有没有类似的产品,甚至说有没有一模一样的产品。我认为,你有一个好的想法。但没有被做出来的几率,是非常非常小的。

    有人说了,我是土豪我任性,我就要去做这个产品!那你就要看一下,你做这个产品能不能卖的出去。如果你卖不掉,那做出来就是孤芳自赏了。如果要卖,就要考虑到后续的推广渠道、营销人员、营销方式等。表面上看,小米的手环卖的挺好的,华为的手机也卖的挺好的那么,他们在背后打了多少广告?投了多少营销进来?任何一家大的品牌公司,每年营销投入都是以亿或者十亿为单位的。如果你不掏这个钱,想去卖好它,也没那么容易的。

    现在很多人,没有接触过硬件,也没有接触过智能硬件的产品的设计,会想当然的觉得,做智能硬件挺简单的。这个也怪不得他们了,以前手机时代的时候,媒体里面,尤其是互联网媒体,说MTK出了个Turnkey方案,把所有的东西都做好了给你,你拿去直接生产就行了。或者自己改一块电路板,找别人买点外壳往上一装,一台手机就出来了。

    但是,实际上呢?可信度基本为零,都照他那么讲,这些手机行业的工程师岂不是全失业了?像中兴、华为、OPPO、小米这几个手机品牌他们每家有多少工程师?至少好几千人。他们要这么多工程师干什么呢?像金立这样的手机公司,他的大部分的手机用的都是MTK的平台,就是刚才讲的Turnkey的方案。那为什么他还需要养这么多工程师呢?

    媒体有时候会个大家这个误导:做智能硬件产品很简单。但并不是这样的。实际上,我们一个项目,大的流程是:从前期的市场调研、到产品定义、到需求分析、到方案设计、 然后到外观结构的设计、软件硬件的设计、物料的采购、经过多次的试产、多次的测试和整改、生产管控、质量控制、量产出货、售后跟踪等。这是一个很繁杂的链条。这里只讲了十几个大的方向,每个点下面,还有很多细节的事情。

    就拿媒体最经常说的,画一个电路板就解决了。真的画一个电路板有那么简单么?如果真有那么简单,硬件工程师就不可能拿那么高的薪水了。画一个电路板需要考虑的东西很多,像电源的设计,和走线是很相关的,整个电路板的抗干扰设计,高速信号需要仿真、射频音频之类的弱信号需要保护、还需要考虑到电路板的防静电能力。这些跟工程师的水平很有关系,也体现出一个公司的设计水平。同样是画一块板子,有些人几千块就可以画出来而有些人需要花几万的成本才能画出来。对于军工类的电路板,投入的要更多。

    还有一个,就是媒体经常说的,做一套外壳就可以解决了。我们先不谈做外壳需要开模,开模是要收钱的,单从设计上来讲,结构设计要满足外观的效果、要能降低模具的成本、有足够的生产效率、结构强度要高、长期使用的质量可靠性也需要高,这些都是跟结构设计息息相关的。你找一个初级工程师,他随随便便肯定能给你画出来,但他画出来的质量是什么样子的?为什么资深工程师的待遇比初级工程师高很多?因为他们的经验比初级工程师丰富很多。这些就是为什么有些公司设计费用很低,而有些公司设计费用很高。如果说你做一个外壳,什么都不考虑,只要能把它拼起来就行了,任何可靠性和可生产性都不考虑的话,做,肯定也是能做出来的,但你就等着后面不断的去为产品擦屁股吧。

    这里还有个重要环节,大家没怎么注意的:测试。测试:这里有很多硬件电路的测试、软件的测试、结构的测试、整机的可靠性的测试、还有大量的压力测试。举个例子哈,手持设备里,有一个测试叫“微跌落”拿着一个产品,从10cm左右的高度摔到一个钢板上去。需要摔多少次?你们能想象么?像国内的一线品牌,微跌落次数一般在两三万次!不断的摔下去,拿起来,再摔下去,再拿起来。对于一般小一些的品牌,至少也要做到几千到一万次。这样才能保证在一到两年的产品生命周期里,不会因为经常的振动和晃动导致损害。这些测试,都跟产品的设计有很大的关系。尤其跟结构设计关系非常大。对于很多山寨品牌来讲,他都没听说过这些测试,做出来的产品,刚出厂的时候是好的,但你用上个把月之后,就有比较高的几率产生损害。

    那么没钱怎么办呢?

    对于很多创业团队创业公司来讲,前期不可能像一线品牌那样子,一次投入上千万做一个项目。那怎么办呢?卖房、卖血、卖肾! (是不对的!)我们有更好的办法,让你前期尽可能少投入一些:做原型机!

    原型机可以不考虑可靠性问题(也可以不考虑结构、外观等),原型机唯一的作用,就是给你验证核心业务和核心功能。等你把核心业务核心功能跑通之后,就可以用原型机去招商、去拉风投。如果你招商和风投情况都比较好那么钱的问题自然而然就解决掉了。大家都看好你的产品,也相信你能做出来,自然会有很多人想来投资,不管是众筹还是风投。就会支撑你后面拿到更多的资金,做的更好。

    一定要记得,对于创业型公司,尤其是你不太懂的地方,切不要贪大求全。任何一款产品,我们想的都是很美好的,从软硬件、到平台、到生态链,我们都可以规划的出来,但如果你前期就这么做的话,比方说你做一个手环,想把生态链都打通的话,肯定不止几十万的投入了,至少要到百万级别。

    所以前期尽量把不太需要的功能都砍掉,只保留核心功能。省钱、快速出产品,出原型机,才是王道。现在的风投都很精了,已经不会在你只有一个PPT的情况下就给你投很多钱了。必须要要拿出来一个实物,来证明你能做的出来,风投才敢继续往下投。

    因此,咱们要的就是:省钱,因为前期主要是靠自己投资的;快速,你一旦速度慢了,商机就没有了

    2 智能硬件开发流程

    硬件产品覆盖单片机控制硬件电路、蓝牙BLE硬件、嵌入式硬件、多核心Android智能硬件、移动通信设备硬件等众多领域。开发流程包括器件选型、方案设计、电路设计、PCB图绘制、SMT贴片、硬件调试、射频调试、EMC和ESD测试、失效分析、品质管控。

    智能硬件,常见的主要有小型单片机硬件系统和大型Android硬件系统。

    8位、32位单片机,在小微型智能硬件领域应用很广泛,成品价格低、开发周期短,适合运算量小、通信数据量小的应用场景。单片机在智能小家电领域有:智能电饭煲、智能花盆、空气净化器、智能台灯窗帘等;在智能工业领域有:环境温度监测、空气质量监测、水质监控、农业喷灌控制等。随着BLE、ZIGBEE、GPRS、NB-IOT等众多无线传输技术的普及,单片机+云服务的架构应用越来越多。

    越来越多的设备智能化、互联化,这些都离不开燚智能单片机硬件设计。燚智能丰富的单片机系统开发经验,为您快速实现非智能到智能、单体到组网的产品快速升级。

    单片机只能实现简单的数据处理,如果需要做复杂数据处理,例如视频处理、语音识别、人工智能等,就需要Android类智能硬件了。

    Android智能硬件,当前主流为4核-8核ARM Cortex A7或更强的处理器,集成GPU,很多还集成LTE通信,运算能力超强、通信数据量超大、软件扩展性非常好、UI界面漂亮、人机交互超便捷。Android智能硬件已在逐渐取代传统嵌入式Linux和嵌入式Windows的。例如智能车载、智能手表、智能家居网关、智能电视、智能工控主机、智能导购屏这些产品,几乎都采用了Android系统的智能硬件。

    传统的PC系统,因结构负责,硬件尺寸大,在智能硬件领域应用不多。嵌入式Linux因开发资源和第三方资源远不如Android多,硬件成本也要比Android硬件系统贵,因此逐渐被Android智能硬件取代。

    智能硬件开发流程,通常有以下主要步骤:【需求分析】-【方案设计和评审】-【硬件设计和评审】-【打样制作】-【测试整改】-【交付归档】

    《需求分析》尤为关键!很多创业型产品倒在不断的修改功能需求。软件迭代相对快一些,但硬件迭代一次少则一个月,多则两三个月;软件迭代几乎不影响整机,但硬件迭代很有可能导致整机结构有变化,这样子产品上市就遥遥无期了。需求分析准不准,直接关系到产品的时间、成本、质量。燚智能会以十多年的行业经验,向客户问非常多的问题,以帮助客户分析需求,少走弯路,选择合适的技术路线。

    智能硬件“方案设计”这一概念。智能硬件产品往往涉及到一些新技术或非常规技术,项目风险会比较大。需求分析结束后直接开始做硬件设计的话,很容易遇到偏门物料买不到、芯片选型不满足指标、电路设计有缺陷等问题,导致项目延期客户流失。因此在正式设计之前先做好大量准备工作,包括《关键器件选型》、《关键技术验证》、《系统框架设计》、《产品风险评估》、《功能交互设计》、《产品测试大纲》等一系列步骤,由CTO组织对每个项目的方案设计做详细的评审,通过评审后才能正式开始设计工作,能够极大的提升产品开发质量,减少研发风险。

    硬件设计,主要包括《原理图设计》和《PCB图设计》。看似很简单,很多小公司,一个工程师画原理图、画PCB、写代码调软件全包了,你能相信他样样精通么?硬件设计不仅仅是把线路连通就算完成了,还需要考虑到功耗、散热、抗辐射、防静电、高速信号走线设计、射频性能等一大堆问题。如果设计不合理,一般功能性上不会有太大的问题,但是性能就完全没办法保证了,肯定是通过不了各项测试的。

    硬件设计完成后,需要进行内部评审,包括《原理图评审》、《PCB图评审》、《结构评审》等,每个评审表格都有几百项,通过评审检查设计错误,将常见错误封锁在设计阶段。设计阶段修改一次只需要一两天的时间,如果已经把PCB做出来了,再来修改至少半个月的时间,还会带来极大的物料浪费。

    硬件设计完成后,硬件工程师就稍微松口气了。PCB电路板生产是需要一定的周期的,4层板一般需要一周多,8-10层板需要两三周。在这段板厂制板的时间内,采购、资源和生产管理部门需要去做《元器件备料》和《SMT产线预约》。对于一些超长周期的物料,早在设计阶段,甚至在方案评审阶段,就已经开始下单采购了。等所有元器件都到齐了,硬件工程师也早早的把生产资料准备好了,就可以上SMT线贴片生产了。通常第一次SMT都会暴露出一些问题,有物料问题,有生产制程问题,也有硬件设计问题,工程师会记录好这些问题,在后续设计整改时及时改进。

    PCBA(已贴片完成的电路板)完成后,硬件工程师、软件工程师、测试工程师就开始紧张的调试和测试的过程了。看一个产品设计的好不好,只需要看测试报告就足够了。优秀的测试工程师,会结合到产品的使用场景,设计出很全面的测试用例,这些用例能够覆盖到各种常见和不常见的场景,不断的“折磨”产品,直到它出问题为止。一款经过千锤百炼的产品,品质才有把握。像H为品牌的手机,光试产测试样机都要做上千台,不管大的还是小的问题,都被消灭在研发阶段,因此质量口碑很好。

    经过一轮测试后,项目经理会组织项目组成员汇总测试问题,提出并验证解决方法,然后整改到下一个硬件版本中去。如此反复,才能打造一个优秀的硬件产品。

    最后,项目完结后,所有的资料都会归档保存,除了基本的设计资料外,还有评审资料、问题记录、测试用例等,以供后续查阅。很多小公司不重视资料归档和资料保存,一旦某个项目暂停几个月再重启,就很容易出现资料不全、不知道哪个版本才是正确的、老问题又新出现等各种乱象。

    转载自:http://www.ifiretech.com/nd.jsp-id=2&groupId=-1.htm



    展开全文
  • 华为内部硬件开发设计流程

    千次阅读 2020-12-05 10:51:17
    点击上方“大鱼机器人”,选择“置顶/星标公众号”福利干货,第一时间送达华为内部硬件开发设计流程2007年,以2年的工作经验去一家小公司去面试。当时笔试完,对方对我很认可。但当时他说:“我...

    点击上方“大鱼机器人”,选择“置顶/星标公众号”

    福利干货,第一时间送达

    华为内部硬件开发设计流程

    2007年,以2年的工作经验去一家小公司去面试。当时笔试完,对方对我很认可。但当时他说:“我需要招一个,在大公司待过的,最好知道硬件开发流程和规范的。虽然你题答得不错,但是我们需要一个有丰富经验的,最好在华为待过的。”

    当时,我就在想“华为的规范和流程是啥样的”。后来我去了华为,我把能想到的华为硬件开发的几个不一样的点,跟大家分享一下。

    NO.1 文 档,评 审,设 计

    当时刚入职时,三个人做一个电路板。虽然电路复杂一些,还是有一些人力过剩的。所以,我就被安排去写一个PCI转UART的逻辑。

    我当时是新员工,也急于表现自己,利用周末的时间,估计用了一周的时间,就写完代码,开始仿真了。我以为我的导师兼主管会表扬一下,结果没有,他说:“你为什么没有召集大家讨论?然后再写方案,评审?然后再动手写代码?”我当时是不理解的,觉得我一个人就搞定的事情,为啥要这样劳师动众?

    后来反思过后发现了以下问题:

    第一、 从主管的角度,不知道新员工的个人能力,你能把做的事情讲清楚了,他才放心。

    第二、 从公司的角度,有一套流程来保证项目的交付。那么则不再太依赖某个人的个人能力,任何一个人的离职,都不会影响项目的交付。这也是华为最了不起的地方,把复杂的项目拆得非常细碎,这样不需要特别牛的人来交付项目。这是为什么华为的工程师的收入是思科的N分之一。

    第三、 从效果角度,毕竟一个人的想法是有限的,把想法文档化的过程,就是整理思路的过程;讨论的过程,就是收集你自己没有想到的过程。正式的评审,是大家达成意见的过程。提前讨论,让相关的人都参与到你的设计中,总比你设计完了,被别人指出一个致命的问题要强得多。

    就是因为华为把一项工作拆散了,所以沟通,文档,评审,讨论,变得非常重要。这个工作模式的缺点,也是显而易见,沟通成本高,工作效率低。

    NO.2 硬件领域的人员构成

    在华为内部里面,人员角色非常多。硬件的人是对产品开发阶段,端到端负责的。做单板硬件工程师,可以涉猎最多的领域,同时也是工作内容最杂,接触人最多,扯皮的最多的工种。

    但是也因为有人专门负责画PCB、EMC、电源、逻辑,原本硬件工程师应该做的领域。那么硬件工程师就武功尽废,变成“连连线”。

    其实不然,正是由于每个人都是一个小的领域,没有人统领,所以一个好的硬件经理的作用非常的重要,是贯穿所有领域和全部流程的关键角色。正如原来华为内部论坛上有一个人比喻的,硬件工程师更像是处理器里面的“Cache”,是所有环节的中转站。大公司把人的分工分的这么细,也是防止某一拨掌握了太多公司的核心技术,出去单搞了。

    NO.3 华为的流程

    其实华为的流程,很多人都知道IPD流程是从IBM来的,我个人理解:IPD流程已经在华为变种,结合了中国人的特点,华为的企业特点进行了变通和优化。如果华为僵硬的套用IBM的这套流程,也必定不会这么成功。

    那么概括一下华为的硬件开发流程:

    需求分析→总体设计→专题分析→详细设计→逻辑详设→原理图→PCB→检视→粘合逻辑→投板→生产试制→回板调试→单元测试→专业实验→系统联调→小批量试制→硬件稳定→维护。

    流程的根本在于,这个环节做好了,再进入下一个环节。所有的环节其实跟其他公司并没有太大的区别,只不过严格把握了进入下一个环节的考核条件。令硬件工程师最纠结的是“没有个节点跟’投板’对应”。

    华为支撑IPD流程的系统是PDM(又名爬的慢)

    PDM的中文名称为产品数据管理(Product DataManagement)。PDM是一门用来管理所有与产品相关信息(包括零件信息、配置、文档、CAD文件、结构、权限信息等)和所有与产品相关过程(包括过程定义和管理)的技术。华为所有的器件资料,产品部件,工具,文档,原理图,PCB,逻辑代码等都存在这个系统上。但是系统过于庞杂,其实比较难使用,跟服务器归档、SVN归档、也容易搞混淆。

    NO.4 归一化

    1

    器件归一化

    硬件工程师一般都能够理解,在一个板子上面的,尽可能的选择成本更低的器件,选择更少种类的器件,便于集中采购,同时也便于加工。但是其他公司可能没有对器件归一化的工作做得那么细致和严格。

    第一, 由于华为整个公司使用的器件种类非常的多,所以如果减小一个器件编码,带来的收益是十万人民币到几百万,而其他公司可能达不到这个高的收益。所以如果能减少一个编码,宁愿选择可能成本更高的器件。但是这个也需要按照每年的器件直接成本收益*器件发货数量,与编码成本+加工成本差异,进行对比的。不过器件归一化之后,器件的价格又可以跟供应商重新谈价格,这个收益是迭代的。所以,有时即使是成本占优,也会倾向去器件归一化的结论。例如,逐步去除了5%精度的电阻,归一化到1%。

    第二, 器件归一化,都是需要进行专题分析的。因为也有工程师为了归一化,对电路原理没有充分分析,导致的归一化带来“问题引入”。所以,当时我的部门当时有一个表格,“器件归一化分析.xls”的excel表格,把每个器件,原来选型,归一化的选型,更改的原因,都做好记录和原因分析。一是让每个做归一化的员工都充分考虑分析,二是问题都有记录,便于评审,三是出了问题,好打板子。

    2

    单板归一化

    除了器件归一化,更高一个层次的归一化,就是单板归一化。(单板这个概念,我稍微澄清一下,我刚到华为的时候,也觉得这个词很奇怪。因为通信设备,都是机框,背板,加各个功能模块的电路板,各个功能模块的电路就叫做“单板”,硬件工程师,一般也叫做“单板硬件”)

    单板归一化带来的好处,首先是电路的种类少,电路的种类少的好处有三个:

    一是生产成本降低;

    二是硬件维护成本降低;

    三是软件开发和维护的成本降低。

    第一、单板归一化的先决条件首先是处理器归一化。其实,华为的有的产品这点做得其实不好,X86、MIPS、ARM、PPC全部都用个遍,所以一个硬件平台,需要配备各种软件人员,操作系统搞N套,VxWorks和Linux,BIOS各种配套。

    第二、单板的归一化,要注意产品的衍生。第一个版本的机框上的单板所实现的功能,如果后续的产品可以使用,应该直接可以用,不需要再开发。如果不注意这点,第一个版本的单板,到第二版本时,发现不能相互借用。反过来,再修改第一个版本的电路板,来适应新版本。有时问题更糟糕,就是完全不能兼容,只好重新开发。单板的规划显得非常重要。

    第三、单板归一化时,虽然电路部分兼容了,但是结构件不兼容。对于市场人员的配置来说,仍然是两种配置。一样是失败的。

    3

    平台归一化

    那么如果发现不同的硬件平台的架构雷同,功能类似。那么机框也可以归一化。只需要制作不同的电路功能模块,就可以实现不同的功能需求。

    但是不同的硬件形态都是有他存在的意义的,如果强行归一,市场未必会接受这种事情的发生。例如用一个运营商的平台去归一一个企业应用或者家庭应用的产品,可能就未必能够成功。

    4

    网络架构归一化

    这个说法是我自己想的,早在08年的时候,华为就在讨论“云管端战略”了,当时不是很理解。当我们一个运营商平台部门,跟“服务器”的部门合并的时候,似乎理解了点什么。

    当X86处理器足够强大的时候,所有的运算,不管是否性价比最高,都送到云端进行处理,那么所有中间的存储和计算都显得不重要了。那么整个网络的结构,就是终端+管道+云存储和云计算。

    NO.5专题分析

    我觉得很多硬件工程师有个误区,觉得自己的核心竞争力是在于会使用几个软件(cadence、Protel),画画原理图,画画PCB。我早期的一份工作就这样,最大的本事就是照葫芦画瓢,抄Demo板,抄以前成熟的电路,如果碰到了新的电路设计,一般是按照参考电路先画出电路,再通过调试,去尝试,碰到问题,再去解决问题。

    那么我现在的观念是,硬件工程师最值钱的地方是在于懂硬件原理,懂得电路分析,模电数电原理,电磁场理论,而不是会使用画图软件。

    那么华为是怎样做电路设计的呢?为什么会有专题分析的说法呢?为什么电路设计的时候要做专题分析?

    第二、当电路设计过程中,碰到一些新的问题,之前团队中没有接触过的问题,或者认为是重点,难点的内容,会专门做这个问题点的专题分析:例如我们做过的一些双BIOS启动,摄像头的红外LED的驱动,主备倒换啊,之类的,就会把一个问题点分析透,然后再动手做画原理图。

    第三、那么在开发硬件的时候,Demo只是作为参考,每一个依据都是来自于datasheet,除了看芯片的数据手册之外,还要仔细查看数据手册的勘误表errata,核对datasheet与Demo的差一点,如果器件有checklist还得核对checklist。曾经开发AMD的时候,datasheet、Demo、checklist,三个文档对不上的情况。也出现过,一个比较难复现的问题,后来查看了Errata,发现是厂家芯片升级了,修正了bug,而我们还在采购老版本的芯片。

    第四、由于项目本身有交付时间要求,那么在有限时间内其实不可能做到每个问题点都做得深入透彻。那么问题来了:

    是怎么做到的呢?首先,每个项目都有《问题跟踪表》,而硬件团队由于事情非常的杂,所以把这个表要用的非常好,不然丢东拉西很正常。我曾经把这个表应用到家里装修。这个表的原理很简单,就是记录,问题内容,责任人,完成状态,完成时间。但是只要你坚持用,你会发现,你问题不会跟踪丢,做事情会比较有条理,而且会有成就感。用了这个表以后,发现问题之后,先记录下来,即使现在不解决,那么也会识别他要不要解决,什么时候解决。其次、问题分优先级,任何项目都是带着风险前进的,那么识别出高风险的问题,优先解决高风险的问题,带着低风险的问题继续走。这也是华为电路设计中“0欧姆”电阻用的比较多的有一个原因,识别出风险之后,但是又分析不清楚,或者来不及分析,只好做兼容设计。这里不得不感慨一句,在你的设计过程中,你马虎对待,没有分析清楚的问题,最后一定会暴露出来。

    所以,在“菊花厂”做硬件工程师,“专题分析”是设计硬件最核心的工作,而不是画原理图。通过这个方法,用1~2个月做电路分析,而用1~2周时间画原理图,取代了,画图,调试,改版,再调试,在改版的形式。多快好省,是不可能同时实现的,那么硬件工程师有责任做很好的折衷和权衡。

    NO.6 专题攻关:器件选型规范

    一、关于“器件选型规范”:

    在我进入华为的时候,当时整个公司都在“规范”运动,什么都写规范,人人都写规范,什么任职、绩效、技术等级都看规范。(大公司用KPI来引导,容易搞成“运动”)。所以当时,按照器件种类,很多人写了各种器件选型规范。当时,原理图评审的时候,听得最多的就是“规范就是这样写的”,这里面有一些问题:

    1、写规范的人不一定水平高,或者写得不细致,如果出现错误那就更是害人了。

    2、规范有时抑制了开发人的思维,什么都按照规范来,不一定适合实际的设计场景;例如我需要低成本设计,但是规范强调的是高质量,就不一定适用。

    3、有了规范之后,也会导致部分开发人员不思考,例如晶振要求在50MHz以上,放pF级的电容进行电源滤波,而低于50MHz的不用。大家都不想为什么,自然也不知道为什么;再例如网口变压器防护,室内室外,按照各种EMC标准的设计要求,直接照着画就可以;但是很少有人想为什么,也不知道测试的结果怎样,等实际碰到困难时就抓瞎了。的确在有的时候提高了工作效率和产品质量,但是工具也发达,人也就越退化,这是必然。

    4、有些器件的选型,不适合写规范,因为器件发展太快,有可能等你规范写好,器件都淘汰了。例如:在X86处理器进入通信领域了之后,处理器选型规范就显得多余。

    规范确实能带来好处。但是,并不是所有工作都适合用规范来约束。硬件工程师要能跳出“参考电路”、跳出“规范”,从原理思考问题和设计。

    当然规范还是非常有用的一个手段,是大量的理论分析+经验积累+实践数据的精华。我觉得当时我看得最多的规范,是《器件选型的降额规范》,这是基于大量试验,实际案例,总结出来的器件选型的时候,需要考虑的内容。

    例如:规定选用铝电解电容的时候,需要考虑稳态的工作电压低于额定耐压90%;而钽电容,稳态的降额要求在50%;而陶瓷电容,稳态的降额要求在85%;因为这里考虑了一些器件的实效模式、最恶劣环境(高温、低温、最大功耗),稳态功率和瞬态功率的差异……等等因素。

    二、器件选型需要考虑的因素:

    在华为的PDM系统上,器件都有一个优选等级“优选”“非优选”“禁选”“终端专用”等几个等级。工程师可以根据这个优选等级来直观的感受到器件是否优选。

    那么器件的优选等级,是考虑了哪些因素呢?

    1.可供应性:特别是华为这样厂家,有大量发货的产品。慎选生命周期处于衰落的器件,禁止选用停产的器件。我2005年时曾设计过一个电路,设计的时候就是拷贝别人的电路,结果加工的时候发现器件根本买不着,由于器件停产了,只能在电子市场买翻新的器件。对于关键器件,至少有两个品牌的型号可以互相替代,有的还要考虑方案级替代。这点很重要,如果是独家供货的产品,是需要层层汇报,决策,评估风险的。

    2.可靠性:

    散热:功率器件优先选用RjA热阻小,Tj结温更大的封装型号;处理器选型,在性能满足的情况下,尽量选择功耗更小的器件。但是如果是Intel这样垄断的器件,你也只有忍受,加散热器,加风扇。

    ESD:所选元器件抗静电能力至少达到250V。对于特殊的器件如:射频器件,抗ESD能力至少100V,并要求设计做防静电措施。(注:华为是严格要求,禁止裸手拿板的。我本来也不理解,后来我带团队之后,发现兄弟们花大量的时间在维修单板;我们的团队就非常严格要求这一点,看似降低效率,其实还是提高效率的。至少不用总怀疑器件被静电打坏了。)

    所选元器件考虑更高的湿敏等级。

    安全:使用的材料要求满足抗静电、阻燃、防锈蚀、抗氧化以及安规等要求。

    失效率:避免失效率高的器件,例如标贴的拨码开关。尽量不要选择裸Die的器件,容易开裂。不要选择玻璃封装的器件。大封装的陶瓷电容不要选择。

    失效模式:需要考虑一些器件的失效模式是,开路还是断路,会造成什么后果,都需要评估。这也是钽电容慎选的一个重要原因。

    3.可生产性:不选用封装尺寸小于0402的器件。

    尽量选择表贴器件,只做一次回流焊,就完成焊接,不需要进行波峰焊。部分插件器件不可避免选用的话,需要考虑,能否采用通孔回流焊的工艺完成焊接。减少焊接的工序和成本。

    4.环保:由于华为大量的产品是发往欧洲的,所以环保的要求也比较严格。由于欧盟提出无铅化要求,曾经整个公司的几乎所有的硬件工程师都在做无铅化的整改。

    5.考虑归一化:例如某产品已经选用了这个器件,并且在大量出货的时候,往往有时这个器件的选型并不是很适合,也会选择,因为不但可以通过数量的增多来重新谈成本,还可以放心的选用,因为经过了大批量的验证。这也是为什么倾向于选用成熟期的器件,而慎选导入期和衰落期的原因。

    6.行业管理:某一个大类,例如:电源、时钟、处理器、内存、Flash等等都是有专门的人做整个公司的使用的规划和协调,提前进行市场调研,分析,编写规范。他们会参与到新器件的选型上来。

    7、器件部门:专门有器件部门的同事,会分析器件的失效原因,可靠性分析,拍摄器件的X光,评估器件寿命等等工作。

    8、成本:如果在上述因素都不是致命的情况下——上述的因素都是浮云,紧盯第八条。

    NO.7 开会

    开会第一部分 “华为的会议”

    1、首先大公司就是“会多”,因为公司大,部门多,人的职责划分的细,所以一件事情,需要很多人参与。容易出现扯皮的事情。我刚到华为时,非常不适应,什么都写文档,什么都评审,什么都开会;所以不适应这么多会议,开会时就会无聊,所有的贪食蛇的最高纪录都是那段时间破的。

    2、任何事情还是有主要负责人的,华为给予负责人足够的权利,所以能够推动事情的发展,协调到资源。例如行销有足够的强势去推动研发实现客户的需求。产品经理、客户经理的能量还是很大的,能够跟研发的部长直接进行对话,推动研发干这干那。

    3、所有问题最终都是会记录,跟踪,保证完成的。这就是为什么哪怕有些设备的质量,性能并不能让客户足够满意的时候,客户还愿意用华为的设备。就是这个原因,运营商都喜欢用华为的设备。一个问题出来了,还没确定是哪家的问题,华为的兄弟就冲上去了。联通2个人参加会议,华为6个人来参加会议,通过试验举证,证明是Juniper设备的问题。然后给出充分的报告告诉客户,这不是我们的问题,这是XXX厂商的问题。

    4、林子大了,什么鸟都会有。所以推、拖、赖的事情自然总是有发生。这就需要强大而明确的绩效评价体系,去引导员工去主动承担任务,而不是去划清界限。这种“划清责任”的事情也不可避免。否则就是三个和尚没水喝。注:华为的这种凡事充分讨论的做法,在电信运营商的领域是适用的,放在消费者领域、甚至企业IT领域往往会不适用的,因为没有足够的利润率去支撑这么做。所以我说的一些华为的一些优点,各位华为手机的用户不用向我吐槽,:-)

    5、在开会的过程中,经常人们容易进入误区,或者过于发散,或者过于保守。在产品定义阶段的会议,往往都有人提醒,发散的时候不要收敛;在问题解决的会中,往往会提醒,不要过去发散,聚焦问题。这个能够提醒大家的人往往就非常重要。当然有时也会流于形式,各位朋友可以看下一篇案例《华为内部讨论如何给孙杨涨姿势》,会议中不断有人提醒聚焦,但是大家还是比较发散。

    第二部分 《罗伯特议事法则》

    什么是《罗伯特议事法则》?

    一百年前有个好小伙子,名叫享利.马丁.罗伯特,二十五岁,中国人叫愣头青。他毕业于西点军校在南北战争期间奉命主持一个地方教会的会议。结果呢——搞砸 了。人们争个不亦乐乎,什么结论都没有。总之一塌糊涂。这个会开了比不开还要糟糕。这个小伙子呢,有点一根筋。说我要研究一下,弄个规则,否则我就再也不开会了。他研究上下几千年的开会讨论,有一个结论:人大概是特别爱争论的一个动物,最难被道理说服的动物,分歧一旦出现。很难在短时间内靠语言交流说服对方。否则吵个几天几夜都不会有结果。而且越吵越觉得自己有道理,对方是个笨蛋。所以双方找到共同点达成一个结论一定要有一个机制。他把这个研究当作一个战争一样。把人的争论本性当作敌人。最后这个小伙子打赢了。

    打赢的结果是1876年罗伯特议事规则。他自费出版买了一千本到处送人。1915 愣头青罗伯特成了将军,他修订了这规则。一开始人家不重视,嘴上没毛说话不牢的小家伙行吗。唉,没想到,真行,他们一实行这个规则,吵架没了,会开下去了。墨水瓶,板凳也不乱飞了。结果罗伯特议事规则成了世界上最通行的议事规则。

    开会经常有三个问题。

    一,跑题:就是你说李连杰,我扯到成龙,我说猪八戒,你扯到温家宝李鹏。跑得没个边了。而且老人家特别爱摆掌故,一开头,我给你们讲个故事,这一讲,就讲到中饭了。

    二,一言堂:这一个一言堂呢,是领导者爱讲话,谁是领导就哗哗哗说个没完,一讲就全他讲了。第二个呢,农村有一些特别爱讲话的。也有从来不讲话的。。

    三,野蛮争论:一讨论问题,就说你上次多报了五元钱,你不是好孩子,怀疑别人的品德。一百句话中抓住人家一个词不放。甚至打起来。会议就没法子开了。

    四,打断:不得打断别人的正当发言。

    罗伯特议事法则的一条就是:主持人来解决以上问题。但是一般的企业往往,领导出现的时候,主持人是不会去提醒领导,“你跑题了”,“你一言堂了”,“你不应该打断别人的正常发言”,这就是国外的科学的一些理论和方法到了中国往往不适应中国的土壤,不能生搬硬套的典型案例。

    其实在华为,已经能够在大多数会议中,做到发生“跑题、一言堂、打断、不文明”时,有主持人去提醒,并拉回到正轨上。但是一些会议也做不到,比如:领导比较强势,领导自己是主持人,主持人是个马屁精,一些政治敏感问题,就不能去破坏和谐。此处不展开细说。

    那么华为是怎么去解决这些问题的呢?

    1、“以客户为中心”,所以领导再大,大不过客户,客户需求一律允诺,一律搞定。所以大家都是为了搞定客户,当大家在原则性的问题上不会有大的分歧。

    2、 绩效导向,一切是按照结果去评价绩效的。所以在一些问题上,如果领导提出了某个方案,但是可能存在重大隐患时,底下人是有责任去提醒和反对的。否则造成重大严重后果后,领导跑不掉,一样会修理底下的人。都是拴在一条绳子上的蚂蚱。当某个同事提出跟领导不同的意见时,并有价值时,会从绩效结果上去认可这个兄弟。这就是教育员工,鼓励提出反对意见,鼓励纠正领导的错误。

    3、 教育主管。华为提倡狼文化,所有的主管能够被提拔上去,一般都是狼性十足,能讲会说,精力旺盛,在开会时balabala一顿,与员工沟通时也是balabala一顿自己说得爽。那么就会容易造成一言堂,或者跑题。那么在主管培训的时候,都会教育带团队的人,要会倾听,会交流,沟通时要把握节奏和分寸。

    第三部分 减少无效会议

    我曾经支持过CCB的网络建设一段时间,当时刚去的时候,跟他们的IT规划部,开了一个会。当时,开会时就是典型的“一言堂”,他们一个领导过来,一顿狂骂:“你们华为的设备怎么怎么不行,你们思科的设备也是狗屎,你们西门子服务太差。。。。。。”,建行的人,还有设备厂商的人都被骂蒙了,就听他一顿牢骚,骂完设备厂商,开始骂自己的员工“balabala”。然后所有人都不知道这哥们想干嘛,这哥们也讲不出自己想要什么样的设备,性能和服务。然后气愤愤就走了。

    一言堂、跑题、不文明,这些都不是致命的,最致命的就是“无效会议”。当这位领导走了之后,大家继续按照自己的思路,方法,继续讨论,然后花2分钟讨论一下,怎么应付这位领导。所以我们开会时需要的,但是如何开的有效是有套路的。

    那么如何做到呢?

    第一、 例行会议,有议题。例如周会,一周例会的议题做事先的安排,不是很随意的说一下。订好议题,订好每个议题的时间,保证不跑题。

    第二、 会议要有纪要,每次开会的会议主持人,会议纪要人都明确。会议纪要是很重要的一件事情,也需要很高的技巧,即需要有效参与会议讨论,有需要记录下关键要点,不记流水账。

    第三、 会议纪要要分为:

    结论(会议结论不随意更改);

    遗留问题(要符合SMART原则);

    要有责任人;

    要求完成的时间等等。

    纪要有模板,提醒大家纪要要符合SMART原则。

    第四、 勤跟踪,要闭环。所有的遗留问题,在下次会议的时候都会回顾,看看是不是完成了,有没有拖延,直到有个交代。当然,如果返现任务安排有问题,根据评估也会进行问题的关闭和挂起。

    第五、 所有的决议都是需要有理有据的,不能是拍脑袋。因为事前拍脑袋,事后就会拍大腿。然后就有人拍屁股走人了。这样就不会决议是下级服从上级,少数服从多数。当然,这样的话就会存在效率问题,因为有些问题就会因为短时间研究不清楚,决策不下来。这是就有了CCB(这个CCB不是建设银行的意思,CCB(Change Control Board) 在CMMI(Capability Maturity Model Integration)中,是“变更控制委员会”的含义,CCB可以由一个小组担任,也可以由多个不同的组担任,负责做出决定究竟将哪些已建议需求变更或新产品特性付诸应用。典型的变更控制委员会会同样决定在哪一些版本中纠正哪些错误。CCB是系统集成项目的所有者权益代表,负载裁定接受那些变更。CCB由项目所涉及的多方成员共同组成,通常包括用户和实施方的决策人员。CCB是决策机构,不是作业机构,通常CCB的工作是通过评审手段来决定项目是否能变更,但不提出变更方案。至少会保证,决策的决议是集体的智慧。)

    NO.8 测试

    1、从进度的角度对比华为和小米的测试

    按照小米UI每周发布的进度,周四一天的内测。我按照华为的流程怎么套都套不出来。

    疑惑点在于:

    1、内测是指开发人员自测试,还是测试人员的测试?

    2、如果是指开发人员自测试,那么测试人员在哪里测试?

    3、如果是测试人员测试,那么开发人员的自测试呢?开发转测试的点在哪里?

    华为背景的朋友一定会问:测试人员怎么可能用一天的时间完成测试?

    也许有人说,小米的效率就是高。

    那么我们来看一下华为的测试流程,你就知道是否可以压缩到一天完成相关的测试。

    首先说明一点,华为的软件部门,包括UI、或者网站的开发团队也是按照小步迭代进行开发的,在产品稳定后,新增需求会拆分成细小的版本,进行最短周期的开发测试。也可能华为的拆解需求的能力弱于小米,但是这里我们单纯谈测试流程。

    测试是产品开发过程中必不少的环节,在华为的研发人员中,有近三分之一的人员是测试人员。

    华为的测试体系在国内算是起步较早,大概经历了这样几个阶段:

    1) 青铜器时代: 手工作坊式测试

    1996年研发测试团队成立手工作坊方式的研发过程和测试

    2) 铁器时代:IPD和CMM阶段

    1998年华为与IBM合作,开始引进IPD流程

    1999年左右引入CMM理念

    产生IPD-CMMI流程

    2004年在IPD基础上开发PTM流程,自动化测试规模开展

    2006~2007年左右PTM趋于完善

    注:上图中各个TR点的含义如下:

    HLD:概要设计文档;

    LLD:详细设计文档;

    1. UT

    单元测试的对象是LLD中所划分定义的程序单元或模块,它也是单元测试用例设计中可测试的最大单元。该测试对象可能由一个或多个函数或者类组成,测试设计就是对测试对象进行测试用例设计。

    UT的目的,是通过函数运行来检查模块代码对于LLD文档的顺从性,验证每个函数的输入输出响应,与它在详细设计文档中预先定义的是否一致。函数是产品开发实现的最基本单位,下一个实现单位是模块,从测试的角度看,希望UT完成后,每个函数都牢固可靠,下一步的IT测试将聚焦在函数之间配合能否实现分配需求,而不用担心函数本身的输入输出响应问题。

    单元测试比较适合开发人员做。

    2.IT

    集成测试是指把若干个经过单元测试的单元组装到一起而进行的测试,集成测试应依据HLD,主要发现接口、依赖中的错误或不完善的地方。集成测试的对象为若干个单元测试对象的组合,至少为两个。

    IT的目的,是根据模块设计对模块的分解,从已验证的函数开始,逐层向上集成,得到一个可运行的模块。

    IT可以由开发人员做,也可以由测试人员做。不难看出,UT是面向每一个单元的测试,IT是测试单元之间的接口,可以把UT/IT归为“单元级”测试。

    3.ST

    CMM定义的系统测试:系统测试是针对软件项目组所承担开发的软件系统进行的整体测试,将软件系统作为整体运行或实施明确定义的软件行为子集的测试。主要采用的测试方法是黑盒测试,即不管程序内部的实现逻辑,以检验输入输出信息是否符合规格说明书中有关需求规定的测试方法。可见ST的测试对象是规格说明书,更确切的说,是模块需求规格说明书,所以一般也称为MST。模块SRS文档给出了模块的输入输出的相应要求。MST后,每个模块是牢固可用的。

    4.BBIT

    BBIT为模块间接口测试,验证模块之间的接口能不能配合,有时和联调混在一起,其实目的并不相同。BBIT的目的,是根据系统设计对系统的分解,从已通过验证的模块开始,逐层向上集成,得到一个可运行的系统。而联调一般涉及软件、硬件或者不同产品间的配合测试。MST和BBIT可以归到“模块级” 的测试,一个验证模块,一个验证模块间的接口。

    以上UT/IT/MST/BBIT一般由开发人员完成,系统基本可以运行起来了,测试人员可以开展SDV、SIT、SVT了。

    5.SDV

    SDV虽然属于测试人员开展的系统测试,但是有点偏灰盒测试,因为SDV验证各子系统的配合是否满足设计需求(DR),对内部的实现还是关注的,验证多个模块集成以后是否满足设计需求。

    6.SIT

    SIT也是验证设计需求是否得以满足,与SDV不同的是,SIT完全把系统当作一个黑盒来测试,不关心内部具体的实现。实际应用中,SDV和SIT 虽然都属于系统一级的测试,往往由不同项目组(子系统)的测试人员分别测试,他们只关注各自的子系统,所以还是把SDV和SIT归为“子系统级”的测试比较好。

    7.SVT

    SVT是验收测试,其测试对象是产品包需求OR。产品包需求给出了产品的范围,从产品可能的应用环境的角度刻画系统,SVT的目的就是确认(或验收)产品包需求给出的各种应用场景产品均能满足。

    即使是网页开发项目,外包项目,终端的项目,华为的测试仍然会经历以下几个测试阶段:

    SIV:System Integration Verify 系统集成验证

    SDV:System design Verify 系统设计验证

    SIT:System Integration Test 系统集成测试

    SVT:System Verification Test 系统确认测试(系统模拟测试)

    迭代结束后,在正式对外发布前,会将历次迭代实现的所有Story再做一次测试,测试 的主体在测试人员,包括功能、非功能,并要给出测试报告。这个活动就称为SIT或发布测试。

    如果Story 测试、迭代SDV测试都自动化了,则本次测试主要是执行自动化用例、如前 面有测试不充分,则补充测试,以及详细性能测试。如果用例自动化程度不高,则本次测试会 刷选部分用来进行测试。测试结束后需要给出测试报告。

    SIT测试重点:所有迭代开发完成后,由迭代开发团队中的测试人员完成对全系统进行回归测试,达到TR4A的质量标准。遗留问题要满足TR5的DI(缺陷密度)目标。

    4) 集团军时代:IPD-RD-I&V阶段

    2008年左右开始推广敏捷,研发组织演变为PDU方式

    引进迭代开发模式,形成IPD-RD-I&V流程

    系统集成与验证流程:IPD-RD-I&V(I&V:Integrationand Verification)

    项目管理论坛

    《测试计划》编写完成后需要进行评审,参与人员有项目经理,测试经理和系统工程师,测试组长需要根据评审意见修改《测试计划》,并上传到VSS上,由配置管理员管理。

    项目管理者联盟

    待开发人员把《SRS》归纳好并打了基线,测试组长开始组织测试成员编写《测试方案》,测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介,测试思路和详细测试方法三部分的方案。《测试方案》编写完成后也需要进行评审,评审人员包括项目经理,开发人员,测试经理,测试组长,测试成员和系统工程师,返回评审结果。测试组长组织测试成员修改测试方案,直到评审通过后才进入下个阶段――编写测试用例。

    测试用例是根据《测试方案》来编写的,通过《测试方案》阶段,测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项,用例级别,预置条件,操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案,而测试方案又覆盖了测试需求点,这样才能保证客户需求不遗漏。同样,测试用例也需要通过开发人员,测试人员,系统工程师的评审,测试组长也需要组织测试人员对测试用例进行修改,直到评审通过。

    在我们编写测试用例的阶段,开发人员基本完成代码的编写,同时完成单元测试。转测试部后直接进行系统测试。测试部对刚转过来的测试版本进行预测试,如果软件未实现CheckList清单上的10%,测试部会把该版本打回。否则,软件转测试部进行系统测试。根据《测试计划》进度安排,测试组长进行多轮次的测试,每轮测试完成后测试组长需要编写测试报告,其中包括用例执行通过情况,缺陷分布情况,缺陷产生原因,测试中的风险等等,这时测试人员就修改增加测试用例。待到开发修改完bug并转来新的测试版本,测试部开始进行第二轮的系统测试,首先回归完问题单,再继续进行测试,编写第二轮的测试报告,如此循环下去,直到系统测试结束。在系统测试期间,测试人员还需要编写验收手册,验收用例和资料测试用例等。

    修改问题单,直到满足规定的缺陷密度,才能够通过相关TR点。

    如果验收发现的缺陷率在SOW规定的范围内,那么验收成功。如果超过规定的缺陷率,需要质量回溯。

    2、不可思议的小米5%

    雷军说:

    那么我们看华为的硬件测试过程,就知道成本出在哪里了。

    第一、 全程测试参与的流程:

    第二、 多层级的测试与试验

    对于电路的设计,会进行单元测试、整机测试、小批量试制、HALT试验、环境试验、EMC试验、热测试、进入生产环节之后会进行HASS试验。特殊的设备还会进行盐雾试验、硫化试验。整机结构还会进行:跌落试验、挤压、扭曲等等。

    HALT(Highly accelerated life test)高加速寿命试验。HALT是一种发现缺陷的工序,它通过设置逐级递增的加严的环境应力,来加速暴露试验样品的缺陷和薄弱点,而后对暴露的缺陷和故障从设计、工艺和用料等诸方面进行分析和改进,从而达到提升可靠性的目的,最大的特点是设置高于样品设计运行限的环境应力,从而使暴露故障的时间大大短于正常可靠性应力条件下的所需时间。

    环境试验是为了保证产品在规定的寿命期间,在预期的使用,运输或贮存的所有环境下,保持功能可靠性而进行的活动。是将产品暴露在自然的或人工的环境条件下经受其作用,以评价产品在实际使用,运输和贮存的环境条件下的性能,并分析研究环境因素的影响程度及其作用机理。

    HASS应用于产品的生产阶段,以确保所有在HALT中找到的改进措施能够得已实施。HASS还能够确保不会由于生产工艺和元器件的改动而引入新的缺陷。

    硬件工程师最怕HALT试验,因为会超越器件的限制范围去进行测试。但是为什么要这么做呢,其实是找到整个设备的最薄弱点,然后对最薄弱点进行改进。但是由于超出了器件的允许的工作范围,异常的情况特别多,原因也复杂。但是按照规范必须分析清楚,并给出优化措施。这是非常烧脑的意见事情,很多经典的问题都是HALT试验过程中产生的。

    由于我本人非测试出生,有讲的不对的地方请专家指正。现在小米开始不复当年风光了,想到雷军的5%,就写下这些。

    -END-

    整理文章为传播相关技术,版权归原作者所有 |

    | 如有侵权,请联系删除 |

    往期好文合集

    手把手教你详细的硬件电路设计

    学好单片机必须要了解的的8个电路设计

    基础电路设计知识:电阻、电容、电感、二极管、三极管、mos管!

      最 后  

     

    若觉得文章不错,转发分享,也是我们继续更新的动力。

    5T资源大放送!包括但不限于:C/C++,Linux,Python,Java,PHP,人工智能,PCB、FPGA、DSP、labview、单片机、等等

    在公众号内回复「更多资源」,即可免费获取,期待你的关注~

    展开全文
  • 智能硬件产品经理手册

    千次阅读 2019-07-10 19:20:18
    为了帮助新从事智能硬件产品尽快的熟悉智能硬件产品流程,掌握各种数据,平台工具的使用方法,以及提高产品设计能力。特以智能硬件产品经历为例制定适合转型到智能一到三年的PM/PD工作手册,方便新工作。 概述 ...
  • 基于SDSoC的软硬件协同设计流程简介 Software Define 的概念 近年来“Software Define”软件定义这个词持续火热,全球知名技术研究和咨询公司Gartner早在对2014年最有战略意义的十大技术与趋势做出预测时,便提出...
  • 硬件设计完整流程

    千次阅读 2016-04-03 11:26:23
    设计硬件电路,大的框架和架构要搞清楚,但要做到这一点还真不容易。有些大框架也许自己的老板、老师已经想好,自己只是把思路具体实现;但也有些要自己设计框架的,那就要搞清楚要实现什么功能,然后找找有否能实现...
  • 产品交付

    千次阅读 2018-06-12 15:55:55
    操作流程图4. 泳道图5. 产品设计说明书Functional Specifications Document,功能详细说明。有一点像“概要设计”,这步就开始往开发衔接了,产品UI、业务逻辑的细节都要确定,细化文档并保持更新。相应的,有很多...
  • 项目管理:硬件类项目完整开发流程

    万次阅读 多人点赞 2016-07-02 08:21:23
    担任过2个硬件类项目的项目经理(同时作为项目开发成员),以下以近期负责的一个项目为参考, 项目成员: 项目经理1名:负责项目各个阶段的监管,同时兼任应用软件工程师 PM 1名:协助项目经理监管项目各个阶段,...
  • 华为硬件开发

    千次阅读 多人点赞 2018-12-28 18:24:35
    华为硬件开发小结“华为是怎样开发硬件的”——之一1、文档、评审、设计2、华为的流程“华为是怎样开发硬件的”——之二1、归一化“华为是怎样开发硬件的”——之三1、华为电路设计“华为是怎样开发硬件的”——之四...
  • 运维服务交付规范

    2012-09-26 11:35:54
    ITSS中有关运维服务的交付管理规范培训课件,非常有参考价值
  • 归根结底,还是因为既有的Saas化产品如何应付传统企业项目交付的问题。本文从项目型产品和Saas化产品的关系,架构等方面尝试给出答案。 1. 前言 如果说为单个企业实施定制化项目是IT服务商的婴孩时期,通过产品积累...
  • IPD产品开发流程详解

    千次阅读 2021-02-25 09:49:22
    IPD的思想来源于美国PRTM公司出版的《产品及生命周期优化法一书,该书中详细描述了这种新的产品开发模式所包含的各个方面。 最先将IPD付诸实践的是IBM公司,IBM公司实施IPD的效果不管在财务指标还是质量指标上得到...
  • 硬件测试之出厂测验

    千次阅读 2018-08-04 13:13:41
    硬件的质量是整个IT系统的质量保证基石。在复杂的集成应用系统中,某些单点故障可以通过软件的方式来实时监测、规避并临时解决。本文的重点不讨论如何通过软件的手段来保证IT系统的稳定性和可靠性,也不讨论硬件质量...
  • 【IoT】产品设计:硬件成本核算,这篇文章就够了

    千次阅读 多人点赞 2021-03-08 17:09:41
    毛利润直接决定你银行账户里的收益,是指你卖产品给用户获得的钱与你将产品交付到用户手中需要花费钱的差值。不同类型产品的毛利润差别很大,一般会通过计算毛利率代替。 相比于小米硬件成本定价,靠增值服务收费...
  • 作为一个纯粹的物联网云服务提供商,此前完全没有硬件及嵌入式开发经验,突然被要求跑去给客户做完整套硬件产品的确是不小的挑战,况且由于公司内部项目的安排,只有三个程序猿可供我虐待。 (四)Get the shit ...
  • 作为创业公司和推行DevOps工程师们来说,都遇到过这样的问题:硬件资源利用率的问题,造成部分成本的浪费在网站功能中不同的业务场景有计算型的,有IO读写型的,有网络型,有内存型的,集中部署应用就会导致资源利用...
  • 从需求到交付物的四个步骤

    千次阅读 2019-04-01 22:44:07
    项目的最终成果体现为交付物,需求到交付物存在必然的演变过程。总体上分为四个步骤: 1)导致当前需求的问题是什么 相对“问题”,“需求”只是前台。可以用鱼骨图分析“需求”背后的深层次原因,找到病根。 2)...
  • 软件测试流程

    千次阅读 2018-07-23 15:04:21
    进入发布阶段就意味着产品已经通过了测试,可以发布到线上,交付给用户使用。那如何确认测试已经通过?在发布过程中,我们测试人员又需要完成哪些工作? 测试通过准则规范 上线前,需要确认测试已经通过,现在...
  • 软件产品发布基本流程

    千次阅读 2020-08-12 15:12:09
    产品发布前准备 发布之前,所有程序由测试人员进行确认测试;检查缺陷管理系统(比如:JIRA)内登记的所有bug都已关闭,或者遗留的bug不影响系统的使用,如果有严重bug未解决(级别为很严重以上)不能发布; ...
  • 海康威视 AI Cloud 软硬件平台

    千次阅读 2019-05-31 08:44:47
    AI Cloud软件产品 ...2018 年,海康威视基于 AI Cloud 架构,深刻践行“云边融合”的计算架构,全面发布了“两池一库四平台”软件产品,并在实践中不断深化落实“物信融合”的数据架构,将“两池一库四...
  • 项目交付体系

    千次阅读 2020-08-05 13:56:46
    伴随公司的逐步发展尤其是产品型软件公司,企业的产品逐步趋于精品及完善,但如何能够提高项目交付速率,将项目交付批量化、产品交付成熟化、产量化,实现此过程的前置条件有哪些,距离当前的目标还需要做哪些事情,...
  • ToB 服务的交付能力如何优化 75%?

    千次阅读 2020-01-20 10:39:13
    ToB 服务交付的方式分为公有云部署和私有化部署两种。其中,对成本敏感的中小企业往往采用公有云部署的方式,从而尽量减少成本。客单价较高的大型企业、政府、银行和事业单位,考虑到数据隐私、安全、合规等要求,...
  • 软件项目开发流程

    万次阅读 多人点赞 2019-10-08 05:30:56
    软件开发流程(Software development process) 首先 看一下基本软件项目开发流程图 其中 1.需求分析: 通过对客户业务的了解和与客户对流程的讨论对需求进行基本建模,最终形成需求规格说明书。 2.总体...
  • 持续交付

    2018-08-17 16:50:03
    随着微服务架构与容器虚拟化技术的发展,持续集成与持续交付的概念又重新回到了大家的视野,越来越多的公司开始使用持续集成的系统来解决频繁发布带来的质量问题;使用持续交付的工具来实现代码在不同环境上的自动...
  • 互联网项目开发流程大全

    千次阅读 2020-04-15 17:37:28
    项目启动会的目标是明确该产品开发项目的目标。目标不是孤立存在的,目标与计划相辅相成,目标指导计划,计划的有效性影响着目标的达成。所以在执行目标的时候,考虑清楚自己的行动计划,怎么做才能更有效地完成目标...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 31,125
精华内容 12,450
关键字:

硬件产品交付流程