2006年5月26日
#
JSP生成中使用了一般会使用表达式语言EL，语法和Freemarker是一致的，都是${...}，在模版中的<c:out value=$${subject.name}>这一类Jsp EL,很多时候这个${…}是不应该被FreeMarker解析的。但是正如
http://michael.nona.name/archives/75 中提到的，FreeMarker中又没有比较好的转义方法，我下午我也想了很久，突然想到一个方法，可以这样：
<c:out value=${'$'}{subject.name}>
即可以完成转义，解决这个冲突，还是比较好用的
由于yanghuan和shushu考试比较多，晚上我和小曹最终再次review了一下我们的作品，还真是发现了一个小细节的地方不妥，又修改了一下。把所有的word文档转成了PDF，相关文件打包成zip文件，通过email发送出去的一刹那，轻松了很多，两个多月的紧张努力和忙碌，终于可以完美的告一段落了。
从4月中旬中间件课程上杨欢、澍澍说起IBM的SOA大赛，对此都有兴趣的我们，当天去听IBM的SOA宣讲会，立即组织了现在的AccelerateSOA团队，并邀请我们的中间件老师绕老师作为我们的指导老师，从最初对SOA几乎仅仅停留在直觉地概念上，每周开一次会讨论，然后各自去学习相应的SOA资料，到我们每个人都比较全面的明白了SOA的内在思想、整体架构 并叹服IBM在架构上的广博与精妙，并在这将近一个月三两天开会，经常msn会议讨论，email交流，到现在整整两个多月了。这两个多月的合作，我们付出了很多，学到了很多，收获了很多，正如杨欢在我们团队blog上总结的，不管如何，我们已经成功了！
6月26日23：18分，我们的作品正式email提交给了IBM组委会。明天我们应该可以得到IBM的确认吧
现在已经陆续考试了，我们比较庆幸，时间安排得还是很合理，在大规模的考试来临之前，圆满地完成了我们的预定计划。接下来的一周，我们都该集中时间准备一下考试了；同时，在空余时间，我们还会继续SOA的学习和积累，备战复赛。
期待北京之行，五强之争，期待现实中与我们的SOA友队，同台交流、畅谈SOA！
在水木bbs上，都在讨论服务规约具体指什么，这个我也是很疑惑，看了我们伟大的模版设计师小曹同学的服务模型设计文档模版，豁然开朗，呵呵。鉴于很多团队也不明朗，特共享小曹同学的英明发现
中文：
http://www-128.ibm.com/developerworks/cn/rational/419_soa/原文：
http://www-128.ibm.com/developerworks/rational/library/05/419_soa/上面叙述得很详细的，尤其是中英文对照，就可以很快理解啦，摘要如下：
用于软件服务的 UML 2.0 Profile 概述
在IBM Rational Sofware Architect 上实现 profile 的目的是为描述服务提供一个共同语言，该 profile 包括了在开发生命周期内的很多活动并且为不同的涉众提供了视图。例如，该 profile 提供为架构师指定服务的能力――在生命周期的早期――使用逻辑划分来描述整个企业范围的服务组合。这个视图再由设计师来细化，设计师开发服务规约说明――结构上的和行为上的――这个服务规约说明担当服务的客户和实现者之间契约的作用。消息视图为设计师对于公共的服务数据定义提供重用信息模型的能力。
蓝色字体部分对应的是
This view is further detailed by designers, who develop the service specifications -- both structural and behavioral -- that act as the contracts between the services' clients and implementers.
可见：
服务规约应该是the service specifications ，也就是服务的契约、调用约定，担当服务的客户和实现者之间契约的作用，同时服务规约包括结构上的和行为上的，这个我的理解是结构上是指消息的类型，或者在SOA中，应该是SDO部分；行为上，就应该是调用接口了
这是我根据上面developerWorks上的理解
今天整理了一下架构设计概要文档，总算基本上写好了。天气实在太热了，上午出去了一会儿就热得有些受不了了。不过还好明天据说要降温。
然后看了一下原始的需求，发现我们到现在还有一个服务设计没有做，前面也一直没有提到。不过比较疑惑，其中的
l 服务规约
l 服务实现分析
这两项分别是什么意思呢？
期待小曹的服务设计模版，呵呵，有模版可以参照的日子还是很惬意的。
终于发现计数器到1000勒，用SnagIt记录下了这个时刻：
呵呵，上午去实验室的时候，老板说要加强和IBM的合作，我就在想，如果我们最终幸运的进入复赛，那么老板会同意的吧?不管了，先把必要的文档写好，过了初赛，到北京玩一圈再说，呵呵
前一段我们因为很多都是通过email群发的方式，来相互传阅文档，同时每个文档由一个负责人来具体控制，我觉得这样很好，不过我们前面的通过ftp共享的方式，我觉得还是需要坚持，前两次咱们总是需要文档的时候，不知道是在具体那封email里面的，就是这个问题。
我看到小曹晚上已经建立了一个docs_release目录了，我们的正式的文档，就ftp上该目录下吧。另外，每个人的文档，还是放在各自的目录下，同时email附件告知。
ps:这次抢到60了，不过看到我们的访问次数马上就要超过1000了。需要注意的是，我们的1000统计是比较精确的，同时没有计算通过RSS访问的，仅仅有Web访问的计数，所以还是挺可喜的。恩，shushu和yanghuan同学，你们多写写心得哦
推荐两篇文章：
介绍 IBM Rational Software Architect http://www-128.ibm.com/developerworks/cn/rational/524_rsa/
基于RSA实现面向服务的体系架构 http://www-128.ibm.com/developerworks/cn/rational/r-rsa-soa/
我们的组件设计，我看了一下水木上的消息，使用一般的软件画出来也可以，要是可能的话，我们也可以考虑使用RSA来画，或许要好看一些？
晚上又重新看了一下IBM的soa ppt，真的很欣赏一句中国古话了，叫“温故而知新，可以为师也”，呵呵，每次看看，都有一些不同的收获。陶潜曾言，“好读书，不求甚解，每有会意，欣然若狂”，大概也是这种意境吧
WEB1.0是以数据为核心，WEB2.0是以人为出发点的互联网
WEB2.0中的一些技术：
Blog： 用户织网，发表新知识，和其他用户内容链接，进而非常自然的组织这些内容。
RSS： 用户产生内容自动分发，定阅
Podcasting： 个人视频/声频的发布/定阅
SNS： blog+人和人之间的链接
WIKI： 用户共同建设一个大百科全书
WEB2.0中很多技术是为了使Web更加有序化，相互连接，有机组织起来
从知识生产的角度看，WEB1.0的任务，是将以前没有放在网上的人类知识，通过商业的力量，放到网上去。WEB2.0的任务是，将这些知识，通过每个用户的浏览求知的力量，协作工作，把知识有机的组织起来，在这个过程中继续将知识深化，并产生新的思想火花；
从内容产生者角度看，WEB1.0是商业公司为主体把内容往网上搬，而WEB2.0则是以用户为主，以简便随意方式，通过blog/podcasting 方式把新内容往网上搬；
从交互性看，WEB1.0是网站对用户为主；WEB2.0是以P2P为主。
从技术上看，WEB客户端化，工作效率越来越高。比如像Ajax技术, GoogleMAP/Gmail里面用得出神入化。
摘自
http://blog.sina.com.cn/u/4951ae02010003ug
昨天收到的快件，一上午就去拿了，呵呵，原来又是一个光盘，这次包括了一个TurboCRM的实施方案，还有就是一些用友ERP的资料，好像这个和上次的一样，奇怪。
仔细看了一下，TurboCRM的资料还是非常有用的，这次是完整的叙述了一个他们公司的一个案例，我觉得这个应该对我们的设计和架构影响比较大的吧，好好看看再说，正好晚上开会可以讨论一下
仔细看了一下，比较可喜的发现，原来TurboCRM软件是支持B/S模式的啊，原来一直以为不能支持的呢，呵呵。该文章详细的介绍了CRM要解决的问题，以及相应的解决方案，然后就是TurboCRM的一些数据资料的结构和构成，仔细看了倒是发现原来很多理解上的不深入。
具体的资料，放在我们的ftp目录SOA学习资料\用友&TurboCRM下了，大家抓紧时间看看，晚上我们看看可以根据这个把设计做什么改进。
我们已经忙碌了一个多月，现在就到最后的冲刺了，我们再加油一把，就可以到北京休息啦！
今天忙碌了一下，把部署视图写好了。前面大家一直讨论的架构设计的事情，现在经过几轮email讨论，我想我们现在也该是基本上意见统一了，就看明天的组件设计，再把这个写好，我们就可以来一个Review了。
下午收到了IBM寄过来的又一个快件，还没有去看，不过比较好玩的是，这次的收件人是我们的队名AccelerateSOA啦，明天去看看再说，好好奇的呢
加油，Accelerate！
摘要: 用友NC系统中外部数据交换平台的简单原理叙述，同时针对我们的soa大赛，做了一些介绍
阅读全文
BlueDavy的
关于Plugin Framework的关键因素 提到了几点
1、 Plugin的编写
一个好的Plugin System对Plugin没有任何编码上的要求，要求的只是其描述文件的编写
2、 Plugin的部署
如何更加方便的去部署一个Plugin，考虑中根据配置从相应的目录或网站搜索Plugin并注册到系统中
3、 Plugin的调用
根据Plugin的描述采取相应的方式调用Plugin，例如webservice方式、socket方式等等
4、 Plugin的交互
也许可以参考Maven的方式，比如需要调用其他的plugin，则采用类似这样的配置或调用<attain plugin=”pluginname” function=”sendmail”/>抑或采用IoC容器注入依赖？？
5、 Plugin的扩展
对于Plugin的扩展，这个Eclipse的扩展点完全值得参考
6、 Plugin的依赖关系的分析
这是我构思中的一个东西，希望系统所有的模块都基于此Plugin Framework，然后我们可以根据这些模块Plugin来分析整个系统中各模块的依赖关系等等，并进行监控，甚至在将来可以图形化的进行配置，图形化搭积木式的搭建自己的系统，^_^
我发现，这个插件体系结构，和SOA中的SCA体系结构，还有Spring中的Beans工厂，有很多相似之处的，如下：
1. SCA的编写：
需要继承SCA的接口。不过，我倒是更加喜欢spring的方式，使用bean来配置一套系统，对每个bean没有编码限制
2. SCA的部署
使用scdl.xml进行部署描述。如果scdl.xml存在于网络中，是否能部署成功这个倒是不清楚。spring中直接使用xml描述，主要是各个Beans的配置
3. SCA的调用
使用binding进行组合调用，现在支持的有SCA Binding、WebService Binding等等。spring中使用属性注入和构造器注入
4. SCA的交互
使用import/export来暴露具体的接口，然后进行调用。直接使用IOC，注入依赖，相互交互是依靠使用预定义接口，实现契约。
5. SCA的扩展
可以使用继承来修改原来的模块，并在运行时通过替换SCA模块达到目的。Plugin的扩展点（Extension Point）的概念到时值得仔细考虑，非常灵活的。Spring中，通过修改配置文件，使用不同的beans来扩展原有系统。
6、 SCA的依赖关系
好像现在ESB中还没有Service Register的实现，其实，分析SCA的配置文件，是可以找到这些依赖的。本来就是一个总线结构的啊。spring中beans工厂的配置文件现在倒是有很多基于eclipse的实现。
先写这几条，这几天在仔细研究这些技术
由于参加soa比赛，才采用了WBM作为商业建模工具，真正见识了IBM的软件有多么的不好用，联想到以前使用微软软件的舒适经历，突然明白了一点，这就是ibm整个软件思路上的一个特点，好象IBM从来就没有把软件的易用性放到开发计划的重要事项中去，从我上大三学习数据库，使用DB2，我就有这种很深的印象了，就是IBM的软件比较大和难于使用，一如它历史上所推崇的大型机。
微软公司的所有软件，在开发的过程中，都有易用性测试和用户反馈，效果也是非常明显的，也因此建立起了今日的微软帝国。同时，再看看google，令人称颂的也是他的简洁和高效。这些例子都说明，在我们今天的软件开发中，用户的需求和易用性是需要特别值得重视的，恰恰这种我们普通用户都可以体会到的好坏，IBM没有重视，也许还是在抱着它当年的大型机之梦在沾沾自喜吧，历史将证明一切！！
今天发本文主要是实在被IBM的软件气死了，由于WBM的cvs协作设计有问题，我们不能使用cvs进行团队开发，只能每个人都在自己的电脑上处理各自的部分。恰恰是这样，让我发现了WBM的又一个明显的问题，那就是使用WBM的import来合并不同的开发结果的时候，超级难用，而且容易出错。已经有无数次这种合并把我辛辛苦苦的成果覆盖了，今天又一次出现这种事情，实在让我气愤难当，我不知道IBM到底使用过WBM来做一个完成得商业建模没有，如果有，那这种显而易见的问题早该发现了！！
想想一个导入合并其实很容易做到很人性化，比如微软的word，合并文档功能就设计的很好，很智能友好；同时，sybase的PowerDesigner的合并也是，使用图形化的方式，一目了然；其实就是eclipse里面的cvs差异，也是显示的很好的嘛，为什么事情一牵涉到IBM，味道就变了呢？
想到了以前看SharpDevelop的开发日记，决策使用SharpDevelop来进行SharpDevelop开发；在Eclipse的开发中，也使用到了这种思想。当你真正来使用的时候，很多问题是显而易见的。
IBM真是想说爱你不容易啊，强烈建议IBM以后的软件设计中更加重视易用性，重视用户体验，这样才可以更好的发展
前面我提到TurboCRM没有找到开源版本，下午我发email给TurboCRM的相关人员，回复如下：
-------------------
你好！非常感谢你对我们公司的来信咨询。关于soa大赛，我们确实是IBM公司的合作伙伴，关于CRM相关学习资料，请到大赛网站下载。对于我们公司产品，我们对IBM公司的承诺是在最后阶段提供给入选的小组。如果你希望对我们公司及产品了解更多，请登陆我们公司网站www.turbocrm.com 或者其他第三方媒体.谢谢！
朱江
6/5
Best Regard!
Rigge Zhu(朱江)
Marketing Manager TurboCRM(Beijing) Limited
----------------------------
另外，请注意，由于TurboCRM好象没有在线CRM部分，现在IBM已经把CRM部分的描述修改了，具体如下（摘自smth）
我正在安排人更新网站中的题目描述，估计几天之后就会更改过来。
事实上，我们的出题人说，这个其实不会有太大的区别。因此我的个人建议是，不要在这?
细节上耽误太多的时间。
http://www-900.ibm.com/cn/software/websphere/events/soacontest/subject.shtml
Old:
于是，2005年8月份凤凰公司引进并成功应用了某在线客户关系管理系统（On Demand CRM?
。CRM通过订阅的方式来提供客户关系管理服务，凤凰公司不需要提供任何硬件、软件和空
间资源，而只需要每月向服务供应商支付65美元。凤凰的销售人员在任何时间和地点只需?
通过普通的Web浏览器就可以使用和管理客户及销售信息，包括客户信息，商机，业务机会
，以及客户及销售信息分析图表等。
New:
于是，2005年8月份凤凰公司引进并在企业内部成功实施了某客户关系管理系统。凤凰的销
售人员在任何时间和地点只需要连接企业内部网，并通过普通的Web浏览器就可以使用和管
理客户及销售信息，包括客户信息，商机，业务机会，以及客户及销售信息分析图表等。
摘要: 本文主要根据在使用WBI时的经验，简单总结了一下WMI Modeler中使用到的对业务建模的模拟
阅读全文
下面这个网址有最新的资料下载
http://www-900.ibm.com/cn/software/websphere/events/soacontest/down.shtml该软件的网址如下：
http://www.turbocrm.com/index.html不过貌似我找了一下，好象没有看到下载的链接地址，好奇怪啊，不是说给一个推荐的开源的CRM么？
另外，好象我们队这一段写blog慢了一些，小曹看看是否有某人该报告大家啦,haha
发信人: Nanjiren.bbs@bbs.tju.edu.cn.no.spam (西方失败), 信区: Java
标 题: 项目经理：做好项目开始阶段的九条经验zz
发信站: 天大求实BBS站 (Mon May 29 12:04:47 2006)
转信站: SJTUBBS!bbsnews.sdu.edu.cn!news2.happynet.org!TJUBBS
本人做项目经理工作多年，感到做这个工作最要紧的就是要明白什么是因地制宜、因
势利导，只有最合适的，没有什么叫对的，什么叫错的，项目经理最忌讳的就是完美
主义倾向，尤其是做技术人员出身的，喜欢寻找标准答案，耽误了工作进度，也迷茫
了自己。以下是本人一些做项目的个人体会，写出来供大家指点，在讨论过程中共同
提高水平。
项目开始阶段是一个最重要的阶段。项目经理在接手一个新项目的时候，首先要
尽可能地多从各个方面了解项目的情况，如：
1. 这个项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什
么问题。在国内很多客户都很不成熟的情况下，千万不要根据项目的名称望文生义地
去想象项目的目标。一个名为“办公自动化”的项目很有可能在你进场以后一个月才
发现客户其实需要的是一个计算机生产管理辅助信息系统系统。前期了解情况的工作
越详细，后面的惊讶就越少，项目的风险就越小。
2.这个项目里牵涉哪些方面的人，如投资方、具体业务干系方、项目建成后的运
营方、技术监督方等等，很多项目里除了业主单位的结构很复杂以外，还有一些其他
单位也会牵涉进来，如项目监理公司、业主的行业主管机构等。项目经理需要了解每
个方面的人对这个项目的看法和期望是什么。事先了解各个方面的看法和期望，可以
让你在做项目碰到问题的时候，就每件事情分析哪些人会在什么方面支持你，哪些人
会出于什么目的反对你，从而提前准备联合朋友去对抗敌人，让事情向你所希望的方
向发展。没有永远的朋友，也没有永远的敌人，只有一致的利益，这句话作为项目经
理是一定要记住的；
3.基本了解了客户的情况后，下面的事情就是了解自己公司各方面对这个项目的
看法。首先是高层领导是否重视，这个决定了你在需要资源的时候，公司是否会根据
你的要求提供最有力的支持。领导口头肯定是说支持的，你需要做的是了解公司对这
个项目的实际期望，是想把项目越做越大还是想赚钱？是想做样板工程还是干脆想敷
衍了事，公司领导对项目的态度决定了你做这个项目的战略，而这个战略方针将对你
做项目计划产生直接的影响；
4.在做整体项目计划前，还要大致计算一下你手上的资源。首先是时间，现在市
场竞争激烈，往往很多项目要求在几乎不可能的时间范围里完成。对于这一点，你在
做项目的风险控制计划的时候要充分考虑。其次是人员，根据项目预算和已往经验，
大致计算一下未来的项目小组有多少种角色，每个角色目前公司是否有人，是否能完
全归这个项目使用，是否需要另外招聘一些人员，招聘的准备工作要尽早启动。最后
就是一些设备的准备，项目所需大件关键设备要尽早预定，以后不管发生设备等人还
是人等设备的情况，浪费的都是你的时间；
5.现在是做项目说明书的时候了。一份好的项目说明书不仅将要做的事情描述得
很清楚（主要是讲做什么，而不是说怎么做），而且把如何检查也说明得很透彻。也
就是说它不仅说明白了要做哪些事情，也让客户的业务人员（一般不懂技术）知道项
目做成什么样就算完成了。简单地说，项目说明书描述项目做哪些事情和每件事情做
到什么程度以及如何检查每一个结果。
6.是到做总体计划的时间了吗？不，你现在已经知道了客户的目标和你手上的资
源，那么做计划以前，你还需要和你的经理和客户充分沟通资源的问题。因为很多资
源是还不明确的，你需要写一份报告，详细分析这个项目的风险以及对资源的需求情
况。如果一些问题不能得到解决的话，将发生什么样的后果。如果资源不够，就要高
层改变策略，增加对这个项目的投入。甚至在条件许可的情况下，有些公司会放弃这
个项目。总之，没有人能完成一个不可能完成的任务，如果项目经理不能尽早发现风
险，那么就只能去当烈士了。
7. 明白了要做哪些事情和你手上的筹码以及你做这个项目的总体策略，现在是
成立项目小组的时候了。很多项目经理都没有自己选择组员的权利，那么，就尽量发
挥你的影响力去寻找那些你想要的人吧。成员的组成根据项目不同，相差较大，很难
有什么具体要求，但是，一定要有精通客户业务的人，很多小项目里，这个人就是项
目经理本人，大项目里会配备行业专家（Industry expert），这样和客户沟通起来
才不会鸡同鸭讲，双方才可以相互理解。我经常看到的情况是我们的技术人员和客户
交谈时满口的专业术语，结果搞得客户一头雾水，反过来，他还指责客户不懂技术。
其实，明白自己想做什么的客户已经是很好的客户了，不知道自己要做什么，更不懂
怎么做还要指手画脚的客户到处存在，但是要明白，是客户选择了你，而不是你选择
了客户，有了客户你才有工资拿，心平气和一点吧；
8.现在你要面对三群人：你的领导、你的组员和你的客户，和这些人沟通，让他
们知道你打算怎么做，什么时候要他们做什么准备这些事情将是你的主要工作。既然
沟通这么重要，那些事先定义一下沟通的原则也是一件很要紧的事情。很多沟通原则
都是潜规则，如果你在一个部门时间做长了，对这些规则的运用觉得是一件理所应当
的事情，但是，你现在面对的是多个部门甚至多个单位，不把沟通规则说清楚，你以
后就会吃亏。
下面的东西看起来无聊，其实还是很管用的：第一个是规定信息的流动方式和介
质，是推还是拉。推的意思就是项目经理将主动发布信息，不管通过电话、邮件还是
书面方式，保证将信息传达到每个人。这种情况适合小项目，人少；拉的意思就是项
目经理就是一个类似web服务器，你自己需要什么信息就去问他。当然，没有项目经
理把自己搞得那么累，他会用发布信息到公共介质的方式公布信息，简单的是白板，
复杂一点的是项目的公共信息交互区，潜规则就是我发了你没去看就不要说我没告诉
你。说这些看似很无聊，其实里面牵涉信息传达不完全的责任问题。
当然，这些都是指一般的方式，而且不要绝对化，一般情况下，主动沟通和被动
访问是同时存在的，尤其是对领导，项目经理更加应该主动去和领导沟通。第二个问
题就是文档问题，很多人怕写文档，但是项目经理一定要牢记“好记性不如烂笔头”
的道理。有理有时候为什么会说不清呢？就是因为没有证据。所以项目经理开始就要
和客户说清楚有些文档是必须签字的，比如项目经理的项目日志，每个星期至少让客
户签字，另外所有达成共识的东西，比如会议纪要，甚至领导的讲话记录，都要写成
文档，双方签字，这样以后扯皮的时候，就能做到有据可查。记住：说了的就和没说
一样，只有写下来大家签字后才算真正发生了的。
还有一些问题，比如你提交的报告，给领导（包括本方领导和客户领导）做一个
选择题，结果领导压住不批，让你无所适从，结果拖延了进度。这时候，你可以等，
但是注意要留记录，标明是谁的责任；另外，如果你在开始阶段就和领导商定：如果
批示提交三天后没有得到领导答复就算对方同意，这样你就会主动很多。再比如不同
事件的审批流程问题：什么等级的事情记录在项目日志里、什么等级的事情要双方项
目经理专门签署备忘录、什么等级的事情要双方领导出面签署合同附件等等。事先想
得越周到，以后的工作就越主动。
9.好了，做了很多前期工作，定义了一些游戏规则，现在是坐下来做计划的时候
了。这一节，任意找一本项目管理的书都会说得比我好，所以我就少写一点，说一些
自己的体会就是了。首先是找几个关键组员，比如客户业务专家、系统分析员等等，
做一下项目模块划分工作。项目分成几块去做，每一块完成什么，模块之间的信息如
何交换等等。需求定义的是做什么的问题，而这里说的是怎么做的问题。这里要强调
一点：完成一个目标有很多种方式，你要选一种你最熟悉的，而不是看上去最完美的
，这个思路会让你的项目减少很多风险。有时候客户会被某种新技术打动，坚持要你
采用那种新技术，你就应该告诉他：你选我做这个项目，就应该容许我采用自己最喜
欢的方式做事情，新技术之所以有诱惑力，就是因为吃亏的人还不多，我不希望你成
为第一批受害者。
采用一个计划会让你的工作更加明确，比如用微软的Project软件，你填写完表
格以后，就可以知道这个项目有多少件事情要做，每件事情需要什么资源，他们之间
的前后关系如何，消耗的时间有多长，完成后有什么标志等。所有的结果最后用一个
叫做甘特图的形式表现出来。你做完这个表以后会惊奇地发现，甘特图上项目的结束
时间会远远落后于你的计划结束时间（签合同的人永远不会先征求你的意见的）。当
然，学过项目管理的人会大谈什么WBS、优化路径之类的东西，但是我的经验是你再
优化也不可能把这些东西安排到计划的时间结束。如果你没碰到这个问题，在我恭喜
你挑了一个轻松活之前，请你再去确认你是否罗列了所有要做的事情和正确评估了他
们所需要的时间。这时候，你就要考虑牺牲一些任务的时间（也意味着质量）了。按
照什么标准牺牲？这个项目的战略！我们在第三节提到过的战略。
我的经验是如果你什么都赶进度，其结果可能就是十件事情你一件也没做好，想
想多么失败啊。所以，把资源投到你熟悉和有把握的事情上，最后的结果是十件事情
，你有三件做成了精品，三件完成，还有四件因为某些原因延误，成绩单是否靓丽了
很多呢？战略决定优先级，而正确排列事情的优先级是一个项目经理能力的主要体现
。 好，现在项目已经完成了前期工作，了解了项目的目标、搞清楚了手上的资源，
制定了项目的策略，然后编制了项目的整体计划，项目进入实施阶段。进入这个阶段
反而是项目经理比较空闲的时候，不像前期的时候项目经理要象记者一样到处和不同
的人接触，搞清楚他们在说什么，努力猜测他们在想什么和他们的真正目的，那才是
最累人的事情。当然，小项目的项目经理往往自己也是一个资源，要做很多事情，这
时候反而比谁都苦。
项目经理这段时间的主要工作是保持和客户领导以及自己领导的沟通。和客户领
导沟通时特别要注意，除非你需要对方给你支持，那么你才需要讲得具体一点，否则
，告诉他一切正常就可以了，而且态度要积极一些，千万不要说一些领导不懂的细节
，比如：“王局长，最近项目进度还算正常，就是JVM经常发生一些内存泄漏的情况
…”王局长：“(*&$@@”。
摘要: 本文根据我阅读IBM SOA系列文章的感想，摘要的叙述了SOA中SCA Service Module、SCA Service Component、SDO、BO等核心概念的相互关系，以及如何运用这些组合成灵活的SOA应用
阅读全文
下午收到的，呵呵，同样是一张光盘，不过只有10多M，已经上传到ftp的/SOA学习资料/用友ERP案例学习资料/目录下。
下一阶段觉得我们还是应该分工看一下这些资料，在我们前一阶段整理的流程的基础上，完善一下。
我粗略的看了一下，还是有很多东西值得我们好好研究，比如，第一个HF公司业务讲解，上面就特别提到了业务实施的价值，如下：
实施价值：
集中管理：
实现集团内库存量、产能、运力的实时掌握。
能够出具各个公司汇总的，相关业务指标的数据。
……
业务协同：
业务信息实时的反映到财务各归口部门，便于财务分析决策。
销售信息能够实时的传递到下游相关部门，提高了业务协同的效率。
……
资源平衡：
在集中管理的基础上，实现了产能平衡，根据订单要求的交期，有针
对性的安排生产及调拨任务。
根据车辆在途情况，有效的安排车辆的运输路径及装车安排，实现运
输能力的最大优化。
在我们的业务建模的商业价值一部份，我们就应该多考虑一下如何实现商业价值