杂谈项目中的那些事儿:计划与变化_项目管理_非技术区_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 非技术区 > 项目管理 > 杂谈项目中的那些事儿:计划与变化

杂谈项目中的那些事儿:计划与变化

 2011/11/16 13:14:25  ghner  程序员俱乐部  我要评论(0)
  • 摘要:IT项目中,我们最恐惧什么?项目中止?不是,因为对于尽心尽力的我们而言,“项目中止”很少是因为咱这些苦哈哈,也许是财务危机、也许是项目的必要性已不存在、也许仅仅是无限期的延迟。所以,这里我们讨论的是:一个正在执行的还算正常的项目进程中的事情。对于项目执行和管理者而言,我们最恐惧的其实是“变化”,如果谁为了讨好客户和老板,大声呼喊:“我会快乐地拥抱变化”,那么不要客气,对他倒竖中指吧,因为他正把大家拖入泥潭。事实如此
  • 标签:项目 那些事儿 变化

  IT项目中,我们最恐惧什么?

  项目中止?不是,因为对于尽心尽力的我们而言,“项目中止”很少是因为咱这些苦哈哈,也许是财务危机、也许是项目的必要性已不存在、也许仅仅是无限期的延迟。

  所以,这里我们讨论的是:一个正在执行的还算正常的项目进程中的事情。

  对于项目执行和管理者而言,我们最恐惧的其实是“变化”,如果谁为了讨好客户和老板,大声呼喊:“我会快乐地拥抱变化”,那么不要客气,对他倒竖中指吧,因为他正把大家拖入泥潭。

  事实如此,但是纵然我们再怎么不喜欢它,现实情况是:我们不得不接受某些变化。人本身就一直处在动荡的环境中,只是很多时候没有觉察而已。洪灾、地震、SARS、H1N1、伊拉克、朝核、油价、房价、股市以及生老病死,他们都以不可预料或不可准确预料的方式到来,并深深地影响着我们。一种是已知的未知,一种是未知的未知,无论是哪一种未知的变化,一旦发生就会冲击我们的生活。

  从某些角度来讲,我们做IT尤其是软件项目的同仁们算是幸运的了,不会因为建筑工地在伊拉克、苏丹、阿富汗而让家人牵肠挂肚。我们坐在明亮的Office中,对着thinkpad coding,手边还放着一杯coffee。的确,从这个角度来讲,我们真该对自己所处的变化心平气和了。

  为了应对这些变化,我们会采取很多措施来增强自己对项目的安全感。计划就是其中最终要的手段。

  项目经理

  看着WBS:会让我们觉得事情还是挺清晰的吗,这事这么干准成。

  看着横道图,我们又会感叹,事情正有条不紊地进行。

  看着资源负载图,拿着资源平衡表,虽然有些头疼,但也不像想象般的糟糕吗!

  技术经理:

  恩,所有的都按照原先的架构在进行,只要再过三个月,就能交工了。

  事实上,这两个人无日不生活在焦躁不安中。他们知道:所有的利害关系者都正琢磨着:怎么样改动一下,才能让自己脸上倍儿有面子;才能让钱花得不那么愿望;才能体现出我在项目中的价值。

  从供应商和客户的角度来讲:甲乙双方都会有人参与项目,都会有各自的项目负责人,不是东风压倒西风,就是西风压倒东风。我们一般都是乙方,而且经常是被压倒的那位。

  所以,我们的计划总是在修改后再修改,基线调整后再调整,压力一日日增大,甚至要委派一个专门的计划师来做计划。

  我本人本质上很讨厌计划,因为正是计划的出现,让我提前感受到变化的痛苦,虽然没有计划,变化会在最后一次将项目压垮,但我真的很讨厌计划。过去做项目 时,总是硬着头皮,忍着万分的悲痛去看分解,看进度,看那些我很难相信的完成百分比。我已被计划折磨疯了,错了,应该是我已经被计划和变化一起折磨疯了, 我充满了对现实的怀疑精神,可惜我不是哲学家,也不是科学家。

  一度,我陷入一个误区,希望能制定出一个很弹性的计划,让它不那么产生变化。结果是,除了在WBS的最高节点写上项目名称和完工日期,其他我什么也不能做,的确够弹性的了吧。幸好我还没傻到那种程度,敢拿这玩意儿计划交给BOSS和客户,所以也避免了被开除的命运。这都是很久以前的事情了,现在我已经在另外一个职位上工作了,勉强摆脱了项目的梦魇。
对着空白的Project 2003,经过一番苦思,我得出一个结论,应对变化的根本就是计划之外的事情。计划跟变化就像哥俩儿一样,也许更像一面镜子,他们分属镜子的两端,计划总是能在镜内反应出变化所在;变化也能帮镜外的计划变得更加美观合理

  由此,可以看出我这人还真是笨的不一般了吧。

  PMP告诉我们:风险管理很重要,处理已知的未知,需要动用应急储备;处理未知的未知,需要动用管理储备。但是他没有告诉我们怎样鉴别和处理变化。至少在我看来,那些决策树、散点图、七点定律都太具有科学意义了,不大适合咱们“不按章法出牌”的中国国情。所以我想从更感情用事的角度探讨一下:

  1、大胆的拒绝客户的要求

  如果你的合同已经签立了,如果客户实在逼得你太狠,如果你真的觉得这是个不应该接受的变化,那么你就大胆的拒绝他。并且告诉你的BOSS,你拒绝了客户,好让他有心理准备:客户要找他麻烦,告自己的黑状了。你要自信,这事儿就得这么干,换了别人来也一样,你是为了他的利益才这么做的,绝对没有私心。如果他是个好BOSS,就应该帮你顶住对方的压力,毕竟你鞍前马,不仅有功劳,更有苦劳。

  2、拿标准堵住嘴

  不是让你忽悠人,很多时候,客户提出的要求根本就违背了自己的企业标准,那么你很好心地劝告他:对不起,要修改,请先修改你的企业标准,否则这个将来验收的时候,我们都不好办啊!所以,做项目的时候,摸清对方的底子很重要,尤其是这些平时看着是鸡肋,却极有可能影响到项目决策的东东。

  3、对你无能为力的请求,照顾一下公司的面子

  现在大型的软件项目,很少是从头开发一整套方案的。在竞标的时候,往往会说基于什么什么平台,然后在这些平台上做定制。定制这件事,在做项目时,你还是得强调强调的。如果碰到项目团队无法承担,公司也无法解决的问题,怎么办?建议不要直接说NO。而是委婉地说一句:“已提交研发部”,不要加上什么正在解决之类的话,就这六个字,多一个也不要。因为你很诚实地说出了你所知道的一切。

  4、项目第二期

  有些需求是你无法拒绝的,特别是一些系统增强性的需求,而且他也包括在签立合同所包含的项目范围之内,凭着天地良心,你也觉得这些要求不过分,但是你实在没有多余的时间、资源去解决,项目要收尾,要尾款,你说NO也太不给客户面子了,那么不如说:“我们会在项目第二期做”,如果不是大领导,他们也会半含糊着接受了。

  5、告诉团队成员,尤其是开发人员,要变化请告诉我

  很多变化其实也是内部产生的,你要鸡,结果作出个狗来了,为什么?狗把鸡撵跑了。为什么会撵跑,开发人员跟你说:因为我感觉你这个设计不好。然后自我感觉很天才的样子。说实话,我不反对天才,但是在你拿出天才的成果之前,能不能先跟我谈谈你天才的想法。你站在局部的角度,我站在项目的角度,老板站在公司的角度。我自个儿还经常跟老板讨论项目的事情,你干吗不跟我讨论设计的事情。

  6、团队之中界面得拧清

  界面不清爽,大伙儿就容易干出格的事情,所以开发人员会关心架构设计,并主动更改了架构的一部分。团队的组织虽然灵活,虽然没有太多的框框条条,但是大家工作界面的划分是默契协作的根本,否则,出了个什么事,都不知道找谁;不知道找谁,但又很有责任心的人就会自己处理。问题就大发了,虽然我不反对在某些事情上,应该互相帮忙,但是主次始终是存在的,负责人始终是存在的,该知道的人都该通知到的。

发表评论
用户名: 匿名