Oracle神諭

　　時間在一點點的過去，但是確保的進度上還是沒有保障。原因何在：
(1)系統的復雜性。
    (2)程序員的差異因素。
    (3)代碼的維護工作。
    (4)缺乏天才程序員的參與。
(5)項目管理方面的問題。

　主唱:葉麗儀

　　曲:顧嘉輝 詞:黃沾

　　浪奔浪流

　　萬里滔滔江水永不休

　　淘盡了世間事

　　混作滔滔一片潮流

　　是喜是愁

　　浪里分不清歡笑悲憂

　　成功失敗

　　浪里看不出有未有

　　愛你恨你

　　問君知否

　　似大江一發不收轉千彎轉千灘

　　亦未平復此中爭斗

　　又有喜又有愁

　　就算分不清歡笑悲憂仍愿翻百千浪

　　在我心中起伏夠

　　隨著人員的增多，在業務量無法與相應的成本進行匹配時，就發生了可怕的事情。一方面是要保證客戶現有訂單的質量和進度，一方面成本的不斷增多也帶來了巨大的壓力。如何進行操作?

　　很多時候我們很樂觀，將事情想象的比較美好，認為事情會按照我們想象的進行。但是事與愿違，很多事情是有很多風險和未知不確定的因素存在的。這這種情況下，危機和風險意識要具備。失敗大于成功的概率，凡事先有最壞的打算，精心準備下一步的步驟，這樣成功的概率就會增加。

　　對手是最近電視劇熱播的節目，通過PPStream周末整整看了兩天才看了一遍。其中比較好看的幾個亮點如下：
(1)密電所的三駕馬車，文為均出思路，黃永青解決難題，郭忠良負責具體實施。三個所向披靡，正是因為其相應的團隊協作。
(2)三本五十六的豪氣，作為日本的一代梟雄，其所有氣魄確實讓人無形中佩服。作為統帥，還是要有相應的氣魄。
    (3)密電所作為研發單位，主要擔當日本的密碼破譯工作，其中科研單位的管理的也是很有學問。
    (4)復雜關系。作為國共關系、國民黨內部派系關系、父女關系、姐妹關系、上下級關系、夫妻關系、同事關系、部門協作關系等等，關系真的是很重要的，也是很微妙的。
    (5)情報也就信息，信息的重要性特別是在戰爭年代，一個情報決定一場戰役的勝負。
(6)密碼編寫和密碼破解，這確實是一場智力游戲。

　　很多事情，經過我們的規劃后就放權讓下面的人執行了。但是很多事情，到了最后的時刻卻發現很多事情沒有按照既定的要求和進度完成。這是什么問題？最主要的問題在于相應的監控出了問題，如何規避響應的問題你。一個是用人要疑，不要認為人可以在沒有任何監控的情況下完成的，人的惰性是始終存在的，要不斷發問不斷向下屬進行監控。二是要規范，很多設計開發相關的問題都來源于不規范，加強規范操作。三是要嚴格驗證，否則很多事情，做了的事情做的結果如何，是不是滿足了客戶的要求。

　　戰國時期有一位老人，名叫塞翁。他養了許多馬，一天馬群中忽然有一匹走失了。鄰居們聽到這事，都來安慰他不必太著急，年齡大了，多注意身體。塞翁見有人勸慰，笑笑說：“丟了一匹馬損失不大，沒準還會帶來福氣。”
鄰居聽了塞翁的話，心里覺得好笑。馬丟了，明明是件壞事，他卻認為也許是好事，顯然是自我安慰而已。可是過了沒幾天，丟馬不僅自動回家，還帶回一匹駿馬。
鄰居聽說馬自己回來了，非常佩服塞翁的預見，向塞翁道賀說：“還是您老有遠見，馬不僅沒有丟，還帶回一匹好馬，真是福氣呀。”
塞翁聽了鄰人的祝賀，反到一點高興的樣子都沒有，憂慮地說：“白白得了一匹好馬，不一定是什么福氣，也許惹出什么麻煩來。”
鄰居們以為他故作姿態純屬老年人的狡猾。心里明明高興，有意不說出來。
塞翁有個獨生子，非常喜歡騎馬。他發現帶回來的那匹馬顧盼生姿，身長蹄大，嘶鳴嘹亮，膘悍神駿，一看就知道是匹好馬。他每天都騎馬出游，心中洋洋得意。
一天，他高興得有些過火，打馬飛奔，一個趔趄，從馬背上跌下來，摔斷了腿。鄰居聽說，紛紛來慰問。
塞翁說：“沒什么，腿摔斷了卻保住性命，或許是福氣呢。”鄰居們覺得他又在胡言亂語。他們想不出，摔斷腿會帶來什么福氣。
不久，匈奴兵大舉入侵，青年人被應征入伍，塞翁的兒子因為摔斷了腿，不能去當兵。入伍的青年都戰死了，唯有塞翁的兒子保全了性命。

作為一個人來說，沒有一個好心情，就很難做好事情。心情和人的積極性有很大的關聯，心情糟糕和郁悶難免會阻塞人的思路，特別是具有開創性質的事情。
保持一個積極、樂觀向上、好的心情，你會做好事情的。

本源是什么的？
什么是本源？

　　軟件開發公司，某種程度應該是企業的IT部門的一個縮影，不僅僅只是IT系統建設，而且也要參與企業的公司規劃以及IT系統上線后的運維。要有長遠的綁定式的成長的戰略，否則完全按照一錘子買賣的話，系統就只能是一個階段式的產物，雙方的關心點無法得到相應的保障。

　　作為軟件開發人員，我們大多探討的是IT系統建設問題，但是IT做好以后相應的處理的運營確是很多決策人很關心的話題。如何提升管理？如何提高客戶的滿意度？如何降低成本？如何有更多的盈利模式？如何如何進行更加精細化的管理？IT運營的細節在什么地方？

     語言是很有意思的東西。因為涉及語言方面，IT從業人員滿嘴都是技術架構、功能、如何實現等等；然而具體行業人士，大多講著自己的語言，拿供應鏈為例總是在講著如何配送、如何盈利、如何運營、如何成本分攤、如何利潤分成等等；雙方在溝通的過程中就發現其中的有若干的障礙產生。不是IT語言不扎實，也不是物流行業的不專業，關鍵是如何搭建一個橋梁，讓兩者的溝通更加順暢。作為IT從業人員，必須要在行業語言上熟悉，上什么山唱什么歌。

　有人把引擎稱為發動機，其實，發動機是一整套動力輸出設備，包括變速齒輪、引擎和傳動軸等等，可見引擎是只是整個發動機的一個部分，但是卻是整個發動機的核心部分，因此把引擎稱為發動機也不為過。
對于引擎，大家都應該不陌生，引擎的主要部分就是氣缸，這里就是整個汽車的動力源泉。氣缸的工作原理我在這里簡單介紹一下，汽缸包括缸體、進氣孔、輸油孔、出氣孔、火花塞和活塞。汽缸通過進氣孔和輸油孔注入汽油和空氣，在汽缸內充分混合，當火花塞點燃混合物后，混合物猛烈地爆炸燃燒，推動活塞向下運動，并產生動力。同時，爆炸氣巨大的壓力還推開單向閥的出氣孔，排出廢氣。而后，汽缸內殘余廢氣逐漸變冷，氣壓變低，汽缸外部的大氣壓又推動活塞向上運動，以準備進行下一次爆炸。這就是簡單的原理。

　　在資源緊張和項目比較多的情況下，一個人要做N多件事情。當項目達到一定量，例如手頭同時有很多個項目同時需要處理的時候，資源達到一定程度的時候，需要做什么？如何進行操作呢？
首先作為大的方向性的指導，保證大家做對的事情；
其次在一些細節的核心的內容上來親自操刀；
其次相信大家能夠做好事情，充分授權；
排程，在什么時間誰要解決什么問題？

在公司的成長的過程中，由于資源的貧瘠，需要對人有不同層次的拔高。例如需要技術創新、需要測試、需要咨詢、需要項目管理、需要人力資源管理等等，于是乎全能型的人的渴求就出現了。經歷過種種的閱歷后，人是成長了。但是在這個過程中又是很容易迷失自我，因為只是因為需要而不斷的救火，但是自己專心的領域或者感興趣的領域卻消失掉了。一方面人的精力是有限的，不可能將所有的知識和經歷都一一涉及；另一方面作為自己如果沒有專心的領域，也缺乏對問題認識的深度。要有自己的立足或看家的本領，又能博采眾長，觸類旁通。做好人，做好事。

做為公司的老板，經歷過早期創業的艱辛得以今天的成就。
對老板來說，公司內部、客戶、供應商等等關系每日都有繁瑣的事情要進行處理，因此每日日理萬機。
對客戶，要較勁腦汁要把客戶拿下或者維護良好的關系。
公司內部，人員、績效、數據、收入、支出、例外等等事情需要理順，對人的知人用人疑人成了家常便飯。
對供應商，總是感覺和自己的差距有些遠，付出的感覺沒有回報，想要的沒有拿到。
應該說老板的思維方式是異于常人的，他們高高在上，獲得眾人的尊重，但是又有幾多憂慮，沒有人能夠理解他們的苦衷，于是信任與疑問的矛盾不斷涌現。

(1)BS軟件還是CS軟件，或者混合架構的方式。CS在Windows窗體的表現方面有得天獨厚的優勢，且采用RAD的方式開發效率極高。BS在基于Internet的方式下，采用Thin Client的IE瀏覽器作為客戶端，表現力不足，且開發效率比較高。但是在低維護成本、軟件實時性等方面有具有一定的優勢。
(2)軟件基本功能，涉及相應的權限體系、SSO、外圍系統的接口對接、流程的自定義、系統的靈活性、可擴展性、安全性；
(3)各個實體功能的完整性及行業軟件的特有因素的體現的比較；
(4)用戶體驗的比較。

　　時間過得飛快，在某一個領域浸淫了N多年的時間，期間的種種使得自己有一種想寫書的沖動。當然自身的文章功力確實不高，甚至于寫的東西也不長。但是這個不影響想寫一點東西的沖動。
寫文章、寫解決方案、寫書，這個是個難度不斷累加的過程，如果沒有深厚的寫作功力再加上相應的行業背景的了解是很難寫出來的。但是某些散落的感想的珍珠希望能夠串聯起來。
書名叫什么呢？這個是個難題，還是暫時先放在一邊。
要寫的內容呢？行業內容、軟件研發、管理流程內容，另外主要偏向與運營內容，如何進行運營。簡單的說就是行業的IT信息化建設。研發的背景作為我個人來說，確實還是可以的，其中的行業技術方面還是需要進一步的補充完善自己的知識體系，運營方面的經驗是比較欠缺的，畢竟自己還沒有從事過直接的運營。這本書對對于我來說也是個不小的挑戰。
寫書的目的呢？其實最主要的將自己的東西能夠有所梳理、沉淀，將相應的應驗進行總結，如果后來從事這個工作或者為行業能夠有一些沉淀的話，也算達到了我期望的境地。
大綱如何呢？這個可能需要逐步的進行整理。

IT信息系統是一項系統工程，在系統的規劃環節，需要提升不同層次的內容，主要包括一下內容：

概況：<系統Vision>
系統ToBe流程：<主體流程圖及相應描述 參考角色圖>
參與者（角色）功能清單：
核心解決方案
項目管理:如何進行項目管理？
公司產品優勢
前景展望。

　　坐在高高的位置，望著湍急的江河，水中怪獸與人不斷浮現互相廝殺；偶爾滑入水面，參與到其中的戰斗。
忽然，江水蔓延，江水洶涌澎湃。

轉發地址：http://cyc7.cycnet.com:8091/cycmis/y_school/content.jsp?id=11262&s_code=1210

忙亂，熱鬧。處處手忙腳亂，時時心神不寧。一切時間似乎都不夠再用，注意力也永遠無法聚焦于一點……凡此種種，有一個特別的名字，叫做浮躁。
浮躁從何而來？起因緣于繁忙。工作繁忙，一人同時辟有多條戰線，一年需要完成多項任務，一天被日程充斥，一時可能有幾件事情需要處理。于是則浮躁，則心不著地，儼然一只上滿發條的時鐘，滴答滴答飛轉！其實不僅只有繁忙，浮躁與計劃也密切相關。事情一多，腦子發懵，心里起火，手足無措。顯然，此情此景，計劃二字則被淹沒。當然，造成浮躁還有一因，或許還十分重要，那就是心理素質。沒有經歷，沒有經驗，心理脆弱，毫無主見。此時此刻，眾多事情壓來，既而丟失計劃，浮躁所有生成條件頓時全部具備，有如電腦病毒一樣瞬間爆發。
有條不紊，按部就班。時時安然，處處井然。單元時間，所有其它均已排除在外，時時刻刻都在輕松有序的勞作……如此這般，也有一個雙音的名字——靜心！
為何需要靜心？目的在于抵擋浮躁。浮躁一來，忙亂姑且不說，工作效果自然沒有成色。工作好壞，并非只是表面上完成與否。工作質量，需要以工作過程的質量作為依托。手忙腳亂的工作，做過工作，心里無所收獲。心猿意馬的追趕進度，完成的僅是表面文章。靜心則不然。靜心可以讓人呼吸勻稱，靜心能夠叫人心明眼亮，靜心幫助人計劃分明、胸有成竹，靜心還能使人處事坦然。
人人都有忙亂之時，人人都有浮躁之舉。而浮躁遺患無窮，當以何物作為護法？若說浮躁是酸，靜心則屬于堿。為避免浮躁，必以靜心相對。高三后半，復習任務繁重，去浮躁，修靜心，好處多多。

　　在貴州貴陽趕回上海的飛機上，時值傍晚。夜幕悄悄降臨，貴陽的夜來的比沿海城市稍稍遲了一些。云彩朵朵，在飛機的腳下匆匆而過。一邊是太陽的余霞，一邊是月亮姑娘的臉龐已露出來，夜晚的黑與白天的白相映成趣。

矛盾是普遍存在的。
////////////////////////////////////////////////////////////////////////////////////////////
淅淅瀝瀝連著下了十幾天雨，終于今天晴朗起來了。
春天到了，萬物復蘇，等待著春姑娘的腳步。

　　這是一個關于鷹的故事。

　　鷹是世界上壽命最長的鳥類，它一生的年齡可達70歲。

　　要活那么長的壽命，它在40歲時必須做出困難卻重要的決定。這時，它的喙變得又長又彎，幾乎碰到胸脯；它的爪子開始老化，無法有效地捕捉獵物；它的羽毛長得又濃又厚，翅膀變得十分沉重，使得飛翔十分吃力。

　　此時的鷹只有兩種選擇：要么等死，要么經過一個十分痛苦的更新過程——150天漫長的蛻變。它必須很努力地飛到山頂，在懸崖上筑巢，并停留在那里，不得飛翔。

　　鷹首先用它的喙擊打巖石，直到其完全脫落，然后靜靜地等待新的喙長出來。鷹會用新長出的喙把爪子上老化的趾甲一根一根拔掉，鮮血一滴滴灑落。當新的趾甲長出來后，鷹便用新的趾甲把身上的羽毛一根一根拔掉。

　　5個月以后，新的羽毛長出來了，鷹重新開始飛翔，重新再度過30年的歲月！

We also introduced some core JBI concepts:

• JBI container 
• JBI components  
  • Service Engines (SE) provide additional ways of building business services  
  • Binding Components (BC) add the necessary transports to have our ESB communicate with the rest of the world
• Service assemblies (SA), which contain service units (SU) 
• Internal and external endpoints
  container
  components: SE BC

SA SU
endpoints

agent 代理
A service such as the Mule JMX agent that is used by or associated with Mule but is not a Mule-managed
service component. An agent is registered with the Mule Manager and has the same lifecycle as the Mule
instance, so you can initialize and destroy resources when the Mule instance starts or stops.
application 應用
Any program that sends data through Mule. An application can be a web application, back office system,
application server, or another Mule instance.『應用程序、后臺辦公系統、應用程序服務器或其它Mule實例』
channel 通道
A logical pathway on which messages are sent
on a messaging framework. Channels connect
services together as well as different Mule nodes
across a local network or the Internet.
configuration builder 配置構造器
A class that knows how to parse a given configuration file. The default configuration builder is the
org.mule.config.MuleXmlConfigurationBuilder class that knows how to parse a Mule XML configuration file.
connector 連接器
The heart of a transport that maintains the configuration and state for the transport.
endpoint  端點
A configuration entity specifying how and where
a message should be routed. The endpoint is
configured in an inbound or outbound router
and specifies where the message should be
sent or from where it should be received, using
which transport (and optionally which connector
in that transport), and which filters should be
applied before routing the message.
Enterprise Service Bus (ESB)
An architecture that allows different applications to communicate with each other by acting as a
transit system for carrying data between applications within or outside your intranet. An ESB provides
transaction management, routing, security, and other functionality for the messages.
filter過濾器
Specifies logic for determining which messages
are routed to a component. You can set filters
on an inbound router to filter which messages
that service component can receive, or you can
set filters on an outbound router to indicate how
you want to route messages after they have been
processed by the service component.
inbound router 入站路由
A Java class that you configure in the Mule configuration file to determine how a service component will
receive messages. The inbound router includes an endpoint that indicates where the messages will come
from.
interceptor 攔截器
A Java class that is used to intercept message flow into a service component. An interceptor can be used
to trigger or monitor events or interrupt the flow of the message.

Transforms 轉換消息格式，針對已注冊的服務提供者的需求將消息從一種格式轉換到另一種格式。
Routes 路由消息，將消息傳輸到已注冊的服務，并保證傳輸的服務質量、服務層的特性。
Augments 擴展信息，在傳輸的內容中添加額外信息，比如關于消息請求者的元數據。在消息中增加新的通信協議內容以滿足服務提供者的需求。
Notifies 通知消息監聽者的特性消息請求。
Secures 安全傳輸，對于傳輸的消息增加消息認證、授權、不可否認性、機密性等機制。

SLD（Style Layer Descriptor）樣式層描述符

基于XML語言

創建樣式，相對比較簡單。
1. SLD Hello World
1.1 Create the SLD File----OK
1.2 Load Your New SLD  ----OK
1.3 Give a FeatureType Your New SLD---OK
View the Style---OK

2. SLD Text Symbolizers 文本符號----OK 存在問題：使用中國地圖顯示異常，請求樣式不適用于圖層，進一步操作？？？？？？
Modify the SLD File to Include Text Symbolizers
<Label>: What label to give each rendered object. Here we use an attribute of the object, "TYPE". The property name is case sensitive. 標簽
<Font>: The font and size the label will have. 字體
<Fill>: The color that we will fill the font with 填充
3. Outlines and Filters -----OK
<ogc:Filter>
 <ogc:Not>
  <ogc:PropertyIsEqualTo>
   <ogc:PropertyName>TYPE</ogc:PropertyName>
   <ogc:Literal>highway</ogc:Literal>
  </ogc:PropertyIsEqualTo>
 </ogc:Not>
</ogc:Filter>

<ogc:PropertyIsLessThan>
<ogc:PropertyIsGreaterThan>

The halo is essentially a buffer outline of the text.  halo文本的暈環

4. What SLDs are, a text approach
SLD (Styled Layer Descriptor) is a specification put out by the OGC, that defines an XML language to allow users to define symbolization of their feature data. It was written to be a complement to their Web Map Service (WMS) specification, by extending it to allow users a way to define how they want to visualize their features.

Then there are 5 types of symbolizers you can use to actually portray the features,
(1)line,  線
(2)polygon, 多邊形
A Polygon Symbolizer has a geometry and a stroke, just like a line symbolizer, but also has a 'fill', defining what color to put in the center. Can be straight color, or a graphic, of varying opacity and the like.
(3)point, 點
A point symbolizer is made up of a geometry and a Graphic. A graphic is made of either an External Graphic, or a Mark, and has an opacity, a size, and a rotation. Opacity is the same as for the other symbolizers, Size is the absolute size of the graphic in pixels (default is to be dynamic), and rotation defines the rotation of the graphic in the clockwise dimension in decimal degrees. A Mark has a well known name (like square, circle, star, ect.), and a fill and a stroke. An External Graphic uses an xlink to refer to the location of an resource on the web to use to represent the point.
(4)text, 文本
A text symbolizer is made up of a Geometry, a Label, a Font, a LabelPlacement, a Halo, and a Fill.
(5)and raster. 光柵
A raster symbolizer consists of a Geometry(幾何學), opacity（透明度）, channel selection(路線選擇), overlap behavior(交疊事件), color map（顏色地圖）, contrast enhancement(對照增強), shaded relief(陰影浮雕) and image outline(圖像輪廓).

 

有一些客戶本身的需求梳理工作沒有進行，但是認識到相應的IT信息建設的必要性。面對這樣的技術方案書，就相對難寫一些。因為巧婦難為無米之炊。
如何編寫這樣的技術方案書？
（1）把握管理的通用性。普遍企業上信息系統，主要針對需要進行管理上提升，加強收入和成本的管理，提升客戶服務滿意度。
（2）把握行業的通用性。針對企業來說，行業的特性也具有普遍性？如何做好企業的運營？行業運營的方案在信息系統中如何體現？
（3）面子工程。作為企業上信息系統，面子形象工程，也是很關鍵的。提升公司的知名度、品牌效應、提升行業規范性等等。
......

STEP 1. Start GeoServer and Login---- OK

用戶名：amdin
密  碼：geoserver

STEP 2. Create a DataStore -------OK

STEP 3. Create The FeatureType---- OK
3415  PROJCS["WGS 72BE / South China Sea Lambert",
  GEOGCS["WGS 72BE",
    DATUM["WGS 72 Transit Broadcast Ephemeris",
      SPHEROID["WGS 72", 6378135.0, 298.26, AUTHORITY["EPSG","7043"]],
      TOWGS84[0.0, 0.0, 1.9, 0.0, 0.0, 0.814, -0.07838062637389662],
      AUTHORITY["EPSG","6324"]],
    PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]],
    UNIT["degree", 0.017453292519943295],
    AXIS["Geodetic longitude", EAST],
    AXIS["Geodetic latitude", NORTH],
    AUTHORITY["EPSG","4324"]],
  PROJECTION["Lambert Conic Conformal (2SP)", AUTHORITY["EPSG","9802"]],
  PARAMETER["central_meridian", 114.0],
  PARAMETER["latitude_of_origin", 21.0],
  PARAMETER["standard_parallel_1", 18.0],
  PARAMETER["false_easting", 500000.0],
  PARAMETER["false_northing", 500000.0],
  PARAMETER["standard_parallel_2", 24.0],
  UNIT["m", 1.0],
  AXIS["Easting", EAST],
  AXIS["Northing", NORTH],
  AUTHORITY["EPSG","3415"]]
 

STEP 4. Try It Out----Exception
出現問題，出現異常
java.lang.reflect.UndeclaredThrowableException

繼續努力===========|||||||||
嘗試變化地圖的文件-----
嘗試修改樣式----失敗
（1）The requested Style can not be used with this layer.  The style specifies an attribute of PERSONS and the layer is: topp:world_adm0
提示樣式不正確。
（2）重新新增樣式

樣式表的問題-----修改為系統原有樣式。系統正常。

Geoserver 下載后運行有比較弱智的問題：
在運行startup.bat后，系統沒有正常運行起來。原因是因為java_home的放在Program Files下，郁悶了小半天，移動了一下位置，終于運行起來了。

（1）產品的核心競爭力。一定要有比別的公司具有競爭力的特性和功能。為什么比別的公司優秀？產品的管理提升（成本、收入）細節點的提升？圍繞公司戰略層面提升核心的競爭力；
（2）品牌。公司的知名度，公司的市場推廣力度，行業中的口碑；
（3）客戶關系管理。對客戶需求的理解和把握，對客戶相關執行的利益體的分析與規劃。

面對未來充滿憧憬與向往，但是一定要面對現實，腳踏實地，將理想轉化為理性的可以操作的實際行動。
從理想主義到實用主義的轉變。

日常工作的安排對一個公司來說，是至關重要的。每個人要明確知道下一步的工作計劃，現在要做什么？這是很有必要的。

有人喝酒絕對不含糊，每人喝上一杯，然后就安排相應的人或者自己就回去了，知道自己酒量但是不得不喝的；
有人喝酒就不考慮酒量，喝了再說；面對自己的戰友和面對別人的勸酒，結果往往喝的酩酊大醉；
有人是先低頭吃，吃了又吃，喝酒啊，慢慢來啊，酒量啊，大得很；
喝酒的幾個原則：
（1）最好不喝酒，如果一定要喝酒，知道自己的量，適合而止；
（2）如果是很多人一起喝，不得不喝的，避免勸酒，喝更大的份量，這是要避諱的；
（3）埋頭先吃，這是對的，最好不要主動敬酒。

    變革是痛苦的，但同時也是必要的。企業要想獲得相應的持續發展，必須要拿出相應的措施和手段來促進相應的發展。
    作為個人也是一樣的，要隨著企業環境和外在環境的變化，不斷調整自己的角色，適應相應的發展。
    從一個資深的軟件工程師轉變成項目經理，從一個項目經理到項目管理辦公室，從項目辦公室到相應的市場營銷管理，從市場營銷管理到公司整個研發、市場、測試實施、銷售、財務、行政、人事等等方面的全面管理，需要不斷的提升自己，自我充電，方能實現一步步的調整。
     整個過程是痛苦的，也是艱辛的。
     今天看了對話視頻中糧集團的董事長說，最終活下來，或者說生存下來的，不是最強大的，也不是最聰明的，而是最適應外界環境的。物競天擇，適者生存。

時間飛一般的流逝，匆匆地趕不上它的腳步。
08年，是在技術和商務上游離的一年；是有很多失敗與教訓的一年；
08年，是忙碌的一年；是能拼搏敢吃苦的隊伍鑄造的一年；是有將領暫露頭角的一年；
09年，即將是收獲的一年；也是繼續耕耘的一年；也是將帥團隊共建的一年。祝愿我們理性、收獲、成長。

    不知不覺公司又剩下最后一天的時間，可是事情卻依然很多沒有處理掉。溝通很重要，很多事情寧愿多打幾個電話，短信不可靠。時間是不等人的，時間一點點過去，不依賴于人的意志，可是人這個主觀的動物總也不能擺脫懶惰、散漫的本性。
    辦事情的人總也很少，而人總是有這樣那樣的缺陷，如何進行有效利用更好？用還是不用？都會成為難題。

（1）事情越來越多，在項目中的有N多To Do List的，如何靜心？
//不要情緒化，理性，做事情能平和的處理每一件事情。
（2）如何以最快的速度進入進入狀態非常關鍵？
//拿到的事情能快速進入到思維中。
（3）因為處理一件事情后，要快速進入到相應的其他事情的處理；How?
//退出機制，一旦退出后，就不再進入。
（4）另外很多事情做到一半打斷，如何做？
//除非很重要很緊急的事情，否則一律擋掉，一心不能兩用。

最后，不要隨心所欲的處理事情，要有計劃性，否則如野馬在荒原中馳騁永遠找不到相應的目標。

需求變更控制
　
　　前面已經說過了，在軟件開發項目開始之前，就要消除“絕不允許發生需求變更”的思想。在項目進行，一旦發生需求變更，更不要不一味的抱怨，也不要去一味地迎合客戶的“新需求”，而是要管理和控制需求變更。
　
　　1、 分級管理客戶需求
　
　　軟件開發項目中，“客戶永遠是對的”和“客戶是上帝”并不完全的正確，因為在已經簽定的項目合同中，任何新需求的變更和增加除了影響項目的正常進行以外，還影響到了客戶的投入收益，所以有的時候項目經理反倒應該為客戶著想。
　
　　對于項目中的需求，可以實行分級管理，以達到對需求變更的控制和管理。
　
　　一級需求（或變更）是關鍵性的需求，這種需求如果不滿足，意味著整個項目不能正常交付使用，前期工作也會被全部否定。這個級別的需求是必須滿足的，否則就意味著否定自已的項目成員和成員的所有努力，所以定為“Urgent”。 這通常是屬于補救性的debug類型，要救火。
　
　　二級需求（或變更）是后續關鍵性需求，它不影響前面工作內容的交付，但不加以滿足，新的項目內容無法提交或繼續，所以是“Necessary”。一般新模塊關鍵性的基礎組件，屬于這個級別。
　
　　三級需求是后續重要的需求，如果不被滿足會令整體項目工作的價值下降，為了體現項目價值，也是開發人員自已的技術價值的證明，所以定為“Needed”。一般性的重大的有價值的全新模塊開發，屬于這個級別。  項目管理者聯盟，項目管理問題。
　
　　以上三個等級是應該實施的，但時間性上可以作優先級的排列。

　　四級需求是改良性需求，沒有滿足這類需求并不影響已有功能的使用，但如果實現了則會更好，定級為“Better”。界面和使用方式的需求，一般在這個檔次。
　
　　五級需求是可選性需求，更多的是偶是一種設想，以及一種可能，通常只是客戶的的一種個人喜好而已，定級為“Maybe”。
　
　　對于四級需求，如果時間和資源條件都允許的話，不妨做下去。對于五級需求，正如對它的描述一樣，做與不做是“Maybe”。
　
　　2、全生命周期的需求變更管理
　
　　各種規模和類型的軟件項目的生命周期大致可以分為三個階段，即項目啟動、項目實施、項目收尾。不要以為需求變更的管理和控制只是發生在項目實施階段，而是要貫穿在整個項目生命周期的全過程中。
　
　　站在全局角度的需求變更管理，需要采用綜合變更控制的方法。
　
　　（1） 項目啟動階段的變更預防
　
　　正如前面強調的，對于任何軟件項目，需求變更都無可避免，也無從逃避，無論是項目經理還是開發人員只能積極應對，而這個應對應該是從項目啟動的需求分析階段就開始了。
　
　　對一個需求分析做得很好的項目來說，基準文件定義的范圍越詳細清晰，用戶跟項目經理提出需求變更的幾率就越小。如果需求沒做好，基準文件里的范圍含糊不清，被客戶發現還有很大的“新需求空間”，這時候項目組往往要付出許多無謂的犧牲。
　
　　如果需求分析做得好，文檔清晰且又有客戶簽字，那么后期客戶提出的變更就超出了合同范圍，需要另外收費。這個時候，項目經理一定要據理力爭，此時這并非要刻意賺取客戶的錢財，而是不能讓客戶養成經常變更的習慣，否則后患無窮。 
　
　　（2） 項目實施階段的需求變更
　
　　成功的軟件項目和失敗項目的區別就在于項目的整個過程是否是可控的。
　
　　項目經理應該樹立一個理念，即“需求變更是必然的、可控的，并且是有益的”。項目實施階段的變更控制需要做的是分析變更請求，評估變更可能帶來的風險和修改基準文件。
　
　　控制需求漸變需要注意以下幾點：
　
　　需求一定要與投入有聯系，如果需求變更的成本由開發方來承擔，則項目需求的變更就成為必然了。所以，在項目的開始，無論是開發方還是出資方都要明確這一條：需求變，軟件開發的投人也要變。
　
　　需求的變更要經過出資者的認可，這樣才會對需求的變更有成本的概念，能夠慎重地對待需求的變更。
　
　　小的需求變更也要經過正規的需求管理流程，否則會積少成多。

　在實踐中，人們往往不愿意為小的需求變更去執行正規的需求管理過程，認為降低了開發效率，浪費了時間。但正是由于這種觀念才使需求逐漸變為不可控，最終導致項目的失敗。
　
　　精確的需求與范圍定義并不會阻止需求的變更。
　
　　并非對需求定義得越細，就越能避免需求的漸變，這是兩個層面的問題。太細的需求定義對需求漸變沒有任何效果。因為需求的變化是永恒的，并非需求寫細了，它就不會變化了。
　
　　注意溝通的技巧。
　
　　項目開發過程中的實際情況是用戶、開發者都認識到了上面的幾點間題，但是由于需求的變更可能來自客戶方，也可能來自開發方，因此，作為需求管理者，項目經理需要采用各種溝通技巧來使項目的各方各得其所。 

冬天的風一陣陣的吹過，展示出寒冷的氣息。

      如果是單純讓你選擇“大”或“小”，你選擇哪一個？一般人是選擇“大”，為什么？規模大、市場大、公司大；某中程度上大成了一個褒義詞。
     其實面對市場的大與小，客戶的大與小，公司的大與小等等，關鍵是自身的駕馭能力，你是否已經準備好了，你是否將相應的風險是否有所準備；面對大客戶，苛刻的質量和流程要求你是否能做到；面對大容量的市場，你如何一些巨頭進行PK，如何獲得自己的生存空間。
     大與小的選擇本身是一個博弈問題，大小適中最好，利潤最佳最好，項目的主體控制權把握會成為關鍵。

      很多事情是投鼠忌器的，擔心客戶知道了，客戶就不會支付。就這樣我們一直處于等待的狀態，我們期望客戶能夠發善心，通過我們的充滿愛心的英勇善戰的方式去解決客戶的問題。結果我們就一直這么扛著，到達一定狀態后，我們感覺距離客戶支付的時間節點遙遙無期，然后我們就采取很強硬的手段去處理。這時候，雙發鬧得很不愉快。其實實現就應該將相應的規則將出來，例如需求和問題的界定，如果軟件始終處于無法凍結代碼編寫的階段，后期的處理就很是被動，如果進入測試、實施、培訓、上線。

      如何處理與客戶之間的關系是一門很深的學問。這不書本上和傳統宣傳上介紹的東西。如何進行博弈、如何進行平衡會成為最大的難題。但是大家講相應的規則進行制定，提早通知溝通、避免后期操作越來越失控，達到無法處理的邊緣，任由客戶的擺布。
     『投鼠忌器』投：用東西去擲；忌：怕，有所顧慮。想用東西打老鼠，又怕打壞了近旁的器物。比喻做事有顧忌，不敢放手干。將“器”進行警告，“老鼠”是一定要打。

    作為軟件公司而言，質量就是生命。但是很多軟件產品，開發出來后，質量卻是很難滿足客戶的需要。
    一方面是軟件研發人員，功能完成的定位就是“我代碼寫了”，軟件功能是否是能運行僅僅是點一點按鈕，然后說“我可以運行”。但是實際上，頁面的展示邏輯混亂，新增、編輯、查看頁面頁面不統一，頁面的菜單項和實際的展示功能根本就不是一回事，保存有問題，很多狀態位沒有調整。很多的“所謂可以運行”，其實都是一些假的東東。
    另外一個方面是測試人員。因為很多軟件公司為了節約軟件研發的成本，對測試工程師很不重視，甚至沒有測試崗位的設置，導致在相應功能開發完畢就丟給了客戶。客戶做為最終的使用者，很難進行具體的使用，成了Bug的最大受害者。可用是沒有經過實際檢驗的，特別是在一些綜合性的管理信息系統的開發過程中。因為功能量比較大，很多小的功能點，作為項目經理也只是對一些主體的功能進行檢測，沒有細化到相應的實際可用的程度。軟件公司對于相應的軟件功能是必須是要進行檢測的，沒有檢測的系統是不可用的。
    最后是文檔的質量，文檔的欠缺似乎成了最大的問題。很多系統完成后，沒有幫助文檔，客戶拿到相應的功能，難以下手。更不用說從相應的系統流程與業務運作流程進行結合了。
    質量是軟件研發公司存在的生命，否則研發出來的系統只能停留在實驗室中，無法在客戶中進行使用，當然軟件本身的價值也就很難得以體現。作為公司也很難拿到相應的回報，進行良性循環的環節。

     天氣愈發的寒冷，昨天周末幾乎睡了整整一天，感冒的襲擊還是讓我有些透不過氣來。窗外濕淋淋的小雨下個不停，身體黏糊糊的不知所為。又到月末，且到了年末，年度的鐘聲聲似乎就在耳邊蕩漾。
    2008年揮揮手就要過去，2009年趕緊著爭著要奔過來洗刷08年的頹廢、不安；我們也在衷心祝愿我們能夠獲得更大的成長。
    失敗、恐懼、磨難、悲觀等等等都為我們提供了可參考的因素的，經歷就是一種財富，不過悲觀，關鍵在于總結失敗的經驗，對未來進行展望和執行。相信我們能渡過這個艱難的時代。
     很多公司都在裁員、很多公司的高管甚至創始人都被迫離開自己的公司、經濟的低靡和蕭條，似乎成了這個世界的主旋律。相對于這些，我們好多了。面對我們的現實場景，摒棄那些偏見。冬天對我們并不可怕，關鍵是我們如何走出冬天，走向我們的明天。不要逃避，不要回避。
     聽，黃浦江邊的汽笛聲和公路上的鳴笛聲似乎也在向我們吶喊，冬天來了，春天還遠么？

已經凌晨了，辦公室里還是人頭串動，鍵盤敲打的聲音吃起彼伏，討論聲也在辦公室內蕩漾，好似美妙的音樂。

2008年一一天的過去，2009年的鐘聲即將敲響。天氣越發的寒冷，讓人頓生寒意。
面對這樣的環境，如何御寒便成了一個很重要的話題。
（1）多多準備衣服；
（2）盡可能不要再外邊待得太久；
（3）抱抱團，一起取暖；
（4）多運動，有目標的打獵，多多準備食物；
（6）信念。冬天來了，春天還會遠么？