怎样使你的组织敏捷呢？如果你遵循“敏捷宣言”的原则，你就会找到答案，其中心就是让业务开发更敏捷和更具伸缩性。
然而很奇怪，“敏捷宣言”中缺少了一个主题，就是知识管理。 很容易把敏捷知识管理作为整体敏捷性的一部分的重要性忽视掉。 然而事实是，如果知识管理和知识共享没有实现敏捷，那么成为一个敏捷的组织将会很困难。
这里我们来看看敏捷知识管理意味着什么，以及领导力如何帮助企业实现知识敏捷。
什么是知识敏捷？
创建“敏捷宣言”是为了彻底改变传统的软件开发实践。根据“敏捷宣言”，达成目标而不是追求完美；简单胜过复杂；管理人员和技术人员之间应紧密沟通，而不是仅列举文档中的几个要点。
虽然敏捷宣言的作者们考虑的是软件开发，而不是知识管理，但是他们拥护的很多原则也可以用于知识管理和知识分享中来。实现敏捷知识管理需要遵循以下几点。
- 拥抱变化
今天的知识管理要求也许明天就改变了。因此你的知识管理流程应该能跟上持续的变化需求。
- 专注结果
评估一个知识管理解决方案成功的标准在于它是否可以有效运转且达到了预设目标，而不是要它在所有方面都是完美的。追求完美会分散掉注意力。
- 简洁
只要有可能，知识管理系统应该优先简洁。最好是一个易于创建、管理和使用的系统，而不是一个很先进但过于复杂的系统。
- 持续改进
无论你的知识管理解决方案如今有多有效，总有机会能让其变得更好。为此，你的组织应持续评估当前系统，并确定改进方法。
- 技术过程和业务目标的一致性
如果你的知识管理解决方案不能满足业务需求，那么不管它多么有技术含量，也是没有价值的。基于此，管理人员和技术人员应该密切合作，以保证知识管理工具的设计和实现切实满足业务需求，而不是那些可能可以、也可能不可以转换成商用价值的抽象技术概念。
以上这些概念都反映了“敏捷宣言”中阐述的思想。它们是设计知识管理解决方案的良好起点，同时知识管理也可以增强组织的整体敏捷性。
敏捷知识管理的其他品质
敏捷知识管理不应该仅仅基于敏捷软件开发的原则。毕竟，知识管理不是软件开发。知识管理敏捷还要遵循另外几个关键原则。
- 可轻松依靠自己获取知识
第一个也是最重要的原则是，只要有可能，知识管理系统的用户应该能够自己从系统中获得他们需要的东西，而无需他人的帮助。 换句话说，用户可以轻松依靠自己在知识管理系统中获取知识。
敏捷软件开发中没有这个原则，也许是因为这个概念对软件使用没有实际意义。（大多数端用户不需要自己维护软件）
但在知识管理方面，这个原则是确保无缝、高效地访问信息的关键。使用知识管理工具的用户越难获得信息，那么离敏捷也就越远。
- 面对面知识共享不是理想的方式
“敏捷宣言”的原则之一是“向开发团队传递信息和在开发团队内部传递信息的最有效方法是面对面交谈。”
对于软件开发人员来说，会议可能确实是协调计划和共享信息的最佳方式。但是，当你处理整个组织的知识管理时，依靠会议一般不是最好的方法。
在许多方面，会议都是一种低效的知识共享方式。会议需要努力协调，会议有“dead time”，即这个时间你会浪费在等待其他参与者的出现上。对那些又不便使用音频的人来说，这个时间一点意义都没有了。
并不是说在敏捷组织中就不能开会了。这显然是不现实的。但是知识管理工具应该可以做到，把为了共享或提供信息访问而组织的会议数量最小化。
举个例子，有一个员工需要学习如何使用新的软件应用程序。一种方式是，和一个已经使用过该应用程序的人面对面交流。这是可行的，但这是低效地利用了双方的时间。更好的解决方案是，需要学习该软件应用程序的员工可以在他方便的时间查看数字化使用说明。这些数字化使用说明可以供任何其他也需要学习该软件应用程序的员工重复使用。还可以很容易的通过协作功能进行扩展，让大家在需要时提问。
- 欢迎提问，但要控制数量
无论你的知识管理工具多么完善和易懂，用户都不可避免的需要不时的提出问题。这些问题应该受到欢迎，且知识管理系统应该让用户可以很便捷的提问问题。
与此同时，你的知识管理解决方案的设计目标应该是可以最大限度地减少用户需要提问问题的数量。不断的来回是低效的，且会削弱信息的清晰度。
回到那个需要学习新软件应用程序的员工的例子，必要的时候员工应该可以有途径提问关于应用程序的问题，并能够从可以回答该问题的人那里快速获得答案。但应该尽量减少这种来回的需要。这是可以做到的，比如让员工在学习软件应用程序时，可以轻松访问其他员工之前提出的同一主题的问题及其答案。
结论
在许多方面，敏捷知识管理建立在与敏捷软件开发相同的原则之上。但是，知识和软件并不是完全相同的事情，把敏捷带到知识管理中，需要一些额外的考量，以保证在一个组织中知识可以顺畅的流通，且让创建知识的人和访问知识的人之间不要有过多的打扰。
{测试窝原创译文，译者：喜安}
