当晨会无法成为晨会，我们还要坚持晨会吗？

（原标题：当晨会无法成为晨会，我们还要坚持晨会吗？）

编者按：本文作者 Sarah Mei 是 railsbridge 的创始人、Ruby Central 董事和 devmyndsoftware 首席顾问。本文介绍 Ahile 方法（敏捷方法，也被称为轻量级方法，是一组开发方法的统称。）和站立会议的替代方式。

多数 Ahile 方法（以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发）都是行动清单，其中很少或者几乎没有谈到为什么执行这些行动。它们提供的是一张干干净净的待办事项清单和一个宣言：如果你核对了所有复选框， 你就会 “找到正确的 Ahile 方法”。

这样的一揽子交易甚至还受到著名软件技术人员的推崇。我们要质疑谁呢？结果就是，团队连背后动机都没有想过，就投身于一系列的行动。这就引出了许多本质性的讨论：

Q：“我们为什么要这么做？”

A：“因为这是 scrum（一种迭代式增量软件开发过程，通常用于敏捷软件开发。）的一部分。”

这样的回答不仅不会令人满意，还会衍生挫败感。

现实世界中，大家都想成为高效团队的一员，编写一流软件。Ahile 方法的一揽子交易给这些提供了保障。

采取一系列行动来提升团队运作效率的问题在于，团队是由多名具有着不同背景的个人组成的。一套既定的行动可能在一个团队中进行得很顺利，而在另一个团队中则可能很糟糕——即使两者的开发人员相同，项目类似。

如果某种行动没有意义，可以改变团队本身以更好地支持行动的实施，或者调整行动清单来更好地配合团队。在如今的雇用环境中，前者就是不负责任，而后者又难于操作，特别是在只知道行动本身，不知道其背后动机的情况下。

知晓行动背后的动机是十分重要的。否则，当 “惯用” 动作不好使时（不是如果！），就不知道怎样做出调整。

下面举一个例子：

站立会议

几乎在每一份 Ahile 方法的行动清单上都能看到站立会议这一项。站立会议是指，每天开始工作前，所有人聚在一起开一个快速会议，谈谈昨天做了什么，今天计划做些什么及遇到的任何问题。

但如果你们团队中的多数人在旧金山，而你在纽约又雇了些人，该怎么办呢？站立会议的 “惯用” 模式对你就不再适用了，因为他们 “每天的开始” 时间不同。

关于这点，有很多调整会议的方法：

一、让纽约的同事在会议前先工作 3 个小时

二、让旧金山的同事早上 6 点开始工作（哈哈！）

三、不同时区，分别开会

四、每个人在早上开始工作前，先查看 Slack 里的消息

......等等

应该采用哪种方法呢？怎样调整行动才能保留其初衷？不理解行动的原因，就没有思考方向。每个人对原因的理解也各有不同，这些差异都没有明确提出，在项目进展过程中导致了很多矛盾。

站立会议的真正原因在于，确保每个人在开始工作时，能尽可能多地知道发生在自己周围的事情。如果大家越了解团队成员所做的工作，那么他们自己的工作质量也会更高。

其中的影响是双向的：

• 人们需要获取正确的信息（即，没有被无关信息淡化，对其项目有益的信息）。
• 当某个信息能产生巨大影响时，你希望大家获悉它（即，在一日之始）。

我们来看看这些站立会议的调整选项是怎样支持（或者破坏）会议动因的。

选项一——在太平洋时间早上 9 点钟召开会议，让纽约的同事在此之前先工作三个小时——这就不是工作开始时了。我们希望大家在工作开始前就获知这些信息，而不是开始后 3 小时才知道。

选项二——太平洋时间早上 6 点钟召开会议——这能达到会议的目的，但可能与大多数公司提倡的弹性工作制相冲突。很少有人能在早上 6 点钟开始工作，愿意这样做的人更少。同样，让纽约的工作团队按照旧金山时间工作也不现实。

选项三——在不同时区，分别召开会议——只要位于不同时区的工作团队需要彼此的工作情况，这种做法是绝对行不通的。然而，请注意，如果你能将他们的工作划分得足够清楚， 以致于一方的信息对另一方不但起不到帮助作用反而会干扰其工作。这样的话，这种做方法就可行。

选项四——工作前，在 Slack 上更新最新情况同样行不通。因为在开始工作前，团队成员就需要知道其他每一个人的最新进展，而不是一整个上午的随时获知。

能否另辟蹊径呢？

有没有既能支持弹性工作制，又不违背站立会议的初衷的选项呢？

有一种选项，我们一开始没有想到，就是不用要求旧金山的员工早起，也能让纽约的员工及时获取信息。每天工作结束时，旧金山的每个人或者每一组可以录一段有关当日进展的简短视频（或者在 Slack 上留几句话）。第二天工作前，纽约的同事就能通过以上更新的内容得知旧金山的工作情况。然后，旧金山时间早上 9 点钟，在全员参加的站立会议上处理问题和阻碍。

不进则亡

随着时间的推移，必须要不断改进每个团队惯用的敏捷实践，甚至对同一个团队也不例外。尽管如此，许多团队都没做到，结果就是，团队成员相当沮丧，因为 Ahile 方法似乎毫无意义。我甚至见过完全抵触敏捷实践的，实际上若稍作调整，就能达到最初承诺的效果。

Ahile 方法不是待办事项清单。

Ahile 方法是一套哲学，专注于最大化地获取相关信息。在很多案例中，这套哲学都有一套相似的实践行动。可随着时间推移，所有实践都必须进行改进。

如果不改进，就会与其基本理论脱节，变成仅为了让员工不闲着而进行的不必要的举措，这样只会吸引一些没有想法、循规蹈矩员工。相信我，你不会想让那样的人参与你项目的。

动机与行动

如果我们更多地关注行为的动机，就能避免很多大家所遭遇的挫折。 无论何时，在讨论行动时，都要大声问出来：我们这样做的目是什么？我们为什么要做这件事？它给我们带来了什么好处？能给我们带来什么好处？

作为开发人员，我们总是埋头于杂事，投入很多精力编写代码。但要开发出一流的软件，关键在于人，而不是代码。对于代码，我们有明确的标准，然而整个进程的关键在于沟通的标准。

确保所有的标准都要为正确的目标服务，将它们综合起来，你就能做出令人惊叹的事情。

注：本文译者 Raingy Yang。

本文编译自：medium.com，如若转载，请注明出处：http://36kr.com/p/5043067.html

“看完这篇还不够？如果你也在创业，并且希望自己的项目被报道，请戳这里告诉我们！”