2005,我曾为BOSS狂

snowmanjy @ 2006年04月18日, 12:46:18

  题目看起来八卦么？本来想叫做“我和BOSS不得不说的故事”来着：P 。解释一下，此BOSS不是老板的意思，是Business Operation  Support System业务支撑运营系统的缩写。这套系统基本囊括了电信运营商大部分的业务软件，比如营帐、计费、资源管理、客户管理、渠道管理、跨省业务等等，可谓大而全吧。国内做BOSS的也就那么几家厂商：亚信、联创、思特奇、神州数码（似乎现在应该叫神奇了？）还有已经被Amdocs收购的朗新，华为也可以算是硬生生挤了进来，至于东软大唐一类的恐怕就上不得台面了。这几家公司做的如何，业内也都各有评说，我也就不老话重提了，不过在网上见到了一番妙论，引用一下：
   亚信 年轻的时候我也曾经风流过
   神奇 看上去很美的黄昏恋
   朗新 一片即将凋零的黄叶
   华为 因为你不快乐所以我快乐
   联创 钱路在何方？
   创智 选择离开是一种勇气
  （引自：Jackyding 一句话点评国内BOSS厂商 http://forums.cweek.com.cn/showthread.php?t=749）

   2004年底，我有幸进入了上述其中一家公司。前后一年，转战三省移动，也算是为电信BOSS事业做了点微薄的贡献，期间的酸甜苦辣以及种种体会，今天以千千万万忙碌于修补BOSS系统的工蜂－程序员的角度记录一下。

   第一个感觉：大！相信提到BOSS，这一定是首位的印象。就像上面提到的，包括了这么多功能模块，再想想一个省移动用户的数量，相信BOSS系统怎么也胜任这一好评。

   第二个感觉：乱！其实也可以叫做：看上去很美。想象一下大多数程序员的梦想，当然代表人物是老盖：让很多的人用上自己开发的软件。毫无疑问，BOSS可以圆你这个梦。作为一个省级的软件系统，用户上千万，操作员上万，并发访问上千，就连开发人员都数以百计（单就一家厂商来说），是不是感觉很爽呢？再想象一下这样的场景：某省移动BOSS升级项目启动，一周内七八十人挎着本本，飞往现场，飞机几乎成了包机，是不是看上去很美呢？可是在现场开发测试的时候，你就会时时感觉到一种乱：测试环境乱（主机几十台，数据库几十个，appserver更是多到数不清，今天切库，明天备份，后天倒数据，大后天又要预演，很多时候测试出错找了半天却发现原来是数据库被初始化了：（   还遇到过正在给客户演示时别的部门新手把我们的weblogic进程kill掉了。。）、程序乱（很多时候都是赶鸭子上架，有的刚招来的新手就直接派往前线，至于水平，天知道！程序又怎么能不乱）、项目进度乱（几十个模块各自为政，却又剪不断理还乱，往往要停下进度等别的部门提供相关服务接口）、工作时间就更乱（加班是常事了，连局方的人员也要加班，经常披星戴月的后半夜走出机房，好在还可以欣赏下换班的1860mm们，早上赶回来基本还都能看到系统工程师们兔子般的双眼）。


   第三个感觉：累！加班加班，晚上加周末加，去了趟成都，呆了一个多月，却连附近的青城山峨眉山也没空去玩玩。周末晚饭时多耽搁一两个小时去电子科大门口几个人吃上一顿串串香就是最大的快乐了。某个周日，手头有新加的业务模块要实现，还要找用户签字确认功能，要向项目经理报告模块进度，要掌握组里人员进度，要搭新的测试环境，还要跟别的部门人员要接口。。几近崩溃。干脆本本一合，全都去他的，打车去春熙路看美女去(￣ˇ￣)。坐在春熙路看着悠闲到走路都懒洋洋的成都市民，整个人才放松下来，才意识到生活也可以如此不同。


   第四个感觉：悬！上面也提到过，项目进度的紧张，代码的混乱，人员的良莠不齐，呆的久了，感觉如此庞大的系统真是危机四伏，bug乱窜，有时候真有这样的感叹：就这样的系统就要上线。。可是又能怎样，如此功能庞大高实时高并发的系统，怕是神仙也难做到完美。无怪每个月的数据patch大家都见怪不怪了，无他，造成的问题别超过运营商容忍限度就是好系统了。

  2005年，为这样大的系统折腾了许久，有过很多成就感，责任感，也有过危机感。一路走来，学到很多，成熟很多，虽然忙碌，但是忙的无怨无悔。回首2005，一年的汗水青春只为一个目标。2005，我曾为BOSS狂：）

评论

28 楼 partech 2006-11-02  

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

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

27 楼 clamp 2006-11-02  

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

26 楼 bigpanda 2006-11-02  

edge_hh 写道

后来做ERP，才知道什么叫“业务”了。
上千张表。上百个功能节点。数十个模块互相独立又互有联系。
针对我们的软件使用就有专门的资格认证考试。
就这样，比起sap来，我们的产品的功能还是差得远。。
据说人家系统里有几万张表，太夸张了吧。

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

25 楼 clamp 2006-11-02  

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

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

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

24 楼 lixigua 2006-11-02  

ozzzzzz 写道

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

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

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

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

23 楼 BirdGu 2006-11-02  

引用

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

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

22 楼 ozzzzzz 2006-11-02  

BirdGu 写道

ozzzzzz 写道

BirdGu 写道

国内在大型软件系统的组织，管理，规划方面还有很多路要走。毕竟搞得时间短，人才和经验方面的积累都很不够。

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

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

引用

测试环境乱（主机几十台，数据库几十个，appserver更是多到数不清，今天切库，明天备份，后天倒数据，大后天又要预演，很多时候测试出错找了半天却发现原来是数据库被初始化了：（ 还遇到过正在给客户演示时别的部门新手把我们的weblogic进程kill掉了。。）、程序乱（很多时候都是赶鸭子上架，有的刚招来的新手就直接派往前线，至于水平，天知道！程序又怎么能不乱）、项目进度乱（几十个模块各自为政，却又剪不断理还乱，往往要停下进度等别的部门提供相关服务接口）、

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

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

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

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

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

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

21 楼 BirdGu 2006-11-02  

ozzzzzz 写道

BirdGu 写道

国内在大型软件系统的组织，管理，规划方面还有很多路要走。毕竟搞得时间短，人才和经验方面的积累都很不够。

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

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

引用

测试环境乱（主机几十台，数据库几十个，appserver更是多到数不清，今天切库，明天备份，后天倒数据，大后天又要预演，很多时候测试出错找了半天却发现原来是数据库被初始化了：（ 还遇到过正在给客户演示时别的部门新手把我们的weblogic进程kill掉了。。）、程序乱（很多时候都是赶鸭子上架，有的刚招来的新手就直接派往前线，至于水平，天知道！程序又怎么能不乱）、项目进度乱（几十个模块各自为政，却又剪不断理还乱，往往要停下进度等别的部门提供相关服务接口）、

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

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

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

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

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

20 楼 ozzzzzz 2006-11-02  

BirdGu 写道

国内在大型软件系统的组织，管理，规划方面还有很多路要走。毕竟搞得时间短，人才和经验方面的积累都很不够。

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

19 楼 snowmanjy 2006-11-02  

没想到引发了大家的讨论，很高兴：）个人感觉国内的boss的确太多不足，不管是运营商还是boss厂商都有很多问题。就连移动的1860很多时候对新的业务也是一问三不知。当时做项目时，某省sim卡号和手机号的对应关系居然完全用白话写在word文档里，令我读懂及整理出算法费了很大劲，至今我都怀疑局方有没有人懂这块的规则。。。

18 楼 yuxie 2006-11-02  

BOSS开发上简单一点是因为计费、营业、帐务、接口在加上客服、网站分工很明确，个人管个人的，比如营业，你做的工作只需要插表，当然简单

17 楼 BirdGu 2006-11-02  

国内在大型软件系统的组织，管理，规划方面还有很多路要走。毕竟搞得时间短，人才和经验方面的积累都很不够。

16 楼 zjxiongmao 2006-11-02  

现在依然在为BOSS狂。。。

15 楼 yijingyong 2006-11-01  

ERP是啥的缩写?我...............,别骂我．．．．，看了确实觉得你们有种苦中做乐的感觉，看似有中淡淡的忧伤，但是却看得出来你们是很平淡的面队．呵呵，这就是生活吧？？

14 楼 ozzzzzz 2006-11-01  

JavaInActoin 写道

edge_hh 写道

JavaInActoin 写道

BOSS中技术是核心/url]

我做了2年，计费帐务营业都做过，从一开始的开发到后来参与整个系统的设计。是boss的核心业务吧？
我怎么没觉得技术是核心呢？项目经理都是只会C，不懂面向对象。自诩为精通boss业务，其实连数据库都不会设计的，主要技能是跟更高级领导拍胸脯，跟下属瞪眼睛。
技术更新是由业务需求引起的。
不做ERP，我永远也不会体会到一个大型软件产品在几百个人同时研发时，框架，平台，开发方法，面向对象技术，管理方法等等一切是多么重要。

没BOSS经验，我的判断来自你们的讨论

edge_hh 写道

boss很复杂么？
业务简单的可笑。
反正我当年没有项目到100张表。
技术上复杂的地方无非是数据量大，数据库压力大，可能需要拆表来解决。
其它都是so-so了，体力活而已。

既然业务如此简单，技术自然成核心了，保证数据一致、正确、系统可靠、伸缩...，否则数以百计的开发人员都干什么呢。

其实boss内部的业务规则非常复杂，而且面临的客户也经常有千奇百怪的操作，终端客户更加会有许多的不同要求。而这里动不动就会牵涉数百万的资金。而ERP相对来说业务环境要简单明了的多。

13 楼 ozzzzzz 2006-11-01  

最近给某企业做了一个培训，内容结合boss系统的讲解业务需求分析技术。虽然以前也对电信内部开发的混乱有所耳闻，但是进去一看才知道，比我以前听到的和所设想的还严重不知道多少倍。

12 楼 JavaInActoin 2006-11-01  

edge_hh 写道

JavaInActoin 写道

BOSS中技术是核心/url]

我做了2年，计费帐务营业都做过，从一开始的开发到后来参与整个系统的设计。是boss的核心业务吧？
我怎么没觉得技术是核心呢？项目经理都是只会C，不懂面向对象。自诩为精通boss业务，其实连数据库都不会设计的，主要技能是跟更高级领导拍胸脯，跟下属瞪眼睛。
技术更新是由业务需求引起的。
不做ERP，我永远也不会体会到一个大型软件产品在几百个人同时研发时，框架，平台，开发方法，面向对象技术，管理方法等等一切是多么重要。

没BOSS经验，我的判断来自你们的讨论

edge_hh 写道

boss很复杂么？
业务简单的可笑。
反正我当年没有项目到100张表。
技术上复杂的地方无非是数据量大，数据库压力大，可能需要拆表来解决。
其它都是so-so了，体力活而已。

既然业务如此简单，技术自然成核心了，保证数据一致、正确、系统可靠、伸缩...，否则数以百计的开发人员都干什么呢。

11 楼 edge_hh 2006-11-01  

JavaInActoin 写道

BOSS中技术是核心/url]

我做了2年，计费帐务营业都做过，从一开始的开发到后来参与整个系统的设计。是boss的核心业务吧？

我怎么没觉得技术是核心呢？项目经理都是只会C，不懂面向对象。自诩为精通boss业务，其实连数据库都不会设计的，主要技能是跟更高级领导拍胸脯，跟下属瞪眼睛。

技术更新是由业务需求引起的。
不做ERP，我永远也不会体会到一个大型软件产品在几百个人同时研发时，框架，平台，开发方法，面向对象技术，管理方法等等一切是多么重要。

10 楼 JavaInActoin 2006-11-01  

ERP中业务是核心，BOSS中技术是核心，这倒回答了“技术重要还是业务重要”

9 楼 edge_hh 2006-11-01  

毕业时在神州数码做了两年boss，不过不一样的是转战多省的联通。
回过头看，年轻时写的代码真得十分幼稚，不禁为联通用户捏把汗。。。

呵呵，这种boss项目，因为辛苦，技术含量低，当年我们每个项目写代码的绝大多数都是新手，写出的代码那叫一个五花八门。。
每个项目都是，开始前招一批人，中间和之后再跑一批人。
剩下的人都是应届生（比如我）和领导。

合同一到期，不是应届生了，我当天就走了。

boss很复杂么？
业务简单的可笑。
反正我当年没有项目到100张表。
技术上复杂的地方无非是数据量大，数据库压力大，可能需要拆表来解决。
其它都是so-so了，体力活而已。

后来做ERP，才知道什么叫“业务”了。
上千张表。上百个功能节点。数十个模块互相独立又互有联系。
针对我们的软件使用就有专门的资格认证考试。
就这样，比起sap来，我们的产品的功能还是差得远。。
据说人家系统里有几万张表，太夸张了吧。