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年的颓废、不安；我们也在衷心祝愿我们能够获得更大的成长。
    失败、恐惧、磨难、悲观等等等都为我们提供了可参考的因素的，经历就是一种财富，不过悲观，关键在于总结失败的经验，对未来进行展望和执行。相信我们能渡过这个艰难的时代。
     很多公司都在裁员、很多公司的高管甚至创始人都被迫离开自己的公司、经济的低靡和萧条，似乎成了这个世界的主旋律。相对于这些，我们好多了。面对我们的现实场景，摒弃那些偏见。冬天对我们并不可怕，关键是我们如何走出冬天，走向我们的明天。不要逃避，不要回避。
     听，黄浦江边的汽笛声和公路上的鸣笛声似乎也在向我们呐喊，冬天来了，春天还远么？

已经凌晨了，办公室里还是人头串动，键盘敲打的声音吃起彼伏，讨论声也在办公室内荡漾，好似美妙的音乐。