ARTICLE · 1149289
断裂的刹车踏板:给软件项目招标敲了一记警钟
某脱胎于字节跳动的汽车互联网平台，近日发布了一则针对国内某高端品牌车辆制动性能的评测：三台参与测试的该品牌车辆，在百公里急刹时，刹车踏板支架全部断裂，且断裂位置均一致，视频发布后在网上立刻掀起了轩然大波。
铁哥认真捋了一下此次事件的争议内容，认为焦点主要还是集中在对测试环境是否属于“极限工况”的分歧上。
支持车企的一方认为：测试人员未按照国标规范进行操作，属于超出规范的暴力测试。
支持平台的一方认为：测试遵循了国标规范，其操作力度并未超出规范要求，且部分网友还认为国标要求偏低，只是普通场景时的工况，真正在高速上的百公里急刹，踩刹车的力度可能会更大。
从驾驶经历上来说，铁哥也是有三十万公里驾龄的老司机了，记忆中确实也有过两三次百公里刹停的危急情况，只是不知道当时踩刹车的力度数值有多少，但自我感觉是使了大力的。
虽然百公里急刹的场景少得可怜，但任何车辆在这个环节都是不能掉链子的，哪怕是“国民神车”五菱宏光。
并非车圈业者的铁哥，自认存在认知盲区，难以做出专业的判断，但同步到我们软件行业来看，此次事件却能给很多软件项目招标敲一记警钟。
在铁哥经历过的数百个投标项目中，系统功能从来都是招标书中着墨最多的部分，当然，这其中大都是甲方机械地照抄和汇总了各家乙方的系统功能介绍得来，好像一套系统好不好，评价方法就是看其功能全不全。
可作为一只软件行业的老麻雀，铁哥认为评价一套系统是否优秀，重点考察的指标应该是稳定性而非堆料的功能。
在招投标交流中，最常见的就是甲方问有这功能没有，有那功能没有，而乙方的回答通常都是有，或者是简单二开即可，这种问答的结果是无法体现各系统间差异的。
铁哥经历过一些替换系统的项目，听到吐槽原系统最多的并非功能问题（相反有些经过深度定制的功能，客户用得还非常顺手），真正让客户下定替换决心的就是系统不稳定。
如：莫名其妙的宕机，上下游的单据状态不同步，有些查询特别慢甚至能让内存溢出，关键操作日志缺失无法审计，补丁针对A节点打的结果B节点出现问题，按钮点着点着突然就弹个包含类名的英文报错框，同一操作时好时坏难以复现，计算结果出现数据错误等等。
以上问题的根源都在底层框架上，地基不牢靠，构建在上面的各种堆料功能，只要遇上前面所说的“极限工况”，系统出嘻嘻就是必然的。
作为软件招标方，功能验证是很简单的，而稳定性验证却难以开展，这就给一些不愿意花时间打磨系统底座的急功近利的厂商以可乘之机，让他们能够在摇摇欲坠的地基上，与稳定底座的厂商直接开展功能层面的PK。
车圈里的那句名言——劣币厂商把成本花在了客户看得见的地方，而良币厂商则把成本花在了客户看不见的地方，这话同样也适用于现在的软件圈。
鉴于招标方并非专业用户，有时确实难以甄别各家投标方的系统是否稳定，但作为投标方的厂商，其实是可以在标前告知客户，如何在“极限工况”下考察系统的可靠性指标，这样，才能在技术标评审阶段甄选出真正优秀的系统。
相关精华推荐