罗明的博客
... ...
讨论Eclipse, Java, Linux, Google产品
              

前段时间,团队开始实施一个新项目。这个项目有着中国IT行业的三个共同特点:需求繁、工期紧、资源缺。
虽然从目前情况来看,它还有希望不会沦为“死亡项目”,但如果实施过程中不小心翼翼、步步为营,结局
就很难预料了。

虽然有着诸多不利因素,但是我们团队也还有一些有利因素,也许可以主宰项目的命运:
1)开明的领导。俺们的各级领导都算通情达理,不会做那种拍脑袋下结论、赶鸭子上架的事情;
2)详尽和准确的需求调研。前期的很多准备工作不是白作的,最后出来的需求调研文档基本反映了用户的最终
需求;
3)迭代的设计评审制度。大量时间花在编码前的设计上是值得的,原因我就不多说了,凡是学过PM的都清楚;
4)陆续加入的资源。(这一点很有可能从优势变为劣势,因为谁都知道项目中途加入新人只会影响进度)

在项目的初期,作为一个普通员工,在这种情况下最应该做什么呢?我觉得最重要的一样事情是做好个人计划。
不是从项目管理出发的那种整体计划,而是针对自己的任务(功能点)出发的个人计划--WBS清单:

项目经理制订的项目计划通常都比较粗线条,并没有具体到一个个的功能点,只是给出了哪个模块由谁负责、在
哪个期限之前完成。如果你不去自己细化它,而是抱着一种做了多少是多少的态度来实施这个计划,那么可能有
两个问题出现:

1)你负责的模块对于整个项目来说是个不可见的“黑盒子”,没人知道它到底完成到什么程度、完成得怎么样、
存在什么问题。连你自己都不知道自己的进度情况,领导就更不知道了,说不定就会出现拍脑袋的事情出现;
2)万一由于资源、时间或者技术难关的原因无法按时完成任务,那你就成了整个项目进度拖延的罪魁祸首--
领导会问你:既然有问题,为什么不早提出来?为什么要等到项目工期近了才提出来?

为了避免成为罪人,就要做一个聪明的项目参与者。首先要做的是制订一份有关个人的详细的WBS(Work Breakout
Structure,工作分解结构)清单。把自己的负责的模块的功能点全部列出来,注明每一项可能需要花费的时间、前提
条件、可能存在风险等。其目的无非是使得自己的工作足够透明、使得自己的工作时刻处于可控状态。

制订完WBS清单之后,当然是把它呈现给项目经理看,通常这个时候你的台词应该是:“hello,经理,这是我的详
细计划。根据我的评估,你分派给我的任务,是无法在项目限期内完成的,请你给我多分派人手、或者裁剪一下需
求,要不,发我双薪让我拼命加班?”

如果在你有WBS为据的前提下,经理还是逼迫你去完成原来规定的任务,我想这个时候你是不是应该考虑一下项目
失败之后你的出路啦?

最后是几个需要注意的问题:
1)留余地。 制订计划一定要正常,不要把自己的一天工作时间安排到12个小时,不要把自己的周末时间全部占用,
不要忽略了陪老婆孩子、打球、生病的时间;
2)计划与需求密切配合。要知道项目的验收是看需求的,如果你的计划能够与需求上的每一个用例密切配合,相信
领导会觉得你的WBS清单更可信更科学,而且这样的计划实施起来也会很爽的;
3)在出现意外情况时(例如领导要你临时接点额外任务时),记得拿出你的WBS清单,跟领导讲价:“工期给我延
长几天吧?”? 如果不这样,你还是一样会很有可能成为一个可怜的失败的项目参与者,呵呵。

Source:做一个聪明的项目参与者--制订WBS清单



版权所有 罗明
posted on 2005-05-25 17:54 罗明 阅读(171) 评论(0)  编辑  收藏

只有注册用户登录后才能发表评论。


网站导航: