如何面对创业过程中的管理难题？| 5Y View

转载自36氪“神译局”

作者：Jason Cohen

译者：boxi

理想主义的创始人相信，就算自己做大了，也还是能打破常规。他们不会变成那种“典型的大公司”。

他们的意思是：不会有假设员工是愚蠢或邪恶的愚蠢规则，不会让一切比本该花费的时间长十倍，没有一场接一场的会，也不招“普通”人或“正常”人。

也就是说，迄今为止初创企业的现有流程服务得很好，通过调整这些流程，希望能保留小型组织的积极特质，同时避免大型组织的常见问题。现在还是做一样的事，只不过做事的人更多了，而且跟以往一样，我们还是一边做一边想办法。

但是，为什么他们从来都没成功过？为什么这些聪明、善意的创始人不可能像管理50人的组织那样管理一家500人的组织？这些不可避免的规模力是什么？

规模力真的是不可避免的吗？

规模的两个基本挑战

了解这两个主要的驱动因素之后，我们就能了解它们如何了解释会在企业的各个角落出现的挑战。

罕见事情变得常见

随着规模的扩大，罕见事情变得常见。罕见事情很难预测，通常也很难预防。在规模化之前，这些是非常罕见的，所以关系不大，但一旦天天都发生这样的事情时，新的流程的必要性就凸显了。

比方说，如果有 1000 台服务器的话，则服务器每三年发生一次的故障率就会转化为每天都会发生一次故障。客户每天都会受到影响然后抱怨，哪怕单个事件都很罕见，你也无法预测且无法预防。自动化可以帮助一下，但解决不了问题。

这个数学问题整个行业没人能避免。

复杂性超出人类理解范畴

人类思维的计算能力有限。一个系统复杂到一定程度之后根本无法完全理解得了。

“复杂”的系统是可以理解的。这类系统错综复杂，但它们表现出的特性让人可以驯服这头野兽。复杂系统的组件可以单独分离出来、可以独立开发和测试，然后组装；因此，这方面分而治之是一种很有用的技术。挑战是很困难，但可以解决，尤其是如果你之前遇到过类似挑战的话；因此，“专家”（“experts” 与 “specialists”）可以解决这个难题。可重复的流程可以监控这套系统。

“复杂”系统的组件会相互影响，且通常会呈现出周期性。所以，虽然单独开发和测试组件仍然很有用，但组件间的交互还是一样的复杂。事实上，困难大都出现这些交互上。人脑就是由相对容易理解的神经元“组件”组成的；但正是因为在复杂、多向、循环的相互作用当中，一切有趣且难以理解的事物才得以呈现。像“意识”这样的大规模效应完全超出了我们的理解，因为这正是从我们尚未理解的复杂性中产生出来的。

这个术语源自 Cynefin 决策领域思维框架。

随着公司规模的扩大，各种系统都会存在，但从根本上来说复杂（complex）系统是很困难的，而且这种难永远不会都不会改变。随着公司的发展壮大，他们面临的困难会呈非线性增长。哪怕是我们复杂到难以想象的人类大脑也无法理解这个系统。

了解了这两个基本原则之后，我们就可以详细阐述一下规模化时面临的具体挑战。

稳健团队的人力成本

如果以“人均产出”来衡量的话，“一个人的团队”是最快捷、最高效的团队。没有沟通，没有会议，可以立即做出决定。小公司必须用这种方式运作，而且也确实见效。这就是他们行动迅速，并像人们常说的那样“拳拳到肉”的一个重要原因。

但是，生病会导致产品的速度或客户服务的质量一落千丈。对于一支小团队来说，如果走了一个人，你就损失了六个月的进度，因为要重新招人和熟悉项目。或者由于缺乏任何流程和文档，你会滞后十二个月或者得彻底重写……因为只有一个人的话，你就不需要那些东西，因为毕竟我们行动太快了，而且不用沟通。

或者也可能是致命的，因为走的那个人是联合创始人。“创始人之祸”是初创企业死亡的主要原因（注：尽管数据也显示，只有一名创始人的公司失败可能性更高。那么哪一个好一点呢？对我来说，这要取决于特质——有些人确实想唯我独尊，而有些人则想与他人分挑重担。）

也就是说，一个人的团队走得很快，但很脆弱。当公司规模较小时，为了速度牺牲稳定是好的取舍，因为对于应付那些会不断扼杀公司的因素——缺乏客户、缺乏市场关注、缺乏核心功能等等来说，速度至关重要。当公司规模较大，每年员工的流动率达到 15-25%，因疾病、假期和家庭原因等问题不能干活的情况就更不用说了，所以天天都会有人离开（暂时或永久）——罕见事情变得司空见惯。如果态度还是跟小规模的时候一样，那就是无组织性和不负责任的态度，公司将无法运作。

因此，一旦上了规模，任何项目的专门人员都不能少于三人，再加上管理层，可能还包括某种形式的产品管理或项目管理。但 4-5 人的团队生产力不会比单人团队高出 4-5 倍；人均生产力会下降，但稳健性和连续性会增加。另一方面，小公司会因为失去一名关键员工而损失 9 个月的时间，甚至内爆掉都有可能，但大公司却像乌龟，动作很慢，但每个月都会像发条一样又增加数千名客户，并最终赢得比赛。

稳健系统的高成本

你可能认为软件系统不会像人类系统那么脆弱，因为我们有自动化和 DevOps 之类的东西。遗憾的是，健壮的软件的成本一样更高、更复杂。

不妨想想怎么给网站提供服务（不用担心，你不需要成为软件工程师才能弄明白这个例子）。假设你有个为了连接，是接入互联网的，有台跑网站软件的服务器，还有个保存网站内容的数据库。我们只有一台服务器，并且大部分时间这台服务器都能跑。姑且假设它在 99.9% 的情况下都是能用的，听起来不错吧。

但其实没那么好。0.1% 的故障率意味着一年的故障时间超过了 500 分钟 — 这样的停机时间肯定不可接受。之所以这样是因为罕见事情（0.1% 的故障率）会变得常见（如果是1000台服务器的话，一年约 50 万分钟的规模）。

如果我们部署两台服务器呢？这样以来，当一台服务器失效时，另一台仍然可用。只有在两台同时发生故障的时候，网站才会掉线，这种情况发生的概率为 0.1% × 0.1% = 0.0001%，每年只有 30 秒，所以这确实很棒（注：可悲的是，这不是这个世界真正的运作方式。一般故障都是相关的或级联的。为了方便距离，我们会简单一些，但这种复杂性会再次证明这一点）。

好吧，现在价格要贵一倍了，因为现在有两台服务器，但由于网站可以更稳健了，所以是值得的（注：你可能会觉得可以通过买便宜一点的服务器来省钱，因为每台服务器只需要原先能力的一半就行。但其实是不行的，因为在故障模式下，单台服务器依然需要支撑所有的流量，所以每台服务器都需要足够强大才能单机工作。）但是等一下，这还不够，因为来自互联网的流量还需要分布到两台服务器上，而且需要一点智能来将流量路由到健康的服务器上，以免其中一台服务器出现故障没法处理请求。这就是所谓的“负载均衡器”，所有云基础设施提供商都会有这个东西，而且这个的成本更高。于是，我们又多了一个需要管理的组件，并且会产生更多的费用。

等一下，还有数据库没说呢。两台服务器需要共享一个公共的内容数据库，因此需要将这个数据库搬到自己的服务器上。如果这台服务器出现故障怎么办？然后还是会停机。所以数据库服务器也得有两台才能保证连续性。

现在我们已经有四台服务器加上一台负载均衡器，成本变成了原来的4倍多了。健壮性可以买来，但它比你想象的要贵得多。我们甚至还没有意识到管理多台服务器其实更加困难，或者服务器之间的通信有可能会出现故障，或者负载均衡器出现故障而导致整个系统瘫痪（注：是，这个问题也有解决方案——让网络层有更多的冗余，一般是由不同的供应商提供，但同样地，这样的成本更高，也更复杂）——所有这些都会降低我们的稳健性，需要更多努力才能实现。

稳健总是要付出代价的。不管是跑四台服务器而不是一台，还是运营一支四人的团队而不是单打独斗，你都可以用局部的低效率来换取整个公司的连续性。

可预测性

当你规模较小时，就没有预测功能什么时候发布的必要。营销部门不会去安排发布，招聘部门也不会安排接下来 50 名客户服务和销售人员的入职日期。这意味着你可以而且应该为了加快产品上市而进行优化，尽管这是短视的行为。

小公司总是吹嘘自己的速度是优势，确实如此，但很容易看出大公司的优势是如何的不一样，也就是巨大的执行优势。当然，当我们的公司在推出新产品时，营销部门需要对发布日期进行预测，但那是因为这支团队技术精湛、资金充足、协调一致，所以我们可以新闻发布、活动、营销、社交媒体、newsletter等渠道齐头并进，在一周内吸引到关注度可以比小公司一年之内吸引到的关注度还要多。我们还有全球销售和支持团队，因此我们每月会马上对 200000 名现有客户以及数千名新客户展开销售，这意味着我们每个月新增的收入会比小公司一年赚到的收入还要多。

但这一切都需要可预测性。没有可预测性，我们没法安排媒体，没法准备销售材料，也没法培训数百名支持代表，并确保代码质量足够高，可以从第一天开始就能扩展。可预测性需要放慢速度。可预测性需要估计（需要时间）、协调（需要时间）、计划（需要时间）、记录（需要时间），并在实际与预测不可避免地出现偏差时调整所有团队的计划（需要时间）。

当你雇用了很多人时，就需要有可预测性。不妨想想增加一位技术支持团队成员的时间表。首先，招聘正在寻找潜在的候选人。然后再安排并进行面试。之后还得等对方辞掉工作，休息一周。然后还要进行新员工入职培训。从决定扩大支持团队到让新人员熟悉情况，整个时间需要四到六个月。

也就是说，我们必须提前四到六个月预测好技术支持的需求，因为我们现在需要为满足那个需求进行招聘。如果我们低估了需求，我们的支持人员就会因过多的工作而不堪重负；他们的生活质量会受到影响，而对每一位客户的服务也会受到影响。如果我们高估了需求，招聘的人就会过多，变成一种成本惩罚。当然了，同样都属于失效模式，后者要比前者好，但这两种情况都不是最优，而解决方案就是可预测性。

在精益和敏捷思维以及事实的激励下，小公司坚称：“未来本质上是不可预测的”。事实上，天马行空的发明和执行是不可预测的。但这也是一个自我实现的预言。坚持未来是不可预测的，就会忽视可以让未来变得更加可预测的工作，这实际上会导致未来对这个人来说是不可预测的。

小公司缺乏数据、客户、机构知识、专业知识，通常也缺乏个人经验和技能来预测未来，所以他们说未来不可能预测通常是正确的。但这属于原则上的不可能，还是对于他们来说不可能？当公司的规模扩大时，可预测性就成为了必需。不是因为华尔街要求可预测，也不是因为投资者要求可预测性，也不是因为不可预测的组织给出的任何其他推卸责任的借口，而是因为它对于健康的规模扩充至关重要。

实质性阈值

如果谷歌推出一款每年能带来 10000000 美元收入的新产品，算好吗？不，这算失败。他们本可以把数千万美元的产品开发成本用来把现有的运营效率提高 0.01%，就能赚多得多的钱。

在年收入超过 1000 亿美元的情况下（事实上2023年谷歌的收入已接近3000亿美元）谷歌只能把有潜力每年创造 10 亿美元收入的产品看作是绝对下限，如果情况好于预期，要有做到每年100亿美元的潜力。YouTube、云业务以及自动驾驶汽车等都属于这种。

这个原则叫做“实质性阈值”，也就是项目必须做出的，能对企业产生实质性影响的最低贡献。

对于小型企业来说，实质性阈值接近为0美元。本月可以帮助你吸引一些新客户的新功能都值得尝试。每周能增加两次注册的营销活动就是成功的。几乎你做的任何事情都很重要。这很好——不断前进的感觉很好。

大公司的财务成功决定了实质性阀值注定不能平凡。这很困难。哪怕是一家中等规模的公司也需要通过新产品获得数百万美元的收入，乐观的情况下也许需要是数千万美元。很少有产品能够创造出这样规模的收入，不管这是由敏捷、创新的初创企业还是稳重的成熟公司做出来的。作为证据，不妨思考一下绝大多数初创企业从未达到每年 1000 万美元的营收水平，哪怕是拥有不错的产品和非常敬业且有能力的团队的初创企业。

然而，这就是中型公司产品经理的工作，你得发明、发现、设计、实现并培育这样的产品——这是大多数创业者从来都没成功过的事情，任务艰巨。

人才招聘

第2号员工愿意加入初创企业是为了获得经验。即便大幅减薪，即便公司失败（最有可能的结果），因为这里有故事、有影响力、有潜力、很刺激、有控制感、有友谊，还有鸡尾酒会谈话，所以是值得的。

第200号员工不会因为这些而加入。第200号员工在生活和职业方面的风险评估会不一样。第200 号员工会对解决不同类型的问题感兴趣，比方说本文所列出的问题，但你想弄清楚的，为什么前面 7 个人买了这款软件，但接下来的 3 个人却没有购买这个问题他们不感兴趣。如果你降薪第200号员工会不愿替你打工。

小公司把这个当作一种优势，以低于市场的价格招募到优秀人才当然是有利的。但如今我们的数百名员工在其专业领域的技能都要比我在小型初创企业（包括我自己的初创企业）遇到的人要熟练得多。为什么？

原因之一是，拥有丰富经验的人往往处在人生的不同阶段，家庭和其他需求意味着他们想要一份可预测的、明确的工作，能挣到可预测的、更高的薪水。当你将他们的先进技能与规模化企业的原材料（也就是客户、品牌、资金、能够执行更大想法的团队）结合起来时，他们一方面可以创造出巨大价值，同时仍然可以在晚上给孩子盖被子。

另一个原因是，在形成了哪方面的专业知识之后，他们发现在到更大的环境下应用自己技能的乐趣。比方说，有些先进的营销技术对于小公司来说永远都行不通，但对于大公司来说却很有趣、很有挑战性，并且对营收会产生影响。有些很有才的人喜欢这种挑战，这对很多事情都会产生影响：薪酬、如何找到人才，以及为什么这个人想到你的公司工作而不是旁边那家愿意多给你比一点钱的公司工作。因此，至关重要的是要有一个真正重要的使命，要有有意义且有趣的工作可以去做，把每个人的工作与比我们任何一个人都要伟大的事情建立关联。在规模扩大之后这些因素会更加重要，因为这才是人才愿意加入并留下来的原因。

沟通

如果公司只有四个人，人人都需要知道的任何信息只需告诉其他三个人即可。每个人都可以知道一切。如果出现重大误解的可能性有5%的话，这样的情况并不会经常出现。

如果公司有四百人，就不可能在短时间内可靠地传递一条信息出去。5% 的误解概率意味着会有 20 个人感到困惑。这还是在假设他们看了要沟通的内容，或者通过 Zoom 聆听了整个演示的前提下。他们这么做的概率有多大呢？别问。

“Slack”不是答案。“电子邮件”不是答案。答案是：不断重复简单的信息。

“重复”是对“我没看到”的回答。许多领导都会在不同时间以不同形式去重复。让沟通的覆盖面逐渐逼近 100%，尽管这也会给那些真正看完听完所有内容的人造成了附带损害，他们厌倦了总是听到同样的事情，并且想知道为什么他们会因为自己是真正关注的人而受到惩罚。

“简单”是“我不明白/不记得”的答案。就像策略的简单性所强调那样，你必须接受这样一个事实：有人会不看，有人会不记得，有人脑子里会想其他事情，有人对语言的理解能力可能没你希望的那么强，而你写的东西也未必像你希望的那么清晰明了。

但这是不是意味着你没法将复杂的东西向 1000 个人沟通清楚呢？是的，就是这个意思。规模化的沟通很难。

技术与基础设施

在云时代，管理10000台虚拟服务器听起来似乎很容易。把一切都自动化，则任何适用于 100 台服务器的流程，只要重复执行相同的操作，就可以适用于 10000 台服务器——而这正是计算机的擅长。

情况从来都不是这样的。一个问题是瓶颈。所有的硬件和软件系统都存在瓶颈。在规模小的情况下，你不会遭遇瓶颈，或者至少可以通过增加容量等简单技术来解决所遇到的瓶颈。但到最后，你会遭遇困难局面，然后就必须对技术展进行重新架构设计才能解决。

另一个是希卡姆格言（Hickam’s Dictum，对奥卡姆剃刀的反驳）：复杂系统的问题的根本原因往往不止一个。不不妨想想看软件升级导致7名客户出现问题，但却没有被检测到的情况。这个问题的“根本原因”是什么？

• 问题出在我们没有检测出bug；如果我们检测到的话，马上撤销升级就行了。

  
  

• 问题出在我们没有测试到出故障的那部分；如果我们进行更多的测试话，这个问题就永远不会出现在客户那里。

  
  

• 问题出在我们没有写好出问题代码的文档；要是代码写得更清晰一点的话，人类就不会出现编码错误了。

  
  

• 问题出在我们的代码审查没做对；如果用了正确的检查清单对代码进行审查的话，我们在部署之前就能发现出错的代码。

与“连问5次为什么”一样，总会有更深层次的原因，以及不同的原因。与“连问5次为什么”不一样的是，这里不只有一个“根本”原因，而是有很多东西跟很多其他东西会发生相互作用。这并不意味着就没希望了，只是意味着分析起来会很复杂，决定做什么会很复杂，而奥卡姆剃刀并不适用。

所有这些都会放慢开发速度并增加投资。要有一整支团队专门得照顾基础设施、扩展、部署、成本管理、开发流程等事情，这些都不是客户直接可见或由客户驱动的，但对于管理扩展的复杂性是必要的。

大公司不仅仅是小公司 × 100

这些力量导致大公司与小公司有着根本的不同。这既不能说是一件坏事，也不能说是一件好事。这是另一回事。

一些理想主义的创始人认为，规模化问题的根本原因是“命令与控制”式的组织结构。但上面的例子其实都没有提及任何组织结构。这是普遍现象，跟组织架构无关。尝试新的组织结构这个想法也许很妙，但上述基本力量不会因角色和权力结构的重组而被消除掉。

扩张很难，前进的道路迷雾重重，蜿蜒曲折，这要持续多年，你需要的人可能会有所不同，没人能毫发无伤。因此，如果你感觉跟这些力量缠斗很困难，这并不是灾难的征兆。大家都一样的难。

什么时候才是灾难？当一家公司正在扩张，但领导者不理解这些基本力，没有不断努力去根据情况变化调整组织，不去引进经验丰富的人才，认为自己可以在没有帮助的情况下解决一切，这样就会招致灾难。相反，扩张应该意味着要有新的人员、新的角色、新的价值观、新的流程、新的招聘、新的故事、新的限制、新的机会。

有太多的创始人和领导者愿意相信：

但他们错了。确实有些价值观应该坚持。否则这一切就没有任何意义了。但细节必须改变。

很多创始人和领导者无法完成这种转变。这会伤害到公司，有时候甚至会害死公司。类似的恐怖故事比比皆是。这很可悲，因为这样的机会浪费，有时候甚至是数百人年努力都付之东流，本来是可以避免的。

不要成为那些警示故事之一。

五源寻找、支持、激励孤独的创业者，为其提供从精神到所有经营运作的支持。我们相信，如果别人眼中疯狂的你，开始被相信，世界将会别开生面。

BEIJING·SHANGHAI·SHENZHEN·HONGKONG

WWW.5YCAP.COM