16、系统优化、项目风险与快速失败原则

系统优化、项目风险与快速失败原则

1. 利用率目标

有这样一个故事，退休后的布拉德（Brad）和旺达（Vonda）夫妇搬到纽约州北部，在奥齐戈湖附近实现了经营小民宿（B&B）的梦想。他们的民宿有十间客房，经常客满，收入比之前的工作还好。

有一天晚上，著名艺人珍妮弗（Jennifer）及其三人随行人员想入住，但民宿已满员，无法接待。

在计算机系统中，请求到达过程有确定性和随机性之分。当工作负载完全可预测时，请求到达过程是确定性的，比如夜间在线用户都回家后，批处理调度器可使 CPU 以 100% 的稳定使用率运行。然而，随机到达过程中，请求往往会扎堆出现，导致系统资源管理困难。会出现无请求的空闲期，也会有大量请求同时到达的高峰期。空闲期浪费资源，高峰期浪费用户时间。

对于民宿来说，房间空一晚，当晚的收入机会就永远失去了。同样，在系统中，当到达过程是随机的，若想满足所有请求，就需要预留一些空闲资源，但预留多少是个问题，因为预留资源是有成本的。选择利用率目标时，要使其足够低以保证系统响应性，又足够高以避免浪费已付费的资源。

2. 何时升级硬件

2.1 升级的好处

• 能获得更快的设备。
• 得到更好的供应商支持。
• 有更多运行新软件版本的选项。

2.2 升级的限制

• 激进的技术升级（如从磁盘到 SSD）可能使组件响应时间提升 10 倍或 100 倍，但硬件升级无法解决斜坡问题，也不能让你更快地等待同事因运行错误销售报告而持有的锁。
• 最高效的改进（如 1000 倍甚至更多）往往来自事件计数的减少。不能用硬件解决软件造成的问题。

2.3 升级的成本

• 直接的硬件升级成本。
• 可能增加的软件许可证费用。
• 将应用程序和数据迁移到新系统并进行测试的项目成本。而更改作业调度或算法的成本通常要低得多。

2.4 升级的风险

硬件升级需要进行测试，尤其是涉及软件更改时。例如工资系统升级虽无 bug，但仍可能引发问题。

2.5 其他选择

多数人期望硬件升级能让系统整体变快，但很多人没意识到，在高流量强度下，消除一个程序中的不必要事件也能让系统其他部分变快，通过性能分析可以预测这种效果。当无法减少事件计数时（如缺乏相关技能、应用程序供应商不配合或已无多余可消除的事件），硬件升级才是下一步选择。

硬件升级可能改善性能，但也要寻找减少事件计数的机会，这样可能更快、更便宜地产生更大影响。保持应用程序软件简洁，在升级到更好更快的硬件时，能更好地享受升级体验。

2.6 硬件升级分析表

方面	详情
好处	更快设备、更好供应商支持、更多软件运行选项
限制	无法解决斜坡问题，最高效改进来自事件计数减少
成本	硬件成本、软件许可证费用、迁移和测试成本
风险	需测试，尤其是涉及软件更改
其他选择	消除不必要事件可提升系统性能

3. 证明的重要性

有个笑话，一个人在黑暗中找车钥匙，朋友问他钥匙可能丢在哪，他说在那边，但却在这边找，原因是那边没光。这说明人们在解决问题时，当解决方案困难（昂贵、耗时、政治风险高或不方便），需要提供两个方面的有力证明：
- 所提出的困难解决方案确实有效。
- 没有更简单的解决方案。

没有有力证明，人们往往会选择简单的方法。但如果糟糕的解决方案是唯一可行的，尝试其他方法就是浪费时间。证明对个人声誉也很重要，能帮助周围人做出明智决策，保护自己作为顾问的可信度。

4. 低估承诺的问题

很多顾问遵循“低估承诺，超额交付”的原则，认为这样能超出客户期望，成为英雄。但安迪（Andy）和巴尼（Barney）竞争项目的故事表明了这种做法的问题。安迪估计能让重要程序提速两倍，他相信自己能做得更好，但因谨慎和谦逊而低估了。实际上他若赢得项目，能让程序提速七倍。而巴尼估计能让程序提速三倍，最终赢得项目并实现了承诺，客户很满意。如果安迪能更好地预估，结果可能会不同。

5. 七个项目风险放大因素

5.1 潜在客户的目标：追求成果还是形式？

在项目发现过程中，要了解潜在客户的总体目标。是只让你完成一份报告以完成清单上的任务，还是真正希望改善现状。若目标只是生成报告而不做实际改变，需提前知晓，否则会增加项目风险。关注项目报告和文档等形式会增加项目时长和风险，而关注共同创造实际成果则会降低风险。

5.2 潜在客户的偏见：固执己见还是乐于接受？

潜在客户对问题原因有先入为主的观念很正常，但如果他们只坚持自己的观念，不愿接受新理论和方法，会增加项目风险。适度的怀疑是健康的，但不信任不利于项目。愿意评估和接受新想法能降低风险。

5.3 潜在客户的文化：政治导向还是技术导向？

创造某种方法（如 Method R）的目标之一是消除猜测，为企业领导者提供系统性能决策的最佳信息。该方法在重视好奇心、真相和解决方案的文化中效果最佳。若企业官僚主义严重、政策繁多、利益相关者众多且难以确定系统的单一负责人，会增加项目风险；而更分散化、更自由和更有责任感的文化则会降低风险。

5.4 潜在客户的情绪：恐慌还是冷静？

团队的恐慌程度（通常源于领导者）可能与危机的严重程度不成比例。一些领导者在危机中能保持冷静，而另一些则认为团队只有在被逼迫时才会有成效。更多的恐慌、担忧和时间压力会增加项目风险，而冷静、稳定和信任则会降低风险。

5.5 潜在客户的关注程度：忽视还是关注？

在项目工作中，需要客户的资源，其中最重要的是关注。正确的关注能帮助你获得所需资源，如数据库管理员和开发人员的时间来测试想法。忽视会增加风险，健康的关注会降低风险，但不恰当的关注（如出于怀疑、政治或恐慌）会增加风险。

5.6 潜在客户的自我认知：虚幻还是自知？

能力低的人往往缺乏自我认知，这种认知偏差称为邓宁 - 克鲁格效应。处理这种情况很棘手，因为难以判断是客户还是自己受此影响更大。获取正确数据有时需要的时间和精力超过有虚幻优越感的客户的耐心。处于无技能且无自知状态的客户会增加项目风险。

5.7 接触权威的途径：难以接触还是容易接触？

潜在客户的权威模式有集中式和分布式之分。重要的不是权威集中程度，而是接触权威的途径。若与集中式权威有良好关系，风险实际上较低；分布式权威若能接触到，也有助于项目进展。缺乏接触权威的途径会增加风险，与能促进项目进展的人建立信任关系则会降低风险。

5.8 项目风险因素分析表

风险因素	增加风险情况	降低风险情况
目标	只追求报告等形式，不做实际改变	关注共同创造实际成果
偏见	坚持先入为主观念，不接受新方法	愿意评估和接受新想法
文化	官僚主义严重、政策繁多、利益相关者多	分散化、自由、有责任感
情绪	恐慌、担忧、时间压力大	冷静、稳定、信任
关注程度	忽视项目，不提供必要资源	健康关注，提供所需资源
自我认知	有虚幻优越感，不配合获取数据	有自知之明，配合获取数据
接触权威途径	难以接触权威	能接触权威并建立信任关系

6. 快速失败原则

在敏捷开发、精益创业和设计思维等领域，常听到“快速失败”原则，但很多项目管理者和商业伙伴对此反感。其实软件开发人员早已明白这个道理。例如，有一次作者与一个 bug 斗争了一整天，正常运行约 90 秒的程序，尝试某条本应更快的代码路径时，运行很长时间都不结束。在家运行时，作者希望程序能快点失败，这样就能更快看到日志文件，找到修复问题的证据。

当知道代码注定失败时，希望它能快速失败，这样能更快解决问题，完成更多工作，更早发布改进。对于商业想法也是如此，如果一个商业想法注定失败，是希望在投入数百万美元和数千小时之前的一周内发现，还是在投入之后的一年才发现呢？显然是前者。

每个非平凡的商业想法若不进行改进和演变，直接按当前设想实施，都会失败。需要找出导致想法失败的因素，不要害怕，先解决最可能的阻碍因素。若无法解决最严重的问题，就换个想法。通过快速失败，能缩短反馈周期，尽快了解最重要的信息。所以，“快速失败”是一种祝福，而非诅咒。

graph LR
    A[商业想法] --> B{是否注定失败}
    B -- 是 --> C[找出失败因素]
    C --> D[先解决最严重问题]
    D -- 解决 --> E[寻找下一个问题]
    D -- 无法解决 --> F[换个想法]
    B -- 否 --> G[继续推进]

7. 快速失败原则的深入理解与应用

7.1 软件开发中的快速失败实践

在软件开发过程中，快速失败原则有着广泛的应用。以作者遇到的程序 bug 为例，当程序出现异常长时间运行的情况时，就意味着代码可能存在问题且注定会失败。此时，让代码快速失败能够极大地提高调试效率。

具体操作步骤如下：
1. 及时发现异常 ：在程序运行过程中，通过监控系统资源使用情况（如 CPU 使用率、内存占用等）和程序运行时间，及时发现程序运行异常。例如，当程序运行时间远超正常预期时，就需要警惕可能存在的问题。
2. 设置合理的超时机制 ：为程序的关键部分设置合理的超时时间。当程序在规定时间内未完成任务时，自动判定为失败并输出错误信息。这样可以避免程序长时间无响应，浪费开发人员的时间。
3. 记录详细的日志信息 ：在程序运行过程中，详细记录关键步骤的执行情况和相关数据。当程序失败时，通过查看日志信息，能够快速定位问题所在。例如，在上述例子中，如果作者能够更频繁地刷新日志文件，就能更快地获取程序运行的详细信息，从而更快地找到问题。

7.2 商业项目中的快速失败策略

在商业项目中，快速失败原则同样重要。当一个商业想法提出后，需要尽快验证其可行性，避免在注定失败的项目上投入过多的时间和资源。

具体操作步骤如下：
1. 明确核心假设 ：在开始项目之前，明确商业想法的核心假设。例如，假设产品的某个功能能够吸引大量用户，或者假设某个市场需求是真实存在的。
2. 设计快速验证实验 ：围绕核心假设，设计简单、快速的验证实验。例如，可以通过小规模的市场调研、用户测试等方式，验证产品功能是否符合用户需求，或者市场需求是否真实存在。
3. 设定失败标准 ：在实验开始之前，设定明确的失败标准。例如，如果用户对产品功能的满意度低于某个阈值，或者市场调研结果显示市场需求不足，就判定该商业想法失败。
4. 及时调整或放弃 ：根据实验结果，如果商业想法失败，要及时调整方向或放弃项目。不要因为已经投入了一定的资源而继续坚持，避免造成更大的损失。

7.3 快速失败原则的优势分析

优势	详情
提高效率	通过快速失败，能够快速排除错误的方向，将资源集中在有潜力的项目上，从而提高整体工作效率。
降低成本	避免在注定失败的项目上投入过多的时间和资源，降低项目成本。
促进创新	快速失败鼓励尝试新的想法和方法，即使失败了也能从中吸取教训，促进创新。
缩短反馈周期	能够更快地获得关于项目的反馈信息，及时调整策略，提高项目的成功率。

8. 综合案例分析

8.1 硬件升级与快速失败原则结合案例

假设一家企业的业务系统运行缓慢，考虑进行硬件升级。在决定是否升级之前，企业可以采用快速失败原则进行验证。

具体操作步骤如下：
1. 明确核心问题 ：确定系统运行缓慢的主要原因，例如是 CPU 性能不足、内存不够还是磁盘 I/O 瓶颈等。
2. 设计小规模实验 ：针对可能的原因，进行小规模的硬件升级实验。例如，先增加少量内存或更换一块高性能磁盘，观察系统性能的变化。
3. 设定失败标准 ：根据实验目的，设定明确的失败标准。例如，如果系统性能提升不超过某个阈值，就判定该硬件升级方案失败。
4. 评估结果并决策 ：根据实验结果，如果硬件升级方案失败，要及时放弃该方案，寻找其他解决方案，如优化软件算法、减少事件计数等。如果方案成功，可以考虑进一步扩大升级规模。

8.2 商业项目风险评估与快速失败案例

一家创业公司提出了一个新的电商平台想法，在启动项目之前，需要对项目风险进行评估，并应用快速失败原则。

具体操作步骤如下：
1. 识别风险因素 ：根据前面提到的七个项目风险放大因素，对潜在客户的目标、偏见、文化、情绪、关注程度、自我认知和接触权威途径等方面进行评估，识别可能存在的风险。
2. 设计验证实验 ：围绕核心商业假设，设计一系列验证实验。例如，进行市场调研，了解目标用户对电商平台的需求和期望；邀请部分用户进行试用，收集用户反馈。
3. 设定失败标准 ：根据实验目的，设定明确的失败标准。例如，如果市场调研结果显示目标用户对电商平台的兴趣不高，或者用户试用反馈中存在严重的问题，就判定该商业想法失败。
4. 及时调整或放弃 ：根据实验结果，如果商业想法失败，要及时调整方向或放弃项目。例如，如果发现目标用户对电商平台的支付方式有特殊要求，而公司无法满足，就需要考虑调整支付策略或放弃该项目。

8.3 案例分析总结

通过以上案例可以看出，硬件升级、商业项目等都可以结合快速失败原则，在项目早期快速验证可行性，降低风险，提高成功率。同时，在项目实施过程中，要综合考虑各种因素，如硬件升级的成本和风险、商业项目的潜在客户情况等，做出明智的决策。

graph LR
    A[项目启动] --> B{是否符合核心假设}
    B -- 是 --> C[继续推进]
    B -- 否 --> D[分析失败原因]
    D --> E{是否可调整}
    E -- 是 --> F[调整方案并重新验证]
    E -- 否 --> G[放弃项目]
    F --> B

9. 总结与建议

9.1 总结

本文围绕系统优化、项目风险和快速失败原则展开了深入探讨。在系统优化方面，硬件升级有其好处，但也存在限制和成本，同时要关注事件计数的减少。在项目风险方面，需要考虑潜在客户的目标、偏见、文化等七个因素，评估项目风险。快速失败原则在软件开发和商业项目中都具有重要意义，能够提高效率、降低成本、促进创新。

9.2 建议

1. 系统优化方面 ：在考虑硬件升级之前，先评估是否可以通过减少事件计数等软件层面的优化来提高系统性能。同时，要进行充分的测试，确保硬件升级不会带来新的问题。
2. 项目风险评估方面 ：在承接项目之前，充分了解潜在客户的情况，评估项目风险。对于风险较高的项目，要谨慎决策。同时，与客户保持良好的沟通，确保双方对项目目标和方法达成共识。
3. 快速失败原则应用方面 ：在项目实施过程中，积极应用快速失败原则。通过设计快速验证实验，及时发现问题并调整方向。同时，要鼓励团队成员勇于尝试新的想法，不怕失败。

通过综合运用这些原则和方法，能够提高系统性能，降低项目风险，提高项目成功率，为企业的发展带来更大的价值。