搞砸一个产品的功能安全
第一招：人
中国有句古话，做一件事需要天时地利人和，其实，搞砸一件事也是如此。天时地利属于客观条件，今天要教大家的是即使客观条件有利于功能安全，我们也要靠主观彻底破坏彻底搞砸的方法。我命由我不由天，所以我们先主要讨论下“人”的问题。
如果一个功能安全项目中每一个角色都有很强的责任心和使命感，认真踏实，遵规守纪，技术优秀，能力称职，那么搞砸这个产品的功能安全难度太大了，但是不要灰心，只要你认真挖掘，有些项目中总会有那么几个能够助攻你完成破坏大业的人，如果这样的人又是处在比较重要的角色上，例如处在决策者、总工/总师、系统设计、硬件开发、软件开发、功能安全、测试、验证和确认等重要位置，那么你的机会就来了。再如果这样的人在项目中又掌握一定的权力，那么恭喜你，搞砸一个产品功能安全的目标触手可及了。以下特征有助于帮你识别这样的助攻人才：
急功近利。心里只想着利益，奉行天下万事唯快不破，而不遵循功能安全产品开发的客观规律；
投机取巧，敷衍了事。做事不求甚解，成果东拼西凑，只做表面功夫，说起来头头是道，实则背后挖了一堆坑；
不懂装懂。知其然不知其所以然，了解点皮毛就敢飞上天，实际能力配不上说过的大话，把产品功能安全带到一条不那么正确的路上；
推卸责任。做事没有担当，自己铺展的烂摊子总要想方设法怨到别人头上，不会反思自我，不会进取改进，责任都推出去了，就和自己没有关系了，所以不求做好，只求自保；
自私狭隘，争抢风头。做事不是以把事情本身做好为目标，而是攀比与争抢，诋毁别人的有益成果，总有那么一股怨念驱使着自卑而变得咄咄逼人；
对功能安全缺少敬畏之心。从心底里就完全不懂功能安全也不在乎是否安全，或者虽然懂功能安全是什么，但同样漠视安全带来的后果。
以上这些特质的人，遇到了就收下吧，哪怕只有一两个，他们也一定会帮你把产品功能安全搞砸的。
第二招：需求
在功能安全项目中，需求的管理与跟踪至关重要，所以想要搞砸功能安全，你先搞砸需求那么就成功了一半。首先，需求来源于用户，项目启动后，需要把用户需求转化为系统需求，作为项目设计开发、验证测试的原始依据，因此需求错，将会导致步步错。
想要搞砸功能安全，制定需求时只需要以下几步：
需求制定随意化。不用费时费力把外部的客户需求研究透彻，只需要拍脑袋定需求即可，反正在项目中，系统需求就是源头，你定什么后面就做什么。
需求描述歧义化。你要发挥障眼法，把需求描述的模棱两可，以“一千个人眼中有一千个哈姆雷特”为目标，要让一千个人对同一条需求能够产生一千种解读。
需求模糊化。针对一些有具体特定要求、定量要求的需求，你只需含含糊糊的描述，让其他人无法明确理解意图，无从验证。
需求不跟踪，不落实。清晰的条目化需求有助于需求的跟踪与正确实现，每条需求带有唯一编号进行设计跟踪和测试验证，都是保证需求落实的手段，所以你一定不要把需求条目弄得太清晰，至于安全认证流程中要求的需求跟踪，编号胡乱对应一下，内容不用认真分析是否完全一致对应。
需求不完整。制定需求时考虑不周，需求不完整，足可以给后面的开发工作带来一系列的麻烦，到具体的细节时不知道该如何处理，如果开发人员也是你的搞砸团队队友，那么就可以随意发挥，这样产品的后果就会存在无限种可能了。
总之，要想搞砸一个产品的功能安全，只需要在制定需求时漫不经心一点，就足够让后面的工作抓狂了，一份以“搞砸”为目标的系统需求是万恶之源，把它应用于项目中就相当于打开了潘多拉魔盒，邪恶就会由此释放。
第三招：设计与开发
设计开发作为研发产品的核心环节，想要搞砸产品的功能安全，在设计开发上搞事情是可以事半功倍的，在设计细节上偷偷埋个雷再遇上一群“搞砸”队友，很多时候都会无人知晓。
首先是系统层面的设计，一个好的功能安全项目，这个阶段需要统筹全局，从系统角度出发，基于系统需求制定系统架构及策略，确保系统实现功能正确，性能良好。反之，你在进行系统设计时，只要脑子空空，不统筹，不思考，东拼西凑做出的系统设计，多半都离搞砸不远了。你无需考虑功能分配的是否合理，系统层面的安全策略是否足够，也无需顾忌系统故障检测方法与覆盖，更不需要关注系统导向安全的时间性能，反正是冲着搞砸的方向努力的，只需要胡乱搞出一份系统设计交差即可，即使以后出现问题，你还可以任性的甩包给软件，硬件，安全专业。
对于硬件设计的“搞砸队”队友，你只需生搬硬套个硬件电路，不需要深入思考他的失效模式与影响。对于器件选型，你也可以完全放飞自我，什么降额设计，电气隔离，EMC防护，通通可以不用那么用心设计，对于逻辑电与接口电，也可以混淆不区分，对于安全机制与策略，也可以佛系选择，如果嫌弃动态的检测有点麻烦，那就直接都选择静态好了，反正功能实现了，至于安不安全那就不关心了。
对于软件开发，很多人都说了靠流程去保证软件的质量，那么就更加可以忽略设计细节了。管它什么防御性编程，管它什么内存保护，管它软件逻辑是否完美，管它具体实现与需求细节分支是否完全一致，总之，在不深究的情况下，功能实现了即可，至于在特定场景下，软件是否会产生一些意想不到的情况，是否在故障时真正导向安全，这些都不是一个搞砸人的目标。最多你按标准的流程、技术方法来敷衍执行，原则上可能也没发现你的差错，但背后你绝对有实力挖出一堆坑，最终成为搞砸产品功能安全的刽子手。
第四招：功能安全
目前功能安全的门槛参差不齐，人员水平鱼龙混杂，看了几遍标准完全没有实战经验就可以大谈特谈功能安全了，所以你从这方面来搞砸产品的功能安全是可以让人毫无防备的。
安全分析可深入也可肤浅，你非要这样分析，没有人能够制止你，所以你根本无需自己埋雷，你只需水平不足够看到别人的雷即可。你可以自己根本没有做过一个完整的功能安全项目就夸夸其谈，你也可以不懂硬件、不懂软件就瞎指挥，你还可以认为就按照标准要求完成相关的交付物你就实现了功能安全，你更可以搬弄些标准术语让自己显得深有建树，总之，你可以走你的路，没有人能够阻止你搞砸的脚步。
什么HAZOP，什么FMEA，什么HARA，什么FTA，什么DFA，什么PHA，什么SHA，什么IHA，什么OSHA…….你都可以照葫芦画瓢。你也可以不用那么关心安全策略是否合理，安全机制是否足够，安全防护是否实现，软硬件开发细节是否满足功能安全要求，分析的场景是否全面，测试对安全防护的检测是否充分，你可以站在很高的高度去分析，高到不去了解实现细节。
第五招：测试、验证与确认
对于一个功能安全产品的开发项目，测试、验证和确认是一道道壁垒和最后的防线，如果你在这个时候选择对别人埋的雷视而不见，或者根本不去排查雷区，慷慨放行，那么产品的功能安全就可以彻底搞砸了，你虽然不是搞砸的始作俑者，但你绝对是重要的助推者。
单元测试你完全可以冠冕堂皇的测试语句覆盖率、分支覆盖率和MCDC覆盖率，不用管具体的设计意图的，函数本身设计意图错就错了嘛。集成测试和确认测试你只需要做做表面功夫，正向的功能都测试了即可，不用管什么故障插入测试，绞尽脑汁穷举各种故障场景失效情况进行测试费时又费力，如果强行要求，只挑选二三蒙混过关就行了。对于测试用例的设计，测试结果的要求也不用那么较真，一切看心情；对于接口测试，调用关系和接口协议的测试随便测一测，不用遍历细节。
至于文档验证，那就更容易了，你可以对着检查单都写通过，而不深究每一个文档内容是否真正正确，真正满足要求。你也可以出工不出力，每个文档都浏览但只是走马观花完全查不出问题，总之，天下套路千千万，相信你都懂的。
第六招：安全认证
如果你认为产品的安全认证可以保障你没办法搞砸功能安全，那你就大错特错了。尽管安全认证都是有资质的第三方独立机构，但是还有以下漏洞你可以钻：
安全认证公司风格不一，人员水平差别较大，难免也会存在想和你一起搞砸功能安全的同伙；
鉴于技术保密性，安全认证过程中第三方评估人员未必能够获取你全部的资料而面面俱到，所以你搞砸的小动作可以在第三方评估监管下神不知鬼不觉的进行；
安全认证是建立在双方相互信任的基础上，如果你提交呈现的是一份造假的数据或文件，第三方评估人员也无从知晓。
因此，安全认证也无法阻挡你搞砸一个产品功能安全的行动，只要你有这种搞砸意识，那么有志者事竟成。
第七招：逃
等你彻底搞砸一个产品的功能安全后，并不是高枕无忧了，后面隐藏着无限风险，因此教你最后一招：逃！温馨提示以下几点：
产品上线后，你要随时做好跑路的准备，一旦发生功能安全事故，你可能被追责，因此三十六计走为上计，但这个走也是有技术含量的，不会因为你换了公司换了职位就可以免责，至于走到哪里去，还需要你自己琢磨。
如果你搞砸的是一个轨道交通相关产品，那么今后你和你的家人、朋友要尽量避免乘坐了，说不定什么时候你埋下的雷就会炸了，那可是要命的事情，所以乘坐相关轨道交通出行需慎重。
如果你搞砸的是汽车电子相关产品，那么首先记得不要买相关的品牌汽车与产品，另外，在路上走路行车都要万分小心了，你不撞它不代表它不撞你，你的雷最终炸了你自己就不好了。
以上内容如果你觉得只是危言耸听，事故只是小概率事件，那么请记住世间存在因果报应的可能，不是不报，时候未到。
搞砸一个产品的功能安全相关推荐
- 几行代码就搞定一个文字识别功能，同时还能转换成语音，畅快！
前几天想把一篇不错的文章保存下来,无奈是图片的,于是想利用python把图片中的文字识别出来 实现的方式还是挺多的,这里介绍下百度的AI开放平台,毕竟大公司,感觉识别的精度会高点,同时相信他们的算法也 ...
- 利用python+百度AI搞定一个文字识别功能同时转换成语音
一些准备 使用百度的AI开放平台,首先你得有个百度的开发者账号,相信你有百度云的话应该都会有,没有的话简单注册一下就可以了. 然后进入控制台选择人工智能-文字识别去创建个应用,这样就会生成对应的App ...
- 《完美搞砸中台项目的10个方法！》
点击"技术领导力"关注∆ 每天早上8:30推送 作者| Mr.K 编辑| Emma 来源| 技术领导力(ID:jishulingdaoli) 你没有看错,本文研究" ...
- 二维码QR Code不是一个产品,是一个功能
2019独角兽企业重金招聘Python工程师标准>>> 台湾有许多公司,开始跨入 QR Code 的相关应用,热度开始逐渐上升.最近有幸跟许多在这方面有兴趣的朋友们聊天,得到了很多的 ...
- 【干货】一个产品经理眼中的云计算：前生今世和未来
一 最近发了太多JobDeer的广告了,感觉不写点干货有些对不起我的粉丝们.于是这次写写我还算熟悉的领域--云计算. 作为新浪云的前产品经理,我不想从技术角度去讲云了,这次我从产品的视角来管中窥豹吧. ...
- SAP License：搞砸SAP项目的3种方法
在一次上线之后,我和几位项目里的战友坐在街角的夜宵摊前,啜着啤酒啃着串,分享着各自的SAP故事. 不知什么时候开始,话题转向了各自经历的,失败的或濒临失败的项目经验. 这也进而让我想把那天聊到的一些内 ...
- 机智云产品、功能、服务一览表
前言 简单来说,传统电子设备接入云平台需要开发三个方面的能力: 1.是完成设备与云端的通信能力: 机智云提供了多种基于wifi(GPRS.BLE)模块的通信解决方案,企业开发者只需要在wifi模块上烧 ...
- 搞AI的产品经理该怎么写PRD？谷歌的导师教你
乾明 整理编译自 Medium 量子位 报道 | 公众号 QbitAI 作为AI产品的产品经理,该怎么写好一个产品需求文档( PRD )? 对于大多数人来说可能还没有清晰的概念.到底该咋办呢? 莫慌! ...
- 摘抄和总结--确保搞砸人工智能项目的十种方法
鲍捷 文因互联CEO 原文链接 目录 文章目录 一下子砸很多钱 描述 总结 根据最新论文来决定技术路线 描述 总结 脱离真正的应用场景 描述 总结 使用过于领先的架构 描述 总结 不能管理用户预期 描 ...
最新文章
- IE6-IE9兼容性问题列表及解决办法_补遗漏之一：button的type默认值改变为submit了。...
- JQuery Mobile 手机显示页面偏小
- [转]轻松掌握Ajax.net系列教程十六：使用DropDownExtender
- leetcode436. 寻找右区间（二分法）
- 错误：The project was not built due to Unparsed aapt error(s)
- 河南省队选拔 HAOI2015 解题报告
- 心语收集8:若无缘，与之言多，亦废。若有缘，你的存在，就能惊醒他所有的感觉。...
- 关于matlab浮点转定点总结
- b+树的增删改查_EF Core / 基础_从建库到增删改查
- pytorch 网络搭建简要步骤
- 【SPSS】SPSS之主成分分析及因子分析
- jdk、jre各版本下载
- 小程序开发流程详细，小程序开发教程
- 基于java springboot租房平台设计，公寓租赁系统
- Invalid config, exiting abnormally
- 微信小程序中界面常见的交互反馈、用户即时反馈
- 数据库查询+数据库备份+数据库恢复
- Android自定义记账软键盘(仿鲨鱼记账的记账功能)
- ubuntu 11.10 3D桌面特效及其窗口特效设置
- Beyond：二十年摇滚之累