复杂性的蝴蝶效应

编者按：看似无关紧要的决定却会为显著的组织和运营复杂性打开大门，这就是复杂性的蝴蝶效应。以小唯美的Basecamp最近就遇到了类似的情况，仅仅是在自己的定价表增加了几行看似无伤大雅的话，却让整个公司的运营乱得一塌糊涂。创始人兼CEO Jason Fried通过剥茧抽丝的分析，最终得出了消灭复杂性的解决方案，并跟大家分享了如何及时发现导致复杂性行为的经验。

最近为了消除企业的复杂性，我们在内部展开了一连串的努力。

复杂性就像成瘾……它来得很慢，形成的弱键你几乎感觉不到。但随着它的继续，这种粘结悄悄地固化，直到后面牢固到难以打破的地步。

消除运营方面的复杂性涉及到取消人工进行的繁忙工作、瓶颈、依赖性、取消对安抚的承诺，以及一大堆别的东西。

在此我愿意分享一个我们企业自身的实际例子，从中可以看出几个小的设计决策是如何导致了重大的运营复杂性的。

Basecamp企业版

在Basecamp 3中，我们曾经提供了企业版的套餐。基本上这是定价更高按年付费的套餐计划，里面还提供了一些额外的东西。这里的危险信号就是“额外的东西”。

为了提供差异化并且证明更高定价的合理性，我们给定价表增加了几行东西。我们这么做主要有两个原因：

1）给价格增加更多感知（东西更多=更值钱）

2）在视觉上区分企业版和其他套餐计划（更长的好处列表）

下面就是我们的套餐计划表的样子（补充箭头是为了强调本文的要点——并不是我们的实际定价表）：

红色箭头标出的四行导致了内部的4个大燃点

看起来真的是很无辜。这没什么大不了的，对吧？

复杂性悄然入室

下面我们来看看上图中箭头标记的每一行对于我们公司内部来说都意味着什么：

1. 支票付款。较大的组织往往都喜欢用支票来付款，因为有应付账款部门来大额发票。所以我们认为我们额企业版也许也一样可以接受发票。简单流程：有人寄支票过来我们就处理。不要紧的，对吧？但结果表明这对于我们的业务经理却是相当大的额外工作，他的任务要处理支票然后更新站好以确保被标记为已付费。任何人处理过应收票据都应该知道，支票可以在不提供合适的识别信息的情况下就发过来。这就使得本来应该是很简单的一笔存款变成了哪怕最高明的侦探也很难解决的问题。

2. 专门的客户经理。如果客户给了我们一大笔钱，那么他们有权跟我们的某人直接取得联系似乎就顺理成章了。但是我们并没有专门的客户经理。所以这意味着我们必须分配支持团队的某人给这位客户，而这个人本来已经有其他事情要做了。现在这个人又被绑定到一位特殊客户上了。如果他不在公司怎么办？现在他们又得协调其他的人来代为接管了。我们已经把负担和期望转移过去并制造了把人纠缠到一起的依赖性。还有到底对客户经理的期望时什么？我们从来都没有真正列举出来过，所以双方对此都有很多假设。这个主意可能会导致非常复杂的关系。

3. 为整支团队提供60分钟的个人游。如果你每年给Basecamp 5000美元的话这个似乎也挺合理的。但是我们这边谁来干这件事情啊？应该由谁来协调、安排，如果某人不能做的话又应该由谁来重新调度？客户经理？这样一来那个人就越陷越深了，也没办法应付其他的工单了。是的，如果有要求的话我们是提供了参观项目，但选项和责任是不一样的。我们在把自己和特定客户安排和需求的道路上已经走得越来越远——就因为他们付给我们的钱更多。

4. SLA正常运行时间保证。这究竟是什么意思？我们把它列到定价表上面去的时候都还没有完全确定清楚细节。我们当时认为我们可以稍后再明确下来。于是我们在Basecamp上面启动了一个讨论线程。都有谁参与讨论？David、Mercedes、Kristin、Chase、Noah、Merissa、Will、Jonas还有Taylor。所以这牵涉到了所有权、我们的COO、支持团队的几个人，还有运营、版权、设计方面的人。你很难想到一些“简单的”、看似无关紧要的东西会牵涉到公司各个层面那么多的人。这一切都是为了实现一个我们认为是一个好想法的承诺，而这个承诺几乎可以确定是不必许下的。SLA在线时间是我自己提出的糟糕主意。

那我们可以换种方式来处理吗？当然。我们本来可以把支票付款之间事情自动化的，或者至少显著减少人力方面的工作。我们可不可以把宕机时间跟自动折扣绑定呢？我们能不能自动发出一封“参观安排”电子邮件，里面附上共享的日程安排系统链接，这样客户只需要选定时间然后整件事情就可以自动化运转呢？可以、可以、可以，都可以。但这些实现需要大量繁重的工作，而所针对的只是一小部分客户而已。

但更重要的是，让我们回到问题的根源：我们究竟需不需要提供任何上述东西只是为了证明更高定价的合理性呢？或者我们干脆就定高一点价格就行了。就算是基本相同的东西大公司往往都会支付高一点的价格的——也许他们就是想多付点。也许他们不管怎样都会多付点钱。可能支票付款这一条会影响到绝对无法用信用卡付费的一些人，但其他的好处远没有那么明显。

然后我们再往后想一步……我们为什么要针对一些客户多收那么多钱呢？我们需要那些客户吗？我们的企业需要依赖于一小部分付费多很多的客户吗？不需要。

我们并不是企业软件公司。我们也不想成为一家企业软件公司。我们对解决大公司问题没有兴趣。我们的兴趣——我们的热情是帮助小公司把业务做得更好，并且有控制地发展。我们知道Basecamp 3比任何其他产品都更适合于这个。为什么要分散我们帮助小公司的注意力只是为了从大家伙那里多拿一点钱呢？

所以为什么我们要去吊大鲸鱼呢？最主要是因为这件事情似乎很容易做。而这个，我的朋友，正是复杂性藏身之处。

解决方案

那我们该怎么办呢？我们最后停止提供企业版套餐。问题解决了。现有已经订购了企业版服务的客户还可以继续，我们只是不再向新客户提供了。

一些经验法则

如何才能认出自己正在制造复杂性的情况呢？以下是一些经验法则，当你在做自己的事情时下面这些是需要你后退一步再考虑一下的东西：

1. 我有没有给别人制造工作？在定价表上面加多一行然后说“哦，我们会照顾好那个的”是很简单的事情。我知道——我就干过那种事情。说易行难。

2. “我们会晚点搞清楚。”这一条未必都是糟糕的，但这是危险信号。当你留了一堆悬而未决的问题时，你是可以第一时间回避问题了，但你知道其实质是找到答案会很有挑战。

3. “如果这件事变成了大家讨厌的事的话我们后面会进行自动化的。”这个选项也不一定都是坏的，但要意识到我们一贯都不会经常返回来对一些事情自动化，除非这些事情让程序员/设计师自己感到很痛。如果痛苦是别人的事情的话，他们是很容易就会让情况继续的。由于自动化需要对问题有深入了解，也需要程序员和设计师资源，很容易就会找借口说“这件事情还不够重要，我们得先处理更重要的面向客户的产品工作。”

我相信还会有其他的经验法则。如果你还知道别的办法的话请在评论区提供你的高见。

希望这篇文章能让大家了解到几句话就能增加显著的组织和运营复杂性。这实在是蝴蝶效应的很好例子。翅膀扇动掀起惊涛巨浪。