项目质量体系搭建
质量意识
引入两个问题：
1、没有bug，算不算高质量？
2、没有bug，并且满足用户的需求，算不算高质量？
质量的认知
说起“质量”这个概念，我们都很熟悉，会说“坏的质量会怎样怎样，好的质量会怎样怎样”，但让我们给出质量的正式定义，可能不是容易的事情。
软件质量
我们来看下ISO9126国际标准是如何定义的软件质量的：
以上质量模型由6个特性和27个子特性组成，其核心理念就是系统、组件或过程满足特定需求，满足客户/用户需求或期望的程度。简单的说：客户满意度越高，质量就越好。当然，目前我们还没法严格按照质量模型定义的标准去逐一评估每个特性是否达标。
这里我将软件质量翻译成使用质量来进一步探讨对软件质量的认知
使用质量
使用质量是从客户或用户使用的角度去感知到的质量。因为质量是相对客户而存在，没有客户就没有质量，质量就是客户的满意度。
例子1、
例子2、
例子3、
从软件质量的定义，可将软件质量分为3个层次，具体如下。
● 满足需求规定：软件产品符合开发者明确定义的目标，并且能可靠运行。
● 满足用户显示的需求：软件产品的需求是由用户产生的，软件最终的目的就是满足用户需求，解决用户的实际问题。
● 满足用户隐式的需求：除了满足用户的显式需求，软件产品如果满足用户的隐式需求，将会极大地提升用户满意度，这就意味着软件质量更高。
质量的重要性
经典名言：
丢失一个钉子，坏了一只蹄铁;
坏了一只蹄铁，折了一匹战马;
折了一匹战马，伤了一位骑士;
伤了一位骑士，输了一场战斗;
输了一场战斗，亡了一个帝国
– 本杰明·富兰克林
一个小小的细节都会产生极大的影响，这就是我们所说的蝴蝶效应。
引用前几年的一份关于消费者对购买的产品不满意的调研报告：4%的人会抱怨、投诉；96%的不提意见；91%的人不会复购；13%的人会向身边约9个人诉说对产品的不满；寻找一个新用户比留住一位老用户多5倍多开支
由此可见，低质量给用户带来的连锁反应，不仅仅是产品的价值下滑，更是给公司的品牌价值造成了巨大的影响
实际工作中，我们经常能听到以下声音：
- 这问题与我无关
- 等客户提出来再说
- 上次都没问题，这次肯定也没问题
- 一直都是这样，应该没问题
- 这问题不大，就这样吧
- …
暴露出的问题：
1、质量意识薄弱
2、存在侥幸心理
3、习惯性思维，无法提供客户需求质量
4、执行不彻底，敷衍了事
最终：失去质量 ➞ 失去顾客 ➞ 失去市场
质量的信念
质量意识本质上是一种思维逻辑，即能否站在用户和产品角度思考并解决问题。主要包含如下几方面：
-
用户意识：即你研发的软件产品是否满足了用户的真实需求，解决了用户的底层痛点，产品使用的感受是否良好。简单来说就是——在能用的基础上是否好用，创造更多的经济价值。
-
商业意识：即开发的软件产品能否为企业创造商业价值。技术本身是没有直接价值的，技术的价值需要有一个依附物或者说承载品，这个物品就是软件产品能创造的商业价值。
-
数据意识：软件产品最终要投入市场让用户使用，然后才能发现不足并且不断迭代优化。当数据量越来越庞大时，不仅要意识到产品带来的经济价值，更要意识到我们所做的事情带来的社会价值。
质量是习惯出来的，没有最好，只有更好和持续改进，因此我们可以：
- 打破思维边界：技术思维会关注技术实现和细节，产品思维关注用户体验、商业价值和为什么要某个功能；
- 改变原有习惯：日常工作和生活中，站在产品角度思考接触到的物品，背后的价值、用户体验和使用场景等；
质量落实
质量保障体系好坏的标准，不是里面的内容多么充实、饱满，而在于执行力。落地后，需要整个团队去遵守，形成思维化习惯而落地，在执行的过程中不断去优化，进而继续坚持。
先来看下项目开发的生命周期，这边划分了4个阶段：需求阶段 -> 开发阶段 -> 测试阶段 - > 上线
结合我们公司目前业务的快速迭代以及敏捷开发的模式，本次质量体系的重点先从需求阶段和上线阶段落实，着重抓好产品的“入口”和“出口”
需求质量
需求质量体现在如何能正确的洞察客户的需求。如果需求都是错的或者有偏差，那么研发出来的产品返工和失败则是必然的。
需求基本过程
我们首先看，需求的整个过程。
举个例子：
用户需求：我想随时随地的与他人进行交流沟通
于是诞生了产品 – 手机
但用户不是专业人员所以，通常会说的比较抽象，比如：好用、时尚、使用流畅。我们称为，产品的特性，最后这些特性具体用什么功能体现，需要什么软硬件，定义清晰，最后我们才能进入开发。
这个过程如下图所示：
所以，需求的形成是：
需求的有效性
需求来源很杂乱，通常会有下面几个来源
- 领导指示
- 年度战略规划
- 行业竞争/数据分析
- 竞品的机械模仿
- 产品经理自己的假设
- 用户反馈
- 市场/销售/运营意见
当把需求都收集完了之后，接下来就进入到需求筛选了，把一些不合理的需求剔除掉
例子1
例子2
需求评审
意义
- 明确业务、产品价值
○ 需求是为提高用户体验、解决用户痛点等服务的，那么我们做需求也要明确其最终实现的业务或产品价值到底是什么，需要通过需求评审会议做一次全方位的传达。 - 达成一致意见
○ 现实中一个需求的实现往往需要项目组各端成员的协同，那么拉齐大家对于需求理解的一致性是非常有必要的，同时也能明确大家对于需求的疑问点，以及所要面临的挑战。 - 明确最终需求
○ 评审会的各参与方可以从不同的角度思辨需求的真伪、完善度及合理性，从而保障最终得出的是真正的需求，减少返工和成本超支
参与人
所有参与实现需求的相关人员，包括业务方、产品经理、UED、PM、开发、测试、其他团队依赖方等
- 业务方：业务方代表或用户代表，即需求提出人员或最终的使用人员。若是产品经理自发产生的需求，则邀请最终功能使用人员进行评审。若是直接面向用户的，可以考虑邀请对应的运营人员参与。-- 判断方案是否正确，信息传递是否准确
- UED：交互视觉设计师
- PM：项目经理，协调资源，排期
- 开发：包括客户端、前端、服务端等所有与需求实现相关的开发人员都需要参与
- 测试：测试是对需求质量进行把控的重要一环，因此测试人员必须参与需求评审会。
- 依赖方：如果该需求的实现需要依赖其他团队的上下游链路，那么依赖方的产品人员和开发人员也要参加需求评审会。
评审流程
评审前
- 首先，确认需求文档、原型都已经完成；
- 提前找核心人员沟通需求主流程，提前消除大问题；
- 提前给参会人员发PRD和原型，让大家可提前了解需求；
评审中
- 讲解需求的背景和价值、功能模块及整体的优先级
- 参与方应对所有不明确、依赖边界情况、技术实现困难点等问题提出自己的疑义，尽量在会议中明确敲定各项问题
评审后
- 给所有的参会人员发一份会议纪要，纪要内容包括：
○ 已经达成一致的会议结果，如：分工，预计上线时间等；
○ 会议上已经确认了的修改点以及修改后的方案说明；
○ 会议上遗留的争论点/问题，每个问题责任方，解决deadline等 - 发出更新后的需求文档，并且更新到公司内部系统的产品资源中
- 如果需求文档需要修改的地方比较多，建议再约一次需求评审会，重点评审修改后部分
需求变更
当需求确定后，难免会遇到需求变更的现象，面对需求的变更需要有套规范的处理方案
探究原因
- 内因
○ 需求理解偏差：需求传达过程中出现的遗漏或是失真情况
○ 没有抓住需求本质：客户有时候不能真实表达其实现需求，在需求调研或分析时，也没有抓住需求实质，容易引起变更。 - 外因
○ 客户/业务方：老板或业务临时加的紧急需求，或是市场变化所需
○ 战略定位：基于公司战略转型、产品定位改变而做出的需求调整变更
应对措施
- 需求确认：确认需求变更来源，找到原始需求，最好能与需求提出方进行直接沟通，进行需求确认。
- 需求分析：对变更的需求进行真伪的初步分析，从需求背景，需求目标，需求解决的问题，产品所处阶段，需求成本，产生的风险进行综合评估。
- 替代方案：并不是所有的需求变更都要满足，考虑是否替代方案，现有的产品适当调整能否能满足业务方需求
- 需求评审：所有参与方进行需求评审，同时评估需求变更产生的影响，如进度，成本，风险，可能造成的延期等。
- 信息同步：重点向需求变更提出方进行信息同步，同时也要在团队内部进行变更信息传达，原型以及PRD及时更新同步。
- 资源申请：需求变更肯定会既定项目的进度，资源，质量会有影响，需要向上反馈，申请项目资源（包括加班）。
- 开发排期：根据需求轻重缓急进行开发排期；不着急的需求安排到下个版本开发，着急的需求协调开发立刻解决。
- 风险管理：需求变更可能会原有的产品架构产生影响，以及带来其他潜在的问题，需要与开发等一起做好可能的风险管理。
总结
需求是规划的起点，也是研发的起点，质量是否符合要求，但这个要求是否正确，其实更重要，我们应该投入更多的质量保障在这个环节
上线标准
上线流程
这里特地提到了预发布环境（目前我们缺失的环节）预发布环境是产品质量最后一道防线，有必要备一套。列举几条预发布环境的作用：
- 上线部署的一次演习，可排除上生产环境时出现的缺少配置或缺少数据等问题
- 使用生产数据做验收测试。减少因使用测试数据导致的漏测，加强数据兼容测试。
- 可以执行在测试环境下没有执行条件的用例，提高用例的执行覆盖率，如三方服务的依赖
每个产品可根据自己业务线的特点，适当调整。怎样在产品上线时间点和产品质量之间找到平衡点，需要根据实际情况来分析决定，以下根据公司实际情况罗列了两个上线标准
功能测试通过标准
性能测试通过标准（偶尔有）
注：目前只针对需求的上线定个标准，后续可以根据实际情况定义其他类别的上线标准，如：bug上线，技术优化上线，紧急上线，异常回滚等标准