K-log释义
前些天翻译了一篇在企业内部试验k-log的小结的文章，转发到Blogchina.com，方博士在留言中建议说最好能对K-LOG作个解释，要不然很多人不大明白。这个建议提的很好，因此了，我再翻译一片John Robb在http://groups.yahoo.com/group/klogs/message/211的Basic k-log info，借用这位老牛的释义来对k-log在商业方面作个说明。
=======
亲爱的K-logger们：
本文是对那些来到这个list的新手所作的关于k-log商业应用的简单概述
什么是k-log呢？
K-log能够使雇员发布（post）书面评论，看法的要点，链接，文档，重要的email，以及图片到公司的内联网，在哪里呢，人们能够查找、浏览、建档发布的内容。这使得知识的分享变得非常的容易。k-log通过个人一时间为顺序来组织这些被发布的信息。k-log非常容易使用，并且能很快的为个人带来好处。k-log运行在浏览器中，这提供了一种分布那些存储在个人桌面（电脑）上的信息的简易方式（They also provide a simple way to distribute information currently stored on the desktop (document folders, e-mail, and bookmark lists) with contextual information necessary for complete understanding of its use. ）。
K-log会带来什么好处呢？
解答。k-logs让人们获得他们遇到并需要解决的难题的途径变得简单和容易。对k-log文档作些简单的查询就很快能找到所需的答案了。
专业。因为k-logs是由个人来组织的知识和信息，找到那些你可以从中获得帮助的专家是相当容易的。他们能够通过搜索，k-logger之间的交叉连结，以及虚拟社区工具得到。
组织文档。k-log对那些发布的知识内容提供了一个永久的归档。不管雇员去留，他们的知识都会别留下来。
k-log经济方面的利益有哪些呢？
缩短查找的时间。例如，更快，更准确的对客户的需求做出反应。
更准确的决策。专家的使用，来自k-log方面的提示，将会改善公司决策方面的能力和质量。改进的知识交换（交流）将会揭露出那些浪费的项目和不准确的假定（assumptions）。它同时也将显露出公司内部那些被隐藏的知识和信息。
更快速的培训新来的雇员。新雇员能够更快的发现他们需要的信息、context，和insight，这让他们变得更有生产力。一个新的团队成员能够通过阅读团队的k-log迅速的跟上团队的进度。
简单的管理和改善的公司控制。The elimination of what is that person doing (?) or how is that project progressing (?) questions that plague managers.
k-log的特性有哪些？
weblog的功能。以时间方式最值得发布（内容），日历，以及自动更新。
拥有一个易用的基于浏览器的编辑环境。
可以订阅的知识信息流（RSS）。
Categorization of posts for the development of user specific Weblogs and Subscriptions.
社区工具（引用，热门目录等）使得发现其他k-logger变得非常容易。
具有发布电子邮件，链接，图片和文档的能力。
Long term = integration with Web Services for the desktop digital dashboards that deliver timely info from corporate applications.
作者的个人WebLog ：http://jrobb.userland.com
一次K-log试验性实践回顾
国外有一些探索试验，感兴趣的请看以下《一次K-log试验性实践回顾》。对于KLog，解释性的文字在最后。
作者：Rick Klau
翻译来源：CNBlog.org
对那些感兴趣的人来说，我想我应当就我们历时一个月的基于Radio软件的K-log试验补充一个更新资料。（如果想要了解更多关于k-log，可以看看Yahoo上的http://www.rklau.com/tins/ 。我是公司高层管理团队成员之一，在公司内部，我常被看作“web guy”。因为某些原因，我不大想简单的要求人们来使用这些-anything coming from me about technology is taken with a grain of salt。当然，我已经发现它很酷-if it blinks, has buttons or makes noise, I'll give it a whirl。问题在于，是否组织内有其他人像我一样发现weblog非常有用。
公司的IT部门最近将公司内联网（intranet）更新到一个新的版本，这个内联网是作为一个庞大的静态站点而存在，它收藏了许多有用的参考信息（销售文档，人力资源信息，客户支持数据库，公告等），可是却没有太多的时常变动的动态内容。
最终，我将目标锁定在使内联网有更多的用途 - 一个公司的所有人都能方便的分享他们的意见、问题、经验的地方。
我在公司内挑选了12个人组成了一个试验小组。这些人从公司的一个层面被挑选：QA，销售，市场，专业服务，开发，产品管理，同时，他们也被作为公司多种级别（levels）代表，from the CEO on down。如果成功了，那么希望小组的每个人能够象福音书传道者那样将之带入公司内它们所在的团队。
我们用30天时间评估Radio（注：Radio提供一个30天的免费试用期）。我的目标是：
获得Radio并将他们安装到这12个人的（电脑）桌面上。
创建一个和公司内联网其他部分一致的定制的界面（look&feel）氛围。
单独会见每一个参与者确保他们明白Radio如何使用和我们对这个试验的期待。
定期发送有关使用Radio的提示、技巧和建议的E-mail给小组。
在中期进行一次全体组员参加的会议，集中处理并分类反馈，flesh out问题和困难。
在月末准备一张评估表格收集试验团队中的反馈：
这帮助你更容易的传播你工作上的信息么？
你有没有学习到关于公司的一些你以前不曾知道的知识？
你有没有每天检查新闻聚合器？
作为k-log的结果，你有没有在工作上感觉更有效？
决定是否为这第一个团队购买使用许可证（license）。
决定是否为公司里面更多的团队购买使用许可证。
安装、启动并运行Radio是我们的第一道篱笆。建立我自己的weblog对我来说小事一桩，倒是将发布位置从缺省的Userland域名（weblogs.com）转换到我自己的域名上花了几分钟时间。
在初始安装期间，我们发现许多浏览器的cache设定是自动检查页面是否有新的版本（更新）。结果，一些浏览器的设置被发送到Radio服务器，但是当页面刷新的时候没有在浏览器中显示出来，因为浏览器载入cache中的版本。这给用户带来一些疑惑（我已经更新了我的用户名和密码！为什么它仍然显示旧的设定数据呢？）需要解决 - 一旦我们设置浏览器每次访问页面时都去检查页面的新版本，我们就解决了这个问题。
遇到的第二个问题和我们内联网内的安全有关。我们的内联网使用的是IIS服务，依赖NTLM授权。这就是说，web服务（IIS）只会信任微软应用程序请求文件，拒绝任何其他应用程序对文件的请求。虽然IE浏览器和web服务器通信没有任何问题 - 但是，它是一个微软产品，而Radio不是，所以不能。这就意味着，用户想要试着订阅另一个用户的XML feed的时候，将会得到一个错误。它说Radio不能传递（passing）适当的授权信息给服务器，所以服务器不返回请求的文档给Radio。我们的解决办法是，改变对XML文档的授权模式（scheme）不要请求微软的安全信息。（这里需要标注一下，这并不是Radio的问题（problem），严格说起来，是微软的问题，但不管怎么样，它是Radio引起的。非常感谢Userland的Jake Savin，最终帮我们是被并解决了这些问题。）
我们（公司）的web开发小伙子创建了一个彻头彻尾拷贝了公司内联网look&feel的Radio主题（Theme），- 让用户感觉到一个舒适的熟悉的环境：我们使用和处理的是我们自己的东西。Radio在支持template-based（模板）设计方面作了很棒的工作，所以，最终的用户能够定制它们使之与内联网的其他页面看上去一致。
然后，我和每一个成员单独交谈确信他们明白Radio的基本功能和使用。这里是你怎么发布，这里是它取到哪里。一些人想要更多，于是我们设置了个人的偏好使能发布标题，一些人喜欢能够自动添加一个页面到他们blog的想法，于是我们安装了Radio Express，等等。
在这些交谈之后，我发送了一封电邮给每个成员，强调了一些基本的问题。不需要太多的想象，- 相信他们知道这里是什么并知道如何扩展它。我对Aggregator做了更详细地解释，并且上传了一个大约有100个左右RSS feeds的分类略图，（outline），这样就不再需要花费太多的时间来熟悉掌握NewsisFree和Syndic8。在outline中的每个链接已经被格式化成能自动添加URL到Radio aggregator。（Many thanks to John Robb for doing some of the heavy lifting on this already; I simply added that info, combined with some of my own, to an OPML-based outline that activeRenderer made easily browsable in the browser。）一个可以编辑的这个outline的复件在此处可以看到：这里，我已经把一些内部的信息给除去。
在试验的第二个礼拜的开始，我发了第二封电邮对aggregator做了更多地说明，并解释了如何相互订阅彼此的站点。我们的web开发人员设置了IIS来索引所有的weblog，这样所有的内容变得可以搜索，并且还建立了一个多人（团队）weblog，让所有的帖子能被聚合到一个访问者能够浏览的页面，这样他们就可以看到各种不同的言论。
在第三个礼拜开始，我安排了一次试验小组全体成员的会面，这是一次富有成效的头脑风暴会议。首先，下面是到目前为止我对使用者weblogging的反应的的一些观察：
人们有些被改头换面的重新起步的展望给遏制（overwhelmed）。没有任何东西在那里（应该是指blog）- 这让一些人止步不前了。他们不知道该放什么在“那里”。
一些人迷惑于什么东西该放在哪里的问题 - 那些感兴趣的信息片断应该放入到内联网（通过Radio），还是放在CRM应用程序（我们自己的产品，InterAction）内，或是通过e-mail散播？
一些使用者，受制约于e-mail的习惯，很担心这样简单的发布信息不能确保是否有人来读它们 - 如果它很重要的话（a subjective assessment,to be sure个人主观上的估计，的确），他们更愿意以e-mail方式来发送，这让他们感觉更自在舒服。
试验组提出了一些明确的要求。非常有趣，其中有一个功能最近作为Radio的增强版本已经被发布：能够在他的收件箱（inbox）得到来自Aggregator的最新的帖子（posts）。其他要求大体类似：必须把数据放置在其他地方的前景（prospects）使一些人气馁。人们已经习惯并依赖于Outlook - 他们不想再去学习其他界面了。
许多人一致认为k-log对那些级别、资历较高的管理人员来说会是一个和公司其他人员分享他们智慧的重要媒介（途径、方式）。说来也怪，同样这些人不能确定它们作为个人是否有一些对于他们团队以外的人员来说有价值的信息。有点矛盾，然而一个用户所作的评论（被其他用户附和）确是得知 "on the other side of the house"在做什么是非常好的一件事。
由于weblog灵活的特性（不象结构化（structured）的程序，weblog真的能成为你想要它们成为的那种东西），看到使用者 shape their own expectations in testing out the software时并不感到完全的意外：
一个高级开发人员将Radio当做一个很棒的有注释的书签工具 - 一种保存URL并提高他自己的批注给团队其他成员的方式。
一个市场管理人员将Radio作为一个剪报服务，它可以将从其他站点复制过来的信息片断保存到自己的网页上。
一个销售人员使用Radio来分发相关产业新闻给其他销售人员。
一个时常和培训的客户共进午餐的QA测试者经常在blog上提供午餐时间讨论的话题的概要，分享客户方面的需求、兴趣和对他们的调查。
在第四周结束时候，我发了一封电邮调查使用者对这个项目的感受。下面是一些观察：
多数使用者在头一个月中发布了5到10篇的帖子。这些相对来说比较少的数目并不十分让人惊奇。毕竟weblogs是一种分享信息的新的范例（paradigm）。然而，它还是比预料中的要少许多。较少的发布比例的原因有：繁忙的工作时间安排、不能确定该发布什么等。
虽然人们明白Aggregator的价值，但是却甚少使用它。多数订阅1-2个公司内部其他人的weblogs，很少订阅其他（互联网上）的站点。另一方面，许多人利用了k-log “主页”（也就是前面提到的那个被所有使用者的weblog订阅的多人weblog）。
调查发现多于3/4的人相信公司将从一个更大范围内的推行blog而获益。那也就是说，those same individuals questioned what the focus of such an implementation would be, and whether people would actually contribute.
不管怎么说，我非常惊喜于人们使用k-log的那些方式。
下面是一些更为现实，但是也更为重要的观察（these are mine,your mileage may vary）：
1、评估类似这样的项目30天远远不够。因为时间紧迫(you are competing for time)，并且要成功的分享k-log还需要人们在如何工作这个方面做出转变。要完成这些，我想一个更为现实而可行的时间期限应当是90天。
2、在一些技术难题困挠其他人之前就解决它。我天真的以为我在建立自己的weblog上没有任何问题，因此在内联网内做同样的事情也会同样轻而易举。我们做的是非常明确的标准安装，可是却遇到一些困难。（正如前面所提到的，这些挑战和Radio没有关联，而是我们的内联网设置方面的问题 - 但是你还是必须事前做个充分的测试。）
3、把握好人们工作的方式（how people work）。我低估了多数人希望继续保留Outlook的要求 - 和使用浏览器这种转变带来的相对陌生的工作方式。（如果你认识到我们自己的产品是完全基于web客户端的，你会更惊讶于上述这个事实。）如果你的使用者期望能在一个特别的界面里工作，那么尽可能的让他们更轻松的继续留用原来的环境。（对于我们，我们可以实现了Radio的mail到weblog的功能，或者我们花一些时间来创建类似Outlook界面的网页）
下面是我从这次试验经历中获得的教训：
1、有一个困难要解决。在人们没有认识到有困难之前告诉他们“一切会好起来的”是一种投机取巧的做法。正如上面所提到的，weblog对不同的人会是不同的东西（things）。在我们的试验开始，我们只是简单的说我们想要看看人们是否会发现它们的用处。换句话说，我们没有去尽力解决那个难题。
2、奖励共享。一部分人说他们将blogging纳入到日常例行工作上有些困挠 - 因为他们还有许多要优先做的事情（they had a number of other priorities competing for their time）。一点也不让人奇怪，人们总是趋向于被那些他们能够得到承认的事情吸引（而去做它）。一个成功的k-log部署必须提供有效的奖励来加强分享（/共享）的意愿。
明确你所要寻找的。这个和第一点相关了，但是我认为单独来讨论它非常重要的。我很奇怪许多人在概念上理解weblog能做什么，可是他们却迷惑他们能在其中分享些什么。人们已经习惯于清晰的正式的交流形式 - 而weblog是高度非结构化的（unstructured）。没有了焦点（清晰的样式），习惯（惰性）就占了支配地位。
3、保证高级人员的参与。我倾向于认为大众化的KM是最难实现的。当一个项目象这样被从从上至下支持时，人们更可能注意到（赏识或认同？）这个项目的重要性。 - 更加重视（appreciate）这个项目和公司的总成功之间的关联。我们是否在推进k-log上取得成功，需要包括进更多的高程管理团队。
结果：如何在内部分享信息方面的我们学到了许多。在公司里，没有人在他们的weblog方面有糟糕的体验。当其他人认识到他们更像一个信息的“消费者”而不是“生产者”时，他们会被weblog吸引。这次经历激起了激发起了许多次关于在企业内部那些信息是有价值的很好的讨论。销售人员开始思考他们能做些什么对产品管理有帮助，开发人员开始考虑市场如何运作能使他们更有效率。
在第一个月结束时候，。要取得长久的成功，我们还必须让使用Radio作为写作工具的人数有个扩展。我们还必须定义我们的目标 - 应当更明确而不是简单的说明我们能如何改善沟通。但是这是一次很有益的开始 - 也是更好的理解weblog怎么让我们更加聪明的第一步。
