公司项目管理

前言：本站为你精心整理了公司项目管理范文，希望能为你的创作提供参考价值，我们的客服老师可以帮助你提供个性化的参考范文，欢迎咨询。

项目启动阶段的主要任务根据PMI的解释，接单之后项目自然转入启动阶段。启动阶段PM的主要任务是率领总体架构设计师和系统分析员收集尽可能详细的数据，确立尽可能详细的需求，进一步确立详细的项目范围，预估资源，确立其他方案并获得进入下一阶段的批准。在这个阶段，随着需求分析的深入，PM也开始在公司内部进行人员挑选和资源争夺，着手组建自己的项目团队。项目即将进入计划阶段。

在收集完数据之后，PM要和客户开始明确项目的大小，成本，规格，期限等重要特征并将其写入合同文本，同时准备内部的包括预算，衡量标准等文档，建立项目的评估标准。接下来就是需求分析。由于专业的原因，我们这里仅讨论软件工程项目的需求分析（以下简称需求分析）需求分析的主要参与人员有PM，总体架构设计师，系统分析员，熟悉业务流程的客户。PM统领的团队这时候还不是真正的开发团队，我们叫做前期团队。随着需求分析的逐步深入，新的团队成员不断加入，启动阶段结束的时候正式的团队将建立。对一个已经启动的项目来说，需求分析直接决定了项目的成功与失败。最初的需求体现在客户的工作说明书或招标文件及附件上。这种需求一般比较含糊，无法体现客户真正的需求。前期团队要根据自己的经验和客户沟通并引导客户进入正轨。有时候客户会很不讲道理或者思路僵化，就要求按照他的思维去定一些明显错误的需求。这个时候团队成员要耐心和客户举事实，谈经验，讲道理，用图形或模型等直观的方式将需求描述出来，比如常见的数据流图等。所以说，争论再所难免，客户有时候会吹胡子瞪眼睛拍桌子甚至会说"这个东西不要你们做了"之类的话。PM此时除了要亲身参与需求分析综合整理文档之外，还要处理好团队成员与客户的关系，确保关系不会恶化到无法收拾的地步。只要PM尽力约束团队中的成员，这个度还是很容易控制的。

对快速开发和叠代开发来说，需求和实现往往是同步进行，开发速度快是一大优势。对有相同或类似模式的小项目来说采用快速开发或叠代开发是很合算的做法，时下流行的极限编程就是针对这方面建立的思维模式。然而，大中型项目中有太多不一样的需求和模块。如果不是因为项目有差异，那么市场上就只有产品而没有项目了。所以，大中型项目的需求要认真仔细的去做。我们要讨论一个问题，究竟应该在需求分析和总体设计上花费多少时间？我们熟悉的瀑布开发模式基本上分需求分析，总体设计，软件开发，测试等几个阶段，然而究竟应该在前两个阶段上花多少时间却没有定论。实际项目操作的例子表明，分析设计的时间越长，需求设计做的越详细，测试的时间就越短，返工率越低，风险也越小，成本越容易得到控制。

而需求分析和总体设计没有做好就急忙上马进行开发的项目在项目初期进展顺利的时候问题不大，到了项目后期和测试阶段一些潜伏期比较长但是破坏作用比较大的问题就会凸显出来，造成返工，延长测试时间。所以与其把问题堆积到紧张的项目后期，不如把时间多花点到需求分析和总体设计上。基础夯实了，金字塔就容易造了。在日本公司打工的程序员们可能都知道，小日本的软件规范非常厉害，他们花在需求分析和总体设计上的时间通常在40%到50%左右，远远超过国内软件项目的实施，效果也要强的多。他们总体设计的规范甚至详尽到某个过程该如何判断，确立什么样的条件，换言之就是把什么时候该如何写(if...else)语句都帮程序员定好了。在这样的软件规范下，程序员更象是装配流水线上的工人，对一个模块或技术熟悉到一定程序就变成了完全的重复性劳动。所以在日本和欧美经常会有程序员是低级工作一说，很多人不明就里，对国内程序员也照搬，对国内的程序员来说是很不公平的。在国内，只会照抄别人代码，一点都不懂创新，凡事依靠别人，快下班就盯着表看的程序员是不少，这种人一般很难有什么前途。但是，优秀的不断进取的程序员也很多。由于国内没有象CMM这样的软件规范或者很少，所以这类优秀的程序员不少都是干着系统分析员甚至PM的活，拿着程序员的工资。这类程序员虽然在起步时会吃很多亏，而且是主动找亏吃，然而几年之后与前一种程序员的社会地位会出现明显的分化。当上进的程序员们作为PM进行商务谈判的时候，前者还在各个公司里频繁跳槽，跳来跳去都不满意。有些扯开了，回到我们的话题。

日本的软件规范与CMM有惊人的相似，其中至少有35%以上都是几乎一模一样的。最近经济不景气，东京倒闭了160家软件公司，这个数字是今年6月份的，还在不断增加。这些公司纷纷抢滩上海，招收技术人员。如果去这样的公司应聘就要考虑清楚了，进去可以学到他们的规范和质量控制，可是要想从程序员成为系统分析员或PM，比登天还难。往往一个程序员进去干了好几年，对自己的那一块熟的不得了，而对隔壁同事所做的东西一窍不通。拒传华为正在尝试CMM4（华为印度研究所已经通过CMM4），对在华为工作的程序员们来说可谓福祸难料。当然，已经作到PM或QA或者热爱CODING的朋友例外。需求分析本身也存在着时间分配的问题。第一遍需求分析花的时间会最长，分析员们在客户的各个部门之间几乎把腿都跑断，把口水说干，就是为了确立一个初期的需求模型。所有的文档将会提交给PM进行复审并签字，不合格的打回重做。反馈表随之将提交给客户，第二遍第三遍等等等等接踵而来，与客户反复讨论和磋商，反复提交文档和表格，目的只有一个，明确需求。当PM最终合并了所有文档并确立需求之后，最终生成的需求文档将提交给客户的各部门负责人签字。这些文档将作为合同的附件添加，以便在将来项目变更或者碰到重大问题时和客户扯皮的重要依据。

需要说明的是，客户并非都是蛮不讲理，但是说实话，颇有无奈，国内目前的项目大多数客户为了不让自己的钱白花，经常变着法子提需求。在启动阶段明确需求并签字，无论最终情况如何，一份详尽的书面文档可以解决很多口头承诺或概念模糊的文档带来的许多问题。详尽的需求分析有一个额外的好处就是对一些双方都很陌生或者从来无人尝试的领域将是一个决定是否进行项目的判断标准。有时候，这种大项目在签单时双方都没有绝对把握保证可以出成果，一旦在需求分析阶段发现难以逾越的技术难关，就会放弃项目。典型的例子就是NMD洲际导弹防御系统。上世纪八十年代初美国搞星球大战计划，拖跨了苏联。大家对那段历史有些含糊，很多人认为苏联人上了美国的当。其实并不完全如此，苏联人的情报机构无孔不入，并非那么容易上当受骗。实际上当时美国国防部已经开始着手NMD系统软件的需求分析，前后耗资数亿美圆，耗时两年，仅仅是做需求分析，终于发现存在着在当时技术上无法达到的高度，随后项目被放弃。