建立成功团队idp_如何建立快乐的团队-CSDN博客

建立成功团队idp

作为开发人员，我们花费大量时间来优化我们开发的软件。无论是代码性能，服务可用性还是用户体验，使事情变得更好都是当务之急。但是，我们很少考虑让编写软件的人员感到高兴也可以对我们的软件质量产生积极影响。

在过去的四年中，在远程团队工作过，我对团队之间如何交流和合作感到特别感兴趣。拥有一支高产的远程团队并不容易，并且有很多选择要考虑。最近，我在柏林Codemotion世界发表了一个演讲，总结了我的一些经验。我将在这里与您分享要点，而我的幻灯片也可以在本文末尾找到。

为什么快乐的团队很重要？

首先，更快乐的人更有生产力也就不足为奇了。我们提供测试覆盖率和正常运行时间报告，以衡量软件的性能。但是，有一种简单的方法可以量化幸福吗？

华威大学的一些研究人员试图提出一个所谓的“幸福方程式”。哈佛大学的研究人员创建了一个应用程序，恰当地称为“ 追踪您的幸福” ，以试图量化与幸福有关的原因和条件。这两项研究的结果都有一些共同点。

通常，当人们没有时间压力，没有被打扰并且对正在执行的任务有自主权时，他们会感到最快乐。牢记幸福的三大Struts，我们可以对开发团队的运作方式进行一些更改，以使开发人员感到满意，从而提高生产力。

制定团队沟通流程

对于所有类型的团队来说，使用Slack之类的交流平台是很常见的，即使他们位于同一物理办公室中。 Slack有点新潮，因此请务必评估它对您的团队有多重要。

非常重要的是，所有沟通都必须有一个流程，以及明确定义的期望。如果开发人员正在从多个渠道获得通信，则可能是一个巨大的中断，并且势不可挡。取而代之的是，将所有传入的通信都集中到一个集中的任务管理器，无论是Tracker，Jira，ZenDesk以获得支持等。这使得管理需要关注的内容变得更加容易，并且比单独检查Twitter，电子邮件，GitHub和Slack所造成的破坏更少。

此外，如果您打算聘用远程员工，则必须保持所有团队沟通的持久性。任务管理器非常适合此操作，因为它允许通信记录持久且可搜索。如果另一个工程师对与某个功能相关的业务逻辑有疑问，那么通读Tracker凭单上的对话要比联系个人尝试将决策逻辑拼凑起来要容易得多。

使您的会议持久

“这次会议本可以是一封电子邮件，”曾经去过无意义的会议的每个人都说。

会议是破坏性的且昂贵的—不需要时。当一个复杂的话题需要大量讨论时，必要的会议可能会非常有成果。但是，让工程师离开他们的工作去参加有关项目状态或信息发布的会议可能会令人难以置信。

首先，会议期间进行的讨论不是持久性的，很难将会议的讨论和结果传达给不在场的人。持久的沟通对于高效的远程团队至关重要。

如果需要召开会议，则可以通过录制会议或键入会议记录（例如我们在1970年代！）来使其保持持久性。一个好的会议选择是Google Doc。每个人都可以阅读和评论，所有的交流都记录在文档中。在Codeship，我们从人力资源讨论到规划工程冲刺都使用Google文档。

考虑软件架构如何影响团队组织

“受制于哪些设计系统的组织才能生成设计，这些设计是这些组织的沟通结构的副本。” 著名计算机科学家梅尔文·康威（ Melvin Conway）这样说，他现在被称为康威定律。用更明确的术语来说，康韦定律指出，任何软件都可以反映出产生该软件的组织结构。

如果您要求三个团队使用一个软件，那么最终可能会包含三个组件。同样，如果您要求一个统一的团队使用三个软件，则该团队将自动分成较小的团队。想象一下，如果您邀请25人组成的团队来设计汽车。 25个人都不可能坐在一个房间里去做各个部分。取而代之的是，有些人将在引擎上工作，有些人将在内部的用户控件上工作，而有些则在安全功能上。人们可以自我组织成较小的单位，以便在流程上享有自主权。

通过这种模式，我们可以考虑软件体系结构如何影响团队的组织方式。如果您从一开始就将应用程序设计为具有单独的组件（即使该划分是简单的事情，例如带有Go API的React前端），则可以允许工程团队在其工具和流程上拥有更大的自治权。他们可以更好地指示如何花费时间，如何组织工作流，以及定义自己的部署周期。

密切关注软件体系结构将影响开发团队的自主权，并因此影响这些团队的生产力。