项目进行到今天，我突然发现项目已经花费了快70%的时间，而离编码结束似乎还很遥远，面对着领导质问般的眼神和组员迷茫般的目光，我深深地吸了一口气，大脑开始了高速地运转，到底谁动了项目的时间？
项目情况
首先介绍一下项目的大概情况：
其实项目倒不是很复杂，一个处理业务流程的系统。接到项目的消息是七月底的时候，由于当时领导与客户谈妥之后，客户想在八月中旬就看到，所以当时就非常紧张。考虑到时间如此之紧，项目便匆匆开始。本来计划三个人的，但是考虑到时间太急，又加了三个人进来。在写SRS的过程中，客户那边传来消息，DEADLINE不会这么紧，这样我们紧绷的神经轻了下来，这一松就松出了问题，对于一些不确定的需求我们一直也没有得到客户的确定，这段时间里我一方面对SRS进行尽可能多的理解，另一方面安排设计阶段的任务。随后的工作也基本上是重叠地进行的，在对需求没有清楚认识的情况下开始了设计工作，设计没有完全结束的情况下，编码又开始进行了。在编码开始后，SRS其实还没有RELEASE，MILESTONE也一直没有到。但是我们也不能一直等下去，编码在一步步地进行，突然之间，我发现，时间不够用了……
下面，我就从几个方面来分析一下为什么我的时间不够了，它们都去哪儿了呢？
进度安排
在先前的安排下，我的计划做的非常粗，因为时间实在是太短了，做的计划基本上是Mission Impossible的。在得知时间宽松一点以后，我把计划做了适当的调整，个人觉得还算比较合理，但是计划的实施并不都像计划那样的完美。
需求的不清楚使得文档的完成一托再托，耽误了不少时间，我看这样下去肯定不行，就开始了设计工作，而在设计的过程中，我们一边设计，一边等客户的消息，可是过了很长时间，最终等到的客户回馈是没有回馈。这才坚定了我们的想法，开始大干实干。而这时，项目的进展情况已经与我的计划差别很大的，设计期本来是一个星期，结果花了两个半星期，虽然在设计文档初稿完成并讨论后，我安排了一部分的编码工作，因为我不想让时间浪费，人员闲置，但是这部分的工作也花了不少的时间，使得设计的质量并没有达到预想的效果。
当然，还是那句老话，计划永远赶不上变化。即使计划的再好，在实施过程中总会发生一些事情让你的计划变得毫无意义，况且谁又能把计划做的如此天衣无缝呢。我的理解，对于计划，只需要一个大概的规划即可，即分哪几个大的阶段，每个阶段大概多久，需要多少人即可，在项目开始就制定一人精确到每天每时每人的计划完全是扯淡。
对于计划，我的一点感受就是制定计划是件困难的事情，因为软件开发不像别的计划，所有的步骤都是事先确定的，不需要你去做一些创造性的开发。而软件开发则是一项目创造性的工作，做为项目经理，每周，甚至每天都需要对于开发组成员制定计划，这种任务都是根据项目的具体情况来划分的，而且，我们的项目由于规模小，并没有专职的设计人员，每位成员都参与到设计中来，但是有一个问题就是成员都是新手，而且所用的技术都不熟悉，这势必会影响到任务执行的效率。
客户关系
客户关系是一个非常重要的问题，这个项目的情况有点像传统的项目开发。在确定项目的时候，客户发来了一个需求，然后我们根据其需要写出需求文档，然后就给客户发过去，希望能返回一些反馈。但是实际情况是文档发过去后就再也没有回馈信息。在开始的时候，我们只与客户有过一次电话会议，寻问了一些不清楚的需求。
但是随着项目的进展，更多的不清晰的需求展示在我们面前，而这以后我们再也没有与客户进行过沟通，不光是界面，还有需求，都不知是否让客户满意，现在只能等做完测试后交付给客户看看客户的认可度如何。
与客户的沟通实在是太少，结果如何，只有等项目结束后才知道了。
资源管理
在这个项目中，资源对于我来说主要就是时间的计算。每位成员在项目中的投入比例都是事先决定的。比如说只在这一个项目中工作，就是１００％，如果还有别的项目在同时做，可能就是５０％的时间在这个项目上。在项目开始后，我犯了一个错误，就是算时间的时候基本上按实际工作来说，比如一位１００％在项目中的成员今天只花了４个小时在这个项目上，那么我统计时也只算了它４个小时。而其实应该是统计１００％的时间。在得知这个错误后，我才发现刚开始编码时，我们已经花了将近一半的预计时间了。
要解决这个问题，完美的方案就是把成员每天的时间都安排满，这样的话，项目经理既不会担心无谓的时间消耗，又为项目的不增进展而感到满意。但是，这种毕竟只能是一种幻想，不可能会实现。但怎么去更高效的安排每位组员的工作，这又与上面说到的任务计划安排联系到一起。这个问题还需要学习了。
交流沟通
这里的沟通问题指的是组员之间的沟通。这个问题在项目的前期特别明显，所有的组员对于需求分析及设计的工作更多的是与我项目经理来联系，等于是我去做一个传递信息的中枢，对于需求的不清晰着实让我非常为难，甚至有时我前后说的结果都不一致。为了解决问题，我特意的将一些工作分派给两个人来做，但是效果仍然没有太大的改变，两个人之间的交流还是不够。到了设计的中后期，以及编码，这种情况才有所改变，因为此时必须要与别人去联系，交流才能将自己的工作进行下去。
后期的交流中经常发生对需求认识不清楚的情况，这又要谈到文档的问题。项目中的文档我觉得主要有两个方面的作用，一个是写文档的过程是一个思考的过程，可以帮助我们去尽可能多得思考；另一方面是交流，让大家都能通过文档了解所需的内容。但是不是每个人都会仔细的阅读几十页的文档，如何让组员清晰的了解需求以及后续文档是一个难办的问题。
风险控制
在项目进展中，风险管理还是按照来做的，每周去检查一下当前的风险状况，有无增减的必要。但是真正实施的时候，有些流于形式。首先，项目的风险项定义不难，总会定义出一些风险，但是如何去规避，发生了之后如何处理，就非常难于实现了。在当下的组织结构中，有的时候风险即使发现甚至发生了，也没有办法去处理。