ZT：blog、wiki、项目管理和项目知识管理

长城小站是由志愿者支持的公益性网站，无固定经济来源。2012年小站台历是由各方网友赞助图片、设计、印刷精心制作的纪念品，用于小站运营经费筹款。 欢迎您购买小站台历，支持长城小站与小站博客的发展。

blog、wiki、项目管理和项目知识管理

题目涉及的这些关键字显得很庞杂，每一个关键字都值得大书特书，这里我只关注它们只关注它们各自特点、是否可能融合、如何融合以及融合会产生怎样的力量。

各自特点
blog：以网络为载体，让独立的个体进行表达的简单写作工具，其特点它象写日记一样，是以我为中心，自我表达的，看到一个人的blog，如同看到他的profile一般。我如果你不清楚blog是什么，那就去google一下吧。
wiki：以网络为载体，围绕某一主题进行自由写作的工具。在这种写作环境之下，每一个人都可以自由的修改所有他能看到的页面（这也意味者易于破坏）。它的哲学是：“人群性本善”－即是当行善的人和行恶的人拥有同样的力量的时候（这是因为页面用版本管理工具管理）,整个人群所彰显出来的就是“善”的特性。
blog和wiki的共同特点：简单，自由－－利于释放人们的表达欲望，不象传统的写作方式，如在报纸上发表文章，出书，搭建个人网站... 那样难以表达自我。千万可别小看简单、自由这两项特性，这是blog和wiki之所以存在的基石，下面的论述中，你会常常感叹于－－正是因为其简单，才能.....
项目管理所面临的主要挑战来自于沟通的困难。无数的厂商/组织提供了无数的工具/开发流程、在各个不同的层面，针对对团队的开发模式、组织方式、沟通机制/工具、氛围来试图解决这一困难。
项目知识管理对于一个组织的积累、成长，其重要性毋庸置疑。但是我们见到更多是无积累、无意义积累的组织（大多数中小组织都属于此种情况－－项目完成后，成百上G的文档以简单组织、难以访问的方式累积下来，再无人问津）。大公司可能会有能力去支付象IBM内容管理软件的高昂费用，来达成这一目标，但由于其严格控制的权限，个人的思想难以沉淀在组织里。
项目管理过程积累下来的知识构成了组织的知识库。

融合的基本思路
相似融合：
* 项目组由不同个性的人组成，这些人有共同的工作目标。
* blog是个人自我表达的工具，wiki围绕某主题进行写作。
* 多个项目组积累的知识，构成更大的项目知识库。
* 多个wiki主题,通过interwiki的形成更大的主题。
互补融合：
项目管理有很强的组织性，在协调、组织和分工的同时，也会对组内成员造成一定的压抑，并且降低某一部分组员的成就感。blog+wiki形成的自由表达沟通平台可以从另一种方式平衡这样的压抑，从而形成更强的项目组。
从这样的思路出发，我们会很自然的得出blog和wiki融合的基本思路和特性：
1)blog是作为项目组成员表达自我的一个平台，但是涉及项目部分的文章（如，小技巧，周报，代码评审意见..）将会自动送到wiki系统中去。
2)wiki作为项目组沟通平台，一方面，关于项目的信息（主要是动态的方面），由于其简单易于访问的方式，更容易让组员接受，乐于通过这样的平台进行有效的沟通；另一方面，组员的blog将会出现在项目组的wiki中，个人在完成自身积累的同时，也让组织完成了积累。
3)由于有相当多项目开发是在客户临时准备的现场进行，项目组的网络环境差强人意，访问Internet可能都不行，逞提对外发布的平台。这时候，项目组就可以架设一个简单的wiki+blog系统，定期或项目完成后通过interwiki的方式加入组织的项目知识库。

blog+wiki如何解决项目管理中的一些具体问题
代码评审(code review)是许多项目经理认同的、有效的项目管理手段之一，但是具体操作起来确令许多项目经理却步：如何评价、监督评审者的工作，如何评价被评审者，如何缓和审查者和被审查者可能的矛盾。在blog+wiki介入的项目中，可以采用这样的操作方法：组员贴出自己的代码邀请其他人进行评审，评审者自由选择代码进行评审，完成平均评审代码量。项目经理对于评审者的工作量一目了然；由于是公开并留下记录的评审，评审者如果有“对人不对事”的倾向，在这样的半正式的情景之下也会慎重考虑；解决了“对人不对事”的问题，评审者和被评审者之间的矛盾自然消失。
项目经验的积累－－我们常常会有这样的经历，当前碰到的问题在以前的项目中遇到过，于是开始在庞杂的、各种各样格式的项目资料库中翻查，这时候一般都是无功而返，然后寻找相关的人员回忆，运气好的话可以回忆起来，运气差的话，连相关的人员也找不到了。而blog+wiki的介入下，无论个人还是组织都有了一个良好的项目经验积累的容器。
此外还有工作进展、会议既要、TODOlist、周报的问题都可以在wiki+blog找到适合的答案。

blog+wiki引擎选择
关于blog和wiki独立的引擎极大繁荣，这方面的介绍不是本文的主旨，可以查阅相关资料，不再赘述。但是blog+wiki的成熟整合方案目前还较少，服务于项目管理的blog+wiki就更少。选择的原则如下：
1)简单。功能复杂既无必要又损害了使用者的积极性；
2)还是简单。维护blog+wiki平台所需的技能越少越好，懂得这些技能的人群越广泛越好。
3)blog系统之间和wiki系统要有足够的互动能力，拥有同样的运行环境，但是又不能过于紧密的耦合。
4)支持中文：中文编辑/显示，中文页面名，interwiki中文支持。
遍寻一晚，我选择了基于perl的MovebleType+Oddmuse整合版本http://www.qinyu.net/archives/000281.html，但我仍嫌它不够简单，而且二者的互动能力仍然很弱，需要改进。考虑到java技能的广泛使用，使用java技术的的blog+wiki系统应该是较好的选择，但我只发现了基于jsp的wiki系统JSPWiki http://www.jspwiki.org，没有发现基于jsp的blog系统。

MovebleType+Oddmuse


JSPWiki

总结
blog+wiki仍然不是软件工程问题的“银弹”，但是这两项技术所倡导的哲学与软件工程需要解决的主要问题的答案，在我看来隐然相和。



blog、wiki、项目管理和项目知识管理

左云于 2004-03-04 12:56:39 发表在分类：尽闲侃 中
(62077次点击) | 标签：