2008年1月2日
#
時間在一點點的過去，但是確保的進度上還是沒有保障。原因何在：
(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）信念。冬天來了，春天還會遠么？
常言道：“疑人不用，用人不疑。”而今在企
業管理中卻流行一個新觀點：“疑人也用，用人也疑。”這個問題的焦點是“疑”和“用”。“用”是目的，“疑”的手段。如果只是用而不疑，那企業遲早必亂；
如果只疑而不用，那企業的人才必定越來越少。疑和用本來就是矛盾的統一，諸葛亮用魏征難道不疑？既然疑為什么還要用他？“取其勇也”！
.C,k4_X]&m+Bw!g0
其實企業的用人，也是一種“風險投資”。選聘人總不太可能一潭水望到底，況且人也在發展變化著，只能說基本符合條件，至于今后是否出色，還有待于實踐的檢
驗。雖有“他究竟能否干好”的疑慮，也還要用著看看，這便是“疑人也用”。疑人也用，是廣開招納人才大門之舉，只要是有用人才，皆可以用。三國演義中甘寧
曾在黃祖處任職，黃祖以“寧可劫江賊”而不重用，后甘寧投奔東吳，破黃祖而立大功；田豐為袁紹手下的謀士，由于袁紹聽信謠言疑而不用，還殺了他，最后招致
大敗。疑人是主觀的東西，人才卻是客觀存在的。如果稍有懷疑就不用，那世間還有什么人才可用？ 中國物流博客 I0[z$en:D [H4B
1e!d#i-j.ku.Y0
而“用人不疑”，說的是企業管理中必需的監督機制。企業管理中，既要有激勵機制，又要有監督制約的機制，這是企業管理不可或缺的“兩個輪子”。沒有監督機
制的管理，名為“放手”，實為“放羊”。想當初英國的巴林銀行對駐新加坡的里森“用人不疑”，結果三年中他一直做假帳隱瞞虧損，最后造成8億多英磅的損
失，迫使有200多年歷史的老牌巴林銀行破產。“用人也疑”的監督制約機制，體現著企業的運行機制的完善。對任何人來說，沒有監督制約機制，就等于沒有有
效的管理，“用人不疑”也就建立在盲目無序的基礎之上，最后難免要出現這樣那樣的問題，甚至是滅頂之災。
“用人不疑”也往往會被解釋為放手不管，任其去干，而“用人也疑”則是放中有管，在放和管中尋求最佳的適應度，使企業管理中激勵機制與監督機制之兩個輪子和諧運轉，并行不悖。
滄海一聲笑 滔滔兩岸潮
浮沉隨浪 只記今朝
蒼天笑 紛紛世上潮
誰負誰勝出 天知曉
江山笑 煙雨遙
濤浪洶盡 紅塵俗世幾多嬌
清風笑 竟惹寂寥
豪情還剩了一襟晚照
蒼生笑 不寂寥
豪情仍在癡癡笑笑
啦 啦 …… …… ……
（1）不要動怒，怒則非理性，不應該說的說了；人是情緒化的動物，但是不能為情緒所左右；
（2）改掉一些口頭禪，言語要為溝通后的結果負責；
學習一下律師！！嚴密的邏輯 + 靜
專注于項目整體生命周期(PLM 包括設計、設計、開發、測試、實施、運維)效率的提升
專注于系統性能提升
猴哥猴哥
你真了不得
五行大山壓不住你
蹦出個孫行者
猴哥猴哥
你真太難得
緊箍咒再念
沒改變老孫的本色
拔一根毫毛
吹出猴萬個
眨一眨眼皮
能把鬼識破
翻個跟斗十萬八千里
抖一抖威風山崩地也裂
哪里有難都想你
哪里有險都有哥
身經百戰打頭陣
懲惡揚善心如佛
你的美名萬人傳
你的故事千家說
金箍棒啊永閃爍
掃清天下濁
當月光灑在我的臉上
我想我就快變了摸樣
有一種叫做撕心裂湯
喝了它有神奇的力量
閉上眼看堂
那是藏著你笑的地方
我躲開個獵人的槍
趕走墳墓爬出的憂傷
你，我變成狼人摸樣
你，染上了瘋狂
你，穿上厚厚的偽裝
你，換了心腸
我們還能不能再見面
我在佛前苦苦求了幾千年
愿意用幾世換我們一世情緣
希望可以感動上天
我們還能不能能不能再見面
我在佛前苦苦求了幾千年
當我在踏過這條奈何橋之前
讓我再吻一吻你的臉
讓我再吻一吻你的臉
答：掌握足夠的信息 一個人不可能成為全才，但是一個人可以做為信息整合專家。快速匯總、分類、整理、模塊化、可編寫方案、可演示功能。
外勤隊伍，主要是在客戶現場一線進行服務的人員。這些人員在某種程度上相當于公司代表，其一言一行關系到客戶對公司的評價問題，實在馬虎不得。
其人員的要求也比較高：（1）心理承受能力強，（2）工作能力強，（3）溝通能力強。三者缺一不可。由于身在客戶現場，長時間和自己熟悉的朋友不在一起，難免寂寞孤單；客戶現場的情況可以說錯綜復雜的，沒有相應工作處理能力，將使得客戶對我們的客服代表產生懷疑，將產生更多不良的效果；溝通能力更是需要，在很多事情的處理上，只有雙方進行有效配合，才能達到相應的結果，否則單方面的努力是無濟于事，沒有實際的效果的。
一時落魄不免膽寒
那怕失去希望
每日醉茫茫
無魂有體親像稻草人
人生可比是海上的波浪
有時起有時落
好運歹運
總嘛要照起來行
三分天注定
七分靠打拼
愛拼才會贏
男兒當自強
林子祥
傲氣傲笑萬重浪
熱血熱勝紅日光
膽似鐵打骨似精鋼
胸襟百千丈眼光萬里長
誓奮發自強做好漢
做個好漢子每天要自強
熱血男子熱勝紅日光
讓海天為我聚能量
去開辟天地為我理想去闖
(碧波高漲)
又看碧空廣闊浩氣揚
即是男兒當自強
強步挺胸大家做棟梁做好漢
用我百點熱耀出千分光
做個好漢子
熱血熱腸熱
熱勝紅日光
歌詞：
從那遙遠海邊慢慢消失的你
本來模糊的臉竟然漸漸清晰
想要說些什麼又不知從何說起
只有把它放在心底
茫然走在海邊看那潮來潮去
徒勞無功想把每朵浪花記清
想要說聲愛你卻被吹散在風里
猛然回頭你在那里
如果大海能夠喚回曾經的愛
就讓我用一生等待
如果深情往事你已不再留戀
就讓它隨風飄遠
如果大海能夠帶走我的哀愁
就像帶走每條河流
所有受過的傷
所有流過的淚
我的愛
請全部帶走
今天我寒夜里看雪飄過
懷著冷卻了的心窩飄遠方
風雨里追趕
霧里分不清影蹤
天空海闊你與我
可會變(誰沒在變)
多少次迎著冷眼與嘲笑
從沒有放棄過心中的理想
一剎那恍惚
若有所失的感覺
不知不覺已變淡
心里愛(誰明白我)
原諒我這一生不羈放縱愛自由
也會怕有一天會跌倒
被棄了理想誰人都可以
那會怕有一天只你共我
今天我寒夜里看雪飄過
懷著冷卻了的心窩飄遠方
風雨里追趕
霧里分不清影蹤
天空海闊你與我
可會變(誰沒在變)
原諒我這一生不羈放縱愛自由
也會怕有一天會跌倒
被棄了理想誰人都可以
那會怕有一天只你共我
仍然自由自我
永遠高唱我歌
走遍千里
原諒我這一生不羈放縱愛自由
也會怕有一天會跌倒
被棄了理想誰人都可以
那會怕有一天只你共我
被棄了理想誰人都可以
那會怕有一天只你共我
原諒我這一生不羈放縱愛自由
也會怕有一天會跌倒
被棄了理想誰人都可以
那會怕有一天只你共我
主唱:葉麗儀
曲:顧嘉輝 詞:黃沾
浪奔浪流
萬里滔滔江水永不休
淘盡了世間事
混作滔滔一片潮流
是喜是愁
浪里分不清歡笑悲憂
成功失敗
浪里看不出有未有
愛你恨你
問君知否
似大江一發不收轉千彎轉千灘
亦未平復此中爭斗
又有喜又有愁
就算分不清歡笑悲憂仍愿翻百千浪
在我心中起伏夠
天氣越來越冷了，冬天一天天逼近，穿的都厚了！準備過冬了。
親愛的紅杉旗下公司CEO，
現在到了十分危急的時刻。大家注意到谷歌、雅虎和思科等公司最近的股價了嗎？他們全都暴跌。谷歌的市盈率已跌至只有原來的二十分之一。你們知道這意味著什么嗎？紅杉資本合伙人的凈資產總計損失達幾十億美元。數十億美元啊！遭受如此大的損失，我們現在都不再是億萬富豪了。當初，納斯達克突破2500點時，我們公司至少有六個億萬富豪。現在一個都沒有了。也就是說，本打算50出頭退休的我們，現在若想實現億萬富豪的人生目標，大多數人只能繼續奮斗下去。我們也許再也看不到10億美元了？還是打消這種想法吧。
大家應該了解的另一件事是，在我們有限的投資者面前，我們再次顯得山窮水盡了。我們在互聯網泡沫破裂時也曾遭遇類似的危機，當時，我們過于自信，在那種情況下還堅持投資了Webvan和eToys。盡管我們的創始人唐•瓦倫丁(Don Valentine)早在1999年中期就預測“將有許多互聯網公司破產”，但我們仍做出這些投資。現在全世界都知道，我們是慘敗而歸。我們不得不站在所有投資者面前，對我們如此愚蠢的行為表示歉意。想想吧，紅杉資本竟然公開道歉！
也許，一系列投資的成功沖昏了我們的頭腦，讓我們不知不覺放松了警惕。我們在YouTube的投資帶來了8億美元的回報，投資其他Web 2.0公司也讓我們獲利數百萬美元。我們本應該更早敲響警鐘，現在，我們想提醒大家再次注意紅杉資本對我們所投資的公司的各項要求：
1. 市場規模和時機就是一切！我們不會花錢去告訴人們，他們為何要喜歡你們的產品。很多VC在剛起步的公司身上浪費了幾十億美元，這些公司在市場尚未形成之前便去開發產品。
2. 我們還要重申一下第一點的重要性，也就是說，市場規模比你們本人更加重要。正如我們一向說的那樣，你們不能改變市場機遇，但可以撤換CEO。
3. 我們的投資理念是，僅僅用一根火柴點燃地獄般的火海。假如你們不理解這個類比，我們再解釋一遍，那就是產品一定要做到節約，節約，再節約！任何剛剛起步的公司只有兩項任務：一是“生產產品”，一是“銷售產品”。如果你們的團隊中有人做不到這兩點，那就炒他的魷魚。
4. 不要租用昂貴的辦公樓，不要鋪張浪費。
5. 聘請一些年輕聰慧的移民。他們的薪水比最低工資水平稍高，每周可以工作100個小時以上——相信我們。紅杉資本有個秘密：過去15年，在我們多數最劃算的投資交易中，對方的創業團隊中都有二十出頭、很有拼勁的年輕移民，例如谷歌的塞吉•布林(Sergey Brin)和YouTube的陳士駿。
6. 一旦產品開發出來，你們就應該考慮減少工程師數量，因為他們中很多人已不再有用。工程效率才是至關重要的！
7. 管理層每一個人都應參與產品銷售，這樣，管理人員才能真正了解自己所銷售的產品以及如何成功進行銷售。這件事情必須在擴大銷售團隊之前進行。
8. 解散吃得肥頭大耳的銷售團隊，硅谷到處充斥著這些拿著高額底薪和獎金的銷售人員。把底薪控制在最低水平，在銷售人員實現較高的銷售目標后再給予他們大量獎勵。
9. 要明察市場，打擊競爭對手，揭露他們的缺陷，在經濟不景氣的情況下更要如此。他們受傷了，才會安靜下來。絕不能像他們一樣。要么進攻，要么等死。
10. 現金比你媽媽更重要！(你們已經領會到這一點了嗎？)
現在的確已到了危急時刻。與其它所有投資集團一樣，我們也通過PowerPoint解釋當前世界上正在發生的事情，但我們也不知道到底怎么了。我們唯一清楚的是，將類似YouTube這樣一家已沒有多大盈利空間的公司以超過16億美元價格賣給谷歌的日子已經一去不復返了，至少現在來說是這樣的。如果你們仍對自己的公司抱有這種幻想，那么在下一輪融資行動中，你們可能要到Kleiner Perkins碰運氣了，我們將不再向你們提供資金。
讓我們重申一次：在用光我們提供的資金之前，你們的現金流仍沒有什么起色的話，那就不要再伸手向我們要錢！
從煙臺回來后，每天的工作任意性有些太強，是要盡快安排自己的事情列表，并且按照計劃去執行。
計劃----執行----監控
有一段時間沒有寫Blog了，手是生了很多。
操作要規范：
(1)方法論的總結：任何事情要講究一個方法論，講究現實的操作意義；
(2)制度的完善：制度的完善非常重要的，沒有規矩，不成方圓。
具備咨詢顧問的幾個前提條件：
（1）扎實的行業背景的了解；
（2）收集資料(其實最為關鍵的就是這個東西，在相應的產品展示方面，一般只有幾個小時，如果不能抓住重點，抓住受眾的注意力，即使你具備相應很深厚的功力，對方也不會對你認可的。)；
（3）急人所急，把握對方的心理。從根本上，是需要心理學上把握一下。身體語言很重要。
什么是啞鈴型管理模式
啞鈴型管理模式是指企業的產品開發和
營銷能力強，
生產能力相對較弱的一種組織結構形式，是一種中間小、兩頭大的管理。在管理方式上，啞鈴型管理模式重點抓研究開發和
市場營銷環節，而生產環節主要以組裝為主，少數關鍵、重要零部件由自己生產，多數零部件則是擇優選擇生產廠家進行外協和外購。在繼續搞好
生產管理的同時，提高
市場營銷能力和產品開發能力。
與啞鈴型管理模式對應的是橄欖型管理模式。
啞鈴型管理模式的特點
通常而言，啞鈴型管理模式的企業要力求經常保持四類產品：
1.正在市場上銷售的產品；
2.已經研究成功并不斷加以改進、等待適當時機投入市場的產品；
3.正在試制的產品；
4.正在構思或開始實驗的。
“啞鈴型”管理模式的“五個接軌”
（一）實現領導班子思維定勢的轉軌：由簡單生產型轉為依靠科技進步型。
（二）實現企業管理觀念的轉軌：由重生產輕開發轉為重開發重科研。
（三）實現適應市場需求的經營戰略轉軌：由被動靠市場搶占市場引導市場。
（四）實現技術改造投入規模的轉軌：由“生計型”投人轉為“發展型、擴張型”投入。
（五）實現管理方式的轉軌：由傳統方式管理轉為科學管理。
單一事務處理是比較簡單的，但是隨著項目越來越多，項目進度一步步的逼近，如何來把握繁雜的事務就非常關鍵。
首先，要把握一個清晰的主線，不能漫天撒網，搞個不停。主流程和做對的事情。
其次，分擔一些相應的工作。
最后，要注意調節大家都心情，在高負荷工作下，要讓人的心理趨于平衡。
感覺自己不能集中精力，似乎一切都別人掌控中。
感覺很是被動，不知道世界變得如此混亂污濁不堪。搞不清方向，理不清頭緒。
兄弟們都在干活，我卻沒有辦法聚焦。
頭腦冷靜、冷靜、再冷靜。
第二天就要交貨，晚上就要Beta測試，這個時間你該做什么？
--（1）走動管理，檢查目前的進度，如果發現有疑問，及時解決。
--（2）主動承擔一些任務。
--（3）鼓勵一下大家，調用大家都積極性。
入 業務 出 業務
入 技術 出 技術
入 代買 出 代碼
游 刃 有 余
1判斷select選項中 是否存在Value="paraValue"的Item
2向select選項中 加入一個Item
3從select選項中 刪除一個Item
4刪除select中選中的項
5修改select選項中 value="paraValue"的text為"paraText"
6設置select中text="paraText"的第一個Item為選中
7設置select中value="paraValue"的Item為選中
8得到select的當前選中項的value
9得到select的當前選中項的text
10得到select的當前選中項的Index
11清空select的項
js 代碼
// 1.判斷select選項中 是否存在Value="paraValue"的Item
function jsSelectIsExitItem(objSelect, objItemValue) {
var isExit = false;
for (var i = 0; i < objSelect.options.length; i++) {
if (objSelect.options[i].value == objItemValue) {
isExit = true;
break;
}
}
return isExit;
}
// 2.向select選項中 加入一個Item
function jsAddItemToSelect(objSelect, objItemText, objItemValue) {
//判斷是否存在
if (jsSelectIsExitItem(objSelect, objItemValue)) {
alert("該Item的Value值已經存在");
} else {
var varItem = new Option(objItemText, objItemValue);
objSelect.options.add(varItem);
alert("成功加入");
}
}
// 3.從select選項中 刪除一個Item
function jsRemoveItemFromSelect(objSelect, objItemValue) {
//判斷是否存在
if (jsSelectIsExitItem(objSelect, objItemValue)) {
for (var i = 0; i < objSelect.options.length; i++) {
if (objSelect.options[i].value == objItemValue) {
objSelect.options.remove(i);
break;
}
}
alert("成功刪除");
} else {
alert("該select中 不存在該項");
}
}
// 4.刪除select中選中的項
function jsRemoveSelectedItemFromSelect(objSelect) {
var length = objSelect.options.length - 1;
for(var i = length; i >= 0; i--){
if(objSelect[i].selected == true){
objSelect.options[i] = null;
}
}
}
// 5.修改select選項中 value="paraValue"的text為"paraText"
function jsUpdateItemToSelect(objSelect, objItemText, objItemValue) {
//判斷是否存在
if (jsSelectIsExitItem(objSelect, objItemValue)) {
for (var i = 0; i < objSelect.options.length; i++) {
if (objSelect.options[i].value == objItemValue) {
objSelect.options[i].text = objItemText;
break;
}
}
alert("成功修改");
} else {
alert("該select中 不存在該項");
}
}
// 6.設置select中text="paraText"的第一個Item為選中
function jsSelectItemByValue(objSelect, objItemText) {
//判斷是否存在
var isExit = false;
for (var i = 0; i < objSelect.options.length; i++) {
if (objSelect.options[i].text == objItemText) {
objSelect.options[i].selected = true;
isExit = true;
break;
}
}
//Show出結果
if (isExit) {
alert("成功選中");
} else {
alert("該select中 不存在該項");
}
}
// 7.設置select中value="paraValue"的Item為選中
document.all.objSelect.value = objItemValue;
// 8.得到select的當前選中項的value
var currSelectValue = document.all.objSelect.value;
// 9.得到select的當前選中項的text
var currSelectText = document.all.objSelect.options[document.all.objSelect.selectedIndex].text;
// 10.得到select的當前選中項的Index
var currSelectIndex = document.all.objSelect.selectedIndex;
// 11.清空select的項
document.all.objSelect.options.length = 0;
凡事
(1)膽大，要敢于打破常規，從相應的解決方案去思考并解決問題。
(2)心細，要針對細微處的問題進入著手，將相應的紛繁復雜的業務中整體相應的脈絡，并且將相應的血肉進行填補。
競爭變成驅動力分兩種情況：內部項目和外部項目（外部客戶）。從內部來看，當組織意識到很多工作自己做比外部獲得花更大的成本時，問題就產生了。從外部來看，當公司不再有價格、質量優勢，也不能增加其市場份額時，公司也就有麻煩了。
在很多事情去做的時候，由于信息的不對稱，以及所做事情時主觀的態度，最后就表現為盲目的樂觀。
避免盲目樂觀要做到如下幾個方面：
（1）信息盡可能對稱，要了解各方面的信息，分析信息。
（2）要有一定的風險意識，很多事情其實風險就是結果。
難得有時間玩一把魔獸， 輸了，有些可惜。把錄像仔細看了一下有以下經驗教訓：
(1)要勤于練兵，作戰前的練兵（打獵）是很有必要的，有幾次我的部隊都在喝水，老是怕死掉。對方的部隊卻是一直在練兵，部隊的作戰能力非常高。
(2)將一些缺血的士兵拉回后方休息，不要在前線，將其安排在大本營內部或者將補血站。這些部隊的單獨操作非常關鍵。
(3)頭腦一定要冷靜，特別在大規模作戰的時候。因為這個時候，其實雙方的力量是比較均衡的，但是攻擊那一個，后攻擊那一個就很是關鍵了。其實ALT的要經常使用，觀察自己的弱點和對方部隊的弱點。
(4)一些參數，每個士兵的血量和錢的多少要清清楚楚；
高層對信息技術的看法
重新設計操作和支持流程 The redesign of operational & support processes
信息技術使用過程中的線性領導
更干的業務導向型的首席信息官A business-oriented highly capable CIO “the IT leader must be a full player” "the CIO must know the business" 商業的機會和許多特定的商業戰略
承諾對信息技術進行投資 A commitment to invest in IT.
變革的有效管理 The effective management of change
Lot for Lot--按需訂貨
MRP的一種訂貨技術，生成的計劃訂單在數量上等于每個時間段的凈需求量。
ROUNDING PROFILE：是用來定議訂購單位是否有小數位。比如：訂購單位為KPC，我們允許它有小數位，就設置ROUNDING PROFILE為0002；如果是其它訂購單位的，假如我們不允許它們有小數位，我們就設置它為0001。
For each order proposal, the system calculates the date that it must be converted into either a purchase order or a production order so that the purchase order can be sent to the vendor on time or the production order can be transferred to production on time. Naturally, the vendor can only deliver the ordered quantity punctually if he receives the purchase order on time. The same applies to production - the ordered quantity can only be produced according to schedule if the production order is received on time.
昨天在客戶在一起聊系統流程的時候，客戶說了幾句話，很值得思考。
“主管評價任務好壞、檢查執行情況。
主管減少批量分配任務給下屬。
將任務列表列出。
由一個人執行完畢后，再分配下一個任務。
任務的指派還是由主管完成。
可以由下屬主動去爭取下一個任務。
任務數與相應的績效掛鉤。
”
有點意思！
例外事務管理也就是非正常業務發生業務。
在實際的執行過程中，有很多打斷你當前計劃的事務，這些事情是最容易出現問題的。
針對這些事務的處理尤為關鍵。
Review
To look over, study, or examine again.
復習，檢查：重新仔細察看、研究或檢查
To examine with an eye to criticism or correction:
批評，評論：用批評或糾正的眼光檢查：
reviewed the research findings.
評論研究發現
-----------------------------------------------------
英文的這個詞語確實很不錯。
在很多日常工作中，正是因為缺少了Review的過程，直到我們把相應的時間耗盡，一天天接近交付的時間。最后，我們交付了。客戶開始進行驗收，進行整體的Review，結果發現這個東東是有很多問題的，根本沒有辦法正式使用起來的。
Review什么：a.描述問題 b.缺少內容 c.半成品 d.流程圖 e.編號問題 f.格式 g.是否達到下一階段目的
Review 的方式：a.交叉Review （多輪） b.項目負責人Review c.會議室Review
今天你Review了么？
輔助而不是武斷地替代。
支持而不是情緒化操作。
目標一致，項目搞定！
排程能力；
風險預見及處理能力；
執行力；
協調能力；
很多事情，我們在苦思冥想。其實道就在你身旁，你沒有深思，沒有琢磨，一味地在動。
設計源于思考。設計源于借鑒，他山之石，可以攻玉。
一個完善的國際委外加工體系，使得全球的生產和營銷變得得心應手。大家都知道日本豐田的汽車制造銷售總額已經位居世界汽車制造業的第二位，并成為全球汽車制造業盈利總額和利潤率最高的企業。但很多人不知道，日本并不制造汽車，就像“耐克”不制造“鞋子”，“宜家”不制造家具一樣，它只是組裝汽車。它的汽車零件全部委外加工和采購，二三百個供應商替它生產汽車零部件，日本人只是負責組裝、設計。這種戰略和驕人的業績，就是建立在高度標準化的委外加工戰略的基礎上的，否則僅依靠豐田公司是無法做到的。
上述案例說明，委外加工的經營方式是世界大型企業常用的較為成熟的非常有效的一種方法，大凡世界500強的企業都是委外加工的典范，他們作為終端企業，緊緊抓住設計和市場，將生產直接委外加工，大大降低了成本，降低了企業負擔和管理的復雜性，并能集中精力開拓市場，抓好銷售、設計和物流環節，致使他們能快速復制，快速擴充，快速做大做強。他們利用的是全球的資源，通過專業化分工，達到互利互惠的目的，并使龍頭企業享盡其優勢，并使其發揮了引導、管理和提升的作用。
什么叫專業水準？
溝通---OK 作為經常在客戶現場溝通過程中的，已經都是OK的。
文檔---作為整體是比較欠缺的，因為一是不重視，二是ouxie因為寫的數量還是有些少，再一個可能是確實在專業上把握的不夠到位。
指導---而不是讓客戶牽著鼻子走。你考慮了客戶沒有考慮的問題。
（1）特定時間：在具體相應的時間范圍內，不能超過這個時間，任何操作這個時間范圍內的都是不允許的。項目每每延遲，都是因為相應的時間方面沒有處理好。關鍵是項目管理的問題。
（2）高質量：軟件的本質的在于高質量，沒有功能、特性的各項指標，軟件就是不可用的。
（3）適用于客戶：不能根據軟件削足適履，更不能根據客戶現實情況進行盲從，要適用于客戶的系統。
業務流程方面，不要進行涂鴉式的繪制。
其實強調布局。涂鴉說明思路敏捷，但是具體的布局及相應信息的處理是非產更關鍵的。
系統測試是一個極其重要的環節，就像我們的汽車產品出廠之前的全面檢驗一樣。系統上線之前必須做一次全面的測試，以發現和解決更多的問題，降低系統切換的風險。
這個階段通常叫CRP(Conference room pilot)測試，分為單元測試和整體測試，單元測試發現和解決單個模塊的問題，通過整體測試來發現和解決各個模塊連接的問題。在這里我要重點強調的是整體測試，這個測試必須要請全體項目組參加，而不僅僅是局限在幾個關鍵用戶范圍內，CRP整體測試必須包括所有的高層領導、中層領導，因為這個測試也是對管理層的一次重要培訓，一般在項目實施過程中，中高層沒有太多的時間參與具體設計，因此有許多地方他們在CRP測試之前是不明白的。必須通過這樣的形式和方法讓中高層看到系統演示的結果，讓他們看看用系統管理和手工管理的差異，親身體會一下整個系統連環運作的過程。
很多項目之所以成功，就是總經理親自帶隊全程參加整體CRP測試，整整在會議室坐了一個半天。我們說ERP工程是“一把手工程”，如果說一把手的確做到全程參加整體CRP的話，從這一點看那一把手工程就是落到了實處。當然我們的CRP測試必須是用企業真實的數據、真實的流程，得出真實的結果，而不是瞎編幾個數據，走個形式。CRP測試的理念必須是以業務流程為主線來測試，測試流程和數據，而不是僅僅測試系統有沒有問題。
The SAP HU is used for tracking the handling units used by the materials. Some common handling units are packagings materials like cartons, pallets etc.
In the SAP system, the handling unit (HU) expands on the shipping unit. Handling units can be nested and you can also create new handling units from several handling units as often as you like. At the material item level, HUs contain the complete material identification, the quantity, and, in the case of serial numbers, the respective object list. Handling units have unique,
scannable identification numbers that can be developed according to standards such as EAN 128 or SSCC.
Handling units contain all inventory management information of the materials they contain that are maintained in Inventory Management. There are also status messages that you can call up at any time that indicate whether a handling unit is only planned or if the ship-to party has been notified of the arrival of this handling unit, or whether it is in the warehouse or has already been posted to goods issue. The integrated history function also records each business process in
the life cycle of each handling unit, meaning that you can track the handling unit’s path and development at any time.
Refer to : Logistics -> Central Functions -> Handling Unit Management
In HU-managed storage locations, all goods movements are executed through the specification of the respective HUs, and Inventory Management is performed through the handling units. If you are working without HU-managed storage locations, you can work with handling units (without stock information) as before in the delivery and in the shipment.
In HU-managed storage locations, materials can be managed in HUs only. Mixed stock made up of packed and non-packed materials within the same storage location are not supported. HUs can also be managed in interim storage types. Unpacking a material from a HU means that the stock of the material is posted to a storage location that is not HU-managed.
If you call up normal material movements in connection with an HU-managed storage location, a delivery is created, rather than a direct material posting, which has been the procedure up to now.
Please note that if you want to use 311 to move the material already in stock, but in a non HUM Storage Location and you want to transfer those materials into a HUM Storage Location 304. If this is the case you can use the transaction VLMOVE with the destination plant and storage location. Before that you have to create the HU with the transaction code HU02 Storage location: where the material is and the status: in stock.
Handling units are unique at client level in at least one system. Using an indicator at client level, you can control whether you are going to work with the HU functions. Since the handling unit is a physical unit, the central logistics processes are controlled through the input of the handling unit identification. These processes include putaway, picking, and stock transfers, as well as goods receipts and goods issues.
A handling unit’s mobility can be limited if quality checks are active. Changes in the stock category caused by a quality inspection are made using a posting change in the handling unit.
There is also a report available that you can use to find and display handling units using different selection criteria such as material, packing instruction, or storage location.
Although the handling unit is basically a unit that remains constant in the system, you can change it by repacking the materials it contains. All the packing functions, such as packing, repacking, and unpacking, are completely supported by the handling unit functionality. In this way, handling units can be created in production, during goods receipt, or in the packing areas of the warehouse. If you have automatic packing, the handling unit is created from the packaging proposals defined in the system (from the packing instructions, for example).
操作過程的規范化。在整個操作過程中，要形成文檔化、規范化。
寧可多整理花一些時間來梳理，避免相應的現場的混亂、無計劃，減少臨場的發揮因素。
準備更加重要！
（1）項目的概況、目標、要解決什么問題、所涉及的組織機構
（2）業務操作流程（包括主流程及分之流程）圖形展示及相關的描述
（3）業務系統流程（包括主流程及分之流程）圖形展示及相關的描述
（4）角色 業務流程 操作流程 操作時間 異常
（5）關注點、特殊點、核心點的處理
（6）單據格式、報表格式、數據勾稽關系
-----需求調研主要關注的是要做什么的問題，對怎么樣去做的事情可以不做過多考慮。
做為一個leader，一定要對部下的想法有一定的了解。不作為的現象是不正常的。要了解其中的原因？現在究竟在做什么？想做什么？在一個事必躬親的情況下，對部下做事情的成就感就會有很大打擊。如何做？如何更好的解決這些問題？
不知不覺，立夏已經來了。街上的人穿短袖的人越來越多了。
在相應的時間，練練內功是很重要的環節。把公司的每個人培養成精英。
今年的春夏來的有些晚。按照我們以前的趨勢推算，這個季節應該已經到。但是，現在天似乎還是那樣的不緊不慢。感冒等多種病癥又不斷侵襲過來。我們要做的無非是積極進取，抵抗相應的疾病，為春夏的到來做好相應的準備。
這幾日，生病了。嗓子痛的要命，又感冒。
身體是革命的本錢。
煙要戒掉，這個玩意即花錢又危害健康。理智些，戒掉！可以尋找一些替代品。
注意身體的健康，保證一定的運動量！
專注！必要的專注，主要是不要在一些小的事情有過多的思考或行動，這個對整個的操作本身上有很多相應問題。專注的目標在于高效率！
人不在于數量的多寡，在現在的市場競爭中關鍵是人的質量的競爭。一個能力強的人、主動意識比較強烈的人，要比一個能力弱、無主動意識的人的工作效率要高很多。我們一直在強調現在的任務這么重，沒有辦法完成之類的話。其實關鍵還是對于內部員工的能力的培養、主動意識的培養，這才是關鍵的。斯巴達300勇士體現也就這一點。
事情總是一件一件的追著趕過來。以前的事情推進的還沒有完成，而現在又有新的事情。如何做？
(1)將事情排列下來；
(2)優先級最高的先進行處理；
(3)考慮backup的機制，是否別的人可以替代做一些事情；
如果自己存在相應的問題，及時自我反省，盡快修正自己的問題，為下一次溝通或下一段的溝通提供較好的效果。
很多應該傳遞的信息及時傳遞給相應的人員，做好相應的準備工作。快速響應尤為重要。
快速進行適應，.......適應相應的環境.......進入工作狀態........
1.要針對老總、運營有較強的針對性；
2.盡可能少使用一些軟件上的專業術語；
3.將自己的優勢展現出來；
4.語速慢一些，將自己的系統講清楚，講明白；而不是自己清楚、自己明白；
5.現場互動，講的時候觀察客戶的表情，必要的時候引導相應的人員進入討論；
6.不要刻意認為老總對業務、對軟件不懂，這些人能夠到公司的最高層，在業務上、軟件的篩選上也是非常慎重的；
7.精神要飽滿，狀態要好；
8.整個小組團隊要整體發力，團結一致；
one ...two...three..... do your job!
走動式管理... ....
日志管理... ...
對軟件設計和改進的過程中，將自己當作用戶，對自己的軟件認真仔細的走一走。
我們是作為研發的成員，我們的目標在于生產軟件。但是更為關鍵是軟件研發出來后如何使用？如何使用問題又歸結到軟件如何進行設計？設計決定研發成果（功能體），而研發成果又促成了軟件如何進行使用。但是反向的邏輯就是要在設計的過程中，充分考慮使用者的感受和習慣。在設計時，要這樣想？如果你再用這個系統進行運作，你會怎么樣？感覺是"哦！酷斃了"還是"shit！一堆...."。
當然作為我們研發出來的后的實施團隊就更加重要，因為軟件體是固化的（交付后一階段的研發成果），但是使用的方法和思路要給使用者提供，如果沒有一定的思考，就很難讓用戶滿意。
其實，根本上是兩個方面。一是，如果你使用，如何進行設計；二設計出來后，如何進行實施？
事找人，不是人找事。--- ---
關鍵是如何形成待辦事項？
(1)將需要做的事情一一列出，并按照事情緊急及重要程度排列；
(2)有些事情不是短時間內（一天半天）就能完成的，最好能跨越周期安排相應的事項，形成日程安排（計劃調度），必要時按照甘特圖的形式進行輔助。
（1）客戶的需求是非常關鍵的，哪怕我們就把原來的需求羅列出來。這個也是非常重要的，然后是相應的解決方法，如果是已經開發出來的，將產品演示出來。如果沒有就實際說明是需要進行開發的。給客戶的需求一定要留一章來講PPT；
（2）客戶的需求和我們目前的產品的差異度，主要還是將前提的調研結果與我們的產品的吻合度、差異度（將來開發的重點）；但是這個東西也比較敏感，如果感覺差異較大，可能影響客戶的選擇。中間可能自己清晰，操作過程模糊處理。
（3）重視需求調研階段。一定要將此階段作為重點，在整個研發周期中要有一定的比例，另外實施周期也是非常關鍵的。
（4）產品的業務流程的演示是非常關鍵的。一定要保證業務流程的演示正常、講原有的功能比較好的功能點展示出來。
（5）Portal的方面的重視。我們分離出對外或協作單位的Portal。用戶在目前的情況下，一般是比較拒絕客戶直接在企業系統中使用的。Portal的使用，可以為客戶提供一個專門的門戶來進行使用。
（6）在前期的項目接單過程中，也要強調團隊協作，需要一個總體的協作或者售前的Team Leader。特別是對應大的客戶。
（7）細節決定成敗。
客戶需要的是運營經驗+管理系統的支持。一般很少有公司說，我們運營模式很不錯，但是IT有些差，我來給你完善的需求你來給我們實現。更多的是要你的系統能給運營本身帶來什么東西？能夠給管理帶來什么提升？ ...提升...
IT的投入帶來運營的提升，帶來公司價值的提升，這才是關鍵。你來指導，而不完全是定制。強勢未必是件壞事情。
強調研發是對的，但是更多的是你已經實現了什么？你的產品功能如何？如何來提升價值？運營咨詢+IT技術支持+ 產品研發
軟件研發和項目運營是兩件事情。項目運營中會出現很多系統在測試階段沒有出現的問題，這個時候要非常謹慎。
開放式的項目方式的操作方式是最復雜的，因為代碼沒有凍結的時刻，隨著運營的過程，系統要不斷的進行調整、測試、上線。
PPT作為現在主要演示的文檔。
Excel 電子表格文檔... ...
人是很感性的動物，外界的風吹草動，對自身影響是非常大的。
要能夠保持自己的一份安靜，你在資源貧乏的情況下，如何做？安靜 冷靜 敏銳 拓展
---客戶聯系--銷售初步確認---客戶現場參觀調研---客戶提供資料---提供解決方案？？
如果客戶有比較明確的需求資料，我們相對容易處理，只需要對其逐條進行分析，然后總體上進行概括分析就可以了。但是如果只是一堆零散的資料，如何做？
難度系數比較大!
首先是消化---消化---再消化，思路-串聯---再串聯-----
系統的背景是怎么樣？系統的建設目標是怎么樣? 業務流程是怎么樣？ 運作的關鍵點是什么？
Budget ----年前
Budget-----年中
如果給幾分鐘的時間，你如何表達一個復雜的問題？
你的主體內容是什么？
I Best
U & I best
I better
標書作為公司最后與客戶確定是否成交的媒介物，重要程度是可想而知的。
如何有效地編寫標書？特別是標書樣板已經發生較大改變的時候。
(1)結構清晰
(2)內容事先預準備
(3)格式調整
(4)客戶所關心部分及客戶的閱標習慣
------------------------總體還是要思路清晰！
流程 延至 標準.....
方法 延至 策略.....
定位-------
定位決定如何去做
定位決定態度
定位,,,,,,,,,,,,,,,,,
獨斷：單個利益實體的考量
共謀：多個利益實體的考量
一般人認為回答問題是體現一個能力的重要表現，其實作為提問也是一個非常重要的能力體現。主要表現在以下幾個方面：
（1）提問題之前，是不是自己對這個答案已經有更好的了解。如果這個問題已經有答案，是不是一定要問。
（2）合適的時間對合適的人問合適的問題。對你的老板、客戶、供應商、同事等等。
（3）你提問題的目的是什么？是要解疑釋惑，還是另有他用？
（4）三思而后問
（5）一般來說問題，不適合太長，否則你的問題究竟是什么？
（6）問題，你究竟想問什么問題，是否有效的傳遞給對方。
（7）注意語是
提問題的內容：
（1）你的擔心點。
（2）如何做？哪一種方案更好
遇到這種情況如何辦？你的頂頭上司找到你的下屬咨詢一個事情，發送郵件，結果下屬也回復這個郵件給上司。后來，這個郵件又發送到你這里，要我來看看。該如何做？
第一，你的頂頭上司找你的下屬的目的是什么？是想參考一下他的意見還是想把這個事情交給他做？如果是參考一下他的意見，那沒有關系，可能結合著一下看看，是不是又補充或者完善的地方。如果是想交給他處理，可能任務這個事情比較小一些，應該他可以單獨處理好的，但是這個你就不適合去主動做這個事情，而是需要輔助指導這個事情完成。
第二，后來交給你后，如何協調你與下屬之間的關系，如何進行應對？其實關鍵大家還是溝通好，也不要不清不楚的，這樣反而很是別扭。
最后，其實對公司來說，只要Case能夠真正有效的執行下去就OK，大家有這樣的想法就可以很容易解決。
其實一個公司的扁平化的管理也是很常見的現象。
功能是否完成？
測試結果如何？
文檔編寫是否完整？
遺留問題如何解決？
用戶的接受情況如何？
項目的后續總結分析情況？
需要交付的還有什么遺漏？
開始事后項目分析。
這兩天為一個電子郵件的事情花了近一天的時間，其實也不是什么特別復雜的事情。感覺自己的手感確實沒有以前好了，以前寫代碼那確實感覺真的是代碼再寫代碼。
在我們日常的開發過程中，總是希望能夠一夜建成大廈。但是冰凍三尺非一日之寒，很多東西是需要一點點的積累才能做好的。更多的是我們要去做，只有你做了，大樓才能接近完工。設計階段很重要，但是在實際的操作過程中，還是需要有很多細節需要注意的。
如果進行改造原有的系統，特別是爛尾樓的處理，有很好的想法，但是如何在最短的時間內，將其進行改造成具有競爭力的產品。
PM，主要項目的管理人員，主要負責的是項目的交付、進度、風險、團隊的管理工作等；但是一線的軟件研發公司，不寫代碼，團隊成員很難對你信服，因為技術是實現的關鍵。每日堅持半天左右的代碼編寫，也可用使自己保持對程序的敏感性，更了解我們程序員要什么，如何做得更好。
為什么提出這樣的問題？主要針對用戶不知道自己需要的是什么東西。或者知道自己要的是什么東西，甚至對具體的功能也提出要求。一種是說，你看著辦吧，你們做過的應該是什么樣子的就什么樣子？結果到最后的時候，這個東西要修改那個東西要修改；另外一種說，你就按照我說的做就可以了，我們的實際用戶一定會用的不錯的，另外我們設計了這么多的亮點和新特性，結果這個東西花了很大的代價形成，結果愣是實際用戶迷茫，這么智能，可惜功能太冗余了，一點也不人性化。你真的對實際用戶負責了么？
出現這樣的問題，大多是因為我們站在實際用戶的角度進行深層次思考，不能僅僅站在軟件功能的強大上，更不能只是針對用戶IT負責人的功能進行盲從。我們對實際的應用負責，我們對用戶負責。
我們要真正從實際使用的具體情況出發，從用的角度出發，從用戶的實際操作水平出發，你是實際的用戶，你會怎樣操作？可用、易用確實需要付出很大的代價。在有限的資源、時間、成本的情況下，如何能相對理想的方式解決確實一種藝術。
保持饑餓的狀態
Hungry--------------------Do it!
失敗：
（1）沒有客戶實踐，盲目開發。
（2）技術路線調整，例如數據庫遷移后放棄。
（3）對行業的把握不夠。
新版本的升級如何做來做：
(1)清晰地知道自己在做什么，對項目進行清晰化、明確化。其中設計到業務的操作流程調整、功能新增。
(2)數據的串通，將單個業務功能點和整個業務流程進行全面串聯。
(3)以客戶為導向，以解決實際業務問題為導向。
危機意識是非常重要的。
一個項目前期的時候，和客戶一起談的很不錯，似乎合同就要簽下來了，但是結果簽單的公司不是我們。
風險，在項目的操作過程中，到處充滿著風險。如何規避相應的風險，危機意識非常重要。
幸福就是做你自己喜歡的事情，幸福就是和家庭其樂融融，幸福就是和自己的同事一起戰斗，幸福就是苦思冥想后的靈感一線，幸福就是看到自己設計的系統客戶用的很好......幸福.................................
作為大公司的企業應用系統，在使用過程中是非常謹慎的。但是作為系統本身，在系統上線后，依然會存在一些相應的BUG，當然在系統的運行過程中還存在有相應的新需求及相應的調整。
change control & scope management有時間我再寫。
補丁的過程中存在的問題：
(1)有些補丁打上去了，有些補丁沒有打上去(代碼已經提交了)。后續的補丁對前面的補丁有很強的依賴。
(2)補丁有問題。
對于開發層面，每天的代碼提交需要有嚴格的日志，通過SVN或其他相應的工具雖然能夠體現出是誰提交了文件，修改了什么，但是對于補丁可能是一個相應的集合，需要開發人員將相應的內容能夠完善起來。這個如果能有有效的工具進行控制最好的。目前還在尋找中....
補丁上線。在測試、DEMO環境和product環境的多次檢測是一個不錯的方法。
關鍵是要建立一個補丁的流程機制
(1)開發人員，提交代碼，提交內容備注填寫。
(2)測試人員嚴格測試。
(3)實施人員、系統管理員的多次檢測和緊急恢復制度。
文檔化、流程化、標準化是非常關鍵。
在客戶談判過程中，一定要注意以下幾點：
（1）頭腦要冷靜，在客戶交談特別是在雙方利益有沖突的情況下，不要頭腦發揮，完全意氣用事，要有冷靜的頭腦。
（2）搞清楚對象的目的。不要一味自己的說，這樣會使得自己比較被動，你的立場和想法都已經暴露出來，客戶很容易對你進行攻擊的。
（3）不要哥們義氣。私下都是朋友兄弟，公司層面是公司層面。如果以兄弟博取對方公司層面的事情，都是不對的。
其實最重要的一條，還是要冷靜下來對待。
深思熟慮！
你的最大價值在什么地方，做能發揮自己最大價值點的事情。
合理的時間安排是非常重要的。
首先事情要有條理，將所有需要做的事情做成列表形式，按照Project格式的最好，整理成自己的工作列表。
其次，不要重復工作，如果有人已經在處理這樣的事情，就暫時不要處理，否則，你在做，其他人也在做，重復性的工作要不得。除非，別人沒有能力或者需要你的幫助時才這樣做。
再次，要先做緊急且重要的事情，不要在一些瑣屑的小事情上花費大量的時間。
最后，主要注意完整性，一定要有相應的記錄。
在公司的早期發展過程中，我們往往強調快速反饋，其結果就是銷售實施人員匆匆反饋；開發人員匆忙修改；又匆匆部署；其結果很難保證。很大程度上依賴與開發人人員的嚴謹性，而測試人員的缺少或懶惰又使得客戶實施過程是來回的反復。
在成長過程，逐漸建立標準的規范，使得質量確保有一些保證。但是要求時間、成本就會大大增加。
如果在靈活性和穩健性、標準化和低成本；當然我們不要忽視標準化的過程，因為這樣才具備可復制性和可操作性。當然在操作過程中如何更加有效，如何提供工作的效率，將系統的靈活性和穩健性都能得到提到是一門學問。
不能為了靈活，而拋棄標準。標準化的東西才具備有較強的可復制性和低成本的特性。