项目中如何避免团队成员相互甩锅

项目中如何避免团队成员相互甩锅产品在最终上线开通出现了问题，必然是由众多因素所致，所以终于会出现团队甩锅现象的发生。出现问题不要紧，重要的是，产品经理可以通过哪些方法来避免团队之间家电产品甩锅现象的发生。"我们是谁”“我们是产品经理”“我们的日常是”“撕逼、背锅、甩锅”“人在工位坐，锅从天上来”，作为苦逼的产品经理，必须要做好时刻背锅、接锅的准备。“常在河边走，哪有不湿鞋”，其实，不仅仅是产品经理，只要身处职场中，总会有那么一两个锅砸来，轻则撕逼，重则大打出手，造成团队关系恶化，进而对团队工作产生不可逆的影响。与其被动的“后发受制于人”，何不尝试“先发制人”。那么，作为团队“主心骨”的产品经理，我们怎样做可以尽量避免团队之间甩锅现象的发生，从源头根除问题的产生呢？通过“Case-Case”的方式重现问题，会更加明确的给我们一些实际的提示。下面我们一起跟着故事去思考，产品经理可以现象哪些方法来避免团队之间甩锅通过的发生。案例一：某童鞋在刚入坑时，负责了一个简单的数据分管产品，由于是数据产品，所以需求只是通过简单的述，就进入了开发流程，结果出更了上线事故。事后复盘，分析原因，发现是由于Python与Java语言规则不同，导致了接联调失败。测试认为尚未按照需求完成了测试，且代码功能正常，问题不在测试；其他两个接开发也觉得自己的代码运行正常，问题在于上线前未进行联调，一时间三方各执一词，开启了“甩锅大战”。那么，针对案例里的出现甩锅里边事件，我们又该如何避免呢？漏测的测试案例中，上线任务是依照“产品-开发-测试-上线”流程开展的，出现了上线事故，多数时候，测试作为上线前的最后紧接着数条关卡，往往也会因为测试用例未覆盖到位，而成了直接责任者。仔细的我们会发现，导致漏测最主要的原因就是需求没有说清楚，问题既然已经定位清楚了，那下一步就是“对症下药”了。在工作中，我们经常会使用会文档拿来交流，因为其具有可传递性和完整性。因此，像这种技术上用的对接，我们必须要有一个完整的文档对一些必要的细节进行记录和描述，减少沟通过程中会信息的遗漏，使大伙儿都可以接收到完整有效的信息，进而保证了沟通的有效性。所以，一份且清晰的需求文档是开发环节必不可少的。好的需求文档，需要具备以下几点特征：11）正确］用户的需求片面能够被正确的满足，且逻辑恰当无误的被表达。2）完备］需求文档要尽可能完整且颗粒度较细的把所有场景、特殊情况、业务、产品、数据流逻辑都写清楚。3）无歧义［文档里所有的用词、描述要精确，切不可出现“可能”、“大约”“在某种程度上”等不合时宜的表述，让开发人员去猜测我们的想法。14）优先级［像画原型一样，一个产品必然满足由多个功能来满足用户，而多个基本功能等待开发时，就一定要注明错误率，告诉开发计划我们的重点是什么，而后是什么。］5）可验证［所有设计的功能，是在技术评估后，可以被准确实现，且测试验证此信的。低效的团队沟通案例中，在产品上线挫败后，由于相互甩锅而再经验丰富一次引发了团队矛盾，上演了一场“甩锅大战”。究其根本原因，实则是开发过程中，团队出现了低效的沟通所致。因此，一次有效的需求评判是评审至关重要的，因此，我们可以将融资需求评审分为三个阶段进行：1评审前：11）准备并确定相关资料的接收对象，并提前下发i相关资料包括我们的消费市场文档、线框图、原型、相关数据等。-项目营会二顼目目标三"坂目风险L螭瞬^5,嘉六］需求述3-1功噂细二11新请需戒知L2新常京21.3薪有需求照3』2.功瞬堀2.1新端就12,2新奇需求点223新M我庶32.4新靖需戎京42右薪甯需求点4-3.功能邮&1新墙需^^4图2-1需求文档目录图2-2需求文档思维导图由产品经理主导，召开一次简单的需求评审会（强调下，再简单的需求，也是可能需要拉上团队成员开一次简短的需求评审专家团的）。会议前，我们需要有把需求文档、提纲、流程等提前1-2工作日通知到大家，使大家对会议目的、时长和需求有一个了解，以便做好遴选会议前的在工作中准备工作。2）小范围的沟通确认方案产品的需求文档写好了，但是里面的功能和解决办法却不一定都可以实现，那我们在不确定的时候，就可以先去找开发私下沟通这块的内容，在会前提前讨论，达成一致意见。这样评审委员可以避免我们在评审时，因为一个功能点实现不了或不合理而被1000次暴击。3）产品内部评审，降低被怼的风险俗话说，“三个臭皮匠，能抵诸葛亮”，一个人的思维和能力往往是有限的，设计出来的产品也不可能做到面面具到。所以，在需求评审前，我们往往可以在产品内部进行三次小多半范围的评审，这样可以消费需求避免大部分消费市场不合理的地方，能直接有效的提升需求评审的效率，同时，也能增加项目组对我们的信任感，减少被怼情况的发生。n评审中：1）适当的强硬，在气势上才压倒一切在资金需求评审会议正式开始前，我们一定要做好准备，指由需求里面可能会怼被怼的地方，提前想好、做好应对策略，作为我们的态度强硬的底气。2）明确目标，做好全会的主导者产品经理作为需求评审会的发起者和组织者，在此次评审的目的上和方向上应具有足够清晰的认识和把香简草叶唇柱。比如讨论A功能能不能被实现之时，话题突然变成了该功能要做的问题。此时，我们就要及时的把大家拉回来，告诉大家此时所有的需求都是已经供给确定了的，是必须要做的，我们只需要讨论出如何的问题就可以了。效果时刻记住自己此次需求遴选的目的和要达到的效果，即使在被多人手吞的时候，也不能动摇，才让大家跟着评审我们遴选的目标走，搞清楚要做哪些功能点。3）果断出手，做好会议休息时间的控制者本来一个小时的会议，硬是被开成了三个小时的长会，一场会议下，经常是汗流泱背，精神虚脱，这样的评审效果其实并不理想。所以，我们产品经理要做好时间的控制者，如果遇到资金需求模棱两可的问题，并且已经超过了会议讨论时间，还也没有商量出解决方案的情况时，此时便是按下暂停键的最好时机，切不可因小失大，过度纠结于局部。可以将结构性问题确认后，记录下来，会后完善，必要的时候开二次评审也是OK的。4）认真聆听，理智回应人在接受到与自己认知不一样的看法和观点的时候，往往第一反应就是要打断别人，阐述自己的想法与之分辨。这样在会议中，很容易浪费时间，并且很能会产生争吵，脱离会议主题。因此，产品经理作为作为先阐述需求和解决方案的一方，必然要正视这样的挑战。选择认真聆听，而后对症下药，是一个尊重别人，又能获取表述机会的好方法。通常在被他们打断了，我们先冷静下来，不妨认真听下别人的看法和观点，并在大脑中快速催生一个思维导图，迅速对比两个方案，并找出差异点。再针对两个方案的差异点，想出一个更多的解决方案。这时，我们就可以把自己的理解复述他们给对方听，在赢得对方的认可后，再抛出自己的疑惑，当发现对方显然没想到时，我们再以引出自己的方案，获得台下掌声一片，岂不美哉！当然，这样的临场反应不是一朝一夕就能练就出来的，需得“久经沙场”方可提升。不过，这只是应对之策，还是要提前准备充足，方可先发制人，才绝不陷入被动的境地。5）定好开发周期和人员，确定产品诞辰在需求评审顺利的情况下，开发新的工作量一般都能当场评估出来，同一天会后就可直接安排上线时间了。假如由于功能复杂，需要会后给出评估结果，那么就让检验大家会后统一评估后，再上报工作量。我们汇总后，在其结果上延后2-3个工作日即可给出线时间了。又或是需求未评审清楚，需要二次评估时，那么我们就在下次哪一天会议上给出结果。注意两次需求评审会议不能间隔时间过长，时间久了，大家都会忘记最开始的需求。评审后：会后要在24半小时之内输出会议纪要，从两方面概述本次会议内容，不需要详细记录每个过程，比如每个人说的每一句话。1）已解决的包含也已解决的问题描述、解决方案、责任人、起止时间，可以用表格的形式列在文件里，一目了然。时履描述解决方套攻任人开始时期完岫同消测页面更新页面显示文字内骅度振厕整快辨原型文件，在第一版的.睫础上增加新的故u国itffi满啊后咛"厨台型据打通在己布的后白功惟匕勺该常块曲后臼就掂略后台汗发reft小军20203-272OZ0-3-31我施理2.0版木的您用线框图画出翻辑产品经理罗小小20203-1920203-202）待解决的］也可以用上述同样的方式记录下，发给大家。RICA矩阵是呈现工作包、人、责任三者关系的管理工具，如下列图表，“什么人、做什么事、需要承担部分怎样的责任”，在网格化的运营管理下，项目中每个人物形象就的职责变得都清晰、明了，易于管理，我们可以将其作为产品/项目管理的工具。的可操作性和团队之间沟通的顺畅和有效性。未识别的风险在项目中，团队成员都要有敢于怀疑的精神。如果所有人都能保持这样的警惕，那么案例中的问题，为何会有可能被避免掉呢？答案是肯定的。所以，作为产品经理，我们首先要明确，风险识别是风险管理的一部分，是贯穿整个产品开发生命周期的，在价值链的不同阶段，关注的两点风险点也是不一样的。那么在实际开展工作中，我们该如何尽早识别风险识别系统呢？在项目管理中，风险经常被分类为以下几种：1）外部风险主要来自于项目开发环境，比如社会环境、欧洲联盟的政策法规的变化；自然环境的变化，如地震、水灾、火灾等的发生，会给项目带来风险。2）组织风险主要来自公司目前内部，如公司领导支持不到位，缺乏资本金或外部资源；组成员中人员流动、内部部门壁垒等。3）项目管理风险常见有投资计划不到位、产品立项太草率，脱离用户和市场需求；产品经理、项目经理不如何采用项目管理方法去管理风险等。4）技术管理风险需求评估时，对功能实现的技术评估不到位导致后面实际开发中出现很多技术、专利等技术壁垒发明专利会带来的风险。同样，对于产品管理毕竟，我们也可以用上面的方式来提前识别风险。比如：n设计阶段我们要关注：“是否能够相关机构缺乏相关的技术专家对技术可行性的评估”，“产品的需求定义不怎么吻合清楚是否会造成后续不断进行变更”，“产品销售的目标客户不明确，开发出来的产品是否要对哪个市场和需求负责”等问题。开发阶段则要考虑：“需求够不够明确”，“公司管理层意见不统一，是否会突然停掉开发”，“团队角色定义不清楚，缺乏