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