代码之家  ›  专栏  ›  技术社区  ›  mezoid

鼓励团队沟通的最佳方式是什么?[关闭]

  •  7
  • mezoid  · 技术社区  · 16 年前

    我在一个中等规模的团队(20多名开发人员)工作,我认为团队成员之间的沟通没有达到应有的水平。

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

    我们还使用“敏捷”方法进行开发。..我把它放在引号里,因为它看起来更像是“尽快获得这个功能……我们大约一周后就会为你提供规范……现在就开始工作,但一定要对它进行单元测试,并让别人审查它的代码”。

    因此,我们的系统设计不佳,因此难以维护。…所以我们最终会有少数人成为“大师”,他们非常熟悉他们创建的系统。

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

    我的观点不是抱怨和说“哦,天哪,我的事情很难”。…相反,我担心的是,除非我们的团队开始更好地沟通,否则我们将陷入这种僵局。

    让我试着更好地解释一下我的意思。...

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

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

    现在很明显,我可以通过阅读博客和关注我使用的工具的最新消息来找到这些信息。..我确实这么认为……但团队中的每个人都没有真正实践持续学习的做法,所以你最终会发现人们在没有真正理解的情况下使用新功能。..

    此外,我们的团队最近接到指示,开始进行代码审查。..但没有任何关于这到底意味着什么的指导。…目前,这只是意味着将你的代码交给某人。团队中的任何人,让他们看看你的代码。..无论是两秒钟还是两个小时,它在整个团队中都没有得到很好的确立或统一。…如果他们真的在做。..

    编写单元测试也是如此。…我们被鼓励写它们。..但整个团队并没有真正沟通编写它们的最佳方式是什么……所以一些开发人员试图编写它们,发现很困难,要么编写糟糕的单元测试,要么放弃并决定单元测试是一个坏主意。..

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

    一周的主题可能是C#的一个高级新功能和围绕它的推荐最佳实践……下一周可能是关于代码审查和寻找什么。..而下一个可能是介绍一个鲜为人知的遗留系统。……然后,开发人员可以使用讨论来分享他们的经验和问题。最终的目标是建立一个开发者可以自由分享想法和信息的地方。

    我得到了我的经理和几位开发人员的支持,以推动事情的发展。..但有人告诉我,这样的想法以前也有人尝试过,但最终都消失了。

    我希望这个想法能够成功,而不是当我最终离开这家公司时,我会独自推动它,直到它消亡。

    那么,我如何鼓励我的团队更好地沟通呢?我对开发者论坛的想法听起来是个好主意吗?我该怎么做才能防止它灭绝?

    有没有更好的事情是我可以做的,而不是我没有考虑的?

    不仅仅是开始一系列会议。…我如何鼓励和影响我的团队开始作为一个团队表演?我真的很喜欢我的工作,相信我和一群优秀的开发人员一起工作。..但我也真的想在我认为目前有点缺乏的领域为球队增加价值。我如何有效地做到这一点?

    8 回复  |  直到 13 年前
        1
  •  6
  •   Jeremy French    16 年前

    团队精神很难强迫。大多数试图让人们更好地合作的尝试都会适得其反。它需要被培育和成长。

    与其开一系列会议,不如每个月左右举行一次团队午餐会(关于公司)。这是一种非正式的活动,不会影响任何工作时间。没有什么正式的,只是人们相互交谈和“联系”的机会。如果人们有能力,晚上喝几杯酒或打牌会有所帮助。重要的是,这是自愿和非正式的。

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

    然而,贵公司的管理风格似乎与事情背道而驰。

    “尽快获得此功能……我们将在大约一周内为您提供规范……现在就开始工作,但一定要对其进行单元测试,并让别人对其代码进行审查”。

    这让事情悬而未决。有人读过开发团队应该做的事情,但不愿意花时间(也就是金钱)把事情做好。这将使开发人员失去权利和动力,从而损害团队。

        2
  •  4
  •   Bravax    16 年前

    在我看来,你的团队似乎缺少了一位技术负责人。

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

    例如:

    1. 你提到你在团队中使用了许多产品,有时在没有向团队提供笔记或培训的情况下更新这些产品。
      技术负责人将记录产品及其使用方法,最好是在维基上,这样其他人就可以做出贡献,并且对新产品有经验,这样他们就可以在需要时帮助任何人。
      技术负责人还将提供如何使用新产品的指导,无论是电子邮件、文档、维基文章等。

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

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

    所有这一切的关键是让每个人的工作更轻松、更有效率。 这个人可能很清楚是谁,因为他们将是最受尊敬的成员,每个人碰到墙都会去谁那里。 这个人需要一些时间来扮演这个角色。

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

    此外,每月吃一次非正式的午餐、踢足球或其他任何可以让团队成员非正式地建立联系的活动都有极大的帮助。

        3
  •  4
  •   Gishu    16 年前

    很难给出确切的答案。除了尝试一些东西,并希望其中一些能坚持下去

    避开当地的知识孤岛 - PairProgramming 如果A在X有一些专业知识或时钟时间的领域注册了一个任务,他可以让X和他配对。执行任务的过程在X的脑海中传播了东西,是一个实时的代码审查,有助于提高团队的平均技能/专业知识/代码熟悉度。它还鼓励人们互相交谈,而不是躲起来。。

    技术演进的动态步伐 -生活的真相。..需要习惯它。使用开发者论坛、午餐盒论坛、棕色包会议、维基、读书俱乐部、在线论坛等可能会奏效。这取决于你团队中的个人选择什么作为他们首选的摄入方式。处理反馈。..如果团队觉得他们从开发者论坛中受益,他们会坚持下去。如果它消失了,想想为什么它没有坚持下去。用学到的经验尝试其他事情。。

    松弛 -一个经常被忽略的方面。确保人们有时间帮助别人。不总是落后于最后期限。

    创造一个鼓励和促进人们发声的环境。.帮助别人。然后让个体将其凝胶在一起。 祝你好运。

        4
  •  2
  •   G S    14 年前

    也许你关心的不是沟通,而是队友的动力。在像编程这样的知识领域,动机必须来自从业者的内心。没有它,很难走得太远。如果是这样的话,你需要搬到另一个地方。

        5
  •  1
  •   Martin Wickman    16 年前

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

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

    第三,开始使用结对编程。不要勉强,但要大力鼓励。此外,确保配对时间仅为一天左右。让我们轮流配对。这建立了集体代码所有权和团队精神,因为这是“我们的代码”,而不是“他的代码”。

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

        6
  •  1
  •   Treb    16 年前

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

    在我公司,我们经常用“开车”这个词。有人需要推动一个项目,需要推动测试等。这意味着要承担起这项任务的责任,并积极追求。不要只期望你的同事分享信息,向他们展示该做什么以及如何做。

    当你发现VS2008的一些新细节时,请与他们分享。但要专业。不要只是告诉今天晚些时候和你一起喝咖啡的两个人,准备一份小演示文稿或文字文档来描述你的发现,并将其传达给所有团队成员。 我当然更愿意做一个简短的演示,而不是仅仅给他们发一封电子邮件,但这可能是不可能的。

    你可以把它融入到定期的信息交流会议中,但我认为在日常工作中保持同样的态度至关重要。不要只是这样做,要活下去。

    (哦,天哪,我听起来像是那些愚蠢的高薪激励教练之一!好吧,也许他们是对的,应该得到所有的钱;-)

        7
  •  1
  •   jamesh    16 年前
    • 驻扎在同一地点 .同一个房间里的每个人都鼓励自我组织(通过无意中听到的对话)。但是,你必须将干扰因素纳入你的估计中。
    • 禁止即时通讯/IRC 除了最小的东西。或者全部在一起。你不会受欢迎(我也不喜欢),但这会迫使人们开始公开交流,打破派系。
    • 定期、快速、专注地举行技术会议。 每日站立就是一个很好的例子。
        8
  •  1
  •   Chuck Conway    16 年前

    总会有人分享你的激情并加入你。也总会有9到5岁的开发人员。对此无能为力。

    如果你有管理层的支持,那就跟着它跑。我认为管理层的参与是最难的。希望当其他人加入你的行列时,其他人也会加入进来。祝你好运

    推荐文章