质量意识

引入两个问题：
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等
发出更新后的需求文档，并且更新到公司内部系统的产品资源中
如果需求文档需要修改的地方比较多，建议再约一次需求评审会，重点评审修改后部分

需求变更

当需求确定后，难免会遇到需求变更的现象，面对需求的变更需要有套规范的处理方案

探究原因

内因
○ 需求理解偏差：需求传达过程中出现的遗漏或是失真情况
○ 没有抓住需求本质：客户有时候不能真实表达其实现需求，在需求调研或分析时，也没有抓住需求实质，容易引起变更。
外因
○ 客户/业务方：老板或业务临时加的紧急需求，或是市场变化所需
○ 战略定位：基于公司战略转型、产品定位改变而做出的需求调整变更