协作文化的四大支柱

安全、速度、清晰、承诺。

你团队中的每个人都会定期分享想法吗？会主动提供反馈或提出疑问吗？ 他们能否展现脆弱的一面？能否安全地挑战甚至质疑任务本身**？**

协作文化有四个核心支柱：

前两个支柱相辅相成：安全与速度。后两个支柱则确保你的流程在短期和长期内都能体现价值。

安全： 失败是否“安全”？实验精神是否受到鼓励？
- 一次“失败”永远是学习和改进的机会。
- 当情况或观点发生变化时，是否会进行讨论并接纳？
- 领导层应强调从“被拒绝”的提案中学习到了什么。即使没有提案最终“胜出”。
- 明确在何种情况下适合进行根因分析（Root Cause Analysis）？（是因为与 OKR 不一致吗？领导层是否可以进一步明确或缩小目标范围？）
速度： 起草提案应该花多少时间？
- 经验法则： 理想情况下为 1-20 分钟；最多不超过 2 小时。
- 这里的速度关乎效率。这是对你和同事时间的双重尊重。
清晰： 你是否产出了清晰且可执行的决策？所有参与者是否都明确其价值？考虑对外部团队的价值：让他们更早收到通知，避免在法律和合规部门可能反对的代码上浪费精力。
承诺： 你能找到两周前做的决策吗？三个 Sprint 之前的呢？如果找不到，那么投入大量时间就没有意义。

建议： 讨论并确定最适合团队的工作方式。根据需要进行调整。

尽可能简洁地记录你们的共识，例如：

涉及 UI 的内容，首选在简介中附带截图。
首选单行文本摘要。（业务拓展或新功能建议使用单段落摘要。）
在最终决策截止日期前，在提议的方案中加入原型图（Mock screens）。
制定具体的标签建议：（例如：Urgent、[Team-Name]、Needs C-Level Approval、Hackathon、Spike related。）

花点时间思考这个流程，向你的团队证明你重视一个能听取他们想法的环境。

重点关注以下领域：

设定清晰且最低限度的预期。通常按角色/部门定义（例如：财务、安全、事件响应、工程、高管）。
- 任何草案只要有想法就可以分享，不嫌简陋。（使用清晰的标签注明状态。）
- 是否要求拼写和语法正确？（对于给高管的提案，那是肯定的。但对于安全事件响应，语法优先级可以降低。）
- 是否首选草图或图表？（网络变更可能需要流程图。销售预测可能是该团队的常态。）
- 是否期望作者针对问题提出解决方案？（或者只是一个占位用的“稻草人”方案？）
提供多种提案示例
- 为每种模式创建简短示例。
- 利用待处理的决策来吸引团队成员参与。
根据团队性质，考虑制定行为准则（Code-of-Conduct）
- 如果涉及第三方、非员工、开源社区等，这一点尤为重要。
同理心
- 人们在分享想法时往往会感到焦虑。这是人之常情，即使是顶尖高手在表演时也会紧张。
- 照顾团队成员的沟通偏好和需求。
- 定期与团队（或个人）讨论这一点。通常一次快速的结对讨论或头脑风暴就能帮助消除阻塞并重新注入活力。

建议： 养成一旦写好标题就分享提案的习惯。

即使它在 draft（草稿）状态下停留一段时间也没关系。

每当提案准备好推进时，召集利益相关者，进行讨论并向前推进。

随着提案的不断完善，积压的草稿想法会变成一个充满机遇的源泉。

新想法是否受到欢迎？你们是否会为那些“天马行空”的提案喝彩？这将直接影响想法的价值和产出量。

要有意识地去塑造你希望看到的模式。

在理想情况下，对提案做出响应应该是一个只需点击几次的过程。

明确你到底需要一份带有详尽笔记的深度分析，还是一个简短的单行评论，甚至只是一个表情符号投票。

预期必须明确。试图通过给文档贴上“进行中”或“征求可行性建议”之类的标签来描述质量水平，通常无法激发评论者的积极性。团队需要知道预期的交付物究竟是什么类型。

拒绝（或对失败的感知）绝不应成为一种阻碍。在这里，“容错文化”至关重要：拥抱更早、更频繁的失败！重视低成本且及时的反馈循环！

每个团队在这方面都会有不同的规范和优先级。尝试在回顾会议中反思并改进你们团队的方法。

思考一下在你的组织中，想法是如何产生并演进的：