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），這樣和客戶溝通起來
才不會雞同鴨講，雙方才可以相互理解。我經?？吹降那闆r是我們的技術人員和客戶
交談時滿口的專業術語，結果搞得客戶一頭霧水，反過來，他還指責客戶不懂技術。
其實，明白自己想做什么的客戶已經是很好的客戶了，不知道自己要做什么，更不懂
怎么做還要指手畫腳的客戶到處存在，但是要明白，是客戶選擇了你，而不是你選擇
了客戶，有了客戶你才有工資拿，心平氣和一點吧；
8.現在你要面對三群人：你的領導、你的組員和你的客戶，和這些人溝通，讓他
們知道你打算怎么做，什么時候要他們做什么準備這些事情將是你的主要工作。既然
溝通這么重要，那些事先定義一下溝通的原則也是一件很要緊的事情。很多溝通原則
都是潛規則，如果你在一個部門時間做長了，對這些規則的運用覺得是一件理所應當
的事情，但是，你現在面對的是多個部門甚至多個單位，不把溝通規則說清楚，你以
后就會吃虧。
下面的東西看起來無聊，其實還是很管用的：第一個是規定信息的流動方式和介
質，是推還是拉。推的意思就是項目經理將主動發布信息，不管通過電話、郵件還是
書面方式，保證將信息傳達到每個人。這種情況適合小項目，人少；拉的意思就是項
目經理就是一個類似web服務器，你自己需要什么信息就去問他。當然，沒有項目經
理把自己搞得那么累，他會用發布信息到公共介質的方式公布信息，簡單的是白板，
復雜一點的是項目的公共信息交互區，潛規則就是我發了你沒去看就不要說我沒告訴
你。說這些看似很無聊，其實里面牽涉信息傳達不完全的責任問題。
當然，這些都是指一般的方式，而且不要絕對化，一般情況下，主動溝通和被動
訪問是同時存在的，尤其是對領導，項目經理更加應該主動去和領導溝通。第二個問
題就是文檔問題，很多人怕寫文檔，但是項目經理一定要牢記“好記性不如爛筆頭”
的道理。有理有時候為什么會說不清呢？就是因為沒有證據。所以項目經理開始就要
和客戶說清楚有些文檔是必須簽字的，比如項目經理的項目日志，每個星期至少讓客
戶簽字，另外所有達成共識的東西，比如會議紀要，甚至領導的講話記錄，都要寫成
文檔，雙方簽字，這樣以后扯皮的時候，就能做到有據可查。記?。赫f了的就和沒說
一樣，只有寫下來大家簽字后才算真正發生了的。
還有一些問題，比如你提交的報告，給領導（包括本方領導和客戶領導）做一個
選擇題，結果領導壓住不批，讓你無所適從，結果拖延了進度。這時候，你可以等，
但是注意要留記錄，標明是誰的責任；另外，如果你在開始階段就和領導商定：如果
批示提交三天后沒有得到領導答復就算對方同意，這樣你就會主動很多。再比如不同
事件的審批流程問題：什么等級的事情記錄在項目日志里、什么等級的事情要雙方項
目經理專門簽署備忘錄、什么等級的事情要雙方領導出面簽署合同附件等等。事先想
得越周到，以后的工作就越主動。
9.好了，做了很多前期工作，定義了一些游戲規則，現在是坐下來做計劃的時候
了。這一節，任意找一本項目管理的書都會說得比我好，所以我就少寫一點，說一些
自己的體會就是了。首先是找幾個關鍵組員，比如客戶業務專家、系統分析員等等，
做一下項目模塊劃分工作。項目分成幾塊去做，每一塊完成什么，模塊之間的信息如
何交換等等。需求定義的是做什么的問題，而這里說的是怎么做的問題。這里要強調
一點：完成一個目標有很多種方式，你要選一種你最熟悉的，而不是看上去最完美的
，這個思路會讓你的項目減少很多風險。有時候客戶會被某種新技術打動，堅持要你
采用那種新技術，你就應該告訴他：你選我做這個項目，就應該容許我采用自己最喜
歡的方式做事情，新技術之所以有誘惑力，就是因為吃虧的人還不多，我不希望你成
為第一批受害者。
采用一個計劃會讓你的工作更加明確，比如用微軟的Project軟件，你填寫完表
格以后，就可以知道這個項目有多少件事情要做，每件事情需要什么資源，他們之間
的前后關系如何，消耗的時間有多長，完成后有什么標志等。所有的結果最后用一個
叫做甘特圖的形式表現出來。你做完這個表以后會驚奇地發現，甘特圖上項目的結束
時間會遠遠落后于你的計劃結束時間（簽合同的人永遠不會先征求你的意見的）。當
然，學過項目管理的人會大談什么WBS、優化路徑之類的東西，但是我的經驗是你再
優化也不可能把這些東西安排到計劃的時間結束。如果你沒碰到這個問題，在我恭喜
你挑了一個輕松活之前，請你再去確認你是否羅列了所有要做的事情和正確評估了他
們所需要的時間。這時候，你就要考慮犧牲一些任務的時間（也意味著質量）了。按
照什么標準犧牲？這個項目的戰略！我們在第三節提到過的戰略。
我的經驗是如果你什么都趕進度，其結果可能就是十件事情你一件也沒做好，想
想多么失敗啊。所以，把資源投到你熟悉和有把握的事情上，最后的結果是十件事情
，你有三件做成了精品，三件完成，還有四件因為某些原因延誤，成績單是否靚麗了
很多呢？戰略決定優先級，而正確排列事情的優先級是一個項目經理能力的主要體現
。 好，現在項目已經完成了前期工作，了解了項目的目標、搞清楚了手上的資源，
制定了項目的策略，然后編制了項目的整體計劃，項目進入實施階段。進入這個階段
反而是項目經理比較空閑的時候，不像前期的時候項目經理要象記者一樣到處和不同
的人接觸，搞清楚他們在說什么，努力猜測他們在想什么和他們的真正目的，那才是
最累人的事情。當然，小項目的項目經理往往自己也是一個資源，要做很多事情，這
時候反而比誰都苦。
項目經理這段時間的主要工作是保持和客戶領導以及自己領導的溝通。和客戶領
導溝通時特別要注意，除非你需要對方給你支持，那么你才需要講得具體一點，否則
，告訴他一切正常就可以了，而且態度要積極一些，千萬不要說一些領導不懂的細節
，比如：“王局長，最近項目進度還算正常，就是JVM經常發生一些內存泄漏的情況
…”王局長：“(*&$@@”。?????????????????????????????????????????????????
摘要: 本文根據我閱讀IBM SOA系列文章的感想，摘要的敘述了SOA中SCA Service Module、SCA Service Component、SDO、BO等核心概念的相互關系，以及如何運用這些組合成靈活的SOA應用
閱讀全文
下午收到的，呵呵，同樣是一張光盤，不過只有10多M，已經上傳到ftp的/SOA學習資料/用友ERP案例學習資料/目錄下。
下一階段覺得我們還是應該分工看一下這些資料，在我們前一階段整理的流程的基礎上，完善一下。
我粗略的看了一下，還是有很多東西值得我們好好研究，比如，第一個HF公司業務講解，上面就特別提到了業務實施的價值，如下：
實施價值：
集中管理：
?? 實現集團內庫存量、產能、運力的實時掌握。
?? 能夠出具各個公司匯總的，相關業務指標的數據。
?? ……
業務協同：
?? 業務信息實時的反映到財務各歸口部門，便于財務分析決策。
?? 銷售信息能夠實時的傳遞到下游相關部門，提高了業務協同的效率。
?? ……
資源平衡：
?? 在集中管理的基礎上，實現了產能平衡，根據訂單要求的交期，有針
對性的安排生產及調撥任務。
?? 根據車輛在途情況，有效的安排車輛的運輸路徑及裝車安排，實現運
輸能力的最大優化。
在我們的業務建模的商業價值一部份，我們就應該多考慮一下如何實現商業價值