保障产品质量的两个关键措施(上)

技术团队实施过程中,如何保障产品质量!

互联网产品,从产品经理开始设计产品到产品上线的过程,需要多个角色参与,例如有产品、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.制定规范,要求会议结论及时整理留档。可以是软件记录、邮件,能把信息记录并且传递给干系人就可以。


工作规范会增加成本执行,所以规范一定是为了解决工作中的问题产生的。建议根据自己团队事情情况,制定能解决自己团队问题的协作规则!

未完待续----------

----------------------------------------

欢迎大家关注微信公众号“小圣聊产品”!

会分享一些产品工作中的经验、有意思的事情!

--------------------------------------

0条评论 添加新讨论

登录后参与讨论
Ctrl+Enter 发表