作为一名系统工程师， 10年后，你现在所学习到的各种技术有多大程度还有用呢？
可能你会说：“10年后现在所学习到的技术基本没有用处了”。
在IT这个技术更新换代这么快的行业里，有这样的不安感没有坏处，
但是，如果你看看，理解一下一些经验者的思想，你应该可以获得自信，有些技术是10年后照样通用的。
哪些技术是10年后还会通用的：
1、把技术分解后理解吸收的技术。
2、通过与现有技术知识比较、调查分析新技术问题的技术。
更广泛意义上的技术（项目管理、设计分析）：
3、把握项目状况的技术。
4、风险把握的技术。
有过几年项目开发、管理经验的同行应该能理解以上提到的“技术”的概要含义，
接下来我再把它展开，借助一些自己和他人的事例， 跟大家交流和沟通。
1、把技术分解后理解吸收的技术。
2、通过与现有技术知识比较、调查分析新技术问题的技术。
你所在的公司、新的项目又要采用新的技术了，但新的技术采用的话会有哪些风险，这需要你去评价的时候。
或者已经采用的新的技术，项目经常会出现一些预见不到的“小”技术问题需要你去解决。
这样的场面，作为一名专业系统工程师，不管是今天或10年后，同样会存在的。
看看在这个时候如何运用以上两种技术。
学习和评价新技术的时候
要正确评价是否采用一项新技术时，关键要能理解新技术的本质。
本质由“目的”、“概念”、“构成”组成。 对新技术的理解要
分解成这3个方面来。
不要去看太多对该技术的长篇大论说明，
按照本质的这3项内容，抓住几个
关键词去理解，就抓住了该技术的经脉。
比如：最近比较流行的SOA
概念：面向
服务的
架构(Service Oriented Achitecture)
构成：
松耦合的通信结合
目的：各
子系统能简单地组合
当然，抓住了几个关键词后你能理解多深还有一个关键点就是对这些词本身的理解度了。这些内容就像练武功当中的基本功。没有任何一项新技术是完全新的，其中的90%都是之前的概念、技术的改进。
比如用“面向对象”的概念来
比较SOA。
对象的重要概念是属性和方法。比如人的属性有手有脚，方法能跑步。强调对象的共性。
SOA是面向服务。服务的概念就是任务交给我来做，具体怎么做就不用你管了。强调对象之间的分工。
面向对象的设计有个关键点是封装，不该你知道的东西就不让你知道。 SOA的设计有个关键点是责任明确，什么业务功能该是哪个子系统的分清楚，有跨系统的业务时就设计子系统之间的接口与通信。
这样一看，SOA里有大多的概念是面向对象中传承下来的。如果你的项目组中对面向对象设计开发熟悉的话，就不用怕朝采用该新技术和概念的方向去了。
调查解决系统BUG的时候
“新技术”不光是指业界新出现的技术，对于你而言是“新”的技术问题同样可以用以上的分解、比较方法来掌握。
我曾经帮分公司一个做系统维护的同事解决一个对我来说是“新”的技术问题。 一个BS系统，后台是Oracle数据库的，用户使用系统一年后多个功能的性能急剧下降，有个画面查询100条数据要5分钟！ 我没做过几个BS系统，Oracle没接触过。但可以用分解、比较方法帮助同事解决了问题。
首先：系统性能问题可以
分解成客户端， 通信， 服务器端（应用服务器端、DB服务器端）。
如果是客户端程序的问题，一般是有复杂的显示处理逻辑才会出现，多个功能都初步排除。 通信的问题：可能是前程序与后台过多往复请求造成，优先度放后面点调查。 服务器端，有变化的是DB数据量中主要表数据近期上升到百万条（虽然还是少量级）。所以先查DB。 用我现有技术Informix的知识判断，该数量级就出性能问题应该是索引优化设计有问题。 接着跟同事一起用Oracle索引分析工具来调查（我提出要用索引分析工具来调查的时候，同事还不知道Oracle中有该分析工具，而我用
比较
的方法就可知有该工具并且使用方法不会有多大的差异）。当时优化了其中一个表后，前面提到的画面查询时间就降到了10秒。 后来，仅索引分析改善的方法就解决了性能问题中的70%。（当然索引优化也可能会导致其他相关联的程序性能降低的，后来在这项负面影响范围的验证上花了不少时间） 其它30%主要是客户端程序的部分代码不良导致的。
我不是要描述同事菜鸟，问题应该是，对维护重视度或投入不够，而技术员还没到30岁就没有什么钻研新技术的干劲是挺可悲的。 我接触的国外的系统工程师中有很多是40多岁了还有时会做程序员的角色，对技术那是专。
3、把握项目状况的技术。
4、风险把握的技术。
系统工程师以下要做的事应该是10年后也是一样的：
项目按计划保质完成、设计适合用户的业务系统。
做项目管理的时候
3.1 确实把握项目进度的技巧
项目管理的两个角色: PL(PROJECT LEADER)项目带头人和PM(PROJECT MANAGER)项目经理是不一样的, 我试着从这两个视点来讲一讲.
2005年我做一个项目的PL, 项目的开发阶段(不包含设计)被压缩得很短, 只有3个月, 高峰期需要有28人同时在开发和测试. 进度控制是整个项目成功与否的关键因素. 我们采取了以下措施: 划分3个小组, 小组每天早上开一个10分钟左右的短会, 确认进度和各自碰到的困难. 每个星期全体
固定开一次项目定例会, 重点就是进度确认. 开会之前我和两个副手分别将划分好的3组模块的详细功能进度统计信息分析, 写成每周进度报告书, 内容是
进度图(开发和测试的每周进度计划曲线与每周进度实绩曲线)、
本周重点解决的问题、
目前主要担心点、以及根据这些内容分析后对进度进行微调整的方法。会议上向所有项目成员及PM进行短时间的报告，通过进度图向所有成员明确大计划进度及自己所作部分所处的状况，通过重点解决的问题和主要担心点引导大家讨论....
这个项目进度和质量控制都比较成功, 我总结了主要是上面几点方法, 它的道理是什么呢? (方法可以变, 这道理才是不变的).
其一: 每个人对自己进度的认识都是不准确的, 一般是偏向过于乐观估计. 如果每天让他说出来, 并且同时把碰到的困难说出来, 自己对进度的认识会变得清晰一些. 旁观者也可以比较客观地理解他的进度, 反而可以给他提醒和帮助.
其二: 每个人口头说出来的进度都是不准确的, 因为短时间说出来的内容往往考虑不周, 遗漏了整体工作的其他内容. 各个功能的进度加起来是不等于总体进度的. 所以让每周总结进度写出来.
其三: 每个人对自己要重点解决的问题认识是不同的, 进度延迟的原因往往是计划该完的作业还在继续, 无视进度延迟导致有其他更要重点解决的问题或进展方法必须改变的事实. 所以例会上就着进度总结里的
本周重点解决的问题
来展开讨论, 基本上可以找出进度延迟的真正原因.
其四: 有些问题超出自己的控制范围时, 大家就会"担心", 所以根据报告里"目前主要担心点", 可以找到你需要帮助成员解决的问题. 并且有些是你也无法预知和控制的, 这就是项目的
风险.
报告会之后我向客户(老板)报告的时候主要就是报告风险. 提前采取预防措施.
(这部分例子待加.)
这是以前写的日志，郑福根个人日志搬家。。。给看了有用的人看。