原文链接 点击这里
在大多数公司，做决策需要开会。在Alan，我们在在线论坛上开启一个名为"issue"的书面对话。这些对话是透明、异步和书面文化的基石。掌握这个论坛的对话机制是每个Alan员工的关键。以下是他们的做法。
引言#
每个人都讨厌会议#
没有人做好准备，会议开始得很晚，而且声音最大的人总是有最后发言权，不管对错。一小时后，你的思绪比进入会议室之前更加混乱，你在想是否还有止痛药。但你已经习惯了，毕竟，“会议病"是每个自尊公司的标志，对吧？
如果有人告诉你可以用不同的方式做事呢？在Alan，他们很早就发现了会议的局限性和风险。会议被设计为简短（不超过15分钟）、组织良好（有明确的议程），因此能产生决策。问题是它们经常偏离主题——很难控制讨论。结果，他们经常感到失望，难以记住说过什么，而且对于缺席或远程的人来说很复杂。
所以他们决定把传统上口头进行的事情……写下来！
结果是：他们做出更好的决策，因为写作迫使我们花时间思考。讨论更加细致、更有文档支持和论据充分。简而言之，这不再是一场口才比赛。更妙的是，用书面内部论坛取代会议增加了每个人的自主权：通过公开提供信息，参与讨论的可能性增加了，协作变得更容易。
想知道这个方法吗？他们会向你解释一切。
1. 将平台改造为在线论坛#
现在，当他们需要团队的智慧来解决问题、深入研究某个主题、验证解决方案时，他们不是安排会议，而是在在线论坛上开启一个对话（或"issue”）。这个论坛托管在一个名为"Github"的平台上。
什么是Github？#
最初，它是一个为网页开发者设计的协作平台。其理念是分享和集中对他们创建的代码的反馈。
他们发现社交平台和结构化反馈管理之间的权衡很有趣，所以决定转变其用途来托管Alan的所有决策对话。
具体是怎么做的呢？
- 在Github上创建账户。
- 创建一个假的"代码"目录并将其设为"私有"（在Alan他们命名为"Topics"来决定生活话题 😇）
- 创建标签系统以更容易区分每个对话主题。
- 他们进入目录的"Issues"选项卡查找所有当前"开放"的讨论——以及"关闭"的已做决策。
💡我们现在已经超过了17,000个issue的里程碑。这意味着多少会议没有召开，节省了多少时间！这些知识历史很有价值：只需在Github上做一点研究就能理解每个决策的来龙去脉。如果我们想质疑它，我们已经知道过去哪些论点获胜了。
2. 定义规则：何时开启"issue"？#
“开还是不开讨论，这是个问题。效率要求，他们知道并非每个决策都系统地需要开启issue。如果有些可以在几天内解决，其他的可能需要超过一周……所以，为了确保做出更好、更快的决策，他们开发了一个系统。
问自己正确的问题#
- 谁会受到这个决策的影响？
- 这个决策的可逆性如何？
- 这是一个紧急决策吗？
- 我需要更多背景信息来决定吗？
确定影响程度#
通常，当决策的影响程度和可逆性被认为很重要时，就会开启一个issue。简单来说，以下是他们更喜欢在论坛上而不是在Slack上讨论的情况：
关键联系人#
他们使用LOCI（Lead、Owner、Consulted、Informed）模型来明确责任和在每个讨论中均衡分配参与者。
Lead（负责人）#
描述#
Lead负责决策的成功。他/她确保每个决策背后的背景被正确理解并在团队内部分发。
特点#
在讨论开始时，他指定他希望参与决策的程度，以便Owner拥有所有信息来做出裁决。
职责#
当Lead不是最终决策者（Owner）时，他/她应该：
➡️ 确保同意正在考虑的决策。 ➡️ 信任"Owner"并接受团队产出的责任。 ➡️ 在强烈不同意时表达意见。
分配#
每个讨论应该只有一个"Lead”。
Owner（所有者）#
描述#
Owner负责最终决策并领导项目实现设定的目标。
特点#
如果遇到无法解决的问题，必须向Lead汇报。
职责#
作为指挥者，他或她必须：
➡️ 确保每个贡献者都被告知讨论（并及时贡献） ➡️ 调查问题，收集答案并跟进项目。 ➡️ 开启和关闭讨论。做出并分享最终决策。
分配#
建议每个决策只有一个人负责。
Consulted（被咨询者）#
描述#
“被咨询"的Alan员工是那些在决策过程中意见很重要的人。他们的输入被认为是做出最佳权衡所必需的。
特点#
他们将控制权交给决策者（Owner）。如果强烈不同意，他们必须发出警报，在最坏的情况下，将信息上报给Lead。
职责#
作为讨论的积极贡献者，他们有义务及时贡献，即使只是确认他们对讨论没有补充。
分配#
建议每个讨论通知不超过6个"被咨询"的Alan员工。虽然他们的输入很关键，但这可能导致进度延迟。
Informed（被通知者）#
描述#
这些是被告知进展的Alan员工，通常是在决策做出之后。
特点#
与这些Alan员工的沟通是单向的。
职责#
作为"被通知"的Alan员工，不期望他们做出贡献。
分配#
决策者应考虑决策的潜在影响，并相应通知受影响的Alan员工。
有用的定义#
好的，但他们如何评估这个重要性阈值？Alan区分两种类型的决策：
- 单向决策（难以逆转）
- 这些是需要太多努力或重大支出才能逆转的决策。
- 例如：价格上调的更新（尽管他们已经下调过）
- 双向决策（容易逆转）
- 这些是乍一看风险不大的决策。意外事件可能导致精力损失，这是可以接受的。
采用"解决问题"的方法#
构建项目或讨论的框架帮助我们做出更好的决策。
框架是工作工具，它们不禁止思考。相反，它们允许我们结构化和澄清观点。
为了帮助我们尽可能有效地传达对问题或决策的思考，每个issue都提供相同的模板。这种结构允许我们更进一步，同时教导初级人员如何分解问题。
issue的典型架构#
- “范围” - 定义范围并澄清讨论的"为什么”
- “这个结果的目的是…”
- “这个issue不是关于…”
- “背景和材料” - 提供背景和有用的资源
- 他们添加任何提供背景的讨论或文档的链接。
- “LOCI” - 澄清责任和联系人分配
- Lead
- Owner
- Consulted
- Informed
- 设定截止日期
- 他们在这里分享期望：贡献截止日期、issue关闭日期、必须找到解决方案的日期。
- 分享解决方案提案
- 他们在这里描述问题的潜在解决方案或提出一些可供选择的解决方案。
- 提出问题
- 所有意见和参与有助于做出明智决策的人都被邀请参与。为了保持辩论朝正确方向发展，讨论负责人向关键贡献者提出具体问题以确认或反驳假设——并避免石沉大海。
- 所有意见和参与有助于做出明智决策的人都被邀请参与。为了保持辩论朝正确方向发展，讨论负责人向关键贡献者提出具体问题以确认或反驳假设——并避免石沉大海。
在写作中展现自信#
为了防止围绕决策的辩论拖延，他们采用一些规则将讨论集中在要点上。
更有效地写作#
- 简洁明了
- 他们相信有用的写作：“构思清晰的内容表达也清晰”，布瓦洛如是说。如果我们不能简单地写下某事，这意味着我们不确定陈述的准确性。
- 应用"那又怎样？“测试
- 每次我们写东西时，他们重新阅读并问自己"那又怎样？“这帮助我们更好地理解信息的含义或论点。如果答案是显而易见的，它有助于更清楚地回答潜在问题。
跟进#
- 关注"百万美元问题”
- 收集许多不同的意见可能令人困惑，关注最重要的问题或症结有助于关注优先级，重新聚焦同事的贡献——而不会迷失在细节的海洋中。
- 定期总结达成一致的要点
- 澄清集体同意的内容和仍需讨论的内容是Github对话所有者的常见做法。这是一种为同事提供更好贡献线可见性的方式，也是一种避免在较低优先级问题上来回讨论的方式——对话的目标应该始终是要遵循的北极星。
- 作为最后手段在Slack上提醒
- 他们限制在Slack上的提醒次数。两个例外：当贡献逾期或当紧急情况需要快速行动时。为了确保议程得到遵守，当所有者需要比较观点以做出明智决策时，可以使用Slack提醒。
- 他们限制在Slack上的提醒次数。两个例外：当贡献逾期或当紧急情况需要快速行动时。为了确保议程得到遵守，当所有者需要比较观点以做出明智决策时，可以使用Slack提醒。
隐藏不相关的评论#
- 一些帖子可能有很多评论。作为所有者，只保留那些推进对话的贡献可能会有帮助。
掌握格式#
- 当涉及到以书面形式传达观点时，内容和形式同样重要。以下是我们如何充分利用Github论坛。
- 键盘快捷键
- 为了节省时间，这里是Github键盘快捷键的完整列表。
- 页面布局
- 在Github上可以添加标题（H1、H2、H3）、脚注甚至表格来充实你的想法。这里是完整的指令列表。
- 键盘快捷键
避免陷阱：异步决策#
通过exit系统，每个人都可以参与所有讨论。没有窃窃私语，没有秘密，没有政治：每个人都有相同的信息——但为了避免失望，有一些先决条件需要记住。
避免共识决策#
在Alan，论坛上讨论的每个决策都有一个指定的"所有者"负责作为"开明的独裁者"进行决策。
她的角色是为公司做出最佳决策，不寻求共识，不搞政治。为此，她必须调查创新想法、衡量风险、分析数据、质疑同事，而不必实施她被告知的所有内容。
在公司，决策不是共识性的，他们不是"民主制”。每个人都是股东，因此是Alan的所有者。每个Alan员工都把公司利益放在团队或个人利益之前。然而，他们也不想要孤立的、草率的或不知情的决策。
当决策所有者相当确定要做出正确的选择时，他决定并尝试。之后，随着影响开始变得更清晰，他们反思所做的决策，并看看如何在未来做得更好。
限制贡献者数量#
有效的决策是限于关键贡献者意见的决策。你知道杰夫·贝佐斯的"两个披萨或什么都不要"规则吗？他的想法基于一个众所周知的事实：如果会议中人太多，效率就会降低。异步决策也不例外：通常，人越多，贡献越少。在远程情况下，当issue的贡献者数量不受控制时（超过6人就变得复杂），这种抑制普遍参与的"旁观者效应"——实际上改变了参与质量——往往会发生。
采用渐进式通知方法#
通过制造噪音，通知使得难以区分重要和琐碎的内容。这就是为什么他们在Alan应用渐进式通知规则：他们相互信任。他们假设每个Alan员工都正确设置了他的Github账户以接收通知。因此，他们限制每个issue"问题"部分中人员标签的数量。
设置账户以接收通知#
- 进入"设置"页面
- 在"参与"和"关注"部分勾选"Web和Mobile"复选框
最后的话#
即使怀着最好的意愿，很难向不在场的人解释会议中发生的一切。但团队中的每个人都可以与决策相关联。
显然，通过论坛进行决策的系统既不是解决这个问题的最佳方案，也不是唯一可能的方案：它只是最像我们的方案，因为：
- 他们限制中断：再见不合时宜的会议和相关的通知洪流。
- 他们减少旁观者效应：再见被抑制的参与和出席主义。
- 他们提高决策质量：欢迎退后一步和基于事实。
提案模板#
范围#
- 这个issue的目标是…
- 这个issue不是关于…