测试团队协作要成功，必须要避开这4个坑！

lsekfe

今天分享几个工作协作过程中的真实案例，每个案例中都有常见的协作问题，希望给大家带来思考。
案例1：我功劳最大，但没有被认可
案例详情：

某团队要将公司的基础组件在该业务落地实施，该团队主管安排两位QA同学跟进了该事情：小B和小D。小B是一个善于用技术解决问题、但服务意识差一些的同学，小D的技术功底弱一些，但服务意识强。

小D日常收集大家的诉求，遇到不太懂的技术问题则请教小B，然后将问题和解答进行了整理，久而久之，最后形成一篇FAQ文档，FAQ文档经过推广、运营，知道的人越来越多，最后该FAQ文档得到了团队成员的普遍好评。

因此，小D同学的影响力越来越大、正反馈越来越多。

这时小B同学有点不高兴了，开始吐槽小D，诸如：小D什么也没干，他最开始的技术基础都是我给他普及的，你们看FAQ文档里的解决方案里的图片，很多都是我的账号登录的，这说明小D同学压根没有自己解决，只是把我的截图贴进去了。

小D听到小B认为他什么也没干，也不甘心，针对小B的吐槽一一反驳，两人的矛盾愈演愈烈。

案例分析：

该案例中关于两人的分工，在主管安排工作时并没有明确，这是小B和小D两人矛盾产生的原因之一，但我认为这不是最主要的问题。工作场合中，类似不明确的事情是比较常见的，最开始不明确，但可以通过几次项目反馈，逐渐把两个人的职责、分工明确下来。

又或者，这两个人谁主动承担的更多，谁就掌握了主动，或许可以主负责整个事项。

相比较来说，小D的主动性和服务意识值得点赞，事情整体的效果也是好的。

但小D的问题是，在享受项目成果时比较自私，有很大的改进空间，比如在FAQ文档当中明确说明该文档是小B和小D的共同成果，如有问题请联系两个人。

在该事项被他人正反馈的任何场合，也应该提及这是两人共同的功劳，不属于任何一方。

这样，小B的技术付出得到了应有的尊重，以后也更愿意跟小D一起合作做更多的事情。

再来看小B，小B的做法我觉得更可惜一些，因为该事项中小B的技术能力是稀缺能力，自己就有能力沉淀FAQ文档。

虽然小D有自私的做法，但小B更应该思考，为什么自己不能把事情做得闭环、充分些呢。

从两个人的协作来看，本来可以双赢的结果，现在变成了双输，他俩的矛盾，让其他同事看到了他们的不成熟，他们彼此也产生了不可调和的矛盾。

案例2：我贡献了点子，但没有被认可

案例详情：

某团队在进行自动化建设时，同学小H和小Q在讨论技术问题时，小H提出了一个好点子，小Q很认可。

一段时间后，小Q同学基于这个点子把自动化实现进行了优化，产出了好的结果，还在较大范围内进行了分享。分享后，小H同学不是太开心。

不开心的点主要在于，小H基于自己的点子做了改造升级，分享时却没有体现出自己贡献了这个点子。

案例分析：

出现这种情况时，我倾向于认为小Q不是有意的，因为如果不是直接参与了开发、编码，很难意识到是小H提出的好点子，且要在分享的场合明确提及。

除非有人问这个点子是谁的主意，小Q也许才能意识到是小H。

当然如果小Q能够意识到小H提出了一个好点子，并在分享场合提及，我认为这是很赞的做法。

但我觉得在这件事上，小H需要改进的地方更多。

如果小H比较介意自己贡献了点子，那可以在自己贡献点子的同时间体现出来，比如写在周报里、发到群里，又或者更早实现自己的点子，并进行分享。

案例3：我参与了开发，但没有被认可

案例详情及分析

某团队在进行自动化建设时，同学小H和小Q在讨论技术问题时，小H提出了一个好点子，小Q很认可。

小Q是某事项的主R（负责人），在跟进某事项的过程中，做出了一些阶段性的成果，成果推广到相应的群时，他人给予了正向反馈，小Q回应“这是我应该做的“，还发了”为人民服务“的动图。

小Q的主管看到这一幕，立刻与小Q单聊，询问该功能都有哪些人参与了，因为主管知道该功能点是由多人协作完成的。

小Q提及另外两个小伙伴也参与了该功能的开发，主管建议在受到他人正反馈时，要特别提及共同付出的其他小伙伴的参与。

理由：作为主R，小Q没有提及协作伙伴的付出，那么小Q后续推动他人做一些事情时或许不太容易，因为他人觉得跟小Q合作只有付出没有认可。

案例4：我是主R，但感觉被忽略了

案例详情：

某专项，分配小S为主R（负责人），小S正常跟进中。组内同学小L比较主动，主动跟小S了解实现、学习技术，并询问是否可以承接某个模块的开发。

小S觉得可行，把其中一个复杂度不高的、独立的功能模块分配给了小L。

小L的功能模块很快开发完成，由于可以独立运行，小L将该功能推广给了使用方，使用方给予了高度评价。

小S心里不太舒服，因为小S觉得是我教会你技术、是我分配你一个模块，现在正反馈来了，你却没有提及我的名字。

案例分析：

小S作为主R，理应承担主R的职责，应对整件事情做好整体规划，需要把设计、开发、发布、推广考虑在内，当引入他人参与时，应该更新项目规划，并将项目规划同步给参与的同学，这样步调才能一致。

所以，小S主R的工作有明显缺位。

而小L主动性强，模块开发完成后主动做了推广，协同方给了很好的反馈，主动行为应该被点赞。

不足之处是没有提及小S的付出，这点可以加以改进。

扩展思考

”案例四“中小S和小L的情况跟”案例一“中小B和小D的情况很相似，你觉得应该如何化解小S和小L的矛盾，避免他们矛盾升级，演化为双输局面？