江苏龙网

  1. 首页 > 人文 > >

#InfoQ#为什么系统越简单，宕机时间越少？( 二 )


现在 ， 再来假设另一个销售流程 ， 在这个流程中 ， 仅仅通知销售团队每一个新的销售线索以及相关的细节 ， 让他们决定是否跟踪该线索 。 如果 Salesforce 通知步骤失败 ， 那么很容易就会有 100 种其他方式将该信息传递给销售团队：报告、Slack 通知、查询信息列表、人工观察 ， 或者使用 Zapier 通过任意媒介发送警报 。 工作耽误的时间最多只有几分钟 。
#InfoQ#为什么系统越简单，宕机时间越少？
本文插图
2
初创公司案例
之前 ， 我的一个客户一直用一个比较老的企业营销自动化平台 (Marketo) ， 并用该平台在几年时间内构建了 629 个自动化流程 。 当某个东西坏了或需要调整时 ， 150 多名员工中只有一个人能做这件事 。 每个问题都需要几天甚至几周的时间来解决 ， 而营销活动只能停滞不前 。 每打一个补丁 ， 整个系统都会变得更加复杂 。

#InfoQ#为什么系统越简单，宕机时间越少？
本文插图
当那个人离开公司时 ， 就没有人会操作这个系统了 。 之后 ， 每个星期都会出现一个新问题 ， 比我们找到并修复它们的速度还要快 。
为避免营销运作陷入停顿 ， 我赶紧将公司从 Marketo 迁移到 HubSpot 上 ， 这是一个更简单的平台 ， 更易于操作和排除故障 。
迁移只花了一周时间 。 然而 ， 在这个过程中 ， 另一个复杂的系统出现了：Salesforce 。 Salesforce 有 10 个自动化流程 ， 100 多个组合操作 ， 所有这些都依赖于 Marketo 中各种微妙的定时自动操作 。 我们花了两周时间 (是迁移时间的两倍) 来理解并将这些流程与新的营销平台集成 。
#InfoQ#为什么系统越简单，宕机时间越少？
本文插图
总的来说 ， 这两个复杂的系统 (Marketo 和 Salesforce) 导致营销团队有六周的“宕机”时间 ， 而销售团队有三周的“宕机”时间 。 这还不包括他们在过去几年中经历的“宕机”时间 ， 也不包括如果我们不彻底检查底层系统 ， 他们将要经历的“宕机”时间 。
最后 ， 我们的系统减少 97% 的进程 (从 629 个减少到 20 个) ， 不过却提供所有相同功能 。 几天后 ， 一个被发现的 bug 在四分钟内就解决掉 。
这段经历让我总结出一些东西 ， 是关于初创公司可以采用哪些原则来规避复杂系统陷阱的 。
3
简单系统的 3 大原则
“拆换”项目很痛苦 ， 具有破坏性 ， 即便从长期利益来看是值得的 。 许多创业公司就像船舶一样 ， 它们在初始阶段没有足够时间和资源来进行大修 。
以下是我在评估或实施新系统时要遵循的三条原则:
1. 满足特性并不一定要复杂
如果一个复杂的飞行控制系统总是让飞机停飞 ， 或者像 Marketo 这样的企业营销平台经常使营销活动停滞 ， 那么它又有什么用呢?
选择易于操作的工具 ， 而不是承诺提供最多特性的工具 。
2. 复杂的设想导致复杂的实现
如果解释或理解一个设想需要太长时间 ， 那么实现它将会更加复杂 。 当某些东西不可避免地出现故障时 ， 修复它的时间就会很长 。
例如 ， 一个销售流程假如要演示一个小时 ， 不管它看起来有多好 ， 后期想要维护都很困难 。
3. 尽量改变而不是添加
当新的需求出现时 ， 我们总是倾向于通过其它方式或在现有系统上集成添加新功能 。 实际上 ， 我们应考虑是否可以通过改变核心系统来满足新的需求 。
就像从 marketo 到 hubspot 的迁移示例一样 ， 这个改变可能会导致预先的计划停滞 ， 但是从长期来看 ， 停滞时间会更少 (计划外的) 。
4
稳定最重要
事物越简单 ， 无序化的可能性就越小 ， 对无序化问题的修复就越容易 。 ——Thomas Paine, Common Sense, 1776


推荐阅读


上一篇：【木易机械】华为扛不住了！华为Mate30一夜跌至新低，还是8GB+256GB

下一篇：「四川观察视频」四川“战疫”第18场发布会⑤我省约5万家中小企业“上云”