2005,我曾为BOSS狂

从我目前观察的情况看，开发这样的软件项目的能力已经比较成熟，而最大的瓶颈在于业务开发和项目的实施部署——也就是说现在的问题大部分还是出在甲方。而这个方面谁能够给甲方的业务帮助越多，谁就将会是最后的优胜者。

这个我了解到的情况好像有些不同。就拿楼主说的：



这些明显都是项目组织和协调方面的问题吧。

另外说个我听说的事情。我一个朋友给一个大型的金融系统做灾难备份系统的设计（哪家的系统就不说了，很大，全国性的。）。照规矩灾备系统是要定期做演习的，系统实施的时候也要做测试的。就是模拟故障导致系统停机，然后看灾备系统能不能按设计运作。但是没人敢做。系统一样也是有很多数据库服务器，应用服务器，就是没有人说得清这些系统的启动顺序！而如果启动顺序有错误，就不能保证整个系统正常工作。大家平时只有求上帝保佑系统不要出故障。自己去吧系统停掉再重起，那是没人敢做这样的事情的。幸好这类系统单个节点的可靠性和冗余度设计都是比较充分的，一般也不容易出事。不过今年上半年出过一次事，系统花了一天才恢复。

另外一件也是这个系统的事。灾备系统在实施的时候要停掉一台服务器一段时间，事先都作了计划，通知了相关的业务子系统，采取了减少影响的措施。结果，服务器停掉没一会，完全不相关的一个子系统的人跑来问，你们是不是把某某服务器停了。原来他们要用到该服务器上的某个文件。但是没有任何文档说明有这样的文件存在，而且会被一个明显不相干的子系统访问，也没有人告诉这个服务器的管理员有这么会事。

这些显然也都是系统设计和开发管理方面的问题。

当然，这些都是前两年的系统了。这两年情况有很大的改进吗？果然如此则幸甚。

这个方面我确实有必要做个专门的讨论了。最近又研究了一下软件危机的问题，结合我们目前的情况，我发现软件工程以前的方向存在一个问题，那就是太多的涉及到开发者，而太少的涉及使用者（客户和用户），实际上这还是没有认清软件主要还是作为一种工具而不是一种消费品产生的。

这算不算是又挖了一个坑？家爱要被你挖成月球了。

这扯的可就大了。
客户还没意思到这个层次，好多问题是无法解决的。

上半年我做数据仓库的项目，本来想象莫像样的搞点业务模型：公司一般只考虑了存储模型，分析模型根本没有建立。 我有此提法，完全被客户否决。他们要的就是报表，要的是数量。那我能怎么办。

我一直认为，客户意识决定了我们生产的产品的好坏。

报表和分析模型又不矛盾
客户理解的是报表，那你就和客户谈报表好了，你自己完全可以用业务模型来支撑的啊。
哪怕客户好几张报表其实都对着一个业务对象，对你也没什么坏处。
事实上很多所谓的商务智能和多维挖掘，转来转去发现最有用的角度还是老的那几张报表。（不排除有做的好的，呵呵）

另外，如果你生产的产品，那么产品特性是你自己定义的，在你把它卖出去之前，只有潜在客户群，其需求是要你自己去思考的，你生产的东西不好，那完全是生产者的事情。

如果是定制项目开发，那么客户要负责的就是明确需求、定义优先级、协调控制等，你做出来的东西是否满足用户需求仍然是你自己的事情。

我读到的数据是8000张表，如果按Data Model Patterns，The Data Model Resource Book里面的方法来设计，是得有这么多。

数了一下我们最大的一个项目，只有3000张表左右，里面还有一些垃圾和重复的，还有好多字典表，真正的实体表大概只有1000不到……

赫赫，别抱怨了。关于乱，其实哪个行业都差不多，BOSS至少还有NGOSS这样的标准存在，其他行业还没有呢！

某天，不乱了，才不正常哩。