CMS漂流

一个冬日下午。从书架上抽出躺书架上月余的书塞包里。步行到附近星巴克。
一口气读完。这是一个关于探索，学习和发现的故事。
经验成为原则，原则成为理论，理论果然就能有效解决问题。
问题和我们遇到的何其相似。这里有聪明勤奋的人们。
这里有智慧和人性的光芒闪耀。
这是我所痴迷的技术。
十三日 十一月 零九年 。于solana星巴克咖啡。
ipod

半年前给zhbo同学讲过两小时。
今天和Bruce同学聊，又就他所在的网站的工作流程发表了一通意见，这个意见，自然可以解释为什么有些非技术人员一样能认识到技术的重要性。自然可以解释为什么这些垂直门户，在拥有同样、甚至更强力量的前线记者、本应更强力量的编辑的情况下，却拼不过搜狐新浪腾讯的对应频道。
首先，软件超越了规则和制度。
软件是代码。
软件是环境、流程和规范。
软件是规则和制度。
软件是系统和核心，系统是软件、人、机器和管理。
所以，同样的功能，会有不同的软件。
同样是操作系统，iPhone和Android可以用起来感觉完全不一样。
同样是在线词典，谷歌金山词霸和网易有道也全不相同。
相比而言，大家现在谈用户体验，这看起来就是一个细节了——基本约定和假设不一样，设定的规则不一样，对用户操作步骤的理解和约束不一样，出来的东西就是两样。
那么，如果对功能的理解没有内化为规则，功能就永远只能是单独的功能。
kolidon以为，将功能翻译成流程和规则，规则再翻译成代码，是产品经理、技术经理、程序员、UI设计师等诸多人共同协力的过程。
因为技术知识的开放性，越来越多的编程人员能够实现功能，功能在软件系统中占的比重将越来越少。
这也能部分解释，为什么简单的俄罗斯游戏，能够经久不衰。
对应的，规范、规则的理解和设定占的比重越来越多。也就是说，管理所占的比重将越来越大。
将项目经理与技术经理放在同等位置的公司，往往能获得更大的成功。
就Bruce同学所在的那个在国内Alexa排名前200的网站来说，他们是新闻媒体，是社区。但仍然离拥有一个成功的内部生态系统差得很远。
对于门户来说，一个集成化的采编发系统的重要性胜过一切。一间大报业集团放下的网站，没有意识到这一点，这让人惊讶。
这个采编发系统，以及以此为中心的辅助系统，本应是他们百多号人工作的基本平台。但让人惊讶的是，此系统真的只实现了基本的CMS功能，没有将平日的采编制度内化为规则和界面，他们更多依靠会议和领导的不断重复强调——这意味着，在这个运行中的软件系统内，没有针对不同业务模型的对应处理机制，没有建立横向或纵向的分工或控制体系，没有与核心系统关联的完整的报表系统和基于软件的绩效考核界面。他们把所有这些统统放到了非常不精确的会议，口口相传和随机命令上。

最后，科学地规划、创造和管理。
考虑另一种情况，继续加毫不相关的功能吧：横向铺得越开，也永远就是一矮小茅屋构成的山区村落而不是一个经过集中规划统一管理的现代化度假村。
没有人愿意长期住在原始村落中——偶尔去吃吃农家菜除外，当然，村民们往往满足于挣农家乐的那份钱。

kolidon中项目实施过程中发现，Drupal项目应用中有如下问题值得关注：
在中等规模项目中，对核心代码及各开源模块源代码的尊重及版本控制与跟踪。
在华的外企和外包企业，对Drupal开发认识不足，因此常常招聘新手来进行“组装”，这些新手无PHP编程基础（可能拥有其他程序开发经验），无充分项目经验，这可能带来的问题是实施计划与项目进度不可控，代码质量与可靠性不可控，维护计划混乱。
实际上，更大的问题在于，即使稍有经验的Drupal开发人员，亦可能无法形成自己的开发规范/契约。自行开发的模块命名、功能分工、模板等均无法控制。
解决方向：
1. 减少对无PHP编程经验的开发人员的招募。应注意开发过程中的标准化文档的生成（即，所有解决方案均应经过讨论和一致许可并形成可供回顾的标准文档）。
2. 每周一次的集中学习，实施质量评估（点评）必不可少，在此过程中，重点讲述不周密的实施方案可能给后期开发，需求变更及维护带来的影响。
3. 在对人员的培训过程中，尤应注意对Drupal核心源码的集中学习，和对Drupal文化的讨论。
4. 若有可能，组织团队成员协同开发和维护某个开源模块。
kolidon识于2009年8月