对团队中“这是某某某的问题”引起的思考

在团队中。我有时会听到这种话:这是某某某的问题。不是我的问题。

说这句话的时候,他至少忘记了他是团队中的一员。另外,也让我感认为。这个团队肯定出了问题。

我刚入行的时候从一件事開始就对这种话感到非常反感。事情是这种:

当时一个项目上碰到了一个问题,数据保存到NOR FLASH时有时会出问题,在模拟器上没有这个问题,

可是一到真机上执行时就莫名其妙的出问题,老是出现偶尔保存不了数据。

于是,请一个当时管该模块的技术大牛来解决这个问题,可是因为是非必现问题,自己复现之后请他过来一起查时,却没法再复现。

这样重复定位了几次后,他变得越来越不耐烦。最后他最终爆发了。对我大声的训斥,说根本就没有问题。

可是,问题不会由于他说没有问题就会没问题了,问题依旧存在。几天后我最终定位到了问题之所在:原来有另外一个线程会定时的往同一个NOR FALSH地址写数据,而写的操作没有相互排斥。而出现故障的代码正是他写的。

这是我在当时和后来总结出来的教训:

1)永远不要说这不是你的问题,由于对于有些问题。不是一时半会就能够分析定位到究竟是哪里出了问题,你说这句话可能会对问题的解决带来麻烦。

2)假设项目中出了问题。即便不是你的问题,也要积极协助查找。至少要又一次排除一下是否是自己代码中出的问题。

3)对于某些比較难的问题,特别是非必现的问题,要保持有足够的耐心。

4)请不要让团队中其他人独自的分析定位清楚了是你的问题了再去解决这个问题,相信到那个时候你也会非常尴尬。

5)当别人有疑问时。请积极配合。

6)假设你自觉得是一个牛人,那么请不要自负。

你的光环或许能够照射别人,却也可能因你的言词伤害到自己的朋友和同事。

7)假设确实自己做错了。要懂得道歉!

说声对不起。别人再说声没关系,事情可能也就过了,要不然可能会为今后同事之间的合作和相处带来障碍,这影响的可不仅仅是你,而是整个团队。

我也没看过什么长篇大论,这仅仅是自己的经验之谈。之所以分享出来是由于从自己的经历来看总有些人连主要的团队的合作方法都不懂。要记住的是:

假设项目中出了问题,一定是项目组中全部成员的问题!!

搞測试的要重现问题,问题解决后要确定问题攻克了没有。写代码的要积极查找分析定位问题的解决办法,即使问题不是挂在你头上。也要积极排查是不是自己的模块出了问题,以配合问题的尽快解决,以免对项目造成影响。

好,写一句话作为文章的结尾:作为团队中的一员,我认为还是有必要遵守一下小学生守则:团结,友爱。互助。

哦。我自己加一个,还要懂得感激。

(完)

时间: 2024-11-07 13:05:19

对团队中“这是某某某的问题”引起的思考的相关文章

git入门(4)团队中git保管代码常用操作

在团队中协作代码时候,一定要熟练使用以下git命令,不至于把代码库弄乱, PS:一定要提交自己代码(git push)时候,先进行更新本地代码库(git pull),不然提交异常 git常用命令 1·.clone相应项目 git clone ... 举个栗子(只是个栗子) git clone https://github.com/saucxs/watermark.git 2.新建分支并且切换到这个分支 git checkout -b 分支名(英文名) git chenckout -b dialy

在团队中如何带领新手——阅读有感

目标 通过引导.任务分配和沟通反馈等方式,让他逐步适应团队正常工作面临的压力.节奏和不确定性.对于一些心理预期过高的领导者,在此阶段应该明白,对于一个新手,还暂时谈不上能力判断和机会给予. 方式 创造良好的工作气氛:信任是第一位的.只有相互信任,才能把工作放手交给新手去做:另一方面,在他们失败的时候依然要给予信任,否则,所有的事情结束点就是“失败”.一个人所取得经验,最大的来源就是失败.良好的工作气氛,也包括各种非正式的交流与沟通,比如聚餐.聚会等等. 定期反馈:可以在每日.每周对新手的工作进行

敏捷团队中测试人员的角色

Karen Greaves和Sam Laing将会在Agile Testing Days 2015上发表主旨演讲,演讲题目为"测试人员正在消亡",Agile Testing Days 2015将于11月9日至12日德国Potsdam举行.小编将会覆盖本次会议报道. 小编对二人进行了采访,关于敏捷是如何影响测试人员角色的,为了缩短测试交付周期,测试人员可以采取哪些措施,敏捷团队中测试人员与其他团队成员之间的协作,敏捷团队中测试人员可以贡献的价值. 小编:我的经验是,敏捷更广泛的普及率正在

ReThought (二): 如何照顾团队中的新人

当我们在说照顾的时候,我们实际上是在给新人减压.当我们在说容忍犯错的时候,我们实际上说你可以犯一两个错误.减压更像是在塑造一种更好的学习体验,或者说更愉快地学习方式. 学习与构建系统 学校的时候,学习倾向于理论性的学习. 工作的时候,学习倾向于应用性的学习. 两种不同方式有着不同的区别,即一个广度,一个深度. 在构建系统的时候,通常我们需要一个基本能工作的系统,其次在系统不断开发的过程中.我们对于深度了解的需求已经变得比广度更为重要. 故而,在一个以产品为主的开发团队中,在早期他们更需要那些有广

测试人员在敏捷团队中扮演的角色

对于开发模式,现在大部分互联网公司都完成了从传统瀑布开发模式到敏捷开发模式的转型,这种转型相对传统的测试人员来说,不论是在角色定位还是在技能栈方面都提出了更大的挑战,那么测试人员应该如何应对呢?下面根据我平时工作的一些总结体会来说说测试人员应该发力的方向,供大家参考: 角色 1: 培训人员 在转型初期,测试人员应该针对开发人员的薄弱环节(即业务技能)进行培训和指导.由于工作任务的差别,开发人员对负责的模块业务和具体实现细节非常了解,但是对周边模块或者业务并不是非常清楚,主要体现在配置和使用方面.

研发团队中引入变化的思路和模式

过程改进是研发管理的本质性工作,如果过程要改进通常意味着我们要引入变化,尤其对当前研发管理工作和流程尚不规范和完善的团队而言,引入变化是必须走的一步.但个人在实践过程中体会到引入变化有时候是一项非常有挑战的事情,如果把握不好可能反而会起到反作用.本文从研发团队如何有效的引入变化的角度出发,对思路和模式进行探讨. 关于团队引入变化,业界也有一些主流方法论,其中受Mary Lynn Manns和Linda Rising两位博士的著作<Fearless Change: Patterns for Int

项目团队中4种组员类型的相应管理方式

在我们的实际软件项目中,管理团队其实比写代码或者实现一个客户的需求更为的有挑战性.因为编程实际上是和机器打交道,而和机器打交道,只要你符合机器预定的逻辑, 一步步迈向解决问题的道路上一点都不难,但是人确实动态变化的,因为人时时刻刻受到各种外部因素的影响.总之,我们可以把组内的人分成四种类型: 1.有意愿有能力 2.有意愿无能力 3.无意愿有能力 4.无意愿无能力 那么对这四种类型的团队成员如何进行管理呢? 1.对于第1种人,授权,充分的授权.比如让其协助管理团队里面的一些事情. 2.对于第2种人

互联网产品团队中Web前端工程师的重要性

国内外各大互联网公司,都有UEx/d|UCD|CDC(Customer Research & User Experience Design Center)团队. 在很多公司会认为,合格的产品经理应该具备技术能力.从另一些角度思考,是否技术人员也需要拥有产品策划能力或设计能力?技术思维与产品思维是相辅相成.缺一不可的.高超娴熟的编码技巧支撑项目快速落地.但拥有了产品的角色之后,能让我们站在更高的角度去解读产品,避免走弯路. 打住,我思考的还不是这些高大上的主题,只是实实在在的前端编码解决方案. 好

团队中的代码审查

代码审查在软件项目管理中是经常组织的活动,通过代码审查的工作也确实给我们的团队带来很多的益处,简单谈谈代码审查的感受,你们的团队是否也在进行代码审查的相关工作呢? 1.为什么要组织代码审查 组织代码审查其主要目的是保障我们的代码质量和软件产品质量,其次是团队的学习提高,共同的成长.可以是两个方面的驱动,外在现实中的工作痛点和团队内在战斗力提高的驱动. (1).实际工作中的痛点:<1>.团队开发的软件质量越来越差,Bug居高不下,问题层出不穷:<2>.团队的代码实现对应的业务功能,但