如何在项目管理中减少团队的启动时间

面对现实：团队的变化

在过去的几年里，我和很多团队一起工作过，有的时间很长，有的则很短。我注意到在这些团队中，都面临一个相同的问题，即团队的成员总是在变化。通常，任何项目背后的变动都会引发这样的改变：比如员工生病或者度假，项目需求增加，出现新的项目或者仅仅是员工希望能改变当前的工作。然而像每日站立会议、结对编程等这样的敏捷实践，如果没有足够的上下文场景，就无法提供给新员工以足够有用的信息。这是因为敏捷实践并不能直接提供新团队成员的学习需要。因此我建议使用其他一些实践以便有效减少新成员的“启动时间”。

将排队论（Queuing theory）应用于团队中

在制造业中，从订货到交货这段时间基本上都会分为四部分，包括：

◆启动（Setup）
产品等待进入运作（Run）阶段的耗时。
◆运作（Run）
产品从待处理阶段进入处理阶段的耗时。有时会分为处理耗时和等待耗时两个部分。
◆移动（Move）
产品转移到下一个阶段的耗时。
◆等候（Queue）
产品进入下一个启动（Setup）阶段前的所有耗时。

将相同的概念应用到团队以及团队中有新的成员加入的情况时，你就能得到如下图所示的结论：

图1

由于从订货到交货这段时间的后两部分（移动和等候时间）不会影响一个独立的项目，因此我们的关注点通常都会落到前两部分上（启动和运作时间）。对于团队的新成员来说，启动时间指的就是他能融入团队并充分发挥自己能力所花费的时间。其中，团队需要吸收并培养新人，教会他们各种技巧，直到他们可以发挥自己最大的潜力为止。为这些事情所付出的所有时间和努力，构成了启动时间。运行时间则与成员在项目中工作的效率有关。

Brook在他的《人月神话》中非常详尽地阐释了新人加入会对项目带来的影响，尤其是已经陷入困境的项目。除了新人了解项目需要花费的时间外，书中还强调了伴随更多人员的加入，会产生更多沟通的开销。提携培训新人还会进一步拖延项目的进度。用于与其他团队成员沟通的开销通常会延续在完整的项目过程中。综上所述，新员工加入由此产生的总开销可以下面的图表表示：

图2

大多数过程都致力于促进团队的通力合作，帮助降低项目运营的开销。但是它们都忽略了一件事，减少新人用于熟悉环境所需的时间——比如，新成员多快可以加入到团队中，或者团队处理成员变更的能力有多强。

敏捷实践关注运行时间，而非启动时间

“学习”对于每一种敏捷方法论都是不可分割的一部分。其中大多数都关注于短期的反馈环、进行自我反省以及强调持续改进。

但是，每个新进入项目的人在进入项目一段时间后，对学习的需求会变得大相径庭。

对于新的团队成员来说，消化信息的过程通常会带来更多的问题。像在Scrum站立会议上说的“我昨天做了……”这种话，会触发新人更多的问题，比如“他们在说什么，这与我所了解的又有什么联系呢？”结对编程的效果也会有变化，如果结对的那个新人对整个项目有个大致的了解，效果会好些；但如果只是面对一个接一个的User Story，效果就会很差，毕竟此时窥一斑而难以见全豹。我曾经见到过，当面对大量琐碎的信息碎片，也没有一条明确的线索将它们串连到一起时，很多团队的新员工都会感到很沮丧。

新人需要学习的主要内容是关于项目的概貌（larger context）。他们要找到应该了解的知识，逐步理解领域相关的词汇表，并融入团队及其文化。项目越复杂，加入的人数越多，这个阶段就需要持续更长的时间。

了解了项目的概况之后，就要学习一些更加深入的知识了。有了概况中包含的信息，其他信息就变得更容易被接受了。每日站立会议、结对编程、测试驱动开发等这些敏捷实践，它们提供的所有信息只有放在一个更大的场景中才会真正有用。前述的这些敏捷实践并不会直接关注团队新成员的不同的学习需求。你应该怎么做？答案是：应用其他特定的实践来减少新团队成员的“启动时间”。

利用“提携(onboarding)策略”减少使用时间

下面简要地列出了一些技术，在我的团队中，新员工们发现这些有助于帮助他们掌握必要的上下文场景，来理解其他敏捷实践提供的信息：

◆预备Email
在新员工加入前，给他们发一封Email，解释一下项目的背景，这样他们在正式工作前就可以先阅读一些资料，或者锻炼并学习与项目相关的技能和知识。
◆业务问题的大视野
开一个会，告诉新成员项目背后的价值以及驱动力。让他们一点点地熟悉领域相关的术语，并把他们的工作放在一个更大的上下文环境中。
◆具化架构
图表可以很好地用于将琐碎的概念放到更大的概念中。以此来将讨论聚焦在汇集知识和分析这些知识如何相互关联上面。
◆项目问题透明
坦诚地公布团队已知的需要改进的领域。要关注如何提高、并制定计划，而不是一味地看到问题有多糟糕。
◆细小的任务
将一件庞杂的工作划分为大量细小的任务，以便新的团队成员不需要很多麻烦就能理解项目团队成员正在做些什么。确保每项任务都能在相对独立的条件下完成。
◆互相学习
让角色相似的人们一同工作，来分享他们学到的新知识和任何可能对其他人有用的技巧。这类会议应该集中在技能的学习与共享上。
◆从学生到老师
尝试让新成员去帮助其他的团队成员。让新成员向其他的团队成员解释概念，这样既能巩固他们所学的知识，又能提高他们的思考方法。
◆尊重个人的差异
让学习的过程适合每个人。使用图表、文档、CRC卡或者任何事物，帮助他们更好地构建出项目的整体图景来。
◆放手一搏
给予每个成员以足够的空间，让他们在一个安全的环境里犯错。有些教训如果是自己学习的，印象将更加深刻。

团队成员在不同项目间轮换不再困难

敏捷实践强烈推崇“学习”，但是它们只关注减少“运行时间”，而非“启动时间”，因此对于团队的新成员来说，敏捷并不是非常有效。理解了新成员对学习的不同需求后，就可以使用一些特定的“提携策略”，直接解决问题。然后采用其他实践持续减少“启动时间”。

大多人在加入新公司时都会经历一些入职的程序。你在项目使用的那一套有多有效呢？

【相关文章】

• 程序员如何正确处理遗留代码

• 如何解决敏捷开发中的用人不当问题

• 敏捷开发中常见的九大误解