mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-29 21:41:00 +08:00
62 lines
6.3 KiB
Markdown
62 lines
6.3 KiB
Markdown
异步决策：帮助远程团队走向成功
|
||
======
|
||
|
||
> 更好的沟通和少量的会议并不是白日梦。这里告诉您异步决策是如何实现这一切的。
|
||
|
||
|
||
|
||
异步决策能够让地理和文化上分散的软件团队更有效率地做出决策。本文就将讨论一下实现异步决策所需要的一些原则和工具。
|
||
|
||
同步决策，要求参与者实时地进行互动，而这对那些需要<ruby>[大块完整时间工作][1]<rt>Maker's Schedule</rt></ruby>的人来说代价非常大，而且对于远程团队来说这也不现实。我们会发现这种会议最后浪费的时间让人难以置信。
|
||
|
||
相比之下，异步决策常应用于大型开源项目中（比如我常参与的 Apache 软件基金会 ASF）。它为团队提供了一种尽可能少开会的有效方法。很多开源项目每年只开很少的几次会议（有的甚至完全没开过会），然而开发团队却始终如一地在生产高质量的软件。
|
||
|
||
怎样才能异步决策呢？
|
||
|
||
### 所需工具
|
||
|
||
#### 中心化的异步沟通渠道
|
||
|
||
异步决策的第一步就是构建一个中心化的异步沟通渠道。你所使用的技术必须能让所有的团队成员都获得同样的信息，并能进行<ruby>线索讨论<rt>threaded discussions</rt></ruby>，也就是说你要既能对一个主题进行发散也要能封禁其他主题的讨论。想一想航海专用无线电台，其中广播渠道的作用只是为了引起特定人员的注意，这些人然后再创建一个子渠道来进行详细的讨论。
|
||
|
||
很多开源项目依旧使用邮件列表作为中心渠道，不过很多新一代的软件开发者可能会觉得这个方法又古老又笨拙。邮件列表需要遵循大量的准则才能有效的管理热门项目，比如你需要进行有意义的引用，每个线索只讨论一个主题，保证 [标题与内容相吻合][2]。虽然这么麻烦，但使用得当的话，再加上一个经过索引的归档系统，邮件列表依然在创建中心渠道的工具中占据绝对主导的地位。
|
||
|
||
公司团队可以从一个更加现代化的协作工具中收益，这类工具更易使用并提供了更加强大的多媒体功能。不管你用的是哪个工具，关键在于要创建一个能让大量的人员有效沟通并异步地讨论各种主题的渠道。要创建一个一致而活跃的社区，使用一个 [繁忙的渠道要好过建立多个渠道][3]。
|
||
|
||
#### 构建共识的机制
|
||
|
||
第二个工具是一套构建共识的机制，这样你才不会陷入死循环从而确保能做出决策。做决策最理想的情况就是一致同意，而次佳的就是达成共识，也就是 “有决策权的人之间广泛形成了一致的看法”。强求完全一致的赞同或者允许一票否决都会阻碍决策的制定，因此 ASF 中只在非常有限的决策类型中允许否决权。[ASF 投票制度][4] 为类似 ASF 这样没有大老板的松散组织构建了一个久经考验的，用于达成共识的好方法。当共识无法自然产生时也可以使用该套制度。
|
||
|
||
#### 案例管理系统
|
||
|
||
如上所述，我们通常在项目的中心渠道中构建共识。但是在讨论一些复杂的话题时，使用案例管理系统这一第三方的工具很有意义。小组可以使用中心渠道专注于非正式的讨论和头脑风暴上，当讨论要转变成一个决策时将其转到一个更加结构化的案例管理系统中去。
|
||
|
||
案例管理系统能够更精确地组织决策。小型团队不用做太多决策可以不需要它，但很多团队会发现能有一个相对独立的地方讨论决策的细节并保存相关信息会方便很多。
|
||
|
||
案例管理系统不一定就是个很复杂的软件; 在 ASF 中我们所使用的只是简单的问题跟踪软件而已，这些基于网页的系统原本是创建来进行软件支持和 bug 管理的。每个案例列在一个单独的网页上，还有一些历史的注释和动作信息。该途径可以很好的追踪决策是怎么制定出来的。比如，某些非紧急的决策或者复杂的决策可能会花很长时间才会制定出来，这时有一个地方能够了解这些决策的历史就很有用了。新来的团队成员也能很快地了解到最近做出了哪些决策，哪些决策还在讨论，每个决策都有那些人参与其中，每个决策的背景是什么。
|
||
|
||
### 成功的案例
|
||
|
||
ASF 董事会中的九名董事在每个月的电话会议上只做很少的一些决策，耗时不超过 2 个小时。在准备这些会议之前，大多数的决策都预先通过异步的方式决定好了。这使得我们可以在会议上集中讨论复杂和难以确定的问题，而不是讨论那些已经达成普遍或部分共识的问题上。
|
||
|
||
软件世界外的一个有趣的案例是 [瑞士联邦委员会的周会][5]，它的运作方式跟 ASF 很类似。团队以异步决策构建共识的方式来准备会议。会议议程由一组不同颜色编码的列表组成，这些颜色标识了那些事项可以很快通过批准，那些事项需要进一步的讨论，哪些事项特别的复杂。这使得只要 7 个人就能每年忙完超过 2500 项决策，共 50 个周会，每个周会只需要几个小时时间。我觉得这个效率已经很高了。
|
||
|
||
就我的经验来看，异步决策带来的好处完全值得上为此投入的时间和工具。而且它也能让团队成员更快乐，这也是成功的关键因素之一。
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: https://opensource.com/article/17/12/asynchronous-decision-making
|
||
|
||
作者：[Bertrand Delacretaz][a]
|
||
译者：[lujun9972](https://github.com/lujun9972)
|
||
校对：[wxy](https://github.com/wxy)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]:https://opensource.com
|
||
[1]:http://www.paulgraham.com/makersschedule.html
|
||
[2]:https://grep.codeconsult.ch/2017/11/10/large-mailing-lists-survival-guide/
|
||
[3]:https://grep.codeconsult.ch/2011/12/06/stefanos-mazzocchis-busy-list-pattern/
|
||
[4]:http://www.apache.org/foundation/voting.html
|
||
[5]:https://www.admin.ch/gov/en/start/federal-council/tasks/decision-making/federal-council-meeting.html
|