站点公告
最新日志
博文评论
博客留言
博客登陆
博文搜索
博客信息
收藏连接
 
为什么项目管理 
一孑 发表于 2009/2/17 17:20:00

为什么项目管理?讲个小故事说吧,绝对杜撰,如有雷同,肯定巧合。

一家公司接了一个小项目,为一个行业网站实现采集数据。于是公司技术人员分析了一番,一致认为难度不大,且工作量也不会很大,主要的难点就是多线程的处理及数据采集规定的处理,其他内容都比较简单,于是公司委派小王、小张、小刘三个人临时组成了一个项目小组来开发这个小系统,预计两个月完成。因为主要是涉及技术问题,所以就让技术能力稍强的小王来负责。

于是小王领着小张和小刘聚在一起开了几天的会,主要是商讨任务分工和解决技术难点。最终决定:小王负责整个软件的集成及系统内部接口规范定义,小刘负责多线程的处理,小张负责界面及采集规则的实现,两周时间进行系统的设计,一个月进行编码操作,剩下两周进行测试,因为集成工作是实时的,可发现很多问题,所以考虑测试两周应该够了,应该都是小问题容易解决,于是并没有申请延期,就按照两个月来进行了。分工明确,任务开始,并且约定每日都要沟通一次,确保彼此工作的一致性。这样下来也过了一周了,为了项目质量,小王向公司提出要求,项目启动时间按照当前来计算。黄总许可。项目启动。

先期进展应该说是很顺利的,制定了相应的接口规范,并且也解决了一些技术问题,如期两周之后对设计成果进行了合并,并确定了彼此负责内容的接口形式及接口规范。编码工作开始。因为有每日沟通做基础,所以,合并工作并没有出现太大的问题。

编码开始后,小王的工作不是很多,接口定义在设计阶段已经做的差不多了,集成工作要等一些成果出来,所以,小王就又重新审核了一下这个小项目,希望能提前降低一些风险,为后期的工作减轻压力。并把当前的工作成果内容向公司做了汇报,也向客户做了沟通,告之公司及客户项目进展一切正常。

公司黄总在接到这个项目之后也一直在考虑一个问题,是否可以将这个小项目产品化,毕竟网络采集还是有一定市场的,同时也可为公司积累一些产品出来,在听了小王的汇报后,当即拍板决定在为客户做项目的时候也做自己的产品。为了应对这种变化,黄总又增加了一个人员小李到项目组主要配合变更部分的制作,并且延长了半个月的时间,最终确认两个半月完成,产品部分只要达到α版测试要求即可。

小王有点犹豫,但还是支持了此决定,因为感觉只是在原有的基础上增加功能,并不会修改原有的内容,而且有给了资源,延长了时间,没有理由不支持啊。于是,刘总和小王又花几天时间重点讨论了在原有基础之上,应该扩充那些功能。就这样事情又开始有条不紊的进行着。这样大家就都开始忙起来了。尤其小王,真的很忙。白天开会晚上考虑设计的问题。

因为忙,原定的每天的沟通变为了两天一沟通,不怪小王,因为小王确实很忙,需要重新考虑新增功能的设计,需要考虑对原有设计的变更,总之问题多多。小王为了不耽误项目的进展,并没有占用小刘、和小张的时间,而是自己承担了很多的工作,并且让小李来配合自己。慢慢的两天的沟通也保障不了了,因为小王将新增的独立性较强的功能分给小李开工了,又是自己来应对了,变得更是忙的不得了。还要与公司沟通新增功能的可用性问题。

差不多明确了方向和目标,也做了相应的设计调整,但就这样也过去两周时间,小王想了想,应该还来得及,毕竟又延长了半个月,增加了一个人。于是召开会议,开始重新分配任务,尽管小刘和小张提前就知道有些内容要发生变化,但还是有点情绪,但还是为了项目的进展接收了这种变更。

事情还是有条不紊的进行着,至少看上去是这个样子,而且每个人的工作都很饱和。黄总心里也很高兴。

很快,小刘就发现了问题,原本的数据采集子线程的分配的方式好像有点行不通了,因为在新的规则变化后,任务执行时是无法获取所有信息,需要进行回调的处理,由于回调可能会引发更多的线程处理问题,所以找小张协商,希望小张可以先将此信息获取,这样原有的子线程分配模式可以不变了,毕竟线程的调试是一件很痛苦的事情。但小张也开始痛苦了,因为要目标改变了(明确的说是提高了),所以要对以前的内容要进行拆分,并结合小李做的引擎进行解析,否则无法支持新的规则,同时界面部分需要拆分,针对客户和自身产品的功能提供是不同的。所以不同意小刘的修改意见。于是小刘就希望小李来帮小张的忙,但小李刚刚介入项目,而且又是做的独立行的东西,对项目整体不是很了解,加之又是修改别人的代码,所以也感到有风险,不太愿意,建议还不如重新构造。三人意见截然相反,于是共同找小王去协商。

此时也已过去一个多月了,小王也开始了现有成果的集成,虽然内容不多,但也发现了一些问题,也想着找其他人共同协商,于是,四个人又聚在了一起。针对不同的意见,小王也很为难,因为项目周期比较短,如果让小李熟悉了代码再修改,时间恐怕来不及,但如果重新构造,相当于又需要进行一次返工,有点浪费,让小张来修改,确实小张的工作量已经很大了,从合理的角度来讲也是应该小刘来修改,但如果这样做,线程的分配调用模式一改,内部需要调整的地方还是很多,而且调试也很困难。

经过再三衡量决定,还是小刘来改,小张还是继续以前的工作,小李抽调出来负责集成,小王自己来解决已经发现的问题,毕竟自己最了解这个系统,同时因为自己的直接参与肯定也会杜绝以后的一些风险。小王心里很郁闷,自己发现的问题还得自己来改。没办法,为了项目最起码要以身作则么,有了小王的以身作则,第一次项目内部矛盾就这样被平息了,项目又开始有条不紊的进行着,尽管小刘和小张心里有点不爽,但为了项目大家还是比较齐心。

又过去一段时间,小李在集成现有成果的时候又发现了很多问题,因为在集成的时候,发现实际很多工作都没有做,完全是靠着集成的时候来完成,而这部分内容自己又不是很熟悉,加之自己还要承担其他编码工作(与小张的配合完成网址解析编码),虽然可以把发现的问题交给小王来做,但总不能一直这样吧,感觉自己好像不尽力似的,尽管如此进度也发生了的延期。好像项目的瓶颈成了小李,小李真的很无奈的向小王再次发出求助请求。

此时的小王也正处于水深火热之中,在帮助小李解决集成问题的时候,也发现了很多的问题,譬如:原来说的不需要保存任务的实时状态现在发现只需要增加几行代码就可以了,如果将来扩展这个功能会更困难,所以,这种小问题就不断暴露,不断的开始重新思考并解决。这每一点都需要小刘和小张的配合才可完成。此时应该说是项目最紧张的时候。所以,对小李的支持力度也就慢慢的弱下来了,等接到小李的求助时真的是有点有心无力了。于是就委派小刘帮助小李来完成,自己集中精力先把需要关键部分完成,让小张赶快把界面部分全部做完,确保在两个月后可以完成第一次集成。

于是所有人在小王第二次的号召下,再次开足马力,毕竟小王的技术能力和人员在这个小团队中还是颇有威望的。此时,黄总也找小王聊了聊天,告诉小王不要做个救火员,应该做个PM。小王心里也很想,但真的是有苦说不出啊,只能一直苦笑。

终于,两个月后,在所有人埋头苦干的玩命精神下完成了第一次的集成工作,小王终于可以松松气了。系统集成好了,开始了第一次的集成测试工作,这一测不要紧,确真把小王吓一跳。很多功能做了界面没显示(小李也不知道),界面有的功能后台又不支持,更为夸张的是,甚至连个数据也采集不下来。尽管偶尔也能采集了数据出来,但简直无法忍受。

小王终于忍耐不住了,真的生气了,训斥了所有人,实际大家也很委屈:

小李:我刚介入不久就让我做集成,很多问题确实不太了解,需要小刘和小张配合,尤其遇到有些需要修改的地方,我也拿不定主意,所以希望您可以协调,但您太忙了,很多问题只能靠我们自己来做,所以,问题可能会多一些。但真的已经很尽力了。

小刘:自己也帮助了小李,尽可能的将需要修改的东西由自己来承担,但很多内容都调整了,甚至有些牵一发而动全身的修改,真的也是尽力了,但时间真的太仓促了,肯定会造成为了追求进度而降低质量的问题。

小张:由于目标变了,很多我们产品提供的功能不能提供给甲方,所以,很多界面都具备两套内容,甲方的功能尽可能形成组件由产品来继承,但就这样,需要做的工作还是很多的,尽管需求本身没有太大的变化,只能增加了功能,但正是这种增加的功能和面向的客户群体不同才造成了这种局面,而且还要配合其他人的工作。

小王:无语,只能硬着头皮继续做吧。

又半个月过去了,大部分的错误都修改了,程序大部分功能都可使用了,但还是存在很多的bug,无法满足交付要求,同时甲方也开始催促什么时候可以做完。项目时间已经到期,但很多的bug还没修改。黄总是比较理解的,所以建议先保甲方的项目,再考虑自身的产品。

又半个月过去了,经过不断的测试-修改-再测试-再修改,甲方的项目算是基本上完了,但这是以牺牲自身产品的工作为代价的。交付甲方,基本可用,等待甲方意见回馈。

又经过多半个月,自身的产品可以交付α版可以交付了,但是以代码拆分为代价的,并非是一套完整的代码,如果甲方项目可以交付还算简单,如果甲方项目如果继续,那将意味着同样的东西,以维护两套代码为代价的。

黄总拍了拍小王的肩膀,看来你还需要多历练历练,还是先做好自己的本职工作吧,把后期维护及产品升级的问题搞定了再说。看来小王还得再投入一次了。

小王欲哭无泪啊,心里这个悔啊,为什么当初没事要找黄总汇报说项目一切都可控制,为什么当初没事要支持黄总决定,为什么当初要让小李做集成,为什么当初……为什么当初……太多的为什么了。

要我说,为什么不项目管理!

 

发表评论:

    昵称:
    密码:
    主页:
    标题: