我看QMP

       QMP到目前为止还是存在着不小的问题，比如说：支持的用户并发数不够。那我真的不知道，这个产品要卖给什么样的公司了？可能这个阶段只能是卖给哪些人数比较少的公司了。

       以目前的架构来讲，要支持大客户可能办不到。因为从架构上就没有考虑产品化的问题。现在要争论是否用Hibernate，是否用实体工具，也只是细节问题，产品要在大面上去考虑，去从架构上考虑我们系统中存在的各种性能和稳定性以及安全性等等问题。

        举一个简单的例子来说，为什么我们的各种统计分析功能是如此的弱，如此之慢？那是因为我们的各种统计分析功能都是现算的，那么自然会做成Applet的方式，利用客户端的计算能力。但是，如果我们软件的架构改变一下，比如说我们在设计之初就区分业务系统，以及统计分析系统。比如：有支持日常的业务数据库，有统计分析数据库，业务数据库负责日常的业务服务，然后通过将业务数据库中的数据增量的计算各种统计分析数据，存储到分析数据库中。那么，在使用统计分析功能的时候，就很简单。
       在度量实体那边也是一样，我们的度量为什么要利用客户端的功能，就是因为服务器段能力比较差。如果有专门的应用来作度量这件事情，生成的度量数据库都存储到另外的系统中，那主业务系统又怎么会慢。
       因此，我想，架构是第一点，非常重要的问题。没有架构设计，那么得到的产品没有办法满足市场的需求。这个是很显然的事情。
      
       第二：关于并发的问题。为什么我们的系统不能支持客户比较多的情况。很多网站动则支持上万人同时在线，他们是如何做到的？那么，我们的系统为什么不能采取点措施，来支持并发问题。那么，接下来就有Session机制的问题，数据库选型的问题（单个数据库，还是多数据源，数据集群的问题），缓存的问题等等。
 我想，采用什么样的架构，直接就决定了系统将来的表现。而这些不是简单的MVC框架划分的问题。

       第三：架构之外。系统的核心竞争力表现在什么地方？我觉得庆武很有想法。做一个和PM集成的BUG管理工具是我们的核心竞争力吗？别人在你这里三个月，花三个月的时间，肯定能做出比咱们更好的BUG管理系统。我看这不是空穴来风，我如果要再做的话，我一个人，采用Rails，能够在很短的时间内完成BUG管理系统的开发，并且不会比现在的BUG系统难用。
     
       那么，我们的核心竞争力到底在什么地方？
      
        我们有很多CMMI/CMM的知识，咱们的产品是贯彻了CMM的理念，但是这还不够。最重要的，我们应该根据我们自己的公式，概念，原理，方法，提供用户可视化的，简洁和清晰的视图和报表，这些视图和报表能够帮助用户（根据各种不同角色的不同）解决问题，帮助用户做决策。

       比如：我们在度量部分，就融入了我们的度量知识在里头，出什么样的图，表示什么意思等等。

       这些东西是别人偷不走的，学不来的。要不然的话，你做一个PM管理工具，别人也可以做一个PM管理工具，你做一个RM管理工具，别人也可以做一个RM管理工具。谁好用，还真的很难讲呢。后来者，总是可以比前来着基点要高些。