业务项目管理的基本原理和方法 过程

项目管理的基本原理和方法：组织与领导项目管理的组织与领导合理的组织结构、适当的领导人选及正确的领导方法对于项目的正常完成是非常重要的。411项目管理的组织:项目管理的组织结构直接影响到管理的有效性,其中的关键点就是管理幅度和管理层次。41111项目管理的组织设计原则:(1)目标的一致性。为了总目标的完成,建立层层保证、左右协调的目标体系。(2)有效的管理幅度和层次。管理幅度与管理层次成反比,因此应尽可能地扩大管理幅度,减少不必要的层次,以免信息的迟滞和失真。(3)责任和权力要对等。责权要对等,有权无责,会助长瞎指挥乱拍板;有责无权会束缚管理人员的工作开展和积极性。(4)要合理分工和密切协作。这种分工协作既包括上下级的分工协作,也包括平级之间的分工协作。(5)集权与分权相结合。集权与分权应考虑到具体项目的情况,但不能走极端。(6)建立激励和约束机制。严明的奖惩制度也是非常重要的一个环节。41112项目管理的组织结构形式(1)传统行政的组织形式。直线制——厂长直接领导车间主任,车间主任直接领导班组长;职能制——厂长和其下的职能科室都对车间主任进行领导,其形式为多头领导;直线职能制——厂长直接领导车间主任,职能科室对车间主任只有建议权而没有命令权。这些组织形式均不适用于项目管理。(2)项目管理的组织形式。项目管理应采取矩阵组织形式进行管理。一个单位有许多部门,也可能同时进行多个项目。组建项目组时,配备人力资源时,可“选用”(而不一定是抽调)各部门的人员。这样,如果需要时,某一个人可能同时参与多个项目,这就是所谓的矩阵组织形式。这种组织形式的要点是:项目组既不是一个行政的组织,也不与任何行政组织并列,它是一个临时组织。412项目管理的领导在企业中,领导需要发挥决策、用人、指挥、协调和激励等5个方面的作用,但不同的领导层次,工作重点和要求也是不尽相同的。41211领导权力的类型领导者权力的大小并不完全取决于职位的高低。一般来说,领导权力有5种不同的类型。(1)强制权。强制权的认识基础是:不服从上司的意愿会招致处罚。(2)奖励权。奖励权的认识基础是:服从上司的意愿会带来奖励,这是强制权的对立面。(3)法定权。这种权力来自在组织机构中所处的位置。例如,公司总经理比副总经理有更多的法定权力。(4)专长权。来自知识的权力,其基础是具有某些专门知识或特殊技能。(5)影响权。由个人资历、榜样、感情所产生的力量,能使领导取得下属的认可。比如:有的领导品行优秀、德高望重而受到下属的钦佩。强制权、奖励权、法定权是由组织结构中的职位所决定的,都来源于行政的力量,而专长权和影响权则取决于个人的知识和品德。有效的领导不仅要依靠行政的权力,还必须具有专长权和影响权,这样才会使被领导者心悦诚服。41212领导方式的类型按照三分法理论,根据领导者控制或影响被领导者方式的不同,可以把领导方式划分为集权型、民主型、放任型。(1)集权型。集权型领导是指领导者个人决定一切,而要下属执行。他要求下属绝对服从,并认为决策是自己一个人的事情,下属不得染指。(2)民主型。民主型领导是指领导者发动下属讨论,共同商量、集思广益,然后决策。他要求上下融洽、合作一致地工作。(3)放任型。放任型领导是指领导者全面放开,下属愿意怎样做就怎样做,完全自由。他的职责仅仅是为下属提供信息并与企业外部环境进行联系,以利于下属的工作。具体的领导者可能是三种方式的有机组合,在推选配备项目管理领导时,应充分考虑到个人的特点和对工作可能产生的影响。按照管理方格理论,又可以领导者对工作的关心程度和对人的关心程度作出衡量。管理方格是一种等分的方格图,其中横轴从左到右表示领导者对生产的关心程度,纵轴从下到上表示领导者对人的关心程度。那么管理方格共有81格,其中根据在管理方格中的位置,有5种类型具有代表意义:111型(失败型)、119型(调和型)、911型(专权型)、515型(敷衍型)、919型(成功型)。项目管理的基本原理和方法：三坐标管理项目的三坐标管理项目实施过程中所涉及的进度、费用与质量是项目实施的三项关键内容,他们之间在项目实施过程中存在一个相互协调、相互制约、相互适应的问题。因此项目的进度管理、费用管理、质量管理及其相互间的有机关系就构成了项目的三坐标管理体系。

311项目的进度管理项目的进度管理是项目能否按期完成的基本保证。项目的进度管理可分为项目进度计划的编制和项目进度计划的控制两个环节,两个环节相互依存,不可偏废。

31111项目进度计划的编制项目进度计划的编制是项目成功的基础,应做到全面分析、抓住重点、科学协调。项目进度计划的编制具体可分为以下步骤。

(1)项目分解(工作定义)。项目分解就是把整个项目逐层分解为具体明确的工作单元的过程。常用的工具为WBS(工作结构分解原理)。项目分解主要包括的内容有:项目的工作分解结构的确定、工作范围的陈述、历史数据的考察、限制条件的分析、必要的假设和对策。项目分解的结果可形成“项目工作列表”。

(2)工作先后关系的确定(工作序列)。工作先后关系可分为几类,其中强制性逻辑关系较为明确,而无逻辑的组织关系的确定较为困难,另外还要考虑外部制约关系及必要的限制和假设。工作先后关系确定的工具和方法主要有:先后关系图法PDM(单代号网络图)、箭线图法ADM双代号网络图)、条件箭线图法CDM等。工作先后关系确定的最终目的是要得到描述项目各工作相互关系的“项目网络图”及工作的“详细关系列表”。

(3)工作延续时间的估计(工作时间)。若工作时间估计得太短,就会在工作中造成紧张被动的局面,从而影响项目的质量;相反若工作时间估计得太长,就会使整个项目工期延长,从而增加相应的费用。因此对工作时间尽量精确估计是非常重要的,然而在编制项目计划的过程中,工作延续时间的估计往往较为困难。为此在保证基础数据正确性的基础上,应采用专家判断、类比估计、模拟分析等专用方法进行仔细分析和判断。工作时间的估计可形成带有工作时间的“工作列表”。

(4)进度安排(工作计划)。项目分解、工作序列、工作时间等步骤和内容就是为进度安排服务的,所有的前期成果(项目分解、工作先后关系、工作延续时间、资源需求和条件、项目日历、限制条件和假设等)都必须在这里得到考虑。由于各种因素之间的关系较为复杂,因此就需要采用数学方法(如:关键线路法CPM、图形评审技术GERT、计划评审技术PERT等)和相关软件(如:MicrosoftProject98),并力求做到有限资源的合理分配和资源的均衡利用。进度安排以及整个项目计划的编制形成的成果有:项目进度(表示形式有:甘特图、里程碑事件图、时间坐标网络图等)、细节说明、进度管理计划、资源需求更新。

31112项目进度计划的控制项目进度计划的控制是项目成功的保证,应做到严格要求、层层落实、适时调整。由于项目计划是根据预测对未来做出的安排,因此在计划的执行过程中往往会出现或大或小的偏差,这就要求项目经理及其他管理人员消除与计划不符的偏差或对计划做出适当的调整,以保证预定目标的实现。项目进度计划的控制可分为两个方面的内容。

(1)作业控制。作业控制的内容是:采取一定的措施,保证每一项作业按计划完成或按调整后的计划完成。必要时应重新安排有缺陷的作业,以保证不影响整个项目的运作。(2)进度控制。进度控制是一种循环的例行活动。按照不同管理层次对进度控制的要求,进度控制可分为三类:项目总进度控制、项目主进度控制、项目详细进度控制。进度控制主要解决的问题是克服拖期。312项目的费用管理项目的费用管理是项目能否按照批准的预算完成的基本保证。项目的费用管理主要包括资源计划、费用估计、费用预算和费用控制等几个方面的内容。

31211资源计划资源计划主要解决动态的用于项目每一工作的资源种类(人、设备、材料)和配制数量等问题,因此资源计划是费用估计的基础。

(1)编制资源计划的数据基础。编制资源计划所依赖的数据有:工作分解结构(WBS)、项目工作进度计划、类似项目的历史信息、项目范围陈述、资源安排描述、资源组织策略等。

(2)编制资源计划的工具方法。编制资源计划的工具方法有:专家判断法、数学模型法、头脑风暴法等。(3)编制资源计划的主要结果。编制资源计划的结果主要是制定资源的需求计划和相关描述。

31212费用估计费用估计指的是预估完成项目各工作所需资源费用的近似值。

(1)费用估计的数据基础。费用估计的数据基础有:工作分解结构(WBS)、资源需求计划、资源单位价格、工作的延续时间、费用会计表格等。

(2)费用估计的工具方法。费用估计的工具方法有:类比分析法、参数模型法、从下往上估计法、从上往下估计法等。(3)费用估计的主要结果。费用估计的结果主要是实施项目所消耗的所有资源的费用和详细说明。

31213费用预算费用预算包括给每一独立工作分配的全部费用,以获得度量项目执行的费用基线。从分类上讲,费用预算包括三部分:直接人工费用预算、辅助服务费用预算、采购物品费用预算。

(1)费用预算的数据基础。费用预算的数据基础有:工作分解结构WBS)、费用估计结果、项目进度计划等。

(2)费用预算的工具方法。费用预算的工具方法与费用估计的工具方法基本相同。

(3)费用预算的主要结果。费用预算的主要结果是获得费用线,费用线将作为度量和监控项目实施过程中费用支出的依据。

31214费用控制费用控制就是要保证各项工作要在它们各自的预算范围内进行。(1)费用控制的数据基础。费用控制的数据基础有:费用预算结果、实施执行报告、增加或减少预算的请求。

(2)费用控制的工具方法。费用控制的工具方法有:费用控制改变系统、实施的度量、附加的计划、相关计算工具等。(3)费用控制的主要结果。费用控制包括的内容有:修订费用估计、费用预算更新、纠正偏差活动、案例学习课程、估计项目总费用。

313项目的质量管理项目的质量管理主要是为了确保项目按照设计者规定的要求完成项目,包括使整个项目的所有功能、活动能够按照原有的质量及目标要求得以实施。项目的质量管理主要由质量计划、质量保证、质量控制等几个环节构成。

31311质量计划质量计划主要是保证项目在项目进度、项目费用的范围内,按照项目质量标准顺利地实现。

(1)质量计划的数据基础。质量计划的数据基础有:质量方针、范围陈述、产品描述、规则标准、其他工作的影响等。(2)质量计划的工具方法。质量计划的工具方法有:利益和成本的分析、提供实施标准、制作流程图、进行试验设计。

(3)质量计划的主要结果。质量计划的主要结果有:质量管理计划、具体操作说明、质量检查表格等。

31312质量保证项目质量保证贯穿于项目实施的全过程之中,它是所有计划和具体实施达到质量计划要求的基础,并为项目质量系统的正常运转提供可靠的保证。

(1)质量保证的数据基础。质量保证的数据基础有:质量管理计划、具体操作说明等。

(2)质量保证的工具方法。质量保证的工具方法有:质量审核以及质量计划所采用的方法。

(3)质量保证的主要结果。质量保证的主要任务是保证质量和质量改进。

31313质量控制质量控制主要是监督项目的实施结果,将项目的结果与质量标准进行比较,找出差距并分析原因。质量控制同样贯穿于项目实施的全过程。

(1)质量控制的数据基础。质量控制的数据基础有:具体工作结果、质量管理计划、操作描述、质量检查表格等。

(2)质量控制的工具方法。质量控制的工具方法有:检查测试、控制图表、统计样本、趋势分析等。

(3)质量控制的主要结果。质量控制除其控制机能外还有:质量改进措施、检查通过、要求返工、完成检查表、过程调整等。另外在质量管理的全过程中还会涉及到一些质量技术文件:质量保证大纲、质量工作计划、技术文件、质量成本计划等。总之,项目的三坐标管理体系中的进度管理、费用管理、质量管理是相互联系相互影响的有机整体,在实际管理过程中不能把它们割裂开来。项目管理的基本原理和方法：基本概念项目管理的基本概念：目前国际上对于项目管理还没有一个统一的定义。主要因为:项目管理是一整套科学的管理体系和方法,很难用几句话对其进行全面而精确的概括,为此只能从不同的角度对其进行描述。描述1:项目管理是在项目运作过程中,综合应用各种知识、技能、手段和技术以完成项目预期的目标和满足项目有关方面的需求。描述2:项目管理是以项目为对象的一种科学的管理方式,它以系统论的思想为指导,以现代先进的管理理论和方法为基础,通过项目管理特色的组织形式,实现项目全过程的综合动态管理,以有效地完成项目目标。另外项目管理还有其它含义:项目管理既是一种科学的管理活动,也是一门新兴的管理学科。项目管理的基本原理和方法：工作内容项目管理的工作内容:项目管理认为,各种项目的生命周期均可分为C、D、E、F四个阶段。各个阶段具有各自的工作方法和工作内容。

(1)C阶段。即概念阶段,该阶段的主要内容有:①调查研究、收集数据;②明确需求、策划项目;③确立目标;④进行可行性研究;⑤明确合作关系;⑥确定风险等级;⑦拟订战略方案;⑧进行资源测算;⑨提出组建项目组方案;bk提出项目建议书;bl获准进入下一阶段。(2)D阶段。即开发阶段,该阶段的主要内容有:①确定项目组主要成员;②项目最终产品的范围界定;③项目实施方案研究;④项目质量标准的确定;⑤项目的资源和环境保证;⑥主计划的制定;⑦项目经费及现金流量的预算;⑧项目的工作结构分解(WBS——WorkBreakdownStructure);⑨项目政策与程序的制定;bk风险评估;bl确认项目的有效性;bm提出项目概要报告;bn获准进入下一阶段。

(3)E阶段。即实施阶段,该阶段的主要内容有:①建立项目组织;②建立与完善项目联络渠道;③实施项目激励机制;④建立项目工作包,细化各项技术需求;⑤建立项目信息控制系统;⑥执行WBS的各项工作;⑦获得订购物品及服务;⑧指导、监督、预测和控制:范围、质量、进度、费用;⑨解决实施中的问题;bk进入下一阶段。(4)F阶段。即结束阶段,该阶段的主要内容有:①最终产品的完成;②评估与验收;③清算最后帐物;④项目评估;⑤文档总结;⑥资源清理;⑦转换产品责任者;⑧解散项目组。(5)以上各阶段的管理内容很多,但其核心工作可归纳为:①项目的可行性研究;②工作结构分解(WBS);③项目的三坐标管理;④项目评估。项目管理的几大过程之一：商务谈判1.作人的姿态来源：作人似乎跟商务谈判不太有关系,很多技术人员相信PM需要的是本事,是如何做好一个项目,而不是会搞好关系弄的四平八稳的人.随着PM在中国的悄悄兴起,越来越多的PM开始在老总的授意下参与商务谈判,和销售们一起打单子,这就比较实在的需要PM们去揣摩客户的心理.揣摩客户心理需要有多方面的知识,需要深度和广度,然而,最重要的仍然是作人.如何放下架子,降低作人的姿态,对从技术人员转型的PM们来说,是至关重要的.降低作人的姿态需要从多个方面去实施,最主要应该记住:人不可貌相,更不可以地位衡量.很多公司为了保持公司形象,会统一叫员工打扮的好看一点,看起来象个白领的样子.然而,老板多半是没有约束的.中国改革开放才二十年,很多有钱的老板实业家文化层次都不高,往往是当大学生们只会把屁股坐在板凳上肆意挥霍父母辛苦积攒的财富时,他们已经在各地奔波,积累丰富的商业经验并对金钱,人生和社会的本质有了充分的认识,形成了自己稳定的思维框架.这些人,很多都是穿着旧旧的衣服,戴着破破的手表,说话的时候经常会带上三字经,钻进上海的人堆里,搞不好你会把他当成民工.因为到他们所处的社会地位,已经不需要任何华丽的外表来衬托自己的身份,他们有的是底气.对PM来说,这是个非常危险的挑战.虽然说项目在初期有意向时会对对方的人事和关键人物有一定的了解,然而大项目里能说的上话的人太多了.上海人最瞧不起的就是土气,很多人谈项目的时候看到民工或很俗气的表现不免会皱皱眉头,往往在皱眉头的时候就失去了项目,也就是失去了市场和金钱.PM必须作到能与每一个层次的人交谈,尤其是看起来比自己层次要低的群体,哪怕是公司里扫地的阿姨.只有作到谦虚谨慎,不摆架子,尊重别人,才会得到别人的尊重,才有机会赢得项目.鼻子比眼睛高的人只会把自己的鼻子撞扁.2.丰富的知识面来源：光尊重别人还不足以赢得项目,准确的说是赢得对方关键人物的信赖.PM一般用不着陪客户喝酒吃饭,那是销售们的事情,但是PM和客户讨论问题可能是最多的.讨论问题的时候就是机会,如何投其所好,是一大关键.金钱与美女依然是常规的敲门砖,然而这种傻瓜也知道的办法人人都会去做.老板的关系也只是一个方面,如今的大老板,哪个没有关系同等条件下PM凭什么去胜过别人一筹我一个朋友(PM)打一个单子时,发现对方对什么都不太感兴趣,费了很大力气也找不到突破口.对方这个人非常顺利,金钱地位美女样样不缺.他花了好多天和对方交谈,以自己的博学逐渐取得了对方的信任.后来他隐约发现对方对数学和天文学的发展史有所涉猎,如获至宝,回家花一个通宵的时间在网络上搜索相关资料.第二天他根本不谈项目的事情,只跟对方大谈特谈哥白尼,布鲁诺,伽利略这些人的生平,整整吹了一天.对方点头如捣蒜泥,态度和热情都来个一百八十度转弯,隔天他就拿到了单子.这是个经典的战例,谁能事先想到哥白尼会来帮助IT的人赚钱这个PM靠的就是博学和由博学引申出的敏锐的感觉抓住了机会,让客户产生共鸣.客户感觉他层次也很高,而且和自己有共通之处,信任度大大增强,把项目交给他放心.如今这种例子在商务谈判中已经屡见不鲜了.对PM来说,并不要求在各个方面都很精通,那是不可能的事情,只要PM对一些流行的话题和天文地理历史各方面的知识有个大概的了解,在需要的时候能尽快的掌握,才有机会创造机遇和把握机遇.3.强大的沟通能力胸中有万千墨水却不知如何表达其实是比较少见的,但并非绝对没有.每个人的人生轨迹都有所不同,思维受环境的影响也各有差异.包括象我们目前这个班级里的一些未来的MSE们,一定有比较内向或者不太爱表达自己观点的人,这些人比较被动,往往很难承担起谈判的重任.从今天开始,这类人就必须重新学习如何说话,如何大声的争论.沟通,并不仅仅是大声说话,而是在表达自己观点的同时发现问题并综合整理加以解决.除此之外,沟通的能力与社会经验息息相关,与PM的见识联系紧密.在日常生活中,PM就要多留心,多思考,当别人想到某个层次的时候要争取比别人考虑的更深.当然,也有一些不够踏实的朋友把沟通和吹牛当成了完全的一回事情,在和客户交流的时候口若悬河的说一些不着边际的话.这种人,碰到不懂,不太认真或者好奇心强的客户是有一定市场的;而有水平,负责任的客户往往会觉得这种人不可靠,一般不会把单子交给他.PM需要把握好这个度,吹是肯定要吹的,只是吹牛的时候一定要有基础的去吹,对从来没涉及过的领域或者根本不懂的东西轻易不要发表意见,挑选自己熟悉的方向合理的进行发挥,适当的留上一两手,给对方高深莫测的感觉,效果最好.4.优秀的售前团队这个团队一般是由总经理发起并组建的,通常不指定PMP,对团队的成员如SALES,PM,SA,ENGINEER们的团队合作提出了比较高的要求.一般公司在接下一个单子进行到一定程度的时候,PM往往会尴尬的发现协议上销售代表们对客户的一些承诺是几乎做不到或者根本做不到的事情.这种情况非常多,销售的任务是拿下单子,我听到的销售们说的最多的就是"没问题"或者"NOPROBLEM",但是当我听到客户的要求和销售的回答时我总是心惊肉跳,很不自然.销售是非常辛苦的,为了建立客户关系,尤其是空白的市场是很不容易的,往往为了一个单子会牺牲非常多.在这种情况下,和销售进行协调自然而然的又落到了PM的头上.在销售和客户做承诺之前,PM要主动的跟销售交流,提供粗略的总体设计框架和技术难关以及能考虑出的工作量,而不是等出了问题再被动和销售在老板面前互相推委责任.在组建团队的时候,PM要根据团队里每个人的素质和任务进行因人置宜的信息传递.优秀的售前团队合作是接单的重要保障.在商务谈判的实际操作中,存在着各式各样的问题,PM的职责和要求绝非以上几点所能描述详尽.根据环境,政策,人文,关系等各方面的不同情况,PM的不同成长经历,每个PM最终都会建立自己对商务谈判的看法和经验.但是有一点可以肯定,这是PM成为PM的第一道关,也是最重要的一关.接不到单子,PM将失去存在的意义.与销售有所不同,PM在该阶段的任务除了接单,还要尽可能的搜集客户关键人物的资料并与对方各个阶层的负责人建立良好的客户关系,以便在项目实施时充分调动资源.项目管理的几大过程之二：启动阶段1.项目的一些基本概念项目三要素有多种版本,各不相同.实际操作中多分为范围,成本与进度,其中最重要的莫过于范围.我们把项目最终生成并提交给用户的产品和文档统称为递交件.谈判的时候一定要确立递交件的标准和要求,也就是范围.尽管商战的时候不可避免的客户会不断提高标准和要求,而承诺的款项却不会有一分钱的增加.但是这个标准对每个公司来说都有一个底线,一旦超过了这个底线,那项目就肯定是亏的.除非是为了二期有利可图或者是为了搞好关系,否则范围超过底线的时候情愿不做,再厉害的PM在这种情况下也是无能为力.建立范围需要的就是PM的多年的实战经验,在大大小小的项目中用血泪换来的一些体会.在这个时候,很能体现PM与技术人员的区别.成本就是客户答应付的款项,与我们的投入成本并不是一回事情.进度就不用多描述了.项目如何成功也有一些关键的因素.个人的理解也不尽相同,通常包括以下几个方面:界定工作目标及工作任务;老板或高层的支持;优秀的PM和开发团队;充足的资源;良好的沟通;对客户的积极反应以及适当的监控和反馈.这里要注意的就是资源和高层的支持.一个上规模的公司总是同时会有很多项目,可是再大规模的公司资源也不足以保证每个项目都能组建最合适的开发队伍或拥有最好的环境.这时候各个团队或者部门之间不可避免的会发生资源争夺战,摩擦再所难免.这时候对PM的作人再次提出挑战.除了高层对PM项目的重视程度,如果PM平时在公司与同事相处的好往往能使很多别人看起来很棘手的问题迎刃而解.相反,一个不会作人的PM由于人缘差,即使高层强压别的部门或团队配合,别人也会能拖就拖,延缓项目的进度和质量.有时候,这种内耗对项目和PM来说是毁灭性的.对客户的积极反应也比较关键.一般来说PM已经被项目里大大小小的事情搞的筋疲力尽,要PM去主动要求客户配合是很吃力的事情.然而,这个时候,越是困难,越是觉得累,越是要去主动.客户往往也不是特别的积极,主动与客户联系沟通和测试能及早发现问题.从风险控制的角度来说,问题发现的越早,风险越小,损失也就越小.积极的态度可以带动客户的积极性,在项目完工的时候,客户对你的感激往往是难以用语言描述的,这对以后接单或者做二期三期会打下良好的基础.因为在和别的新客户谈判的时候,新客户自然会找你的老客户了解情况,这时老客户随意的一句话顶的上你很费心的十句.项目具有商业行为的几个重要特征,有消费源,有参与者,有成功关键因素,有财务目标,有风险.2.启动阶段的主要任务根据PMI的解释,接单之后项目自然转入启动阶段.启动阶段PM的主要任务是率领总体架构设计师和系统分析员收集尽可能详细的数据,确立尽可能详细的需求,进一步确立详细的项目范围,预估资源,确立其他方案并获得进入下一阶段的批准.在这个阶段,随着需求分析的深入,PM也开始在公司内部进行人员挑选和资源争夺,着手组建自己的项目团队.项目即将进入计划阶段.在收集完数据之后,PM要和客户开始明确项目的大小,成本,规格,期限等重要特征并将其写入合同文本,同时准备内部的包括预算,衡量标准等文档,建立项目的评估标准.接下来就是需求分析.由于专业的原因,我们这里仅讨论软件工程项目的需求分析(以下简称需求分析).需求分析的主要参与人员有PM,总体架构设计师,系统分析员,熟悉业务流程的客户.PM统领的团队这时候还不是真正的开发团队,我们叫做前期团队.随着需求分析的逐步深入,新的团队成员不断加入,启动阶段结束的时候正式的团队将建立.对一个已经启动的项目来说,需求分析直接决定了项目的成功与失败.最初的需求体现在客户的工作说明书或招标文件及附件上.这种需求一般比较含糊,无法体现客户真正的需求.前期团队要根据自己的经验和客户沟通并引导客户进入正轨.有时候客户会很不讲道理或者思路僵化,就要求按照他的思维去定一些明显错误的需求.这个时候团队成员要耐心和客户举事实,谈经验,讲道理,用图形或模型等直观的方式将需求描述出来,比如常见的数据流图等.所以说,争论再所难免,客户有时候会吹胡子瞪眼睛拍桌子甚至会说"这个东西不要你们做了"之类的话.PM此时除了要亲身参与需求分析综合整理文档之外,还要处理好团队成员与客户的关系,确保关系不会恶化到无法收拾的地步.只要PM尽力约束团队中的成员,这个度还是很容易控制的.项目管理的几大过程之三：计划阶段1.定义结构分工结构图(WBS)启动阶段结束后,项目进入计划阶段,也就正式进入实施.这里概念可能有些不太对头,其实是翻译的缘故,反正大家明白意思就行,不用拘泥于字面.WBS是一组要提交的项目元素,用来组织定义项目的总体范围,具体包括从工作内容,资源,成本角度考虑项目范围;建立一套系统所需要的分层工作结构;把项目分解成易于管理的几个细目,这概念有些模糊,其实跟资源管理器里分目录是一回事情.可以说,WBS是计划阶段的核心.WBS会详细的分到递交件,包括给自己人用的项目使用的过程文件,给客户用的模块和说明文档,完成每个细目的标准以及如何把这些细目的责任分配到具体的个人.WBS有缩进式和树状式,我这里也没办法画图,大家参考一些项目管理的书籍,里面有详细介绍.我整个文章只挑我觉得需要注意的地方,如非必要,对技术细节或者工具使用不做详细介绍.WBS的细目并不需要分解到同一水平,最下面的细目叫做工作包,分包的依据是个人的责任和可信度,也就是说到每个人头上的任务是否能落实,是否有把握完成;还有就是准备对项目进行控制的程度,程度越深,WBS树也就越深.由于WBS是实用性的东西,根据个人理解也不一样,所以一个项目可能会有几个正确的WBS,看PM的需要和最适合当前团队状态的进行选择.WBS的定义还是很麻烦的PM要召开团队进行讨论,向成员提供与项目相关的所有详细资料,并把WBS树分解到二层三层.然后要花上一段时间让成员进行头脑风暴式(BRAININGSTORM)思考,制订工作产出和相应人员的职责,记录每一个工作包的完成标准.在头脑风暴式思考时,会有很激烈的争论,PM要协调关系,调节气氛,从自己能考虑到的各个角度旁推侧敲,提示成员的思维角度和方向并加以总结.尽管很麻烦,制订WBS仍然是非常值得的.如同需求分析一样,WBS准备的越充分,编码的进度越快.2.风险管理既然是商业行为,那么项目的风险必然存在,相信阅读这个帖子的朋友不少人都经历过或大或小的风险.有些风险很容易解决,有些风险则大大损害利益.不论什么样的风险,能避免尽量避免,所以有必要对风险进行管理.由于风险的不可预知性,风险管理难度很大,概念也很难讲清楚,只能从一些可行的角度去分析,进行管理.首先要识别风险.这是个难度很高的活.PM要先召开风险识别会议,这个会议面向公司,高层,跨部门的有经验的人都将参加.然后审核由项目小组生成的风险清单并与重要成员进行风险沟通,检查一些重要的风险源如WBS,成本(时间)预估,人员计划,采购管理等等.最后就要用到PM本身在以前类似项目中得到的经验教训.识别之后要进行分析.我们可以进行粗略的量化分析(精确分析是不可能的事情).有经验的人可以一起参加讨论,把提交出来的风险进行分类.首先按发生的可能性分,一般分成高,中,低三个级别,虽然很勉强,但是好歹也有个量化了;然后按耗去的成本分,也是高,中,低三级.我们可以把这两种类别的三个级别进行组合,碰到可能性也高,成本也高的风险就定位为不能接受.碰到这种风险只好让客户修改需求或者增加风险预留成本,否则一旦亏起来不是亏一点点,有可能赔的很厉害.高和中,中和中的搭配都是属于高风险,中和低,低和低搭配属于低,高和低搭配属于中.针对出现的可能性,需要采取一些手段降低风险.到目前为止也没有一个定论说有绝对好的方式,只能尽其所能的避免.有几种方法可以考虑,第一种是将风险纳入项目管理计划并指定负责人,由外部人员定期检查项目风险,一旦风险发生,执行风险管理计划;第二种是保险,这种属于风险转嫁;第三种方式有点奸,不过最保险,就是把客户拖下水,让他们一起参与风险管理,呵呵,到时候就好说话了:)风险管理作为项目计划之后,PM需要更新WBS,修改日程计划和更新风险管理计划.风险预留通常是成本的8%.项目管理的几大过程之四：控制和执行阶段1.软件开发实在没什么好说的,也是大家最不愿意谈的,平时在公司里谈的已经够多的了,还要在这里受我唠叨.需要提醒的依然是团队合作精神和完善的文档管理制度.SOURCESAFE这些工具有时候还是有必要使用的.经常看到有人说天才程序员不写注释什么的.我相信有这种天才程序员,因为我碰到过几个.我爱人公司里也有一个,他们的一套产品核心代码就是这个人写的,4年过去了,周边代码换了好几茬,核心算法始终没换过,可惜这小子跟了李洪痔,如今已经不知所踪了.但是他的代码似乎也要有点注释的,没有注释过段时间再天才的程序员也不能保证他是最有记忆力的.而且,对一个项目的编码来说,靠一两个人打天下如今是不可能了.别人的公司都是团队,两人智慧胜一人,这头还在靠一个天才支撑门面,实际上市场可就别人抢了去,那时候再天才也没用了.编码的时候讲究技术公开,程序员不要藏着掖着,对大家没好处,PM要想办法调动大家创新思维的积极性,营造良好的技术讨论氛围,碰到技术难关的时候就容易攻破了.有个问题需要单独对还没有PM觉悟的程序员说,其实是在调研的时候就定了的,就是使用什么样的开发工具.没有经验的程序员往往会拿着C++或者JAVA的资格证书或者拥有一两个开发工具的一些经验而得意洋洋.其实老板和PM根本不看重这个,他们关心的是使用什么样的工具能尽快的达到目的.管你什么C++,DELPHI,PB还是JAVA,只要能做的出来,VFP都可以用.我举这个例子并非说不看中工具,而是提醒想转型为PM的程序员,第一要把工具当作工具,而不要被工具套进去,钻研一些一辈子都用不上的技术;第二要掌握的并非是单独的一个工具,而是流行的程序设计的思想,以及在最短时间内掌握一门陌生工具的能力.只有建立了这样的思维,才有可能转为PM,否则一辈子都是技术工人,最多就是个技术总监.2.变更对任何项目,变更无可避免,无从逃避,只能去积极应对,这个应对应该是从需求分析就开始了.对一个需求分析做的很好的项目来说,基准文件定义的范围越详细清晰,用户跟PM扯皮的幌子就越少.而需求没做好,基准文件里的范围含糊不清,被客户抓住空子搞你一下是非常头疼的事情,往往要付出无谓的牺牲,有时候甚至非常火大.需求做的好,文档清晰又有客户签字,那么后期客户提出的变更就超出了合同的范围,需要另外收费.这个时候千万不能手软,并非要刻意赚取客户的钱财,而是不能养成客户经常变更的习惯,否则后患无穷,维护的成本会让PM吃不消.在客户提出变更请求时,要建立变更申请登记表和变更申请表,并让客户签字.当然,有时候一些不是非常关键的模块PM也不至于一点不讲情面,该卖面子的时候还是要卖,尤其是当着对方领导的面,千万要卖面子,但是也别卖的太干脆,不要让他们得到的太容易.需求做的不好,客户抓住漏洞或者非常不讲道理,麻烦就大了.有时候争论会很厉害,到非常白热化的地步,PM与客户代表几乎沟通不了.PM在客户关系和短期利益两方面难以取舍,一般都是向客户妥协,最终形成恶性循环.这种情况非常难办.一般这种情况都是到了项目后期,做重大的更改几乎是不可能的事情,如果白做就要亏钱.而这个时候如果PM跟对方高层的人关系搞的定,可以透过对方高层把事情压住.然而由于已经到后期,客户代表不会轻易更换,对方这次没有改成,必然心怀不满,下回在别的模块依然会找麻烦或者在谈二期的时候动动手脚,都是很让PM伤脑筋的事情,这方面目前还没有什么好的解决方法,所以尽可能的做好需求比什么都重要.相对需求来说,什么WBS,风险管理,计划进度都是扯淡,需求做好了,一帆风顺.还有一种办法就是装可怜,要装的非常的象,在对方的领导面前装,而且不能让人看出是装的样子,要让你自己都觉得你自己是真的可怜,那么就算这次客户硬是要求改了,下回他也必然不好意思再叫你改.其实人心都是肉长的,如果可能的话,我还是不赞同使用一些手段的,