在这个过程中保障各个环节的质量，最终交付高质量的产品对企业来说非常重要。
这个方面有很多工具，例如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条）