# 30 与风险共舞 在我们出版的《Waltzing With Bears: Managing Risk on SoftwareProjects》（与熊共舞：管理软件项目风险）一书中，我们讨论了两种相反的行为：没有风险管理意识的冒险，以及为了避免风险而造成没法做到任何具有突破性的壮举。现在，我们发现越来越多的组织在这两方面都存在问题：对于那些显而易见而又愚蠢的风险，他们选择了接受；同时却回避了那些代表组织转变的信号。 对于人件这个命题，我们的主要问题自然更集中于社会学，而非技术范畴，因而运用该主题，没有什么领域要强过风险领域。世人皆知风险管理的机制；要是风险没有得到妥善处理，原因很可能就出在组织的制度和文化上。 ### 不要逃避风险 首先，我们需要澄清项目风险是一件好事情，这说明项目是有价值的。真正有价值却几乎没有风险的项目早就绝迹了。如今，重要的项目都需要冒点风险。 设想 Barnes\&Noble 公司雇用你为他们的 Nook 电子书阅读器设计软件。下面是你要应对的环境：你们的主要竞争对手 Amazon 已经占据市场的大半江山；你们已经被远远地落在后面；你们的设备没有明显的优势（底层技术同样如此）；你们刚刚开始与出版商就电子版权达成协议，你们可能永远都达不到 Amazon 已经上架的图书总数。你该怎么办？ 当时，处在该职位上的那位，可谓初生牛犊不怕虎，他甘冒极大的风险，决定提供连竞争对手想都未曾想过的服务：电子出版物的图书馆租借服务。考虑要怎样才能让这个想法运作起来：不仅需要和出版商谈判，还需要和图书馆以及作者洽谈；设计并实现网络借阅的协议；在阅读软件里让借阅到期的图书失效；实现积分系统来奖励图书的作者。风险、风险，还是风险，并且附带着开拓未知市场的变数，推向市场时可能面临无人问津的境况。谁知道会有多少借阅量？ 在这个案例上冒的风险收到了回报。Nook 携带着这一标新立异的功能一起捆绑销售，得到了市场的认可。 考虑自己项目上的风险清单。在项目运行过程中，很多事情都可能出错，管理这些风险就是你工作的主要部分。如果让你不假思索地快速列举出所有的这些风险，我们打赌，你一定会遗漏其中一种重要的风险： ### 我们几乎从不管理的一种风险 我们习惯性地不去管理的风险是我们自己的失败。如果你和你信任的团队需要和一个远在千里之外不知名城市里有时差的合作方互动，你当然会把他们可能出现的不达标当成风险来管理。这显而易见。但是，对于你和你的团队无法达成设定目标的风险呢？你当然会为此焦虑不安；甚至会午夜梦回，冷汗如浆地被噩梦惊醒。之所以没有将其列举到你的风险清单上，说穿了，是因为它会让你自己看起来很糟，像个失败者：毕竟，正因为你的能力使你得到了充分信任；这就是赋予你的职责。 为了说明不管理这一风险的危险性，我们需要思考风险管理的本质：不是让所有的风险都消失，而是确保风险发生时有相应的应对措施。应对措施应该提前就经过规划和演练了。 丹佛国际机场的行李输送系统就是这样一个例子。当权者决定系统必须按时交付，这一点至关重要，以至于根本未将不达标（延迟）视为风险。它之所以不是风险，只是因为它不允许发生。于是，风险就这样被管理上的决定给屏蔽了。 如果他们管理了该风险，就必须制定一个人工或半人工的备份方案，以预备在新系统没有按时交付时负责搬运行李。他们没有这样做，因而当系统延误时，只得推迟新机场的运营时间。一座不能投入运营的机场空置了超过一年，其资金成本最后高达数十亿美金。 当风险友生、系统无法按期交付时，才来计划应对措施已经太晚了。如果早做了第二手准备，准备好应对措施，就可以采用旧式的，临时使用人力小推车的方式运送行李，机场就可以开张了。软件交付的延期带来的不过就是一个小小的失望而已。咱们永远都不会听到这个关于丹佛国际机场行李输送系统的故事；除了项目中的人员之外，没人知道。 倘若一项风险出现的几率极低，那么不去管理还情有可原。但只是因为结果“想起来太可怕了”而不去管理这项风险，那就实在是没有道理了。 ### 为什么不达标的风险总是没有得到管理 当需要完成的任务被视为挑战时，进取精神往往取代了风险管理。大家都会为挑战感到兴奋，所有人都欢迎挑战。在困难的情况下大家能够证明自己的能力。最不需要花时间的就是规划和预演他们自己的失败。时间是宝贵的，特别是当挑战同时又附带着紧张的时间表时更是如此。越是时间紧张，大家越是倾向性地不愿将更多的时间花在制定应对措施计划上。 这并非完全是坏事。如果一位管理者和他的团队都不进行风险管理，那一定会有其他人需要进行风险管理。最好的项目经理面对这种情况时会说：“大家注意，我们很愿意迎接这个挑战，还有这个有点恐怖的时间表，我们一定会做出最大的努力。我们不会有时间来管理那种尽管竭尽全力仍然会失败的风险。但是，我们需要有人挺身而出，负责管埋这个风险。除非我们看到有详细的措施，可以应对我们最后交付推迟的风险，我们不会认为这是一个挑战。这是一场愚蠢的、铤而走险的赌博。 中层管理者和决策者们往往善于将期望获得的结果说成是挑战：他们把挑战塑造为一种卓越的证明。但很多时候，他们并不是要指引团队去追求卓越，而是让团队尽可能廉价地完成项目。不合情理之处在于，项目收益越大，廉价交付却越重要。通过廉价交付来掩饰那些不当的利益肯定不是好的激励，所以，当决策者面临这样的情况时，通常会说：“这项工作非常重要，我们必须在 1 月 1 日之前完成。”他们其实真正想说的是，“这项工作其实根本不重要，1 月 1 日后，我们就不想给钱了。” 这是种虚假的挑战，但团队和团队负责人无法理解。他们可能会认可这一挑战的交付日期，并为之做出最大努力，这个过程中的所有风险管理都被虚假所笼罩。 虚假的挑战项目都有共同的特点：边际收益（因为组织回避风险，它们并非存在真正的技术风险），但时间安排的巨大风险基本是不受管理的。欢迎来到这两个最糟糕的世界。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://doc.shiker.tech/ren-jian/di-wu-bu-fen-wo-tu/30-yu-feng-xian-gong-wu.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.