虽然从目前情况来看，它还有希望不会沦为“死亡项目”，但如果实施过程中不小心翼翼、步步为营，结局
就很难预料了。
虽然有着诸多不利因素，但是我们团队也还有一些有利因素，也许可以主宰项目的命运：
1）开明的领导。俺们的各级领导都算通情达理，不会做那种拍脑袋下结论、赶鸭子上架的事情；
2）详尽和准确的需求调研。前期的很多准备工作不是白作的，最后出来的需求调研文档基本反映了用户的最终
需求；
3）迭代的设计评审制度。大量时间花在编码前的设计上是值得的，原因我就不多说了，凡是学过PM的都清楚；
4）陆续加入的资源。（这一点很有可能从优势变为劣势，因为谁都知道项目中途加入新人只会影响进度）
在项目的初期，作为一个普通员工，在这种情况下最应该做什么呢？我觉得最重要的一样事情是做好个人计划。
不是从项目管理出发的那种整体计划，而是针对自己的任务（功能点）出发的个人计划－－WBS清单：
项目经理制订的项目计划通常都比较粗线条，并没有具体到一个个的功能点，只是给出了哪个模块由谁负责、在
哪个期限之前完成。如果你不去自己细化它，而是抱着一种做了多少是多少的态度来实施这个计划，那么可能有
两个问题出现：
1）你负责的模块对于整个项目来说是个不可见的“黑盒子”，没人知道它到底完成到什么程度、完成得怎么样、
存在什么问题。连你自己都不知道自己的进度情况，领导就更不知道了，说不定就会出现拍脑袋的事情出现；
2）万一由于资源、时间或者技术难关的原因无法按时完成任务，那你就成了整个项目进度拖延的罪魁祸首－－
领导会问你：既然有问题，为什么不早提出来？为什么要等到项目工期近了才提出来？
为了避免成为罪人，就要做一个聪明的项目参与者。首先要做的是制订一份有关个人的详细的WBS(Work Breakout
Structure，工作分解结构)清单。把自己的负责的模块的功能点全部列出来，注明每一项可能需要花费的时间、前提
条件、可能存在风险等。其目的无非是使得自己的工作足够透明、使得自己的工作时刻处于可控状态。
制订完WBS清单之后，当然是把它呈现给项目经理看，通常这个时候你的台词应该是：“hello，经理，这是我的详
细计划。根据我的评估，你分派给我的任务，是无法在项目限期内完成的，请你给我多分派人手、或者裁剪一下需
求，要不，发我双薪让我拼命加班？”
如果在你有WBS为据的前提下，经理还是逼迫你去完成原来规定的任务，我想这个时候你是不是应该考虑一下项目
失败之后你的出路啦？
最后是几个需要注意的问题：
1）留余地。 制订计划一定要正常，不要把自己的一天工作时间安排到12个小时，不要把自己的周末时间全部占用，
不要忽略了陪老婆孩子、打球、生病的时间；
2）计划与需求密切配合。要知道项目的验收是看需求的，如果你的计划能够与需求上的每一个用例密切配合，相信
领导会觉得你的WBS清单更可信更科学，而且这样的计划实施起来也会很爽的；
3）在出现意外情况时（例如领导要你临时接点额外任务时），记得拿出你的WBS清单，跟领导讲价：“工期给我延
长几天吧？” 如果不这样，你还是一样会很有可能成为一个可怜的失败的项目参与者，呵呵。