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