IT项目中，我们最恐惧什么？
项目中止？不是，因为对于尽心尽力的我们而言，“项目中止”很少是因为咱这些苦哈哈，也许是财务危机、也许是项目的必要性已不存在、也许仅仅是无限期的延迟。
所以，这里我们讨论的是：一个正在执行的还算正常的项目进程中的事情。
对于项目执行和管理者而言，我们最恐惧的其实是“变化”，如果谁为了讨好客户和老板，大声呼喊：“我会快乐地拥抱变化”，那么不要客气，对他倒竖中指吧，因为他正把大家拖入泥潭。
事实如此，但是纵然我们再怎么不喜欢它，现实情况是：我们不得不接受某些变化。人本身就一直处在动荡的环境中，只是很多时候没有觉察而已。洪灾、地震、SARS、H1N1、伊拉克、朝核、油价、房价、股市以及生老病死，他们都以不可预料或不可准确预料的方式到来，并深深地影响着我们。一种是已知的未知，一种是未知的未知，无论是哪一种未知的变化，一旦发生就会冲击我们的生活。
从某些角度来讲，我们做IT尤其是软件项目的同仁们算是幸运的了，不会因为建筑工地在伊拉克、苏丹、阿富汗而让家人牵肠挂肚。我们坐在明亮的Office中，对着thinkpad coding，手边还放着一杯coffee。的确，从这个角度来讲，我们真该对自己所处的变化心平气和了。
为了应对这些变化，我们会采取很多措施来增强自己对项目的安全感。计划就是其中最终要的手段。
项目经理：
看着WBS：会让我们觉得事情还是挺清晰的吗，这事这么干准成。
看着横道图，我们又会感叹，事情正有条不紊地进行。
看着资源负载图，拿着资源平衡表，虽然有些头疼，但也不像想象般的糟糕吗！
技术经理：
恩，所有的都按照原先的架构在进行，只要再过三个月，就能交工了。
事实上，这两个人无日不生活在焦躁不安中。他们知道：所有的利害关系者都正琢磨着：怎么样改动一下，才能让自己脸上倍儿有面子；才能让钱花得不那么愿望；才能体现出我在项目中的价值。
从供应商和客户的角度来讲：甲乙双方都会有人参与项目，都会有各自的项目负责人，不是东风压倒西风，就是西风压倒东风。我们一般都是乙方，而且经常是被压倒的那位。
所以，我们的计划总是在修改后再修改，基线调整后再调整，压力一日日增大，甚至要委派一个专门的计划师来做计划。
我本人本质上很讨厌计划，因为正是计划的出现，让我提前感受到变化的痛苦，虽然没有计划，变化会在最后一次将项目压垮，但我真的很讨厌计划。过去做项目 时，总是硬着头皮，忍着万分的悲痛去看分解，看进度，看那些我很难相信的完成百分比。我已被计划折磨疯了，错了，应该是我已经被计划和变化一起折磨疯了， 我充满了对现实的怀疑精神，可惜我不是哲学家，也不是科学家。
一度，我陷入一个误区，希望能制定出一个很弹性的计划，让它不那么产生变化。结果是，除了在WBS的最高节点写上项目名称和完工日期，其他我什么也不能做，的确够弹性的了吧。幸好我还没傻到那种程度，敢拿这玩意儿计划交给BOSS和客户，所以也避免了被开除的命运。这都是很久以前的事情了，现在我已经在另外一个职位上工作了，勉强摆脱了项目的梦魇。
对着空白的Project 2003，经过一番苦思，我得出一个结论，应对变化的根本就是计划之外的事情。计划跟变化就像哥俩儿一样，也许更像一面镜子，他们分属镜子的两端，计划总是能在镜内反应出变化所在；变化也能帮镜外的计划变得更加美观合理。
由此，可以看出我这人还真是笨的不一般了吧。
PMP告诉我们：风险管理很重要，处理已知的未知，需要动用应急储备；处理未知的未知，需要动用管理储备。但是他没有告诉我们怎样鉴别和处理变化。至少在我看来，那些决策树、散点图、七点定律都太具有科学意义了，不大适合咱们“不按章法出牌”的中国国情。所以我想从更感情用事的角度探讨一下：
1、大胆的拒绝客户的要求
如果你的合同已经签立了，如果客户实在逼得你太狠，如果你真的觉得这是个不应该接受的变化，那么你就大胆的拒绝他。并且告诉你的BOSS，你拒绝了客户，好让他有心理准备：客户要找他麻烦，告自己的黑状了。你要自信，这事儿就得这么干，换了别人来也一样，你是为了他的利益才这么做的，绝对没有私心。如果他是个好BOSS，就应该帮你顶住对方的压力，毕竟你鞍前马，不仅有功劳，更有苦劳。
2、拿标准堵住嘴
不是让你忽悠人，很多时候，客户提出的要求根本就违背了自己的企业标准，那么你很好心地劝告他：对不起，要修改，请先修改你的企业标准，否则这个将来验收的时候，我们都不好办啊！所以，做项目的时候，摸清对方的底子很重要，尤其是这些平时看着是鸡肋，却极有可能影响到项目决策的东东。
3、对你无能为力的请求，照顾一下公司的面子
现在大型的软件项目，很少是从头开发一整套方案的。在竞标的时候，往往会说基于什么什么平台，然后在这些平台上做定制。定制这件事，在做项目时，你还是得强调强调的。如果碰到项目团队无法承担，公司也无法解决的问题，怎么办？建议不要直接说NO。而是委婉地说一句：“已提交研发部”，不要加上什么正在解决之类的话，就这六个字，多一个也不要。因为你很诚实地说出了你所知道的一切。
4、项目第二期
有些需求是你无法拒绝的，特别是一些系统增强性的需求，而且他也包括在签立合同所包含的项目范围之内，凭着天地良心，你也觉得这些要求不过分，但是你实在没有多余的时间、资源去解决，项目要收尾，要尾款，你说NO也太不给客户面子了，那么不如说：“我们会在项目第二期做”，如果不是大领导，他们也会半含糊着接受了。
5、告诉团队成员，尤其是开发人员，要变化请告诉我
很多变化其实也是内部产生的，你要鸡，结果作出个狗来了，为什么？狗把鸡撵跑了。为什么会撵跑，开发人员跟你说：因为我感觉你这个设计不好。然后自我感觉很天才的样子。说实话，我不反对天才，但是在你拿出天才的成果之前，能不能先跟我谈谈你天才的想法。你站在局部的角度，我站在项目的角度，老板站在公司的角度。我自个儿还经常跟老板讨论项目的事情，你干吗不跟我讨论设计的事情。
6、团队之中界面得拧清
界面不清爽，大伙儿就容易干出格的事情，所以开发人员会关心架构设计，并主动更改了架构的一部分。团队的组织虽然灵活，虽然没有太多的框框条条，但是大家工作界面的划分是默契协作的根本，否则，出了个什么事，都不知道找谁；不知道找谁，但又很有责任心的人就会自己处理。问题就大发了，虽然我不反对在某些事情上，应该互相帮忙，但是主次始终是存在的，负责人始终是存在的，该知道的人都该通知到的。