质量事故分析
目标：1、各部门了解2019年度质量事故 2、对质量事故的意识培养 3、各自节点的工作缺失及后续改进。
一、纵观我们公司2019年度质量事故概览及分析
挑一些严重且典型的简单讲下
二、为什么会有质量事故？质量事故的原因
伴随着软件诞生开始，bug就会存在，但是不是所有bug都可被饶恕和原谅。
比如以 苹果公司举例：
很久以前几乎所有用户认为 Apple OS 十分流畅、相当稳定，这也是苹果产品饱受青睐的一个重要原因。大约从 iOS 5 开始，单拿 iOS 系统的内核( Kernel )说就已经开始出现了 Bug 激增的兆头，但是仍然不影响用户使用，用户在主观使用上没有几乎没有任何体验。当 iOS 被拍扁， iOS 7 时代，这个问题更加严重，在业内，称 iOS 的 Kernel 是 Buggy 的。这个版本开始，用户体验已经开始受到很大的影响，出现了系统卡顿、程序无故闪退等现象，直到现在 iOS 11，问题简直一发不可收拾，用户很轻易就可以遇到一个糟心的 Bug，可能是交互上的，可能是系统层面上的，可能是内核的。
现在，大家使用安卓系统手机越来愈多。
原因：因为苹果新功能的增加迅速、硬件的频繁更新，系统发展的迅速，根本不足以跟上错误修复的速度，没有功夫沉淀下来好好修修 bug，而是马不停蹄地马上投入明年的开发，这样下去，会形成恶性循环，其实已经形成了。
这其实也是很多公司的影子。
观察软件的用户们，相比上线速度，软件的质量如何确实不被关注，或者说无法被关注。原因呢，可能是对新生事物的期望值比较低，也可能是习惯了在应用中发现问题、修改问题，甚至可能这种方式就是软件行业DNA中固有的。
三、让大家意识到产品质量，是每个部门、每个人的责任及意识。
质量绝对不是一个环节，一个工种可以搞定的
- 从对语言的误用，到对第三方组件的误用；
- 从需求根源就有问题，到需求传递过程中出现的误差； 在我司较多类似案例
- 从设计代码基本逻辑设计不合理，代码架构设计不合理； 在我司较多类似案例
- 从一些参数配置错误到上线的版本弄混； 在我司较多类似案例
- 从架构师不良的设计，到运维人员不规范的操作； 在我司较多类似案例
质量问题可以产生于任何一个环节。 比如许可证制作，在大家看来几乎不可能出现问题的环节
所以，如果仅依靠一个部门或者某个人的努力来提高产品质量——结果是：如果只尝试从单一角度解决质量问题，即使采用再牛逼的技术，下再多的力气，定再多的流程，也可能只会事倍功半。
很多团队解决问题总是极度偏向一个维度的。
- 的组织定义一大堆流程，并严格执行，最后演变成了抠文字的游戏和邮件大战，而对采用落后的技术给生产力、质量带来的极大拖累视而不见；
- 有的团队极度追求技术，什么新用什么，最新的架构、框架全都用上，却发现开发人员一行单测也不写，连类型转换，不捕获异常，少写个等号这样的基础代码级别的 bug 都要等系统测试阶段再发现；
- 有的团队开发人员极为强悍，从代码工程角度来看架构、设计、代码、单元测试、评审都无懈可击，但是需求竟然是邮件来回沟通，到最后还是为其所累；
- 还有的团队似乎每一个点都照顾到了，还过了 CMMI5，貌似一切都很好，但是发现，改一个按钮的需求要搞一个半月才能上线，要知道，开发效率也是质量的一环啊。
如果只依靠测试部门或者某个产品的测试人员，那么，明年的质量事故依然如此甚至可能会更多。
四、针对各个部门，与软件产品息息相关的各位，能做到多少改进？
产品：需求输出严格把控，产品需求宣讲，产品部门领导及产品经理责任。
开发：开发设计文档及输出严格把控，代码review，开发经理及开发人员责任。
测试：用例设计规范，用例评审等等
项目：
还有领导会提到成本。对于成本与质量，如何权衡？——在有限的成本里保证核心功能的高质量。把大部分精力投入在用户最关心的那少部分功能中，在有限成本下才能获取最大的产出和效益。
质量事故发生的成本，以及如果避免要投入的成本对比
我们公司的质量事故， 归纳如下：
1、各个节点都有质量事故
2、项目基本认为都是产品的问题或者产品改进就能避免的问题
3、大部分质量事故实际从工作流程中改进的没有多少
4、改进的措施一般都持续不了很长时间
5、要求第三方外包保证质量是个伪命题
6、领导都认为质量事故到个人，跟领导没关系
7、性能问题，我们公司产品从设计之初就没有产品性能的意识，所以，当前来看后续还是会出现类似问题。
8、基本改进都是测试才会有意识
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
