项目管理中我们可以将自己所做的事分为四类。
不重要且不紧急的事
这一类工作对于系统的建设毫无益处，也肯定不是我们工作的大方向。在一般的情况下，我们几乎不会碰到。这里暂且不讨论。
不重要但紧急的事
这类工作的特点是不重要，但由于各种原因需要我们立刻做出响应、提交结果。
如果我们大部分的时间在做这样的事，就值得我们反思。我们要努力减少这类事中可控的部分。
之所以不重要，是因为他对我们系统的整体建设贡献不大、对后续没有支撑、对现有应用没有影响。
紧急是因为有些事是非做不可的，这可能影响到客户的利益，也会间接影响到项目的前景。
这类的工作如临时的数据提取、在上线计划中期临时应付领导检查、应付集团巡检。
如果存在大量、重复的临时提数，是不是意味着我们的应用太多的偏离了用户的需求，导致用户在现有应用中无法得到自己想要的数据？
重要且紧急的事
这类工作可以说是我们工作的重点。
重要是因为客户关心、紧急是客户急切需要。
对于一个客户关心且急切需要的问题，才是我们项目建设所要解决的头等问题。
So，毫无疑问，我们目前所做的大部分工作就是这一类。
我们日常需求的分析、整理，大部分应用的开发。都是在做这一类重要且紧急的事情。（不过首先要弄懂客户的需求??）
重要但不紧急
最重要，也是我们最容易忽略就是这些事。
项目的成败与好坏和这部分的工作有着莫大的关系。
我认为如下的这些内容都属于这一类
数据准确性的核查。
数据库模型的设计、中间层的设计。
数据库的备份
ETL数据控制
对于如上列出的这些内容，可能一些真正有项目经验的人会有一些异议。
比如数据库的模型和中间层的设计，这些可能是紧急的且重要的。
但是在我经过的这些项目中，这一点却最容易被人忽视。
我说这些是重要而不紧急的原因，是因为在国内大多数项目中，都面临着时间不足的问题。
曾经一本项目管理的书上如是说：在国内，没有哪个项目的时间是充裕的。一般都在加班加点的情况下可以完成就很不错了。
那么在加班加点都在应付什么工作呢，对！是在应付哪些重要且紧急的工作。
说到底就是应付客户大量的需求。加之项目的人员流动大，各个部分的负责人只关注自己负责的一块。最终结果就是没有人关注这些重要但是不紧急的事。
但是如果将重要分级的话，我认为这部分所提的“重要”,其程度会更高一些。
如果我们拨开迷雾看本质，那么真正能够抓住项目本质的，恰恰是这些工作。
目前用户的需求随时都在变动，今天需要的需求可能下个月就不需要了。
今天的需求，下个月就可能推倒重来。最终只有通过我们模型、中间层的设计，来应对客户需求的各种变化。
1.对于项目，有清晰准确的模型。
2.对于ETL严格的把控。(准确性、及时性、安全性)
2.对应于模型，有低、中、高度汇总的中间层数据。(无论这个中间层是MK.ODS,EDS等等）
3.对于模型和中间层，不断地重构和维护。(对于模型不会经常变动，主要是对中间层的维护)
这里我需要举一个小例子，锁网用户应该作为一个应用，还是作为用户的一个属性呢？
其实问题虽小，但是涉及到我们是在整体上看问题，或者仅仅是对客户的需求-响应的简单处理！
对于一个项目的成败，有太多可控和不可控的因素。况且现在项目的成功与失败的界限，已经越来越模糊。
我们是不是说签了合同就是成功。或者说有盈利就是成功？又或者说按时完成了开发任务就是成功呢？
我想对于项目的成功与需要综合考虑才能判定。
但仅仅从项目建设上来说，那些重要不紧急的事更能起到决定性的作用。
