互联网产品，从产品经理开始设计产品到产品上线的过程，需要多个角色参与，例如有产品、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.制定规范，要求会议结论及时整理留档。可以是软件记录、邮件，能把信息记录并且传递给干系人就可以。
工作规范会增加成本执行，所以规范一定是为了解决工作中的问题产生的。建议根据自己团队事情情况，制定能解决自己团队问题的协作规则!
