项目管理-项目管理的几大过程(编辑修改稿)

项目管理-项目管理的几大过程(编辑修改稿)内容摘要：

前者还在各个公司里频繁跳槽，跳来跳去都不满意。 有些扯开了，回到我们的话题。 日本的软件规范与 CMM有惊人的相似，其中至少有 35%以上 都是几乎一模一样的。 最近经济不景气，东京倒闭了 160 家软件公司，这个数字是今年 6 月份的，还在不断增加。 这些公司纷纷抢滩上海，招收技术人员。 如果去这样的公司应聘就要 考虑清楚了，进去可以学到他们的规范和质量控制，可是要想从程序员成为系统分析员或 PM，比登天还难。 往往一个程序员进去干了好几年，对自己的那一块熟的不得了，而对隔壁同事所做的东西一窍不通。 拒传华为正在尝试 CMM4（华为印度研究所已经通过 CMM4），对在华为工作的程序员们来说可谓福祸难料。 当然，已经作到 PM 或 QA 或者热爱 CODING 的朋友例外。 需求分析 本身也存在着时间分配的问题。 第一遍需求分析花的时间会最长，分析员们在客户的各个部门之间几乎把腿都跑断，把口水说干，就是为了确立一个初期的需求模型。 所有的文档将会提交给 PM 进行复审并签字，不合格的打回重做。 反馈表随之将提交给客户，第二遍第三遍等等等等接踵而来，与客户反复讨论和磋商，反复提交文档和表格，目的只有一个，明确需求。 当 PM 最终合并了所有文档并确立需求之后，最终生成的需求文档将提交给客户的各部门负责人签字。 这些文档将作为合同的附件添加，以便在将来项目变更或者碰到重大问题时和客户扯皮的重要依据。 需要说明 的是，客户并非都是蛮不讲理，但是说实话，颇有无奈，国内目前的项目大多数客户为了不让自己的钱白花，经常变着法子提需求。 在启动阶段明确需求并签字，无论最终情况如何，一份详尽的书面文档可以解决很多口头承诺或概念模糊的文档带来的许多问题。 详尽的需求分析有一个额外的好处就是对一些双方都很陌生或者从来无人尝试的领域将是一个决定是否进行项目的判断标准。 有时候，这种大项目在签单时双方都没有绝对把握保证可以出成果，一旦在需求分析阶段发现难以逾越的技术难关，就会放弃项目。 典型的例子就是 NMD 洲际导弹防御系统。 上世纪八十年代初 美国搞星球大战计划，拖跨了苏联。 大家对那段历史有些含糊，很多人认为苏联人上了美国的当。 其实并不完全如此，苏联人的情报机构无孔不入，并非那么容易上当受骗。 实际上当时美国国防部已经开始着手 NMD 系统软件的需求分析，前后耗资数亿美圆，耗时两年，仅仅是做需求分析，终于发现存在着在当时技术上无法达到的高度，随后项目被放弃。 项目启动要确定项目计划，与客户一起实施第一次项目审核，确认并对一些产品和服务向下包厂商下订单。 这个时候的 PM 会忽然发现有开不完的会，一天开三到四个会议是很正常的事情。 这些会议有与客户 的会议，与下包厂商的，有团队的，有公司高层的。 团队的会议主要是建立正式的团队，提供团队成员的角色和职责，提供绩效管理方法，向成员提供项目范围和目标。 与客户的一个主要会议将是项目启动会议。 在这个会议上 PM 会与客户确立正式的交流渠道，项目综合描述，让项目参与人员相互了解，建立以 PM 为核心的管理制度。 还有一些零零碎碎的东西甚至包括办公场地的大小，电话多少部，所有人的联系方式等等都要在会议上确立，并做会议记录。 这都是些非常琐碎的事情，听起来婆婆 ***，却是非常必要，缺一不可。 大概就是所谓三军未动，粮草先行吧。 这 时候，作为公司高层，应该向全公司发表申明，正式给 PM 发布项目经理任命书和项目授权书。 这个动作虽然在别人看来有些形式主义，但是对提高 PM 本人的士气和责任感是有很大助力的。 三 .计划阶段 （ WBS） 启动阶段结束后，项目进入计划阶段，也就正式进入实施。 这里概念可能有些不太对头，其实是翻译的缘故，反正大家明白意思就行，不用拘泥于字面。 WBS 是一组要提交的项目元素，用来组织定义项目的总体范围，具体包括从工作内容，资源，成本角度考虑项目范围；建立一套系统所需要的分层工作结构；把项目分解成易于 管理的几个细目，这概念有些模糊，其实跟资源管理器里分目录是一回事情。 可以说， WBS 是计划阶段的核心。 WBS 会详细的分到递交件，包括给自己人用的项目使用的过程文件，给客户用的模块和说明文档，完成每个细目的标准以及如何把这些细目的责任分配到具体的个人。 WBS 有缩进式和树状式，我这里也没办法画图，大家参考一些项目管理的书籍，里面有详细介绍。 我整个文章只挑我觉得需要注意的地方，如非必要，对技术细节或者工具使用不做详细介绍。 WBS 的细目并不需要分解到同一水平，最下面的细目叫做工作包，分包的依据是个人的责任和可信度，也 就是说到每个人头上的任务是否能落实，是否有把握完成；还有就是准备对项目进行控制的程度，程度越深， WBS 树也就越深。 由于 WBS 是实用性的东西，根据个人理解也不一样，所以一个项目可能会有几个正确的 WBS，看 PM 的需要和最适合当前团队状态的进行选择。 WBS 的定义还是很麻烦的。 PM 要召开团队进行讨论，向成员提供与项目相关的所有详细资料，并把 WBS 树分解到二层三层。 然后要花上一段时间让成员进行头脑风暴式（ BRAINING STORM）思考，制订工作产出和相应人员的职责，记录每一个工作包的完成标准。 在头脑风暴式思 考时，会有很激烈的争论， PM 要协调关系，调节气氛，从自己能考虑到的各个角度旁推侧敲，提示成员的思维角度和方向并加以总结。 尽管很麻烦，制订 WBS 仍然是非常值得的。 如同需求分析一样， WBS 准备的越充分，编码的进度越快。 既然是商业行为，那么项目的风险必然存在，相信阅读这个帖子的朋友不少人都经历过或大或小的风险。 有些风险很容易解决，有些风险则大大损害利益。 不论什么样的风险，能避免尽量避免，所以有必要对风险进行管理。 由于风险的不可预知性，风险管理难度很大，概念也很难讲清楚，只能从一些可行的角度去分析，进行管理。 首先要识别风险。 这是个难度很高的活。 PM 要先召开风险识别会议，这个会议面向公司，高层，跨部门的有经验的人都将参加。 然后审核由项目小组生成的风险清单并与重要成员进行风险沟通，检查一些重要的风险源如 WBS，成本（时间）预估，人员计划，采购管理等等。 最后就要用到 PM 本身在以前类似项目中得到的经验教训。 识别之后要进行分析。 我们可以进行粗略的量化分析（精确分析是不可能的事情）。 有经验的人可以一起参加讨论，把提交出来的风险进行分类。 首先按发生的可能性分，一般分成高，中，低三个级别，虽然很勉强，但是好歹也有 个量化。