51Testing软件测试论坛
标题:
协作问题与分析
[打印本页]
作者:
lsekfe
时间:
2024-5-24 10:52
标题:
协作问题与分析
今天分享几个工作协作过程中的
真实案例
,每个案例中都有常见的协作问题,希望给大家带来思考。
案例一:我功劳最大,但没有被认可
某团队要将公司的基础组件在该业务落地实施,该团队主管安排两位
QA
同学跟进了该事情:小
B
和小
D
。小
B
是一个善于用技术解决问题、但服务意识差一些的同学,小
D
的技术功底弱一些,但服务意识强。
小
D
日常收集大家的诉求,遇到不太懂的技术问题则请教小
B
,然后将问题和解答进行了整理,久而久之,最后形成一篇
FAQ
文档,
FAQ
文档经过推广、运营,知道的人越来越多,最后该
FAQ
文档得到了团队成员的普遍好评。因此,小
D
同学的影响力越来越大、正反馈越来越多。这时小
B
同学有点不高兴了,开始吐槽小
D
,诸如:小
D
什么也没干,他最开始的技术基础都是我给他普及的,你们看
FAQ
文档里的解决方案里的图片,很多都是我的账号登录的,这说明小
D
同学压根没有自己解决,只是把我的截图贴进去了。小
D
听到小
B
认为他什么也没干,也不甘心,针对小
B
的吐槽一一反驳,两人的矛盾愈演愈烈。
案例分析:
该案例中关于两人的分工,在主管安排工作时并没有明确,这是小
B
和小
D
两人矛盾产生的原因之一,但我认为这不是最主要的问题。工作场合中,类似不明确的事情是比较常见的,最开始不明确,但可以通过几次项目反馈,逐渐把两个人的职责、分工明确下来。
又或者,这两个人
谁主动承担的更多,谁就掌握了主动,或许可以主
R
整个事项。
相比较来说,小
D
的主动性和服务意识值得点赞,事情整体的效果也是好的。但小
D
的问题是,在享受项目成果时比较自私,有很大的改进空间,比如在
FAQ
文档当中明确说明该文档是小
B
和小
D
的共同成果,如有问题请联系两个人。在该事项被他人正反馈的任何场合,也应该提及这是两人共同的功劳,不属于任何一方。这样,小
B
的技术付出得到了应有的尊重,以后也更愿意跟小
D
一起合作做更多的事情。
再来看小
B
,小
B
的做法我觉得更可惜一些,因为该事项中小
B
的技术能力是稀缺能力,自己就有能力沉淀
FAQ
文档。虽然小
D
有自私的做法,
但小
B
更应该思考,为什么自己不能把事情做得闭环、充分些呢。
从两个人的协作来看,本来可以双赢的结果,现在变成了双输,
他俩的矛盾,让其他同事看到了他们的不成熟,他们彼此也产生了不可调和的矛盾。
案例二:我贡献了点子,但没有被认可
某团队在进行自动化建设时,同学小
H
和小
Q
在讨论技术问题时,小
H
提出了一个好点子,小
Q
很认可。一段时间后,小
Q
同学基于这个点子把自动化实现进行了优化,产出了好的结果,还在较大范围内进行了分享。分享后,小
H
同学不是太开心。不开心的点主要在于,小
H
基于自己的点子做了改造升级,分享时却没有体现出自己贡献了这个点子。
案例
分析:
出现这种情况时,我倾向于认为小
Q
不是有意的,因为如果不是直接参与了开发、编码,很难意识到是小
H
提出的好点子,且要在分享的场合明确提及。除非有人问这个点子是谁的主意,小
Q
也许才能意识到是小
H
。
当然如果小
Q
能够意识到小
H
提出了一个好点子,并在分享场合提及,我认为这是很赞的做法。但我觉得在这件事上,小
H
需要改进的地方更多。
如果小
H
比较介意自己贡献了点子,那可以在自己贡献点子的同时间体现出来,比如写在周报里、发到群里,又或者更早实现自己的点子,并进行分享。
案例三:我参与了开发,但没有被认可
小
Q
是某事项的主
R
(负责人),在跟进某事项的过程中,做出了一些阶段性的成果,成果推广到相应的群时,他人给予了正向反馈,小
Q
回应
“
这是我应该做的
“
,还发了
”
为人民服务
“
的动图。
小
Q
的主管看到这一幕,立刻与小
Q
单聊,询问该功能都有哪些人参与了,因为主管知道该功能点是由多人协作完成的。小
Q
提及另外两个小伙伴也参与了该功能的开发,
主管建议在受到他人正反馈时,要特别提及共同付出的其他小伙伴的参与。
理由:作为主
R
,小
Q
没有提及协作伙伴的付出,那么小
Q
后续推动他人做一些事情时或许不太容易,因为他人觉得跟小
Q
合作只有付出没有认可。
案例四:我是主
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
的矛盾,避免他们矛盾升级,演化为双输局面?
作者:
岳妙慧
时间:
2024-6-4 04:23
欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)
Powered by Discuz! X3.2