升级路径：好的样子，与坏的样子
每个项目都会遇到团队自身无法解决的问题——超出其权限的决定、滑期的依赖项、由风险演变成的问题。升级路径就是这个问题为了抵达能够采取行动的人而走的那条路。在大多数项目里，它被当作一种形式：治理计划里的一个方框、组织架构图上的一个名字。然后真正需要它的那一天到来，你却发现这条路哪儿也通不到。疫情以来，团队分散在各自的家庭办公室和不同时区，走廊里随口完成的升级悄然消失，正式的升级路径必须承担比以往更重的分量。
一条行得通的升级路径与一条只是看起来整齐的升级路径，差别很少在于那张图。差别在于：有没有人信任它、使用它，并在它触发时采取行动。下面就是区分这两者的关键。
坏的样子
糟糕的升级路径通常并非缺失——而是空心的。它存在，却在压力下无法运作。
触发条件含糊。「重大问题须上报」让每个人自行判断什么算重大，于是大多数人都认定那不是自己的事。
它按职级而非按谁能真正拍板来转交。被点名的发起人离问题隔着三层，问题落到他手里时他毫无背景信息。
没有时钟。一项升级可能一周都无人查看，却没有人算违规，因为从未设定过响应时限。
它只往上走。团队举起一面旗，却听不到任何回音，于是下一次他们干脆不再举旗，默默承受痛苦。
上报被视为失败。指出问题的人落下了名声；隐瞒问题的人显得很能干——直到项目脱轨为止。
好的样子
一条行得通的升级路径，是那种「好的无聊」。人们知道何时该用、它通向哪里，也知道会有事情发生。一旦把这些机制讲清楚，其实很简单。
清晰的触发条件。 用平实的语言界定什么必须上报——超过某金额门槛的决定、超出里程碑的滑期、任何危及安全或范围的风险。尽量去掉需要主观判断的余地。
正确的接收人。 把每一类问题转交给真正能拍板的人，而不是手边职级最高的那个名字。不同的问题可以交给不同的人。
响应时限。 给每个层级配上一个时间——一天内确认收到，三天内做出决定。没有时钟的路径只是建议，不是路径。
一次往返。 每一次升级都要得到看得见的回应，哪怕答案是「暂时按兵不动」。沉默会训练人们不再上报。
一份简短的记录。 记下上报了什么、报给了谁、最后如何解决。这份记录中的规律，会告诉你项目真正的痛点在哪里。
让人敢于使用它
设计得再好的路径，只要举手让人觉得有风险，照样会死。决定性因素是文化，而非结构。当发起人对一次早期升级回应「发现得好，我们来解决」，而不是「这事为什么没处理好？」，他就是在为今后每一条及时到达、还来得及发挥作用的预警买单。在远程团队中尤其如此，因为那位带着坏消息、沉默寡言的成员不会当面把你拦下——只有当渠道畅通、回应公正时，他才会开口。
在需要之前先测试你的路径。挑一个真实的小问题，刻意让它走一遍。如果它抵达了正确的人、得到了及时的答复、又回到了团队，那你拥有的是一条路径。如果它卡住了，你拥有的只是一张图——以及几个月的时间，在更大的问题撞上同一个死胡同之前把它修好。
如果你的治理在纸面上看起来没问题，却在压力下停滞不前，XNM的项目群与项目交付咨询服务可以帮你打造一条真正能动起来的升级路径。