锐客网

  1. 首页 > 睿知 > >

分享产品质量保证措施经验心得 产品质量保证措施包括哪些内容

生活知识睿知

互联网产品，从产品经理开始设计产品到产品上线的过程，需要多个角色参与，例如有产品、UI、开发、测试等 。在这个过程中保障各个环节的质量，最终交付高质量的产品对企业来说非常重要 。这个方面有很多工具，例如PMP、六西格玛等等 。今天也不聊这种比较知名的工具，而是谈一些工作中总结的心得 。
我觉得要保证产品质量，主要分为两个方面的措施：
一、制定工作协作规范
确定大家的角色、职责、分工，协作方式 。这也是大家合作完成同一个任务的基础 。好的协作规范能够提高团队的工作效率 。这一部分介绍一些工作规范方面的问题场景和应对建议 。
二、工作执行过程中监控
规范有了，大家干活的过程中具体干的怎么样也需要关注 。但是大家的情况各不相同，那么在做执行过程中监控的时候，就需要根据人员进行分类，区别对待 。这部分说下如何划分员工类型和各类员工的合作技巧 。
这篇先说下“工作协作规范” 。
一、制定工作协作规范
先说明下为什么需要工作协作规范，用一个场景来做示例 。
产品从设计到上线，是一个多人协作完成的的工作任务 。会分为产品、UI、开发、测试等多个角色，每个角色还会有多个人 。从上面的场景可以看出，如果没有好的工作协作规范，参与的同事即使很努力工作，最终工作也可能做不好 。所以要根据实际情况，制定出适合自己团队的工作协作规范 。让大家明白自己的工作任务以及与其他角色协作的方式 。
下面介绍几个工作协作约定方面的问题和建议：
（一）信息传递与确认
问题描述：
信息传递失真！
从需求来源开始，产品经理、UI要收集需求来进行设计，开发人员根据产品经理的需求文档进行技术方案设计和开发，测试i人员以需求文档为依据编写测试用例、检查开发代码质量 。各个环节环节做好工作的前提就是：上一环节信息传递准确，本环节成员正确理解，本环节多成员信息同步一致 。如果做不到，就会发生如下如图的例子，产品做出来一定是自己蒙圈，客户蒙圈 。
工作建议：
一堆评审会：可以包含产品需求评审会、UI设计评审会、技术设计方案评审会、测试用例评审会 。
评审会占用时间，但是评审会也是有作用的 。必须产品的需求评审会，产品介绍一遍需求，有说的不清晰的地方 。大家可以提问 。消除疑问后大家对需求的认知达成一致 。然后再开技术方案评审，就像是说：“你们的需求是XXX的，我们打算用这样的技术方案实现，你们看看有遗漏或者有对需求理解错误的地方吗？”类似三次握手，需求评审信息是”产品–>开发”传递，技术评审是“开发–>产品”进行信息确认 。其他评审会也一样，各个评审会的最终作用就是尽量确保信息传递的正确、完整 。
为了确保会议开得有价值，建议对会议做一些约定 。例如技术评审会，如果开发同事讲了，产品同时没有提出异议，如果方案未满足功能，责任主要在产品 。明确责任之后，大家会相对的对会议引起重视 。如果评审会只是走形式，开这种会就是浪费单位资源！下面的例子就是这种情况：
（二）各环节参与拦截问题
问题描述：
还有一种情况，就是出现问题后，发现的太晚，甚至上线后才发现 。问题发现的越晚付出的成本越高 。如下：
工作建议：
如果信息传递无误，其实有很多环节都会对问题进行拦截 。不要一提到质量问题就想到测试，测试又不是神仙，其实大家都有拦截问题的机会！例如：
?开发同事根据需求进行单元自测时候发现问题；
?开发团队系统测试的时候发现问题；
?测试同事测试的时候发现问题；
? 产品UAT的时候发现；
都没发现那就可能是三个原因：1.信息传递失真；2.没有明确各环节为拦截问题需要进行的工作；3.如果明确了，那就是大家都碰巧“失职”了 。
所以建议通过评审会来确保需求传递准确，在此基础上明确各个环节需要做的质量保证动作 。
不过，即使明确了职责，现实中有问题漏网的情况也不少 。这就是具体工作执行情况监控的问题了，这个在下一篇文章聊下 。
（三）工作中工具统一
问题描述：
大家都知道，Axure9编辑的原型Axure8是打不开的，墨刀画的原型也不好与Axure原型互通 。还有，如果大家分别负责产品设计的一部分原型，团队中有人用墨刀，有人用Axure，是不是会很尴尬 。
工作建议：
现在各种办公辅助软件很丰富，很多人也愿意尝试新的工具 。尝试新事物是好的，就是需要考虑团队协作 。无论是产品、UI、开发、测试，大家一起工作的时候，都要做好工具类型、版本或产出成果格式的统一约定 。
（四）团队名词统一约定
问题描述：
有时候开会，产品和开发明明达成了一直认识，但是开发出来还是跟需要不一样 。那是因为，仅仅是“你以为”一致了 。其实大家脑子里想的并不是一个东西 。还有因为大家来自不同的公司，每个公司可能都有自己不同的叫法 。例如测试环境和生产环境之间的那个环境叫啥？灰度、准生产、UAT环境？其实不同公司指的不太一样 。
工作建议：
1.各个环节梳理自己的常用名词，进行统一约定 。大家针对同一个东西都有相同的称呼和理解 。例如产品的版本、状态名称和定义、系统的名称和划分依据等 。
2.或者直接拿出成果示例在会上展示，场景事例中可以直接画出图形，胜过十句描述 。具体工作中的一些数据测算、交互动作等都可以直接给出Demo示例与内部团队与客户沟通 。
（五）做好复盘，不重复犯错
问题描述：
由于性格、工作习惯、工作能力的差别，团队磨合的过程中会出现各种各样的问题 。并且由于工作节奏加快、外部环境变化、部门职责调整等因素，会让原本已经形成协作默契的团队产生新的问题 。
工作建议：
问题发生很正常，但是要减少同样的问题在团队内部多次出现 。在问题发生后大家一起去复盘一下，找到问题发生的原因，一起想解决方案 。复盘的主要目的不是问责，而是为了吸取经验教训，避免同一个坑里摔倒两次 。
大家都不说问题原因或者为了怕得罪人不愿意说，问题再次的时候出现大家一起被坑 。
并且在找到问题原因后，要一起想好避免问题发生的解决方案 。不能光靠大家自主能动性，还是要有切实具体的工作约定 。
（六）尽早拿到预期结论
问题描述：
工作中会存在一些风险我们无法完全消除 。例如场景中说的由于UI资源不足，并且是后台界面，就决定请前端工程师找开源的界面套一下样式 。但是发现最终不符合预期 。还有一些小概率异常逻辑的风险，不确定因素的风险 。风险如果真的发生，会对项目资源造成损失 。
工作建议：
尽量找到更多的“佐证”，清晰直观的传递信息，并且请团队成员参与论证 。例如还是界面的问题，在提需求的时候，顺便找几个比较符合预期的软件的界面截屏给开发看，问下能不能做 。这样在开发资源投入前，就能够拿到结果预期，如果不行就赶紧想其他方案（做成啥样都忍了、投入UI资源等) 。
（七）职责该不该分清
问题描述：
职责不清晰，一定是一团乱 。可是工作中非把工作职责分清楚，也有点问题：1.有些很难分清楚；2.即使能分清 。职责分的很清晰，你干你的我干我的互相不掺和，但是自己如果有疏漏或能力不足是不是就不能相互查漏补缺了？
工作建议：
1.职责、任务尽量分清楚；
2.鼓励团队内部交叉检验工作成果，例如产品需求评审会前先进性内部评审；
3.出现分歧遵循“我的地盘我做主”、“专业的人做专业的事”原则 。
（1）我的地盘我做主：工作负责人，为结果负责，同时有最终决策权；
（2）专业的人做专业的事：大家都发挥自己的专业性，做好本环节的质量把控 。由专业人拍板 。例如产品方案的分歧，最终由产品经理决策；技术方案分歧，最终由研发工程师决策 。
（八）团队内部信息传递
问题描述：
自己获取到的信息传递不全 。就像场景中描述的，组长去开会没跟组员同步信息 。
工作建议：
1.相同岗位视角一致，组内同步信息更加便于理解 。约定好谁去参会，谁负责给相关人员同步信息 。
2.会议做好会议记录、录音、录像发给大家 。
（九）脑子没那么牛X就多动笔
问题描述：
有些错误的印象或者习惯：去开会，就是当“大爷”，就是休息时间 。能带耳朵就不错了，带着脑子听的就是负责任的，能做记录的那就是优秀员工 。
工作建议：
【分享产品质量保证措施经验心得 产品质量保证措施包括哪些内容】 1.脑子够聪明，用脑子记 。
2.如果记不住，那就别懒 。跟自己相关的细节动手记录下来 。例如自己需要跟进的问题，后边需要处理的事项 。
3.制定规范，要求会议结论及时整理留档 。可以是软件记录、邮件，能把信息记录并且传递给干系人就可以 。
工作规范会增加成本执行，所以规范一定是为了解决工作中的问题产生的 。建议根据自己团队事情情况，制定能解决自己团队问题的协作规则!

    推荐阅读


    上一篇：淘宝营销方式有哪些 淘宝营销策略

    下一篇：心理咨询要花多少钱 要花多少钱