下载掌阅APP，畅读海量书库
立即打开
如何描述共同目标、共同承诺、共同资源和共同风险。
画布界面分成两部分：表头区域界定协作的范围，内容区域利用四根支柱引导会议或项目。每根支柱代表着一个在任何成功的协作中都至关重要的因素。
深入学习
了解关于团队对齐画布背后更深层的理论内容，参见p.258：共有理解和共同图景（心理语言学）。
任务是任何协作的起点，是任务将所有人联结在一起。它帮助每个人理解什么是重要的，并提供全心投入的原因：
●它很有吸引力，或
●每个人都感觉它与自己相关，或
●它是每个人肩负责任的一部分
当任务不清晰时，参与者会不断地问自己“为什么我要参与其中？”。这时，人们对任务的关注度和参与度都会降低，人们不断地从一个话题跳到另一个，沟通变得支离破碎。这些让人们感到困惑和百无聊赖。
期限为团队框定了一个时间范围。期限是关键：它可以消除一些与目标无关的顾虑，并让每个人都沉浸到具体行动中。
表头区域帮助参与者简明清晰地理解他们为什么在团队里工作，以及引发他们倾听和参与的兴趣。
+描述有意义的任务
以参与者的视角对任务进行积极正向的描述，这样做可以使团队有更多的认同和动力。在进行任务描述的时候，请尽量遵循下面的标准：有挑战性、大胆、独特、非同寻常或有趣。
举例
●正面示例：增强我们的盈利能力并保障我们未来3年的薪酬水平。【目的+收益】
●反面示例：缩减30%的成本。
艾米·埃德蒙森提到，对于要完成的任务，人们必须要达成一致并且为团队任务感到自豪。这样才能激励他们在通向成功的道路上付出个人努力，克服人际关系和技术上的障碍。
（Edmondson and Harvey，2017；Deci and Ryan，1985；Locke and Latham，1990）。
搜索关键词：任务陈述；为项目命名。
+“认同核查”
对一个任务来说，最理想的是采用如下表述：
在完成任务（M）的期间，每个参与者都可以为他的个人贡献（X）赋予意义：
“我正在做X，是因为我的团队要完成M，其中需要我的贡献X，这对我来说很有意义。”
任务：
挑战是什么？
我们想要创造或者改善的是什么？
期限：
多长时间？
什么时间截止？
一个任务可以用多种格式进行描述，例如意义、挑战、问题、项目名称等。
任务只要满足以下标准，就可以放在任务栏中：
●对所有参与者来说都非常清晰明确
●可以帮助人们看到自己在项目中的正向产出
●激发个人参与贡献的愿望
任务示例：
一个期限可以如此描述：
●一段时间范围：几个小时、几天、几周或者几个月
●一个截止日期：具体的截止日期或者两个日期间的时间范围
期限示例：
具体来说，我们准备一起实现什么？
清晰的共同目标会对齐参与者关于需要做什么的意图，可以表现为如下形式：
●目的（需要达成的意图）
●目标（可衡量的目的）
●活动（需要完成的事情）
●行动（活动的一部分）
●任务（行动的一部分）
●工作包（分配给一个人的工作）
●成果（活动带来的结果）
●可交付物（成果的同义词）
●产出（成果的同义词）
●产品、服务（成果的同义词）
TAM是一个半结构化的工具。这里的关键是就可行动的工作达成一致，但这并非一成不变，团队可以对其进行调整。一个典型的TAM包含3～10个共同目标。如果共同目标超过10个，要问问团队，是不是对任务定义得太过宽泛或者模糊。你可能把好几个项目放在一起了，如果遇到这种情况，尝试把项目分拆到几个TAM中。
设定共同目标可以促进团队将任务分解为可行动的工作单元。
询问：
●具体来说，我们一起准备实现什么？
●我们必须做什么？
●我们需要交付什么？
●我们必须完成什么工作？
示例：
描述共同目标的细致程度可高可低。要在清晰度和速度间取得平衡。
最低要求
更多收入
建议格式
提高我们在中国机场的销售收入
建议格式
9月15日前，在中国机场内，对我们的全部产品线进行广告宣传
更为技术导向的格式
作为一个市场开发人员，我需要广告预算，这样我就能在中国机场中推广我们的产品线
提升在中国的市场份额
在今年财年结束前，将所有产品线在中国机场提升在中国的市场份额提升20%
颗粒度太粗或缺少细节
速度越快，清晰度越低
颗粒度较细或充满细节
速度越慢，清晰度越高
目的
一个形容词+一个名词
目的是取得最终成果的中间产物。
最终成果
一个行动层面的动词+一段描述
成果是可交付物、产出、产品或者服务，项目成功时，要达成这些产出或者有实体的可交付物。
目标
一个行动层面的动词+一段描述+可衡量的标准
在目的上面增加一个可衡量的标准，就可以创建一个目标。
用户故事
作为一个＜角色＞，
我想要＜目标＞，
这样才能＜原因＞。
用户故事是一种在敏捷软件开发中用来描述用户需求的技巧。这一方法目前广泛地被其他行业所借用，用来从用户的视角来描述目标。
搜索关键词：用户故事
目标和关键成果（OKR）
目标+关键成果
OKR是一套描述共同目标的系统，这套系统最初由当年时任英特尔CEO的安迪·格鲁夫开发出来。后来这套方法被谷歌采用并流行起来。为了写出一个OKR，你需要为每一个目标确定详细的可衡量成果。
搜索关键词：OKR
SMART目标
SMART目标的标准是具体、可衡量、可实现、现实和有时间限制的。在应用“目标管理”这一概念时，人们常常使用这种方式描述目标，这一广为人知的概念在20世纪50年代由彼得·德鲁克提出。
在目标不会经常变化的情况下，这种方式非常好用。
搜索关键词：SMART目标
+总是从澄清共同目标开始你的TAM旅程
如果共同目标不清晰，就没有办法以团队的方式开展和组织工作。这是托马斯·谢林（Thomas Schelling，博弈论先驱和诺贝尔奖获得者）的洞见：“人们的共同行动是从共同目标推导出来的，两个人意识到他们有共同的目标，认识到他们的行动是相互依赖的，之后才会逆向推导出来一个共同行动的合作方式，以达成他们的共同目标。”换成另外一句话，无论时间长短（比如：3天、3个星期或者3年），如果一项计划的目标不清晰，那么任何工作都没有价值。
+目标拆解和颗粒度
TAM并不是一个为了细致地拆解和跟进工作而设计的工具。这个工具的目的是帮助团队成员快速对齐关键议题，从而带来更高效的协作。如果工作需要非常细的颗粒度，在团队对齐后，你可以使用项目管理工具进行细致的拆分。在其后与团队成员确认工作细分列表。
搜索关键词：工作拆解结构、积压的工作
谁将要做什么？和谁一起？
通过建立共同承诺，团队成员承诺承担并实现一个或多个共同目标。“共同承诺”一栏一般不需要写太多内容：名字和主要的角色一般就足够了。然而，每一个团队成员在其他人面前承诺的仪式非常重要。可以有两种方式：
●团队成员在他承担的共同目标后写上自己的名字。
●如果有人把他们的名字写在TAM上，团队成员会通过明确地说出“OK”“我同意”“我可以”或者“我会承担”来表示同意。
模棱两可的承诺会带来责任的缺失，这种情况经常会出现在一些承诺得相当含蓄的团队中，比如，没有明确说出口。未明确说出口的承诺会在合作过程中带来灰色地带，参与者会预设别人将会便宜行事，这样会增加团队中混乱和冲突的可能性。通过清晰地说出来可以避免上述情况。
→共同承诺的仪式：
探索玛格丽特·吉尔伯特的工作
玛格丽特·吉尔伯特（Margaret Gilbert）是一位哲学家，她对共同承诺的概念进行了多年的跟踪研究。她观察到要创建直接相关的共同承诺，团队成员在他人面前表达出自己对将要承诺的事情的准备度既是必要的，也是充分的（Gilbert，2014）。这个动作就让承诺进入到团队的共同图景或者共同知识中（参见“深入学习”，p.252）。在公众的场合认同共同承诺可以产生道德义务和权利。每一位做出承诺的团队成员有道德上的义务完成他自己那部分的工作，同时作为回报，也有权利期待他人完成他们自己的那部分。这些义务和权利将团队成员凝聚在一起并产生强大的驱动力。
搜索关键词：玛格丽特·吉尔伯特
共同承诺推动参与者从个体状态转化为主动活跃的团队成员的状态。
询问：
● 谁将要做什么？和谁一起？
●谁承诺了什么？
●我们如何一起工作？
●每个人的角色是什么？
共同承诺经常放在相应的共同目标的右侧。
共同承诺可以只是一个名字，或者一个名字加上明确的任务清单。最重要的是，每个人都理解并认同“谁将要做什么？”。
临时性
所有人
财务
IT
最低要求
SJ
莱亚
扬+奈杰尔+伊夫
建议格式
莱亚
（开发）
马泰奥
（设计）
莱亚
（开发）
更细致的工作分工
马泰奥：
-创建纸质版本
-设计数据资产
莱亚：
-技术架构
-编程和测试
颗粒度太粗或缺少细节
速度越快，清晰度越低
颗粒度较细或充满细节
速度越慢，清晰度越高
【团队】或【部门】
当所有承诺还不能马上拆分清楚的时候，可以先写上团队的名字。这非常有用，也是一种最快的方法，但是需要尽快落实详尽承诺，以避免误解。
【名字首字母】或【名字】
如果团队成员过往一起工作过，可以仅标注名字首字母或者名字，这样快速又高效。
【名字】+【角色】
除了名字，有关每个人角色或工作的简洁描述可以提升共有理解的清晰度，同时不会减缓团队对齐的进程。
【名字】+【主要任务/责任】
更细致的工作分工也可以放在TAM中。这个用时更长的方法一般适用于新组建的团队。注意要把分配的子任务匹配到同一目标栏中的每项目标上，以避免团队对于每一栏的具体内容感到困惑。
我们需要什么资源？
所有的人类活动都需要资源，比如时间、资本或者设备。描述共同资源包含对上述需求的估算，以便每个团队成员都能成功地做出自己的贡献。通过提高大家对于完成任务最终所需资源的共同意识，把团队锚定到真实的世界中。
当缺少资源的时候，因为个人受困，团队也会失去交付的能力。工作流程中断，任务完成度也会大打折扣。对资源进行估算与谈判很关键但并不足够。资源必须被分配下去，例如，团队成员可以真正拿到完成任务需要的资源。如果在这一点上不太有把握，一定要坚持，不要犹豫。
+资源状况
资源状况可以用如下方式表示：
可用
马泰奥 √
10天
不可用
莱亚 ×
12天
不知道
萨姆 ？
12天
共同资源帮助团队评估每位成员要完成自己的那部分工作需要什么。
询问：
● 我们需要什么资源？
●我们必须得到什么或者获取什么？
●要想让每个人能更好地为工作做出贡献，我们还缺失什么？
●为了完成工作，什么是必需的手段？
示例：
如果一个团队成员完成他的工作需要一些东西，那么这些东西就是资源！所需资源可以被精准或者不太精准地描述出来；我们总是在速度和清晰度间取得平衡。
最低要求
巴勃罗
在中国有办公室
精准的数据
建议格式
巴勃罗
10天
市场宣传页
100份
差旅费用
2万美元
带有限定条件
最多需要巴勃罗10天的时间，成本是每天1500美元
打印100份市场宣传页（需要在6月3日前完成）
本周末前确认2万美元的差旅费用
颗粒度太粗或缺少细节
速度越快，清晰度越低
颗粒度较细或充满细节
速度越慢，清晰度越高
【资源】
划定资源可以是第一步。这样可以让对话朝着正确的方向进展，例如，明确为了完成工作到底需要什么。
【资源】+【预估的数量】
明确和量化所需资源可以在团队成员间创造很高程度的一致性和真实感。如果很难预估准确的数量，可以预估一个区间或大致范围（1～10天；2万～8万美元）
【动词】+【预估的数量】+【资源】+【限定条件】
当需要对关键资源进行精准定义时，这个更长的模板可以支持团队对齐。但是这个模板只在特殊的情况下使用。
+资源检查表
□人员：例如人数、工作小时数、技能（专业的、人际的）、培训、激励等
□设备和工具：例如工位数量、会议室、办公家具、交通工具、机器等
□财务：例如预算、现金、贷款等
□物资：例如原材料、补给等
□技术：例如应用软件、电脑、线上服务、网络基础设施需求等
□信息：例如文件、数据、访问权限等
□法律：例如版权、专利、许可和合同等
□组织：例如流程、内部支持、决策等
什么会阻碍我们获得成功？
没有风险的项目交付不出来东西。因为存在着一定的不确定性，所以所有的项目都有风险。一旦发生，风险就是带来不必要障碍的事件。这些障碍会给团队完成任务带来更大的困难。它们会增加成本，影响项目交付的期限和质量，甚至会损害人际关系。最糟糕的情况，风险可能会带来整个项目和团队的失败。
TAM有助于降低风险，主要通过下面三个步骤：
1.风险识别
（通过填写共同风险栏进行）
2.风险分析
（通过讨论每一条风险敞口进行）
3.风险转化
（通过使用回溯路径进行）（参见p.74～75）
有关风险管理的讨论至关重要：它们会增强团队的韧性，进而提高成功完成任务的可能性。
+风险敞口
一个标注风险敞口的简单技巧是在记录中使用一个数字或者字母。
比如：
H=高，M=中，L=低
（风险敞口=风险可能性×风险影响）
H 风险1
M 风险1
L 风险1
+专业化的风险管理
TAM是为进行实时、快速的风险管理而设计的；它不能替代深入的风险分析和管理工具。如果进一步，还是要参考专业的风险管理技术。
搜索关键词：风险管理、风险管理流程、风险管理工具
共同风险帮助团队更主动地预测和应对潜在的问题。
询问：
● 什么会阻碍我们获得成功？
●什么可能会出差错？
●我们最糟糕的情况会是什么？
●什么问题/威胁/危险/副作用会影响我们达成目标？
●有什么特别的担忧/反对意见吗？
●什么会让我们考虑备用计划？
示例：
当描述风险的时候，应该实事求是。
关于“共同风险”，存在两个极端。一个极端是，因为有太多的事情可能出错，所以团队花更多的时间用在精准描述风险上，而不是去完成任务。另一个极端是，团队盲目乐观，根本不做风险识别，最后可能仅因为轻易就可避免的原因而导致项目失败。因此，团队应该折中，简明扼要地描述风险，只有在高风险敞口的情况下才描述细节。
建议格式
客户没有
时间
需求不明确
带有后果
客户没有时间可能会导致严重的延迟问题
起初的需求不明确可能会导致服务器宕机
更多细节
时差导致客户没有时间，可能会使项目延迟6～12个月的时间，并增加40%的成本
由于系统工程师超负荷工作，所以起初的需求不明确，这可能会导致服务器错误配置和30%～60%的故障时间
因为客户处在不同的时区，存在无法及时联系到客户的风险，可能会造成项目延迟6～12个月并增加40%的成本
因为系统工程师超负荷工作，存在起初的需求不明确的风险，可能会导致错误配置服务器和30%～60%的故障时间
颗粒度太粗或缺少细节
速度越快，清晰度越低
颗粒度较细或充满细节
速度越慢，清晰度越高
简短陈述
就算只有一条简短的风险陈述，也好过没有。这是用TAM评估风险的精髓所在。
【风险】可能带来的【后果】
【原因】导致的【事件】，可能会造成在【共同目标上的可量化结果】
【原因】导致的【事件】存在风险，可能会造成在【共同目标上的可量化结果】
+风险检查表
□内部的：由团队自身造成的风险，例如失误、瑕疵、准备不足、技能缺失、交付质量、沟通不畅、人员配置、角色、冲突，等等。
□设备的：例如由技术问题、团队使用的产品或者服务带来的风险，工具、建筑物的质量问题，等等。
□组织的：例如由同一组织中的管理层和其他团队造成的风险、缺少支持、政治、物流和资金，等等。
□外部的：例如由客户、终端用户、供应商带来的风险，合规问题、金融市场、天气状况，等等。
+这个模板右侧对风险的描述更加正式，同时也有更多的细节。可是，这种格式也极大地增加了对齐的工作量。为了避免让团队灰心丧气，可以使用模板中左边的简短陈述这一建议格式来描述风险，而右侧这些更细致的模板可以作为讨论的补充指南。如果有必要，可以使用专业的风险管理工具。