1、IT 项目管理五大过程组 PMBOK 将项目管理分为了启动，计划，执行，监控和收尾五个过程组。 一，启动过程组 启动过程组的核心要素是可行性分析，立项，初步范围说明，确定项目的目标和范围，委任项目经理等。很多项目都是在项目启动的时候就注定了是否是一个死亡之旅，因此项目经理应该有在项目启动前启动的意识。只有这样才能够胸有成竹。 项目经理 -在项目启动前启动 未之于未有，始之于未然。风险管理贯穿项目始终这句话应该进一步扩展，聪明的项目经理应该在项目还没有启动前就能够未雨绸缪。项目启动后的每一天往往都异常宝贵，有可能你并不清楚项目是否最终能签单，但只要有 7,8 成的把握，我们就应该提前行动，去分析
2、可能的风险，去降低和消灭不确定性。 项目成功是客户满意-去分析你即将的客户，他们有哪些特点，他们注重产品的哪些特点，以前公司是否和该客户有过合作？在合作的过程中是否出现过相关的问题？客户接口人的性格特征以及是否好打交道。如果客户对产品的易用性很在意，则项目应该提前考虑界面和易用性相关规范制定。如果客户对性能很重视，则应该提交考虑架构设计和以往架构的优化。如果与客户以前合作中经常出现范围的变更和蔓延，则要注意后续加强需求管理和需求开发工作。 分析你是否有可能成为该项目的项目经理，分析高层领导对项目的重视程度，分析如果你能够成为项目经理是否可以获取到高层领导的支持和足够的资源。 真正到了项目经理任
3、命的时候你往往并没有足够的时间来思考这些问题，那你那个时候的接收往往就是被动和突然的。你可能连胜算几何都不清楚就接受了项目。 分析你团队的现状，分析如果项目能够启动团队人力资源是否满足，是否关键岗位或角色还缺少资源？如果存在这种情况，要及时物色和考虑企业内或企业外可用的资源，团队组建需要时间，新人融入团队更需要时间。如果不提前考虑这些问题，及时项目启动后给你资源名额你往往也可能不能及时的获取到你需要的资源。在企业内获取其它项目资源更是一种复杂的交际行为，更需要项目经理充分发挥自己的人际交往能力，提前为项目启动后真正资源的获取进行铺垫。 关注下客户在招标相关采购文件中对产品的要求，企业原有的产品
4、功能特性是否都可以满足，有没有客户特别强调了但我们没有具备的核心功能？对于这些功能是否存在技术难点？如果有， 则这些技术问题应该提前预研，项目中最难估算的任务工作量就是这种事先没有经验积累的新技术任务，而这类任务往往又处于进度计划中的关键路径，直接影响到项目周期的不确定性。 如果项目经理在真正项目启动前都能够很好的分析和思考这些问题， 那被委任为项目经理的时候才可能显得胸有成竹。没有不确定性因素的项目就不应该失败，项目经理的所有工作始终都在围绕着消除项目的风险以达成项目的最终目标。成功只偏爱有准备的人，我们可以临危受命，但决不应该仓促上阵。 IT 项目管理 -项目启动三要素 是否是项目立项审批
5、通过就代表项目启动？真正的项目启动应该包含三个方面的重要内容， 一是项目或产品初步范围已经确定，二是项目的目标已经确定，三是已经选择了委任了项目经理。如果安装PMBOK 的说法，这几个方面的内容都应该在项目章程中得到体现。项目章程也可以简化到项目启动会议既要，但关键点都在于项目经理确定，并给予了法定的正式权力。 1.项目经理的选择和委任 在高层领导支持，项目目标也明确的情况下如果项目还失败，项目经理应该负完全的责任。项目经理也可以选择是否接受项目，但一旦接受了就应该对项目的成败负责。 选择项目经理无定法，仍然关注平衡。如果是已有项目团队，团队成员技能都很强，那项目经理重点是团队建设和资源整合。
6、如果团队技能弱，但责任心和态度积极，那项目经理必须是技能强，必须是一个能够传授知识的好教练。关于项目经理知识和技能层次，原来有文章阐述过，在这里不再多谈。两个关键点就是项目成员愿意和你一起把事情做成功， 另外一个是你能够使项目成员有能力把事情做成功。 高层管理或者说 PMO 如果愿意在项目经理选择上多花些时间，完全是对产品和项目负责任的态度。基于强矩阵或项目型的组织中，高层管理要能够轻松，就是其下一层的项目经理能够真正管理其整个项目团队，项目中 99%的问题都能够由项目经理解决。在这种金字塔型的权力型结构中，取决定性因素的不是塔尖，也不是塔底，而是中层。而项目经理正是这种结构中的中坚力量。 2
7、.项目目标 不要简单的把项目目标理解为进度目标，项目目标必须要包含进度，成本和质量三方面的目标。否则我们虽然按时完工的做出来的产品可能无法卖出去， 或者预审超支。 在这种情况下项目仍然是失败的。 项目目标是如何确定的？是根据项目可研和项目立项后确定的。 确定项目目标是为了保证我们最终产出的项目成果能够赢利，能够为企业或客户带来实际的价值。很多时候项目经理不会考虑为何要制定这样的目标，只知道是高层制定的，项目按照目标做就可以了。如果你不知道为何做的话，是无法把问题做好的，项目经理有必要去深究项目目标的来源。 项目目标最主要的来源仍然是商业目标驱动的，做项目目的仍然是为了为企业创造效益，为了赚钱。
8、真正理解了商业目标，你才可能在进度，质量，成本，范围发生冲突的时候如何去平衡。大家都知道削减不同的边可以达到平衡，但关键点却在抉择究竟该削减哪条边。 3.项目范围 启动阶段的项目范围是一个初步的范围。但启动阶段对于整个产品的范围必须要清晰，产品范围是产品应该具备的功能特性。而项目范围是项目管理和执行过程的所做的所有事情，比如风险应对，项目内学习培训属于项目范围，但不属于产品范围。 我们谈有了初步范围后可以启动项目， 绝对不是指产品范围。 启动项目的时候， 产品范围必须要清楚，产品范围不清楚将导致成本， 进度等无法受控， 产品范围不清楚就启动项目往往是项目做完了还赔钱。项目范围可以初步是说明 W
9、BS 分解可以是一个粗粒度的，细粒度的任务级可以在项目计划阶段在做。 客户关注的是最终提供的产品的功能特性，而不是你内部项目如何去运作以研制出产品。这点我们可以从 SOW 工作说明书中看到，甲方招标的采购文件包或 SOW 都是有详尽的产品范围描述的，因为这也是项目重要的验收标准。 IT 项目管理 -启动 -项目立项 最近在看漫索公司林锐博士的相关培训ppt,从最早推出的CMMI三级精简并行过程SPP,到现在的RDMS 产品，还是很多值得借鉴的地方。今天先看下项目立项管理: 1.立项管理的重要性 立项管理应该说是新产品研发管理的或者说 IPD 的一个重要内容。人在江湖，最怕的就是跟错人，站错队；
10、而对于企业最怕的就是战略性决策和方向选择的失误。项目管理中的项目计划是保证实现项目的目标，而立项管理正是去确定项目的目标，现在竞争如此积累，立项决策是否正确直接导致整个企业的成败。 项目计划是保证如何做成功的问题，而立项是要解决做什么的问题。你需要开发的产品，不管什么客户需求出发 VOC 还是产品核心竞争力，唯一关注点就是效益和利润。这个问题展开就是前期需要投入多少？能否盈利？什么时候能够盈利？能否持久的盈利？整个立项报告的内容都将围绕这些核心内容展开。 2.构思-调查-可行性研究 这里把构思放在第一位太重要了，在像外行一样思考，像专家一样实践这本书已经提到过，我们是无法去穷举我们想做的事情和
11、所有做事情的方法的， 唯一可以采用的就是先根据自己的经验构思或假设，再去证明构思的正确性。 构思的目的就是提出假设，能够提出好的构思的往往是有丰富经验的人，他们有很好的前瞻性和敏锐的市场洞察力。有了构思需要去证明构思可行，而最有力的证据就是数据，拿数据来说话。因此在可研里面必须要先看到这样的步骤: 现状分析-数据收集方案-数据收集-数据分析和预测-财务成本效益分析 步骤都知道是这样， 真正的难点却在于你要开发的新产品根本无法收集到足够多的数据资料来做可行性研究。这个时候风险分析，产品核心竞争力分析，SWOT 分析转移到了重要的地位。风险遇到，可能后期所能够取得的市场和利润也越大，像史玉柱几亿资
12、金豪赌网游取得的成功不是一般人可以玩的。 3.可行性研究报告和立项建议书的重点 前面已经谈到过，最重要的就是要说明前期投入多大，能否盈利，能否持续盈利的问题。但要回答这些问题自然又会从市场现状分析入手: 市场现状-产品定位-产品功能-核心竞争力 通过产品定位和功能特性分析才可能估计前期的投入， 有了对市场和潜在客户的分析才可能预期产品后期的销售确实以确定盈利情况。有了核心竞争力的认识才可能清楚面临的竞争风险，产品是否会被对手快速模范而导致无法持久盈利。 这条脉络清楚后，再看如果你能够你能保证产品能够开发成功，在特定的成本和进度目标里面研发成功，具体分析为: 你已经有的经验资本积累-产品技术方案
13、-项目核心团队 4.危机和风险意识 低头思考的时候我是一个悲观主义者，抬头向前的时候我是一个乐观主义者。立项的时候一定要对风险有充足的认识，真正立项完了则需要积极和乐观应当。对于风险主要来源于技术方面，市场方面，政策环境方面，人员，竞争对手方面等等，这些都必须有详细的分析和应对。 SWOT 分析是立项中最常用，非常有效的可行性分析。在这里我们更加强调去分析自己的弱势和潜在的风险。前期风险考虑的越多，后期就对自己越有利和主动。 5.立项评审和项目筹备 前面已经谈到了立项的关键问题，立项评审也应该从项目关键问题展开。产品的定位，盈利预期，核心竞争力，风险，财务指标等都是重要的评审内容。评审通过后进
14、入项目筹备阶段，立项评审完毕后就应该确定出项目章程所需要的项目目标，制定完项目章程后才谈得上开始项目计划。 IT 项目管理 -启动 -团队组建 IT 项目管理 -启动 -研发规程制定 规程在项目启动时候就开始制定最好。而且应该根据历史已有经验和企业实际情况进行制定。过程必须要有效，任何一份文档都要起到该起的作用。 1.可行性报告内容可以省略，将可行性分析内容全部写入立项报告。 2.调研报告很重要，与客户的每一次调研和访谈都应该及时输出。 3.同样开发通用型软件，必须输出产品需求，作为产品架构设计重要输入。 4.用户需求最好条目化，用户需求要从用户角度来描述，重点在业务规则。 5.项目计划不仅仅
15、是进度计划。 1.没有列出详细设计文档原因仍然在于体现源代码即设计的思路。 2.总体设计包括了对功能性需求和非功能性需求的考虑。在总体设计阶段要制定详细的界面规范，设计规范和编码规范，项目约定。 3.测试重点在测试数据准备和测试分析，针对 V 模型要单独出功能性测试和集成系统测试的不同。 IT 项目管理 -启动 -干系人分析 项目经理接受委任后，个人认为最重要的一件事情就是进行干系人分析。或者讲在启动前或被委任前就应该进行干系人分析，很简单的道理，比如高层管理都对项目不支持，项目经理再有能力也无法使项目实现目标。 干系人是对你项目的目标达成有影响的所有人，如果要关注项目开发出的产品所带来的长期
16、效益，则干系人应该是对项目所开发的产品的整个生命周期都有影响的所有人员。干系人的识别，干系人分析都不是干系人管理的最终目标，最终目的都将落到项目经理如何利用分析的结果，通过自身所拥有的资源，技能，沟通等去影响干系人的行为，以达成项目的目标。 1.项目的出资方和赞助人 对于赞助人始终关注的如何使自己的投资有最丰厚和深远的回报，同时又将风险控制到最低。跟个人投资是一个道理，投多少钱不是问题，关键是如何保证投入有低风险，稳定和客观的回报。因此赞助人不仅仅关注项目本身是否成功按目标完成，而是关心产品能否成功按计划推入市场和创造效益。 对于项目周期较长的时候， 为了项目本身降低风险和满足干系人预期， 项
17、目迭代开发就显得更加重要。迭代开发可以保证将项目分为多个迭代周期，每个迭代版本都是可用的而不是一个半成品，项目最终交付成果会分为多个迭代版本交付，赞助人可以尽可能早的看到项目所创造的产品或成果。同时采用迭代开发每个迭代版本都可以尽可能早的投入市场和进行市场推广，资金不用一次性的全部投入，可以通过市场的反馈不断的纠正方向和需求。 2.项目高层领导 高层领导一般是期望项目取得成功的，但高层领导关注的是 PPM(项目组合管理 )，因此项目经理一定要清楚在多项目，自己的项目在高层领导眼中的优先级和地位。明白了这点才能够分析在多项目资源冲突的情况下，自己的项目如何去通过高层领导协调更多的资源。项目经理需
18、要让高层领导更加了解自己的项目，需要及时准备的定期反馈和汇报项目进展，当出现资源问题时候需要有说服力的证据和数据，通过需要提前提出问题给高层领导进行协调预留时间。 项目没有出现问题，往往高层领导认为项目运转良好而不受重视，项目经理简单认为暴露了问题可能会使高层领导怀疑自己的管理水平，而实际隐藏问题本身，这往往导致项目最终无法实现目标交付。因此勇于暴露项目自身问题，积极汇报高层领导，请求协调和资源是项目执行中项目经理沟通的一个重要方面。 3.项目产出物的最终用户 用户是重要的干系人，直接关系到项目成果能否创造最大效益。在项目启动和确定范围前期，充分的用户需求调研是必不可少的，另外在项目执行过程中
19、可以分多个迭代周期，每一个迭代周期都可以让用户参与进来反馈意见，及时纠正各种偏差，避免前期的缺陷泄漏导致后期过大的纠正成本。项目目标是否能够实现是项目经理必须重点关注的，但项目说输出的成果能否赚钱则显得更加的重要，要使产品能创造价值则必须多考虑用户的需求和反馈意见。如果在项目执行过程中，发现了一个重要的用户反馈需要变更项目范围，在这种情况下项目经理要勇于提出并找高层领导和赞助人协调资源，而不是置之不理的仅仅为了完成项目启动制定的目标。 4.项目组成员 项目目标制定合理，高层领导也能够保证项目资源，这个时候项目成功取决于项目经理，但项目经理必须清楚项目成功依靠的是整个项目团队的共同努力。 对每个
20、项目成员的性格特点和技能特长进行分析是很重要的， 但之前需要先搞清楚项目能够带给项目成员什么以及项目成员能够从项目中获取哪些收益？知脉，财脉和人脉仍然是三个重要的方面，需要根据各个项目成员不同的需求在这三个方面进行平衡。明白了这些才可能在后期的人力资源管理和角色岗位分工中给出较合理的安排。如果项目经理不管钱， 项目成员绩效考核也不在项目经理， 在这种情况下项目经理是很难对整个项目进行管理的，及时项目经理有很强的个人领导力和权威。 二， 计划过程组 凡事预则立，不预则废。项目计划是项目经理的重要一项工作，后续的项目执行监控和复盘都需要以项目计划做为基准进行。在一份完整的项目计划中，可以看到项目目
21、标范围，假设约束，生命周期模型选择， WBS，估算，进度计划，人员计划，质量目标，方法工具技术都是项目计划的重要内容。在项目计划的制定过程中有一个重点就是项目四要素的平衡， 而平衡则需要培训做项目计划时候的系统思维能力。 培养做项目进度计划时的系统观 客户最关注什么 产品质量往往是基本，这是一个默认属性。但是做到哪个度仍然可以谈，所以首先要清楚用户对质量要求的优先级，一般来言可能是可用-易用-性能-安全。这一般叫测试类型，另外就是测试的等级表明测试要达到何种覆盖率或程度。这些都影响到项目周期。 除了默认质量要求，项目周期往往是客户最为关注的。这个往往并不是经过详细的估算，排完进度了再确定下来的
22、，而是项目一开始往往就由客户敲定，而项目范围往往也是在合同就会明确下来。所以跟用户敲项目周期就显得很重要了，根据软件工程和经济学得出结论是：对于一个软件项目我们可以考虑投入更多资源来缩短项目周期，但当项目周期缩短到一定度以后，投入再多的资源也没有用。因此项目经理谈判的底线为在不考虑人力资源情况下项目能够达到的最短周期， 如果这个最短周期还达不到客户要求，必须缩减项目范围而不是牺牲产品质量。 项目计划重点就是通过调整各个要素，保证项目能够有 8,9 成以上的胜算，对于影响到项目成功的全部列入风险和关键问题进行跟踪。项目经理在计划完成后一大半的时间都应该花费在消除不确定性上。项目失败往往并不是进展
23、过程出现太多异常，而是一开始项目经理就不清楚自己有几层把握，一开始也没有分析清楚有哪些不确定性和关键要素。 项目周期敲定了再排进度 如果简单的认为项目周期确定了再排进度就只能是倒排进度， 那说明还没有真正理解各要素的平衡和进度安排的实际含义。项目经理往往根据项目周期倒排不切实际的进度计划，那导致项目进度延期就是必然的事情了。 制定进度前最重要的仍然是根据人力资源情况和项目周期来综合考虑生命周期模型的选择， 是瀑布还是增量迭代，这个直接影响到 WBS 的分解。而 WBS 中我们又最关心工作包或任务的粒度问题，这个需要和可用的人力资源配合起来，一个功能模块分解细后可以更多的人力资源参与进来，使更多
24、的任务能够并行，但无疑会增加前面接口设计和后期集成的工作量。当接口设计和集成工作所花费时间大于开发任务并行所缩短的时间时候，这个时候就到了分解的最小粒度。在这个粗细粒度间就是可以通过调配人力资源能够获取的最大进度压缩。 在 IT 项目中由于岗位角色划分，往往并不适合采用关键路径的方法来预计进度。进度安排关键在让所有人都尽可能早的动起来，在这里可以考虑的思考方式是: 1.关注项目关键资源，关键资源必须优先安排来执行关键任务 2.通过组件细分和迭代，增加后期集成时间，但缩短前期关键路径等待时间 3.通过每日构造将测试也迭代起来 4.进度紧往往更不该跳过需求和总体设计评审而直接编码，后期返工往往是灾
25、难性的 最有效的方法论和过程 在裁剪过程的时候， 必须清楚的认识到哪些过程元素是保证项目成功的核心要素， 哪些是可以省略的。XP 方法论对于任何一个功能的开发仍然是遵循小瀑布，而不是跳过程。一个设计思路可以在纸面设计草图后就可以开始编码，后期再形成规范的文档，但决定不是说不经过设计就开始编码。需求，DEMO 原型，总体架构，数据库设计，评审，项目开发模式和规范都是重要的元素，都应该最有效的去发挥作用。因此以下是可以考虑的关键点 1.DEMO 原型必须和用户沟通确认，但需求阶段技术架构工作可以并行 2.需求和架构，数据库必须经过评审 3.架构或总体设计完成后必须进行培训，强调后续的开发模式和规范 4.架构开发不一定要全部完成才能开始后续工作，但事先要定义清楚接口 4.详设可以出纸面草图，面对面沟通后即可开始编码，后期再补规范文档 5.对于 100%要做的不涉及业务规则功能可提前编码，如一些基础表的维护 IT 项目计划思维导图
