鼓励团队沟通的最佳方式是什么?

时间:2009-01-21 12:34:35

标签: agile

我在一个中等规模的团队(20多名开发人员)工作,我相信团队成员之间的沟通并不尽如人意。

与大多数团队一样,我想,我们有几个系统可以构建和维护。我们还在工作中使用了许多不同的工具,如Visual Studio 2008,Subversion,Resharper,Tibco,TeamCity等。

我们也使用“敏捷”方法进行开发......我把它放在引号中,因为它看起来更像是“急于尽快获得此功能......我们将在一周左右为您制定规范。 ..现在就开始研究它,但一定要对它进行单元测试,然后由某人“。

对其进行审查

正因为如此,我们的系统设计很差,因而难以维护....所以我们最终会有一些人作为“大师”,他们非常熟悉他们创建的系统。

此外,由于整个IT行业的步伐,我们经常需要使用新技术和我们开发的最新版本的工具。

我的观点是不要抱怨并说“噢,我的事情很困难”......而我的担忧是,除非我们的团队开始更好地沟通,否则我们将继续陷入这种困境。

让我尝试通过更好的沟通来解释我的意思....

最近我们刚刚从VS2005升级到VS2008 ......这在我看来很棒,因为我喜欢使用最新的技术。我们也从CruiseControl.Net转移到TeamCity ......这一切都很好。

...但....我们从未真正接受过VS2008或C#3.0的新功能的任何培训......甚至没有关于TeamCity的备忘录...作为IT人员,我们似乎有望适应和我们去学习。

现在很明显我可以通过阅读博客和关于我使用的工具的最新消息来找到这些信息......我做了......但是,持续学习的实践并没有真正实现团队,所以你最终会得到使用新功能的人,而不是真正了解它们......

此外,我们的团队最近已被指示开始进行代码审查......但没有任何关于这意味着什么的指导....目前它只是意味着将代码交给某人......任何人......在团队中,让他们看看你的代码......无论是两秒还是两个小时,它在整个团队中都没有真正建立或统一......如果他们甚至完成了......

编写单元测试的情况也是如此......我们一直鼓励他们编写它们......但它并没有在团队范围内进行沟通,编写它们的最佳方式是......所以一些开发人员试图写他们觉得很困难,要么编写糟糕的单元测试,要么放弃并决定单元测试是一个坏主意......

我提出的帮助改善情况的想法是组织一系列会议作为开发者论坛......在这些会议中,团队成员将提出一个不同的主题,其余的时间用于开发商之间的讨论。

这一主题可能是C#的一个高级新功能以及围绕它的推荐最佳实践....下一个可能是关于代码评论和寻找什么......而下一个可能是介绍一个不起眼的遗留系统......然后开发人员可以使用讨论来分享他们的经验和问题。最终目标是在开发人员之间自由分享想法和信息。

我得到了我的经理和我的几位开发人员的支持以获得一些信息......但我被告知这样的想法之前已经尝试过并最终消失。

我希望这个想法能够取得成功,而不是在我最终离开这家公司的时候,我将自己全力以赴地把它弄死。

我怎样才能鼓励我的团队更好地沟通?我对开发者论坛的想法听起来像个好主意吗?我该怎么做才能防止它消失?

我有什么比这更好的事情,而不是我在想什么?

不仅仅是开始一系列会议......我如何鼓励和影响我的团队开始团队表演?我真的很喜欢我的工作,并且相信我正在与一群优秀的开发人员合作......但我也非常希望在一个我认为目前有点缺乏的领域为团队增值。我该如何有效地做到这一点?

8 个答案:

答案 0 :(得分:6)

团队精神很难逼迫。大多数让人们一起工作的尝试更好地适得其反。它需要得到培育和发展。

与一系列会议相比,团队午餐(在公司上)每个月大约一次。非正式的东西,不会影响工作时间。没有什么正式的,但人们有机会互相交谈和“联系”。如果人们能够,晚上喝几杯或打牌可以提供帮助。重要的是它是自愿的和非正式的。

结对编程可以帮助传递知识,帮助人们相互了解和理解,因此可能值得考虑。

然而,贵公司的管理风格似乎不利于事情。

  

“赶紧尽快获得这个功能...我们将在一周左右的时间内为您制定规范......现在就开始研究它,但一定要对它进行单元测试,然后由某人审查代码”

这让事情在空中留下了很多。有人读过开发团队应该做的事情,但是不愿意把时间(也就是钱)用来做正确的事情。这将使开发人员被剥夺权利和动力,这会伤害团队。

答案 1 :(得分:4)

很难给出明确的答案..除了尝试某些事情并希望其中一些坚持

避免使用本地知识岛 - PairProgramming可能会有效。如果A在X具有某些专业知识或时钟时间的区域内注册任务,他可以要求X与他配对。实施任务的过程在X的脑海中传播,是一个实时的代码审查,有助于提高平均团队技能/专业知识/代码熟悉程度。它还鼓励人们互相交谈,而不是钻孔。

技术发展的动态步伐 - 生活事实......需要习惯它。使用开发者论坛,午餐盒论坛,Brown Bag Sessions,Wiki,Book Clubs,在线论坛等都可以使用。取决于团队中的个人选择什么作为他们的首选摄取方式。反馈工作......如果团队认为他们从开发者论坛中受益,他们就会支持它。如果它消失了,想想它为什么不坚持......尝试其他经验教训......

Slack - 一个经常被遗漏的方面。确保人们有时间帮助某人......而不是在最后期限之后一直奔跑。

创造一个鼓励和促进人们说出来的环境......帮助别人......然后让个人凝聚在一起。 祝你好运。

答案 2 :(得分:4)

听起来我的团队缺少技术主管。

此人将接受管理层的指导,并将其转换为团队其他成员可以使用的实际步骤。

例如:

  1. 您提到您在团队中使用了大量产品,有时更新这些产品时没有给团队注意或培训。
    技术主管将记录产品以及如何使用它们,理想情况是在维基上,以便其他人可以贡献,并且有新产品的经验,这样他们就可以在需要时帮助任何人。
    技术主管还将提供有关如何使用新产品的指导,无论是电子邮件,文档,维基文章等。

  2. 在与管理层,高级开发人员等会面后,此人将就如何进行代码审查提供指导。

  3. 对于任何新的发展或主要功能要求,技术主管将参与设计,因此将进行同行评审,知识将在团队中传播。

  4. 所有这一切的关键是让每个人的工作更轻松,更高效。 可能很清楚这个人是谁,因为他们将成为最受尊敬的成员,每个人在撞墙时都会去。 需要给这个人一些时间来履行这个职责。

    不幸的是,如果那不是你,那么你可能不会说服人们改变他们的工作方式。

    此外,每月一次非正式午餐,足球或其他任何团队成员可以非正式地结合的午餐,都会有很大帮助。

答案 3 :(得分:2)

也许你关心的不是沟通,而是更多关于队友的动机。在像编程这样的知识领域,动机必须来自实践者。没有它,就很难走得太远。如果是这种情况,你需要转移到另一个地方。

答案 4 :(得分:1)

第一件事是通过将团队移动到同一个位置来打破所有物理墙壁,可以将每个人安置在同一个房间。

其次,开始使用发布计划会议。也就是说,您的团队与客户一致,估计需要为即将发布的版本开发的每个故事。我将改善团队成员之间的沟通,因为他们一起讨论技术问题和解决问题。他们正在进行评估,如果做得正确,将导致就估算和设计方法达成共识。通过迭代计划会议,对每次迭代(一周迭代最好)进行跟进,以跟进发布计划。这是团队将每个故事分解为计划实施此迭代的许多小任务的地方。

第三,开始使用结对编程。不要强迫它,但强烈鼓励它。此外,请确保配对仅在一天左右配对。即旋转对。这构建了集体代码所有权和团队精神,因为它是“我们的代码”而不是“他的代码”。

哦,最后:学会总是谈论“我们”和“团队”。永远不要指责。

答案 5 :(得分:1)

您如何鼓励您的同事更好地沟通?以身作则。

在我的公司,我们经常使用“驱动某些东西”这个词。有人需要驱动一个项目,需要开展测试等。这意味着承担这项任务的责任并积极地进行。不要只希望你的同事分享信息,告诉他们该做什么以及如何做。

当您发现有关VS2008的一些不错的新细节时,请与它们分享。但要专业。不要只告诉两个你今天晚些时候喝咖啡的人,准备一份描述你的发现的小型演示文稿或文件,并将其传达给所有团队成员。 我绝对宁愿给出一个简短的演示文稿,而不仅仅是发送电子邮件,但这可能是不可能的。

您可以参加定期的信息交流会议,但我认为您在日常工作中保持同样的态度至关重要。不要只是这样做,活着。

(哦,我的,我听起来像是一个愚蠢的过度支付的动机教练!好吧,也许他们是对的,应该得到所有的钱; - )

答案 6 :(得分:1)

  • Colocate 即可。同一个房间里的每个人都鼓励自我组织(通过无意中听到的谈话。然而,你必须将干扰考虑在你的估计中。
  • Ban Instant Messaging / IRC 除了最小的东西外。或者一起。你不会受欢迎(我也不喜欢它),但它会迫使人们在公开场合开始交流,并打破派系。
  • 定期,快速,专注的技术会议。每日站立就是一个很好的例子。

答案 7 :(得分:1)

总会有人分享你的激情并加入你。也会有9到5人的开发人员。没有什么可以做的。

如果你有管理层买入,那么就用它来运行。管理层买入是我认为最难的。希望随着其他人加入你的行列,剩下的就会出现问题。祝你好运!