题目涉及的这些关键字显得很庞杂，每一个关键字都值得大书特书，这里我只关注它们只关注它们各自特点、是否可能融合、如何融合以及融合会产生怎样的力量。
各自特点
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仍然不是软件工程问题的“银弹”，但是这两项技术所倡导的哲学与软件工程需要解决的主要问题的答案，在我看来隐然相和。
对团队知识管理的一些思考
最近的一点折腾和思考，欢迎讨论交流。
论坛
BBS和论坛是广场，是大家交流讨论的地方，时效性非常强。虽然有精华贴等方式来沉淀有价值的主题，但很难整理维护好。传统BBS的精华区，靠的是有责任心的版主去维护。参加工作后，很少有人会有这份热心和精力。
这种模式，决定了论坛的三个发展方向：1. 娱乐论坛，比如天涯社区，最热的是新闻八卦贴图等娱乐版块。很多技术论坛，最活跃的也是“水上乐园”。2. 咨询论坛，比如CSDN社区，杭州的19楼空间等。用户去这些论坛的目的性比较强，比如提问，查找房屋出租信息等。这些论坛很难留住高手，蓬勃中透露出浮躁。3. 专业论坛或者说圈子论坛，比如好久以前的RoR，还有如今的CCF和DRL等。圈子虽小，但会员的兴趣爱好都比较相近，谈讨的话题也就比较专业化。这种论坛让人有归属感，但对新人来说，很难融入。
可以看出，论坛的强项是交流，是讨论，并不合适团队知识的沉淀和管理。
Wiki
对于Wiki, 其精髓是词条化管理和协作开发，愿景是保存团队成员们认为的最好的答案和方法。Wiki的搭建非常容易，很多团队搭建了Wiki，就以为将知识管理起来了，其实大不然。互联网上公开的知名Wiki，也就维基百科，其它还有些经营得不错的专业Wiki，总的来说是非常有限的。用Google搜索Wiki，更多的是年久失修的站点。接触过几个公司的内部Wiki，绝大部分都已成为陈旧不堪、没人维护更新的信息孤岛。
Wiki真的适合知识积累吗？最近试用了MediaWiki，TWiki，PBWiki，还有商业版的Confluence，以及号称地球上最好的Deki等，从功能上讲，都非常不错。与论坛相比，Wiki的优点是能更便捷地更新维护，但缺点也很明显：缺乏吸引力和激励性。Wiki的维护成本相当高，一般都得通过行政或奖励等手段来有效运作。Wiki基本上属于公共福利，在中国，目前大部分开发人员的经济水平决定了对公共福利的热情和兴趣很难持久，这是Wiki经常成为荒岛的原因。
简言之，从形式上讲，Wiki很适合团队的知识积累。但从操作和维护上讲，Wiki只是看起来很美，实际操作却非常艰难。
Blog
人都有欲望，有所求。论坛上的活跃会员，求的是认同感和荣誉感。企业内部Wiki的搭建者和维护者，求的是自我和团队知识的系统化管理和沉淀提升，但这种热情很难持久和延续，行政和奖励手段的作用是有限的。
从知识沉淀和参与积极性上讲，Blog介于论坛和Wiki之间。Blog是先有自我的沉淀，再有读者的评论反馈。一个好的Blogger会在自我和读者之间做很好的权衡，读者从自己总结的文章中获益，自己也能从读者的反馈中提升自己。这是一种双赢策略，彼此收益，因此自从Blog诞生，就一直连绵不绝发展到现在。
但Blog依旧更倾向于论坛，适合个人发表意见和获取反馈。对团队来说，需要的是一个持续稳定的知识库。而且糟糕地是，一旦用Blog做为团队的知识积累工具，Blog原生的激励性可能很快就会丧失殆尽。
对团队来说，用Blog来做知识管理看起来也不靠谱-.-
人件
除了上面三种，还有Drupal等CMS系统，以及OpenKM等Doc管理系统，就不多说了。至于Sharepoint，实在感觉很混乱，或许混乱本身就是一种良好的状态？
有效的团队知识管理系统需要满足两个条件：1. 知识的添加、维护和查询很方便，可用性好。2. 能有效的激励团队成员自主地去阅读和更新知识库，可持续性好。
可用性上，无论是Blog还是Wiki, CMS等，都没什么问题。
可用性上还涉及知识的分类组织，这是一件非常头疼的事情。MediaWiki采用词条组织海量知识，GMail采用Tags组织海量邮件，抛弃细化的Categories是一种理念上的革新。但对非海量的团队知识库来说，Categories能让知识更有序，新人也能更方便的浏览和查阅。要做出适用性较强的分类和组织，需要不断思考和取舍。
可持续性上，无论什么系统，用来做团队知识管理，都必须行政化或奖惩化或商业化才能有效运作。
可持续性是关于人的，只有人才能减缓信息的“腐烂”。因此知识管理的核心不是知识，而且寻找某种适当的运作方式，能让团队成员真正参与到知识的添加和维护中来。
用什么系统关系并不大，最重要的是保持系统的“活性”，这就是知识管理。