对产品质量的一点思考

不管是做产品还是做项目，也不管是采用瀑布模型还是敏捷开发，我们都有一个终极目标，就是能按时交付质量可靠的功能，其中质量尤为重要。
本文是我对产品质量的一点思考，如果您所在的团队代码质量很高，很少出BUG，那么可以私信我，我们可以交流下关于代码质量的一些问题。
小公司面临的问题
大公司里每个人指责分明，团队的人员配置也比较齐全，有完整的开发流程，流程也会不断的迭代优化，每个环节只要按照流程严格去执行，基本不会出什么大的问题。但不是每个人都能够进入到大公司，或者说会一直待在大公司，如果您是在中小公司，可能会有下面一些情况：
没有专职的需求分析人员，没有专职的测试人员，很多时候是一岗多职
没有不急的项目，客户永远说的都是越快越好
虽然说唯一不变的就是变化，我们需要拥抱变化，但常常会即便拥有一双长臂，也无力拥抱
需求来了，直接写代码，后期补文档
代码中基本不写单元测试
没有自主研发的需求管理平台
为什么会有上面的问题，我觉得很重要的一个原因是成本问题，专职需求分析需要人力成本，写单元测试、文档等需要时间成本，等等。短期看来是节省了成本，但从长远来看，会导致质量下降，最终会得不偿失，如果您是做项目，打一枪换个地方，我不做评价，如果是在不断地迭代成品，那么就要停下来好好思考下了。
我们的现状
10人左右的团队，需要做的事情如下：
需求分析
Vue前端开发
dotNetCore后端开发
H5、小程序、iOS、安卓
测试
运维
上面说到，在小公司会是一岗多职，我们也不例外，大概任务分配如下：
全员做需求分析，即便是新手，也要求做简单需求的分析
后端工程师除了iOS和安卓不做，其他的都做
iOS和安卓工程师除了后端不做，其他都做
只有一两个只做纯前端的工程师
目前来看，整个团队是偏全栈的，全栈的团队理论上效率会很高，的确，效率从来都不是我担心的问题，但质量问题却一直都没能很好的解决：
开发人员还是更喜欢写代码，文档能力偏弱，虽然目前强制规定每个所做的需求在语雀上要写对应的需求文档，但很多时候写不到点子上，关联影响点也没有分析，给测试提供不了很好的支撑
文档写不好，加上开发者的思维，很多低级问题在自测阶段不能被发现
经常改了A模块的一个问题，引发其他模块的几个问题
同样的问题会反反复复出现
怎样解决质量问题
取舍和平衡
我认为软件开发其实是在时间、范围、稳定性和代码质量上做博弈：
时间：交付一个功能的期限，比如老板说3个月要上线某功能
范围：需要实现功能的边界
稳定性：随着版本的不断更新，用户使用产品的一个最直观的感受
代码质量：代码是否是可复用，易于维护的，用户不能直观感受，但也同样重要
领导总是会说，这个时间节点非常重要，或者重要客户，不能延后，等等，总之时间节点后延的可能性不大。
稳定性也不能出问题，轻则客户满意度降低，重则会造成事故，给客户带来严重损失，客户可能因此就丢了。
所以只能在范围和代码质量上做取舍：
本来应该三个月做的任务，非要压缩到一个月，那只能去和领导沟通，将一些不重要，或者不紧急的任务放到下一阶段完成
如果范围也不能压缩，那就只能舍弃代码质量了，怎么快怎么来，但也因此欠下了一个技术债，债是需要偿还的，也是有利息的，还的越迟，利息越多。
自动化测试
自动化测试分为两个部分，构建之前的单元测试和构建之后的端到端测试
单元测试又分为前端Vue的单元测试和dotNetCore的单元测试，在一个已成型的产品中去加单元测试是很困难的，所以只能先找一些关键点，经常出问题的点去尝试
端到端的测试我们采用TestCafe，反复出问题的地方，就提炼出来一种业务场景，有针对性地去写测试代码
配合Jenkins，做到测试的自动化，那是不是有了自动化测试就能高枕无忧了呢？并不是，我觉得更重要的是，每个人员对产品要有深入的理解，对所做的需求要能完全掌握，对关联影响点的分析要没有任务遗漏。
测试只是手段而不是目的，我们的目的是写出好的代码，交付出无缺陷的功能。
总结
没有任何的方法论是可以生搬硬套的，只有不断的去学习、吸收、结合现有资源进行实践、不断的重复这个过程，直到找到一种适合自己团队的落地方案。

原文转自：http://mp.weixin.qq.com/s?__biz=MzU0NjgzNzQyMw==&mid=2247483862&idx=1&sn=b2993fc378c7a1c7e98f7d02238f1db4