#
我来到思奥特公司已经有一年多了，应该是老员工了吧。
但是我近段时间以来感觉到自己的一种无奈，冲不破的霸权管理和无聊可笑的管理者。
于是我想变了。
“穷则思变”，－毛泽东
我想自己是一个超级深水潜水员，因为我喜欢大海，喜欢到大海的最深处，用自己的生物电照亮大海。
我想写一些文章，在谈谈今年的感受，也是IT的人生感受吧。
我想写：软件工业化生产之梦境管理
软件工业化生产之梦境开发
软件工业化生产之JIT生产
软件工业化生产之超级服务者
我很想用WIKI来写这些东西，SPRING的诞生是由一个梦想开始的，软件企业的管理和生产也应该有一些理论的指导吧。我很想写出自己的感受，当然我也需要大家的力量，所以我要加入鹰之队，我要WIKI。
利用现在的空闲时间我要努力学习。我要开创一种利用开源软件做载体来极限学习的方法。
我还有一个伟大的想法，我想开办一个利用开源软件尝试使用到实际应用当中的论坛，我想康比尔，我想OPEN OFFFICE VS M$，我想OPENCMS。。。。。。
可能2006年将给我带来一个应用技术年吧，我想发挥我的一点热量，想重新营造IT界在中国的管理和生产。
请大家关注我的贴子。
2005年在给领导买关子时写的一篇文章。现在读起来也有意思，
大家可以看一看，多拓展一些思路。
多数据库实现数据交换的可行性技术研究
我实施A公司的EAI项目以来，边需求调研和代码开发及最近的正式上线，只用了两个月的时间。项目很快就实施完成了。
今天开会，表示我的EAI项目完成。本来很高兴的事，让领导肯定一下我的成绩，谁知道领导毫不犹豫的把我调到另外一个项目组做CRM分析了，我操（本年度最难听的话），我是万精油呀，到处抹。项目经理一下子变成一个小职员。
CRM是一个烂摊了，即使我做过ERP也知道公司负责CRM调研和分析哪几个人是什么水准。我绝对反对领导这样做，太霸道了，看来这个小公司的弱点已经让我看透了。
埋炸弹。引爆所有程序。
这一段时间，忙于在代码和A公司之间奔波，所以日志也没有时间来写。
今天谈谈我近段时间在客户实施的心得。
到现场实施情况是比较复杂的，所以从刚刚开头我就没有像专家一样的到处都问（调研时可以像专家一样告诉客户一些大道理）。我们的程序是基于合同技术附件签订的，实施也就跟着签字的需求和目标走。
由于前一段时间让一群学生写了一些代码，虽然在质量上我有所“查阅”，但是问题最大的也就是在这里，在实施前只是把大致的错误进行了修改，就匆匆到现场实施。
核心代码由于是自己的思想，也让放心的手下写了，但是还必须得测试和验证其准确性。这是一个重要的工作，也可能会涉及到一些改变。
第一天，到了客户现场，先是对其环境要求，确定完主机和数据库后，就开始安装布置，1个小时后全部搞定，基本上给客户讲了一遍怎么使用（很粗略，因为
以后我们有培训）。接着就联合PDM系统和ERP系统进行测试，还幸运（不相信迷信也这么写），没有出事，用户的输出结果也正确，呵呵，收工回家。
其实，里面的问题很多。只是用户对这个陌生的事物还有好奇的心理，没有深入去学习它。
第二天，接着实施，在不断的测试过程当中，问题就出现了，很小的问题让客户对我的软件产生了怀疑，比如供应商编码和供应商PN号为什么输出是一样的？
员工ID为什么传递不过来？假如PDM发布同一个树但有不同的组成结构时，做的处理不符合我们的实际业务？为什么不同层次的装配件再次发布时，数量不相
加？假如我这一次发布错了，能不能删除？
客户提出了很多问题，我知道我的程序开始让用户认可了，所以我的态度比较友好，（说实在的，哪时候真想找个替身），我把问题罗列出来后，做了归类，并给客户承诺完成时间，并态度友好、热情、友善、和气。。。。的给用户出错原因。当然心态必须是诚实。
一般客户会提出这几类问题。
一、软件本身的BUG，是自己的责任，勇敢的承认自己的错误，合同都签定了，还不让修改一个BUG。
二、在实际需求时，考虑的不充分，或者是技术实现上有制约的地方
三、实际业务和输出结果不符合。
这三类问题，前两类我们很积极并承诺尽快得给用户解决，就是不在合同之内的事也加入代码实现，我们的目的就是先让用户使用起来。
第三类问题，不管用户多么着急，我们也对之的实现优先级降低，同样必须让用户书面提出需求我们再做。
后来的三两天就是修改程序，不过这个时候我手下已经没有人了，所以我自己这两天很辛苦。同样，也发现了很多错误，尤其是表现层，我真是恨这帮学生呀。害的我不得不对之进行修改。
再以后就是实施，就算是我的第二个阶段吧。
这个阶段里，我就象一只狗似的，看见客户负责人就赶紧用舌头去舔人家的脚，（想起了发廊的小M辛苦的为我按摩），晚上人家都下班了，为了赶进度只得自愿加班，晚上经常9点后回家。
这个阶段里，是比较富有成果的，首先把客户前一段时间的BUG和考虑不充分的地方进行了弥补，而且用户对我修改的速度也很佩服。呵呵。（高兴的我自己好象是一个伟大的。。嗯，实施家）
等到用户测试结果正确，不，应该是准确（我的认为），而且从长期的测试来说，我心理比较塌实了，我进行第三个阶段。修改需求并加入新的程序。
这个过程比一个阶段好一些。我可以坐回公司来，上上网，聊聊天，喝口茶，再写写程序了，一两的活两天干，还能混吃两顿饭。呵呵，目前就实施在这里。
对EAI产品本身我给用户提供了一个规则，因为我的软件当中有版本管理和BUG提交模块，所以我每一次的修改就对版本有所影响，小的改动加小版本，大
的改动加大版本，说来也巧，等正式上线刚才从0.8上升到1版本。呵呵。同样用户的BUG管理只开放给系统管理员，我可以每天收集一下BUG，并及时进行
修改。
对TOMCAT中间件服务器和程序本身的性能优化是一个大问题，现在正在解决当中。
程序的稳定性和并发控制也准备在下一期进行修改。
请关注我的贴子。
我没有什么敏捷、什么XP编程的概念，所以我这次的格斗没有套路。
从去年开始我担任了项目经理一职，已经负责公司的三个项目的开发和实施了。
我可以籍以此发表我的看法。
本主题内容是极限开发
首先说说我概念当中的极限开发。
项目特点：面向应用、面向服务的中小企业应用。
先哆嗦一下业务需求：
我们在实际调研企业现状后，最大限度的了解与我们应用范围相关的实际业务。随后进入业务需求分析，其实就是抽象实际业务到软件功能设计。同时考虑到我们应用
范围外的业务，用户可以不太关心这一块，但是我们必须得做。最终的业务需求分析由公司内部评审，（尽管我们的管理不完善，但是我有权力让什么也不懂的领
导参与），再与客户去交涉。直到取得最终评审。
极限开发之前：
我们首先要做概要设计，其实是对前业务需求分析的细化，当然这文档是面向业务的，这个文档是修改最多的，所以在你开始写这个文档以前一定要做好版本管理（包括有效版本的管理）。
概要设计长话短说吧，就是对企业实际业务管理的理想模型，是尽可能的去理想（理智的想象，而不是单纯的想象），同时不能够把软件的功能划分在合同的需求功能之外（这个一定要把握一个度的问题）。
概要设计是一个相对漫长的过程，这个过程马虎不得，一定要有耐心说服用户和有权力的领导，说什么能做，什么不能做，我们为什么这么做，以及变通的业务实现等等。
极限开发之数据库设计篇
大家可能不理解，为什么我首先要对数据库进行设计呀，这个完全和我的习惯有关。（我的地盘我做主）
在对以上概要设计完以后，我的心理就对实际的软件功能有具体的描述了，当然这个是我最清楚了，我在写概要设计的时候会把这些映射成软件的具体实现，并且使
用一些工具比如VISIO在写完概要设计的实际业务时，我会把软件的实现图、逻辑图同时画出来，害怕以后没有时间来想这些，呵呵。
所以在其后的工作当中，我对软件的具体实现就胸有成竹了，所以我直接进行数据库设计。
数据库设计我使用DB Design，这个工具很好用，我在数据库设计时有两个准原则：
原则一：数据库表对应程序功能模块，一个模块一个前缀，并且如果无太多关系的业务模块对应一张表，并且这些表没有关联关系，都是独立的。
原则二：所有的表如果无复杂关系都使用统一的UUID做为主键，同样，如果处理同样的事务，字段名能够统一的话就统一命名，或者有统一规则生成等。
根据以上原则，我的数据库表没有想象当中的复杂，所以在程序实现时就不用考虑数据库间的关系。
极限开发之程序实现－统一增加、删除、修改数据库
数据库设计完以后，就建立映射成实体，并根据现行的软件架构实现统一的对数据库的增加、删除、和修改的操作，比如现在的STRUTS+SRPING+
HIBERNATE的架构，我根据数据库表，生成对本数据库表的增加、删除和修改的类接口，剩下的工作由下面的员工完成，（很想自动生成，但没有时间来写
这些东西。以后这个东东肯定会有人发明）
极限开发之程序实现－封装业务逻辑层
我一般使用VISIO或者现在的WEB FLOW给手下的员工画出程序实现方式，让他们来完成，我的工作是检查他们的代码是不是符合规范，是不是能够符合
业务需求，所以这个时间我的主要工作是质检和修改程序实现的业务逻辑，（有些刚刚毕业的大学生，你要给他讲明实现的业务关系呀，还不如告诉他你应该往哪个
表插入什么数据来得快，这是一个怪圈）
极限开发之程序实现－关键业务实现
关键业务的实现是至关重要的，这个我一个可能是不行，而且可能当时用户的需求在改变或者改进等，所以我就要找一个比较实在、能力比较强的员工来担任这个职务，要尽可能的给他讲明实际的业务和用户需要的效果和目的，说不定他还能帮助你的思维呢。
这个是个重要的环节，所以生产的重点就是这里，在最复杂的业务逻辑时，对程序的处理，一定要画个VISIO或者什么图告诉员工每一步的实现如何做，包括很
多的错误处理等。如果你在这里偷懒了，说明你这个项目的有很多的隐患在其中，这个工作比较艰巨，变数也多，需要多多鼓励员工。
极限开发之程序实现－单元测试
单元测试不是很严格，由公司相关人员测试，不过经过我质检过的代码，一般没有太多问题。
极限开发之程序实现－业务测试
根据项目的实际业务来测试，由我和能力很强和人来测试，最后由测试人员来测试，
极限开发之用户试运行及上线
这个就不用说了，要用服务的意识来帮助客户来认知这个东东，就好象到理发店让小妹妹给你按摩一样，不要害羞。也好象很累了到冼足浴室一样，无微不至引导消费。
我的这三个项目分别是库存管理+财务管理、EAI项目和CRM+服务。
用人最多的时候不超过6人，开发周期没有超过2个月的。
库存管理+财务管理 6人 1.5个月
EAI项目 3人 20个工作日
CRM+服务 5－6人 不到两个月
所有项目均是新写。
今天东看看，西看看，一天全浪费在网上乱逛了。
先是看看淘宝网，想开小店，发现自己的帐号内空空荡荡。修改了一下密码后，就不知道做什么了，
又看看软件项目交易网，东看看、西看看，没有适合自己的软件外包项目，可能自己的能力还不够吧，应该多接受一些实际的应用。尤其是WEB应用这一块，不过通过软件项目交易网也可以看到现在市场的一些需求。
到最后浪费了一天的时间，没有看看OPEN－OPEN，没有学习康比尔，没有看看VITEGER CRM，啊，自己的心太野，就什么也学不会，
君子爱财，取之有道，君子固穷。没有办法。
还好振奋起精神吧。好好学习J2EE技术，为自己以后能够像油条一样积累很多的东东。
左右逢源，左右开弓，多好呀。
Plone
Plone是一种开源的内容管理系统（CMS）。基于Zope，用Python写成。
最早由 Alan Runyan, Alexander Limi, and Vidar Andersen在1999年开始，之后迅速成为流行而又强大的内容管理系统。
Plone
基于 GNU General Public License 发布。它建立在应用服务器Zope和Zope Content Management
Framework（Zope 内容管理框架）之上。Plone的名字来源于一个来自英国伯明汉，叫做Plone的电声乐队
官方网站链接：http://plone.org/
很厉害，仅仅14M左右的东东，就有服务器和国际化的所有东东。佩服。CMS市场是不是做烂了，这么多的开源代码。不过操作方面比OPENCMS容易理解，权限管理不像OPENCMS那么复杂。
北京安特比软件技术公司倾情奉献。
所有资源均来自于网上，本人收集整理，只供学习用途。
如果你要转换其它阅读格式，请保留版本信息。
Compiere ERP使用手册.part1.rar 1423KB | | Compiere ERP使用手册.part2.rar | 1393KB | |
康比尔的学习过程：
难找的汉化地址：http://prdownloads.sourceforge.net/windowutil/
年度工作总结
担任项目经理的职位一年了，尽管自己到现在为止仍然是个不合格的项目经理，但是毕竟站在这个岗位上，主要从事的还是设计和程序实现的工作，加上自己也有志于在这个方向上发展，所以做一个年度总结是有必要的，也希望领导给以指点。
这一年来，主要管理了有两个项目，一个是EAI课题及A公司项目，一个是B公司的二次开发。
EAI课题是今年5月份开始提出来，并由我来担任项目经理的。我很积极的开始工作，并努力配合前方调研和方案建议的撰写。从5月份到7月份是一个EAI课题的调研和需求分析阶段。需求分析由我撰写，并通过公司内部评审；8月份进入设计阶段，概要设计和数据设计由我撰写并通过公司内部评审。9月份开始编码，并在9月底完成代码的编写。
10月份由于公司接到A公司项目的需求，和EAI课题内容很吻合。所以就把原EAI课题实施计划顺延，改变由以A公司的应用集成为主线。10月中旬进入调整期，并在10月底对A公司进行调研和分析，并写出概要设计，通过公司内部评审。
11月份开始编码，并使用两周的时间完成极限编程，11月下旬开始在A公司进行安装调试。其间因为A公司内部的需求有所改变，所以开发也有所影响，致使在12月上旬正式在A公司安装调试，并顺利通过项目验收。
12月份我们就主要开始对EAI课题的另外一个实施方－B公司进行调研编码，在12月份中旬完成对B公司的编码开发工作，12月份下旬安装调试，并顺利通过课题验收，同时得到了用户的认可和肯定。
在EAI课题及A公司项目这个项目当中，时间紧凑也富有挑战性，我合理的安排时间，并对手下的资源充分利用。根据我手下的资源的一些特性，对其分派的任务也有所不同，以下是我在这个项目当中，对资源管理的一些总结：
学
生们可能对企业的实际业务不很了解，就是即使把企业的实际业务抽象的很好，并让学生们去理解，他们对其业务也有很多的疑惑。所以，我对学生在编码上的做法
是：把企业的实际业务抽象成一种计算机语言，并告诉学生这些类主要完成什么功能，对数据库是如何操作的，应该注意的是什么和完成的操作效果是什么。这样做
的话，学生往往能够很快的完成自己的工作。
对项目的控制和质检是必要的，这个对项目的完成质量有很大的关系。因为我的编码实现主要是由学生来完成，所以我对代码的质检是对其代码的检查。对其处理的事务进行细致的查看，所以项目的进度得到了有效的控制。
其次，另外一个项目是对B公司项目的二次开发。
我们主要的工作是二次开发的工作，是对DYNAPDM系统的二次开发，所以我们从刚刚开头时，没有急于编程，而是努力学习，并让手下的资源完成一些TEST功能实现，等到大家对之比较熟悉了，我们才开始编码，尤其这一段时间我们对DYNAPDM的开发总结进行了归档。
等
到我们正式接受B公司的需求并二次开发时，我们的二次开发就开始变得朴素迷离了，因为B公司项目需求的多次变更和完成模板的多次调整，使得我们的二次开发不断
的跟着他们的需求在变更。为此，我们严格了他们对我们的需求，每一个需求是需要共同确认才予以编程，使得后来的编码才有所规范。最终及时完成了B公司项目的
二次开发。
从对DYNAPDM的二次开发来说，我们有以下的总结:
首先，DYNAPDM现行版本不太稳定，导致我们在开发时有所影响。
其次，B公司项目的需求不是太多，也不是太难，但是他的需求多次调整牵扯到我们的很多精力，并且有很多的工作都是无效的，所以以后在对企业调研时应该深入细致的为用户的需求进行判断和确认，免得用户的“拉抽屉”的需求。
最后，我们的员工很努力，虽然项目更改很多，但是我们还是最终及时的完成的项目的二次开发。
总之，这一年又要过去了，虽然工作比较累，但是我在其中也学习到了很多的管理知识，尤其是建立一个规范、高效的开发团队上我已经积累了很多经验。明年将是技术革新最重要的一年，WEB2.0将占据我们的技术生活，很快他将成为业界开发的新的标准。对于我们以技术为主的软件公司来说，应该珍惜这次变革的机会，成为应用这个技术为先的公司，为赢得市场先机而努力。
我
2005-12-20
|