2007年5月31日
#
时间在一点点的过去，但是确保的进度上还是没有保障。原因何在：
(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格式的最好，整理成自己的工作列表。
其次，不要重复工作，如果有人已经在处理这样的事情，就暂时不要处理，否则，你在做，其他人也在做，重复性的工作要不得。除非，别人没有能力或者需要你的帮助时才这样做。
再次，要先做紧急且重要的事情，不要在一些琐屑的小事情上花费大量的时间。
最后，主要注意完整性，一定要有相应的记录。
在公司的早期发展过程中，我们往往强调快速反馈，其结果就是销售实施人员匆匆反馈；开发人员匆忙修改；又匆匆部署；其结果很难保证。很大程度上依赖与开发人人员的严谨性，而测试人员的缺少或懒惰又使得客户实施过程是来回的反复。
在成长过程，逐渐建立标准的规范，使得质量确保有一些保证。但是要求时间、成本就会大大增加。
如果在灵活性和稳健性、标准化和低成本；当然我们不要忽视标准化的过程，因为这样才具备可复制性和可操作性。当然在操作过程中如何更加有效，如何提供工作的效率，将系统的灵活性和稳健性都能得到提到是一门学问。
不能为了灵活，而抛弃标准。标准化的东西才具备有较强的可复制性和低成本的特性。
软件公司的趋势越来越倾向于客户服务，而且是客户一线的服务方式。将自己的队伍驻扎在客户的现场，培训、现场支持、补丁、问题反馈，很多事情要在一线才能够很好的解决问题的。
研发团队贴近客户一线。不能闷着头写程序，不理解一线操作人员的运营模式，不了解业务操作的严肃性，是没有写出的好的代码。更不用说，我们编写行业软件的。
贴近一线的研发团队+驻扎一线的实施团队=成功的研发+实施=客户成功的交付=公司的发展
态度决定未来：对待一个事情的态度决定是否开启这个事情，被动的接受一个任务是很难将事情完成好的，只有积极主动的去做，才有可能将事情很好的完成。
壳子为第二决定因素。资源的多寡决定你是否拥有做成这个事情的重要因素，有了态度，最主要的还是拥有的资源是否能够支持做这个事情。
果子决定最后的交付成败。产品的丰富性、稳定性、拓展性。积极进取、资源拥有、内涵注重，基本上这个Case我们就有胜利的把握。
...积极推进
...注重资源
...强调内涵
==============>胜利就在眼前!
关注新产品的研发及新技术的使用 R&D
项目管理的操作规范化 pm operation standard
培训及带出一支将军团队 training and lead a group of leader
家................城堡
事业............战场
壳子决定入围 ...规模...管理...
果子决定结果 ...内容...运营操作...
.......................--------------->>>>>>>>>>
解放军打歼灭战将向更大规模发展
是集中更大兵力打更大规模的歼灭战
集中兵力打大仗
对付敌人，不但斗力，更要斗智。
//你能不能做？怎么做？后续的保障如何？别人也能做，为什么交给你来做？
标的亮点
管理
实用--解决问题
公司的实力
--可用 客户可用接受，可用进行操作 强调系统的稳健性。
--易用 用户操作方便。
--智能 系统智能化，通过规则库，系统变形金刚
本次项目的上线非常失败：
/////////////////////////////////--------------------------------------
项目及时反馈，项目组成员及时解决问题。
准备DEMO的数据的Setup。
测试到位。
什么叫苦中作乐？
最近接触的一个客户，总是在加班。每天工作的很晚。今天电话过来说：“周末休息两天，还好吧”。看来这家伙又是忙乎了两天，看其MSN，果不其然。
苦中作乐。人生就是如此。
休息了两天，还是有些打不起精神。恍惚的脑子，犹如膨胀的意识。
可能是脑子生锈了，开不起窍来。
有时间还是要写些东西，否则你的代码编写的能力下降，思维僵硬。
此搏非彼博，乃拼搏之含义也。
在目前市场竞争如此激烈的情况下，一家公司、一个人想要很少的生存，必须有铁一般的意志，还要有拼搏。有某客户说，你和XX公司相比较有什么优势？唯有拼！否则，规模、资金、研发能力，你又如何比？再说很多亚太区的总监都是这样拼出来的。
所以，必须有要拼的意识和行为。达尔文的生物进化论，优胜劣汰，此为公理也。
IT，it，它！有次见一个程序员朋友，戏称IT即it，它，非他或她。说明了作为一个IT人员的艰辛程度。如果资源不合理的情况，尤其暴露的更加明显。
作为偶，现在现在已经很少直接去写代码。更多的是客户的电话、沟通；上线了，镇痛开始了，孩子出生的过程是痛苦的。
如何分工协作是非常关键的。特别是一场很艰巨的决战阶段。技术、测试、DB、部署、安装、培训......
PM在项目交付前做以下工作：
（1）风险的控制
（2）难点（顽疾）的监控
（3）Setup计划及安装手册
（4）文档编写
（5）ISSUE的监控
研发力：研究开发的能力。
从简单的词语中，主要考虑的因素有：
（1）团队的领导力，项目管理能力
（2）团队的成员组成，组合式的团队
（3）团队规模项目
（4）研发的产品
（5）CMMI级别
（6）研发的技术能力、行业技术的把握能力
（7）交付的客户
市场本身的问题：盈利的能力
如何选择合适的人？
如何选择合适的人做合适的事情？
如何最短的时间内获得你所想要的人？
磨练---地狱---------
这两天好不容易有些时间，看了几集《数字追凶》。比较有意思，将数学的很多知识和理论应用于破案。其中虽然不排除有夸大数学的作用，但是数学的作用真的还是不能小看。
但是传统的教学，数学只是用于考试、奥数，似乎数学的作用是为了数学而数学。当我们离开学校开始工作时，基本上把课堂上的东西又交还给老师了。作为我们接触数学，特别是应用数学的时候确实如果有其应用的场景，作为数学的作用确实很是明显的。有时间是要补补数学方面的知识了！
最近为了方便接触了一下混淆器。所谓混淆是将代码通过一种rename或者隐藏的方式将编译的代码变得生涩、难懂；但是这个混淆主要使用在程序的内部使用；如果需要进行公开，则其不能进行混淆。混淆的本质还是使用mapping的方式将系统的类、方法、属性等通过一个映射文件，使得混乱的状态大家互相能够识别。但是对外的代码涉及到对外的还是要保持原有的逻辑。
混淆是好东西，但也不是绝对的安全，而且对于庞大的系统本身而言，需要keep的元素以及与jsp等交互共同的信息量也很大。混淆不是忽悠，忽悠.....
以前在邻桌有个同事，敲击键盘的速度很快，发出有节奏的声响，美妙的音乐在演奏。时间过得很快，他已经离开公司，去了另外一家公司。
现在的自己也有一些浮躁，不能完全沉淀下来，总希望能一夜之间将大楼好；总希望能很快将很厚很厚的书能翻烂；总以为项目能在很短时间内完成；也总希望一个技术自己能顷刻搞定。时间，沉淀，沉淀是一种定力，也是一种毅力，需要有坚韧不拔的信念，相信自己能够处理好，但是不是拔苗助长，更不是无视时间的紧迫性。
有些时候，是做了很多无用功，证明了很多失败；寻找什么是错误，或者说证伪也是一种工作，特别在没有以前探索的基础上。
沉淀---------只有沉淀，将每日的得失都总结起来，一点一滴地去成长，将每一天都充分利用起来，相信毅力可以挑战一切未知和高风险的作业。
沉淀---不要梦想一下子就将所有事情都搞定；将事情很快搞定是有时间、精力、资源的沉淀而获得，Just Do It!
小A有个项目，前期有些参与，但是这个行业和目前自己熟悉的行业还是有些差异。但是项目的运作过程中需要进行参与，而且还要进行现场的讲解。怎么办呢？
以最短的时间内消化掉相应的流程及系统操作，否则客户现场情况就很难控制，客户会认为一个生手在操作这个项目。
扬长避短。
注意事前的准备工作。数据 流程 讲解顺序。
问题解答。
WMS: Web Map Service. Displays geographic data as raster images (maps).
------Web地图服务 作为光栅图片（地图）显示地理信息
WFS: Web Feature Service. Communicates real geographic data (roads, rivers etc.) to and from the user in the form og GML.
-----web特征服务。 通讯地理数据（道路、河流等）以GML的形式
WFS-T: Web Map Service-Transactional. Allows the users to edit geographic data in transaction blocks.
-----Web地图服务-- 事务的。 允许用户在事务块中编辑地图数据。
GML: Geography Markup Language. A brand of XML that describes geographic data.
-------地理标识语言。
首先避免疲惫的心态，人在精神不好的时候，很难将系统的亮点和特色展现出来的。加上客户听众数量和质量都很高，如果没有充沛的精力，很难达到理想的演示目的。
数据要做好准备。将一些开发人员的数据尽量删除掉，做一些正规的数据。客户看到一些乱七八糟的数据，客户会认为是你系统的问题或者认为你这个系统根本没有人正式使用过。
流程及思路准备。你先讲什么，再讲什么，最后讲什么，要有明确的思路。否则乱七八糟的思路，客户自然很难接受。
合理避免系统的问题。系统一般都是存在不完善的地方，特别是刚刚推向市场的产品，其问题就更加多。如果不演示，客户会认为你没有这样的功能，如果进行演示了，出现了问题，客户会认为你不完善。在不完善和不存在的选择下，当然我们选择不完善。当然有些客户化、产品的小BUG，我们思路要清晰确实很是重要。
最后的问答，尽可能不要和客户冲撞，合理适时解答问题。
客户变同事的弊端：
（1）客户是上帝，同事是一起战壕打拼的兄弟；两者的差异是明显的。将上帝当同事，或者将同事当上帝，这样的感觉都是不对的。
（2）客户有可能转化为同事。但是如果客户变竞争对手的话，就很麻烦。因为客户和同事相对于操作者来说是信息传递的透明度有很大问题。在这个商业竞争激烈的社会，多多考虑还是必要的。
唐骏
史玉柱
GPhone
-----------------------------------------------------------------------
首先要正确对待学龄前儿童好动的特性，应当将其视为正常现象，因此期儿童大脑兴奋过程占优势，易兴奋、激动和喧闹，要求他们较久地静坐不动或较长时间注意力集中是困难的，所以，决不能刻意限制儿童的活动。
其次，由于此期儿童活动能力和范围加大希望独立做一些事情，大人如进行干予，就会遭到拒绝或哭闹以示反抗。这是一种自我意志的表现，在心理学上称为第一反抗期。这种独立性的表现是一种积极的心理状态。反抗心理越强的幼儿长大后，意志往往越坚强。所以，作为父母应因势利导、注意保护、指导这种品质的发展，不可强加压制、讥讽。当然，也不能过分保护。
再次，是要注意放手让儿童游戏。游戏是此期儿童的基本活动，是促进其认识、情感、意志和个性品质迅速发展的重要手段，也是其生理和心理需要。所以，家长、幼教人员对儿童这方面的活动只能鼓励、不能压制，并应为其游戏创造良好的条件，给予必要的指导。要正确理解儿童早期教育，不能违背婴幼儿的生理心理发展规律，要求他们长时间学习听、读、写、算，或过多限制其玩耍，否则，反而会给他们的智力，心理发展带来不良后果。
最后，父母师长要注意自己的表率作用，此期儿童可朔性很大，且个性处于形成过程，情绪很不稳定，易受外界影响。所以，父母师长要注意给孩子起良好的表率，从而使儿童的模仿、放大效应朝着良好的方面发展。父母师长们要用良好的人格，使儿童潜移默化。否则教育不当，或自身行为不检点，都可能造成儿童出现不良行为或甚至病态人格。
世界本身是混沌的，在无序的设计中产生了规则，通过规则使得世界变的有序。忙碌是一件好事情么？在混沌的世界中，忙碌是解决的方式么？非也。在混沌中找到规律，在盲目中寻找本源。根据相应的优先级别来进行操作。将所需要做的事情写下来，进行思考，通过积极的主动的工作获得相应的问题的解决。科学的方法观，是解决问题的关键。
在研发团队中，人的因素是最为关键的因素。如果是软件研发团队就更加注重人的因素。程序员多为一批不善于沟通的成员，在这个情况下更需要大家在一起进行详细沟通。
把事情处理好，但是不要采用暴力、主观的评价方式。把自己作为教练，作为园丁，时刻关注程序员的成长，一起共同成长。
难题一定经过集中讨论后，再进行处理，减少个人臆断的层面的东西。
分配后要项目进行一定的监督，特别是一些不是很容易解决的难题，以及一些可能实现起来有些难度的人。
累了，倦了，脑袋进水了.......
在任何时间下，特别是在工作状态中保持清醒的头脑。
房子 老婆 孩子 工作 事业 客户 小贩......
作为一个个体还是要保持清醒的头脑，越是在疲惫、累、疲倦的状态下，越是要保持清醒的头脑。
因为这个时候最容易做傻事；作为个体可能还容易承受，最好如果作为一个群体，其损失就是巨大的。
软件公司本质上也是服务产业，而且是发展迅速的服务产业，随着产品的丰富，客户数量不断增多，从原来的一切围绕客户的需求，完全满足客户的需求的目标原则，发生了很大的改变。
永远不要把客户当作傻子，否则你会发现客户永远比你聪明。
不要把客户当上帝，上帝也是需要沟通商谈的，无限制的需求或没有科学方法论的项目永远也没有验收的时间点。
面对客户、面对产品、相对需求、面对验收、面对时间、面对......你准备好了没？
PSBY!
测试......编码......交付......
.....问题解决................................
如果你在 www.workopolis.com 或者 www.monster.com 的网站上敲进 Business Analyst进行关键字搜索，你会发现有上百个相关职位。其中涉及的行业从金融、电讯到医疗、保险不等。首先澄清一下，我们这里提及的BA，是IT相关的BA，有时也称做 Business System Analyst，Business Specialist, Business Consultant or Business System Consultant。
虽然称呼上略有不同，但其实工作性质都是非常接近的。简单而言，BA是一种介于客户和IT团队之间的角色，BA在IT项目中负责发掘、分析、传达和确认客户需求。BA需要了解有关业务上的各种问题并发现新的机会，搭建业务和IT人员之间的沟通桥梁，并推荐问题的解决方案以实现组织的目标。这其中还包括参与系统的设计和测试，以及各种协调工作。
BA的具体职责大体有如下几种：
业务需求分析，建立相关文档和分析、建立业务模型
协助project manager的项目管理工作，如项目scoping，planning
调查、分析现有的系统和业务流程
组织各种会议和workshop
准备External Design文档和进行可行性调查
准备和实施Test Plans
参与IT系统的安装和培训
为什么要在客户和开发人员之间加上一道程序，让他们直接对话岂不更好吗？我个人认为有以下几个原因：首先就是分工细化的要求。IT项目越来越庞大，客户需求也愈加复杂，IT开发人员已无更多精力，这样就要有专门的人员来担当此任。其次，BA的需求分析工作不是简单地坐在那里听客户讲，然后记录下来并组织成文档。在业务分析中会有许多的挑战，需要BA应用特殊的技巧来将客户脑中潜在的需求挖掘出来。BA要做系统的分析，如业务流程分析，要了解客户及其他相关人员和组织。这期间需要付出大量的精力和时间，而不是开几个会再用Word记录下来那样简单。用一个流行的话讲，BA的工作要add value。
BA在项目各阶段中起何作用，他们和团队中的其他成员是如何互动的呢？
BA在项目的初始阶段，要参与到项目目标设定、项目范围的界定、和stakeholder分析等工作中。在项目的需求分析阶段，主要负责分析、开发，了解和记录客户的需求。这其中还涉及到了业务流程分析，建立各种业务模型。这些需求文档和业务模型将成为日后开发人员进行系统分析和设计的重要参考依据。在项目的设计与开发阶段，BA主要是负责联络和沟通，起到桥梁的作用。有时还要参与到系统外观设计中，确保系统设计符合客户的需求。在测试阶段，BA要参与测试计划的编写和实施，审核测试文件的有效性并确保客户所有的需求达到测试标准。在项目的最后实施阶段，BA要参与实施方案的制定与监督计划的实施。有时还涉及到客户培训和项目最后的评估。
要找到BA工作，需要具备那些条件呢？哪个行业又最需要BA呢？
目前来讲，BA的工作机会还是很多的，因为在各行各业中，只要它需要开发信息系统，就得有人来分析记录客户需求，这也就离不开BA这个角色。整体来讲，金融、医疗、电讯、政府等行业和机构都需要大量的BA。而且BA这一职业的特点是在一个行业的时间越久就越吃香，价值也不断增加。目前各公司也越来越重视BA的开发和培养，BA这个职业也越来越受到社会的认可和重视。
笔者本人的经验，找BA工作需要几大法宝。第一就是相关的行业经验。其次是BA的流程技巧。第三是较强的沟通能力。这其中必然包括较流利的英文口语及书面表达能力。
BA的工作前景如何？薪水如何？今后的职业发展又如何呢？
应当说BA的薪水是相当不错的。Junior BA与类似经验的 Developer的收入持平或略高一些。一两年经验的BA 年薪一般能达到五万元，高级 BA 和 Consultant 能拿到7到9万元不等。如果做Contract的话，收入就会更高一些。
从职业发展上看，BA可以向Business Consultant或者Project Manager等方向发展，都是不错的选择。当然也有些BA向Business方向转换的，比如做Financial Analyst或者Process Analyst。
BA工作的挑战是什么？尤其是对中国人，门槛是不是很高呢？
BA这个工作，和其他职业一样面对许多困难和挑战。就笔者本人的经验来讲，主要有以下几点：首先你要对一个新接触的行业和客户在最短的时间内进行了解，熟悉客户专业名词和业务流程。这往往对我们英语非母语和初来乍到的移民来讲是一个不小的挑战。其次就是英语。口音倒不是最大的障碍，很多时候是我们不知如何用恰当的词和句子来表达，结果说了半天别人也听不懂。再有就是许多人对BA的工作流程不是很了解，感觉找工作无从下手。
至于门槛呢，我个人认为应该说不低，尤其是对交流能力的要求。但也没有想象中的那么难。我想只要平时注意学习英语，以积极的态度对待工作中的人与事，经过一段时间的积累和锻炼，工作上就会驾轻就熟。同时，交流能力的提高也有助于今后向其他方向发展。
BA工作的好处是什么呢？
首先BA工作不乏味。通过做不同的项目，你会接触到许多新鲜的东西，最起码你不会厌烦反复做同样的事情。其次，BA工作使你能接触到公司中许多不同的人和各种业务，既有助于发展人际关系，也有助你了解了公司是如何运转的。最后，在当今 IT外包势不可挡的情况下，BA这个职业也显示了其特有的优势。由于BA的工作性质是同客户打交道，必须要贴近业务和客户，因此所受影响就微乎其微。
总而言之，BA这个职业和其他职业相比，既有其优越性，也存在着挑战。对于我们广大移民来讲，首先需要了解它认识它，然后才能根据自身的实际情况做出正确的选择。
做？做什么？
不做？不做什么?
在一个团队工作中，作为团队的负责人，要做的事情和不做的事情要进行区分。作为团队负责最大的作用发挥大家的积极性，激发人的潜能；当然在一些难度比较大的东西，也需要能进行相应的处理。做负责人最主要的是计划，对计划执行的情况进行监控。
作为团队负责人，不做的事情是什么？尽可能不要陷入到代码的细节中，如果需要进行创新性质的内容，可以进行编码，否则最好不要去写代码，还是如果手下能做的尽可能还是通过鼓励、指导的方式让手下的人能完成掉。
当然在过程中，还是强调高度与执行的可能性问题。
接到了一个任务，需要编写公司的宣传册。
编写公司宣传册的goal是：TOP Requirement：接单。
注意是从客户的角度去看这个宣传手册。
Objective:
1.了解公司的基本情况（定位、员工情况)。
2.能够放心将case交给公司来做。
3.公司有什么优势？公司有什么特点？
4.能够快速找到适用自己的产品？
5.技术研发能力、项目管理如何？
6.如何给我做服务？服务相应。怎么给我做软件？
7.从软件声明周期，需求调研、设计、编码、交付、培训、维护如何做？
8.公司的Vision（远景）如何？
9.公司的文化？
当你有一堆事情要进行处理的时候，脑子乱哄哄，客户又电话来催促现在的进度情况，......开发人员感觉自己又很难在规定时间内完成了。
方法论很重要，目前的方法还是比较混乱没有一个合理的方法来进行解决。在时间紧张的情况下只能将需要紧急处理的工作处理掉。
优先级-------------------------------------将你的事情的优先级别完成掉。
客观----不要无视客观的东西，但不要给主观的偷懒的机会！
一个项目有多少个功能点？
一个功能项目中，又有多少子功能点？
如何进行分解？
如果不知道具体的情况，也就不会知道什么时候能够完成，也不会知道什么可能是其中的一个重要问题。
项目进展到相应的coding阶段，其相应的工作分解还没有做的话，项目的交付将成为一个难题。
多少功能项目？子功能项有多少？三级子功能项是什么？由谁来做？
项目管理的关键就是将项目清晰、明确、资源充分利用！
将项目工作任务分解进行到底！
（1）Receving Order 寻找水源
（2）Commuciation & Training 挖井过程
（3）Deliver 最后十米
当你要做一个在既定时间内无法完成任务的东西时，你该如何做？
（1）牺牲所有时间，包括你的休息时间，去将这个任务尽可能接近完成。
（2）按照既定的时间安排，8小时稍稍加班的方式去完成。
健康还是拼命？
----------My Method
（1）首先将优先级别比较高的先进行完成，这样可以尽可能减少不能完成所带来的风险影响。
（2）不要刻意追求完美，在保证基本质量的情况下，加快进度。
（3）尽快将需要分配的东西分配下去。督促进度的加速。
（4）牺牲少许的健康，但是不能不考虑身体的状况。
悲观 => 快乐
束缚自己 => 释放自己
甘于现状=>进取
这些天面试人比较多。一种人是年级太轻，近90年代的新人，在工作中基本上没有什么经验，但是确实给人感觉诚实、可靠；但是基础确实少的可怜。一种人已经是近60年代的人，工作经验应该还算丰富，但是因为确实年龄为他的工作的激情，加上技术的更迭速度很快，很难给人能赶上步伐的感觉。
不过突然也联想到自己十年后的日子。那时候也就近四十了。在岁月的磨练后，在寻找着工作。我能干什么？我该干什么呢？自己是否也想我这些天面试的人。拿这一个包，面试时将将包牢牢抱在腰间，生怕别人拿去；弱弱的问着公司用什么技术，似乎自己在这些方面真的很难理解；当问到薪资时，生活啊！老婆孩子。最少不能少于...元。
这一阵没少写解决方案。作为客户希望提供解决方案的初衷是：（1）想知道自己系统将来是什么样子的？（2）可以对比几家公司，看哪一家性价比高。
从以上推测中，至少要注意以下几个问题：a.突出特色和以往典型案例。公司的优势在什么地方？其他公司这方面的劣势是什么？为什么选择我们？b.针对客户所关心的功能将其细化，最好能提供相应的功能图形。这样方便对比自己心里想要的是什么功能。由抽象的概念转变为现实的操作。c.注意系统的实施步骤（分布实施、迭代、后续维护软件保障、产品生命周期）。
前一阵有个客户在一起吃饭的时候，说他自己有两个缺点：（1）只能专心做一个事情；（2）牢牢把握自己的主动权。(1)专心做一件事情确实也是应该的，但是目前现在的工作节奏多是多线程的方式的，做项目更是如此需要多个事情同时进行处理。主动而不被动。还是强调个人对项目、对事情的掌控力度的问题。要主动安排自己的工作，不要被动做事情。列出清单，按照事情的优先级别进行操作。
最近的事情越来越多，有些手忙脚乱，如何进行合理的工作分解，以及如何进行调节的自己的生活非常重要。多个项目的任务分解以及如何将合理的资源进行处理。其实最好的领导是将下属培训好，这样自己可以做一些关键点的事情。然后逐步地将自己的学习的东西使得其下属能尽快消化掉。前几天一个首席顾问说过这样一句话，“现在做的最多的事情就是培训！”。这个可能就是他对内的focus。有什么事情一定要尽快的分解下去，博采众长，相信你的部署能将事情做好，这样才能更好的发展。
代码浏览。作为一个PM，可能大段的写代码的时间可能少了一些，但是还是要经常做一些code review的工作。因为研发的代码质量要保证，每个开发人员的层次是不一样的，代码编写可能有一些问题的，还有一个对业务理解上的把握。
项目要有一个每日进度情况的报表，这样才能项目的实际上线情况了然于胸。这个不能做成一种形式，另外最好能有人专门整理这样的工作。
作为项目最辛苦的PM，是项目成败的关键。
在开发的中后期是最辛苦也是最无奈的一个时间段。客户来电话或MSN表达了其对业务系统的不满；GPS的接口问题还没有解决；客户说的功能需求还没有明确进行设计开发；核心开发人员要有考试，可能需要请假；又有开发人员没有项目的真实意图；还有些程序员有新的想法要实现；眼看项目的交付时间意义延期，焦头烂额；本想晚上找个时间安静下来写一些代码，睡意又骤然袭来；新的项目又要启动；新的人员招聘计划又在开启；人员安排似乎还不是很合理；这些家伙进展如何？？？................
快有一种恐惧的感觉了。
这时候思路一定要清晰；（1）客户所关心的核心问题一定要解决掉；不要认为开发后期了，与客户沟通不重要。（2）开发人员一定充分理解项目功能要求。（3）态度决定一切。一定有充分的打硬仗的心里准备。否则就不要做什么PM。（4）强调计划性、优先级。（5）合理利用加班。（6）摒弃自我感觉良好的心态。仔细走一走。你对客户的理解肯定是最精确的。站在客户的角度去考虑一下。
从局部出发，从程序模块出发，从程序实现的简便性出发，从个人的主观的想法出发，这似乎从成为我们程序员的一个通病，或者说很多曾经犯这样的错误。
从整体出发，从业务逻辑出发，从系统的可扩展性出发，从系统的角度考虑（不是我在写程序，而是程序在写自己），这样才能实现系统的成功交付和软件产品的市场化。
时间过得很快，另一个项目即将要进行交付了。感觉还是有些不太好。虽然上一周休息了两天，但是感觉似乎休息还不如在公司写些代码。如何提高开发人员的效率，如何使得项目顺利交付成为一个关键。
集中精力，感觉自己的思路还是太松散了，在整个开发过程中，没有进行全程的监控。有时候全心参与了，还是有些心有余而力不足。为什么会这样？（1）管理层次的提高使得自己在纯技术领域有些陌生，在设计时质量不高，在开发人员的指导上也比较缺乏。（2）员工需要进行培养，使其能够养成高效率高质量的工作作风。（3）充分沟通。在整个开发过程开发人员、客户都要进行充分沟通，保证其获得其所需要的信息项。
这一阵子在房子，从中间也悟得一些道理。我们购房要考虑的是地段（交通、内环、中环、外环）、装修情况、楼层、朝向、小区环境、小孩子教育等等。希望能获得一个比较理想的客观环境。但是基于口袋里的情况，只能选择一个相对比较理想的房子。相对的低价能获得相对的优质的房子。当然房东的态度和以前房子的贷款情况也是一个主要参考的东西。
作为一个上系统的企业其实也是一样。希望获得更多功能模块、可扩展性要好、后续的维护要好、最好还是实现可以的一些个性化的需求，当然软件供应商的态度也是一个关键。在硬指标上做好了，态度是很重要的。一般也会参考软件供应商的以前经营情况、团队情况、管理情况、市场情况、行业经验。
作为软件供应商，如何站在甲方的立场上进行考虑，也是一个重要的方面。
今天的天气不错，外面嗡嗡的机器搅拌的声音，冲刺在我的耳膜。我在写着博客。招标失败的信息让深思。行业的经验和产品的成熟度确实让人担心。现在的部分产品确实比较完善，但是成熟度确实还是有赖于提高。创新的思维方式现在很少，甚至原来比较好的思路也难以继承。这一阵主要在忙着市场，每周都在与客户进行交流，内部的开发关心的少了很多。方案写的越来越多，但是本身软件关心的少了很多，很多时间自己的代码也懒得写一下。也许真的需要好好休息一下，思路真是很是匮乏。
ETL(Extract-Transform-Load的缩写，即数据抽取、转换、装载的过程)作为BI/DW的核心和灵魂，能够按照统一的规则集成并提高数据的价值，是负责完成数据从数据源向目标数据仓库转化的过程，是实施数据仓库的重要步骤。
ETL是数据抽取(Extract)、转换(Transform)、清洗(Cleansing)、装载(Load)的过程。是构建数据仓库的重要一环，用户从数据源抽取所需的数据，经过数据清洗，最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。