你可能已经从软件开发团队那里听说过敏捷方法论了。但你也许不知道，组织敏捷性的影响甚至超出了IT的范围，会让你的公司大不同， 从求生走向繁荣。

现在你的公司也许过得还行，不用做太多辛苦的工作也能成为敏捷型组织。不过以我的经验，在市场可以在数周乃至数日内建立、摧毁、颠覆的情况下，在瞬息万变的经济环境下，能够兴旺发展的组织一定是能够快速行动的组织。要想身手敏捷，你需要颠覆过去对业务运作方式大部分的理解。

敏捷实现为什么那么难？

组织敏捷性的讨论已经很多了。真的，在意识到行业正在快速变化后，许多组织都把或这或那的敏捷性作为企业战略的一部分。但是如果你仔细看一下大多数组织，你会发现实施效果跟权威声称的并不一样，结果并没有很大的不同。为什么会这样？因为业务敏捷性是很难实现的。

在我们深入展开之前，我先来定义一下什么叫做“敏捷组织”。如果你能够跟得上或者甚至超越业务背景（客户、技术、市场等）的变化节奏，那你就是敏捷型组织。

这意味着能够回答下列问题：

• 你的行业变化节奏有多快？
• 你的竞争对手交付新产品和服务或新特性和功能有多快？
• 你的客户需要的变化节奏有多快？
• 你的底层技术变化有多快？

这些要素是复合的。也就是说，如果细分市场出现变化或者出现新的市场的同时你的底层技术也发生了变化，你的组织就得同时适应这些变化，综合考虑这些变化的复杂性，也使得组织的灵活性愈发的重要。

考虑到组织敏捷性的这个定义，我们先看看你的业务系统，本文将严格把焦点集中在产品或服务创建上（产品的维护和支持也会受影响，但是这些都谈到的话文章就太长了。本文也不会涉及财务和预算方面，不过这些一样会受影响。）

下面就是产品制造方面受到敏捷性需求影响的六大关键领域。

工作范围如何定义

大多数组织设想的工作是一大批的，要做很久才能交付给客户。但在事情变化如此快速的情况下这样会有巨大风险。如果你在创建产品的过程中竞争对手推出了一项创新改变了你的市场该怎么办？如果在开发过程中你的底层技术改变了，你用的是一个过时的平台又怎么办？

反过来的做法是设想自己的工作是小规模的、朝着一个方向渐进的，但是同时会针对产品或服务的小部分自主性要素实现快速的交付，这种交付未必像通常设想的产品或服务那样“完整”。大多数情况下，你的客户不希望或者需要你把所有复杂的东西都做进产品里面。创建先决条件最低但提供最高价值的产品给客户，然后再评估他们的反馈。这就是你对工作思考方式最根本的不同。这会影响到项目/产品的创建方式，影响到治理、财务、团队架构，还会影响到交付和营销。

团队架构方式

你也许已经听说过团队建设的塔克曼模型。也就是说团队一般处在下面这四个阶段之一：组建期、激荡期、规范期、执行期。不管怎样，团队都要经历这些过程。一旦团队成员补充进来或者离开在一定程度上也都要经历这些过程。

如果团队成员变化率至少超过30%的话，那一定又要经过这一周期。这个过程会导致工作交付放缓，因为大家关注的重点是社会关系/团队动态而不是工作。我们都希望避免这种耽搁。

有另一种选项。许多人是这样对比的：传统办法是我们有了工作，然后我们找“合适的人”来完成工作。而敏捷（组织敏捷性）的做法是，我们必须有一支伟大的团队然后把工作交给这只团队。

如何培养人

要支撑这种有一支伟大的、长久的团队并把工作交给他们的办法，我们需要一种略为不同的培养人的办法。你需要认识的是叫做T型人的人。是的，你需要领域专家，但也需要他们拥有更广泛的专业知识。

他们需要能够捡起任何需要完成的工作，并帮助推动工作进展。一位客户只有一个人能搞定，但是那个人决定要退休了。接下来的6个月时间里，在那位客户离开后，你就要争分夺秒想要把40年经验转交给几个人来支撑那个系统。不要成为那样的组织。

员工培养的传统模式牵涉到要帮助他们深化领域内的专业知识。不妨用敏捷初创企业的思考方式。如果你只能招几个人的话你想要什么样的人？你想要小范围的领域专家吗？不。你想要的是能够捡起球然后运球跑的人。你想要培养这些T型人才。涉猎多方面领域跟培养专业知识一样重要。

如何领导和管理人

如果你的组织要想敏捷，那么领导决策需要尽可能的快，这样才能采取实际行动。这是从聚焦于做出所有的正确决定并减少失败到做出小的、迅速的决定，以及学习和适应快速失败的转移。这让太多主管感到恐慌。我们从小就被训练成要减少失败。

我们读书时的试卷就是分等级的，如果你搞错了，那你就完了，你已经没有第二次机会。这种做法关注的实际上是时机而不是学习。这种思维在读书生涯以及大学毕业后的工作中自始至终都被强化。

今天，在学校里，对学习的关注已经多余时机了。我的妻子就是一名中学老师，在她的班里，学生交多少次论文都是可以的，这样他们可以选择自己想要的优异成绩。

她希望的是给孩子快速反馈然后帮助他们改进。同样的模式可以运用到领导和管理人上面。你需要给他们提供指导和方向，然后让他们自由做出快速决定，不需要每一个决定都问你同意与否。

你的交付管道

为了实现组织敏捷性，你的产品服务交付管道必须重新组织，这样才能处理不断加快的变化节奏。所以，如果你所在行业的变化周期和客户的变化周期都是6个月，但是你的交付管道是12个月的话，你就有些工作要做了。在面临这类时间线转变时，大家没有意识到的是，这同样会带来范围的等量变化。你交付的产品或服务改变也会减少一半。对客户的影响也是一半。对你的支持员工影响也减半。客户文档总量也只有一半。

可以做的最简单的事是看看你当前的产品线然后砍掉一半。不过不要随意乱砍，相反，要首先交付最重要的东西给你的客户。把不那么重要的东西放到第二位交付。这样你就能把钱花在刀刃上。

销售和营销

如果你交付更快，你的营销和销售团队也要加快1倍才行。他们需要加快1倍发布新产品和服务的速度。他们更新销售知识的速度也要加快1倍。

营销活动也需要修改。但是，再次地，记住新的提供品将只有以前范围的一半，所以营销人士不需要沟通那么多的新功能或选项，因为改变的东西只有一半。我曾经跟几个营销团队一起工作过，他们能够做出这一变化，其复杂程度对于产品开发团队也是一样的。不要低估它对营销和销售团队的影响。

成为敏捷的，成为敏捷型组织不仅仅是IT或者软件要关心的事。今天的每一个组织都需要评估是否足够敏捷来引领后市场。因为组织敏捷性会对你的工作设想产生根本性的改变，所以它会影响整个组织，不仅仅是特定产品的交付。如果你的组织不够敏捷来跟上市场和竞争对手，那你有事情做了！这并不简单，但是值得做。