VUCA时代的IT项目管理（一） ——困境

一、真正理解项目经理的角色

对项目经理角色的理解一定要避免两个极端，一种过分强调项目经理的技术能力，认为项目经理应该是团队中技术最强的人，项目实施中的任何疑难问题最终归集到项目经理，项目经理必须说“Yes”或“No”，否则就无以服众。

另一种则过分强调项目经理的领导能力，认为项目经理首要任务是给其组员端咖啡，协调大家之间的关系等。

项目经理跟一般的职业经理人不同，它具有较强的专业性，一个不懂技术的人是绝对不能做项目经理的，项目经理应该是技术和管理的结合。

二、重视对项目组的管理，奖罚分明。

项目管理的核心是‘三角平衡’，即规格、成本、进度三个方面保持平衡。在大部分项目实施中，往往无法确立和实现项目成本的指标、考核和控制，资金的支配权往往不归项目经理，而由公司决定，这样导致公司与项目经理之间的责任不清，对于某些制度也无法贯彻执行，不能很好地实现项目经理负责制。

为了组建一个和谐的团队，项目经理必须充当队员的激励者、教练、活跃气氛者、维和人员和冲突裁决人。

另外，项目经理还必须注重不同岗位的后备人员的开发。在项目的实施过程中一旦出现队员辞职的现象，项目经理能够合理安排人员调动和接替;同时，便于队员在工作过程中形成竞争，以及合理安排期间性休假。

三、计划、计划、计划

几乎所有的人都知道项目的实施需要制定计划。但是在具体 *** 作过程中还是存在以下几种现象：一是项目计划的制定不够严谨，随意性大，可 *** 作性差，因而实施中无法遵循(如项目计划过于粗略，落实不足)，没有做到任务、进度、资源三落实。二是缺乏贯穿项目全程的详细项目计划，甚至采取每周制定下周工作计划的逐周项目计划方式，其实质是“项目失控合法化”。三是项目进度的检查(与进度计划比对)和控制不足，不能维护项目计划的严肃性。

再完美的计划也会时常遭遇不测，但并不表明不需要制定计划了。如果没有计划就失去了参照物。项目经理应该能够预测变化并且能够适应变化。经常做一些“如果——那么”的假设，避免安于项目现状，在项目发生变化时能够及时作出调整。计划总在变化，计划没有变化快，关键是计划能够跟上变化。

在项目的实施过程中，经常会将整个项目分成若干个小的项目，项目经理应有效的利用好时间，做到各个项目之间的有效、合理衔接，保持整体计划的合理性和连贯性。

项目计划粗细程度，是一个需要小心把握平衡的问题。越细则控制力度越大，但项目管理的成本越高;反之亦然。

四、不要吝惜在培训上花的时间，进行二次、三次培训都不为过。

培训是项目实施的一个重要环节，单在进行培训时，应该分层次、分阶段的进行培训，不能期望一次培训就能使单位的人员理解和掌握软件的 *** 作。培训应贯穿于项目的始终，并且应做好适合用户水平的 *** 作手册，必要时在单位内部网页上做“常见问题问答”的栏目。

五、进行原型测试，做好一个理论和实践都可行的实施方案。

不管是培训还是计划都必须建立在一个可行的实施方案的基础上，否则即使方法再好，也不可能达到良好的效果。所以在实施之前，应该进行充分的系统分析和调研，充分听取各个层次人员的意见，多方搜集资料，并且进行多角度的原型测试，在项目小组同意的基础上，才进行实施和培训等计划的制定和执行。尽量避免在实施过程中进行方案改变等情况的发生。

六、合理的降低客户的需求

任何软件都不是万能的，都不可能百分之百地解决客户地所有问题。在项目的实施过程中，应该实事求是地、明确地告诉用户那些是软件做不到的。一些软件公司和实施人员不愿意和害怕把真象告诉用户，只想把企业原本正确的业务流程转变成本公司软件所规定的业务流程，结果造成双方僵持。特别是一些软件程序上的毛病，更是不愿接受用户的指责。其实，这完全没有必要。在不可能解决的问题上跟用户兜圈子，其结果只能是使用户造成误解，和对公司的不信任。

由于各种各样的原因，在企业的经营管理中总会有一些具有自己特色的东西，但是，企业难于在短时间改变现有的做法，这就需要软件的灵活性和实施的变通。当然，应该尽可能地使企业的行为合符有关的法规和惯例，这是最好的结果。

对待客户需求方面也应该讲求80/20原则，不能一味的降低客户需求。这里所讲的合理的降低客户需求，应该是在解决了百分之八十以上的基础上，或解决了企业主要需求的基础上，对于客户的一些特殊需求不预满足或解决。

老师推荐给我们看的几本书让我受益匪浅。特别是《你的灯亮着吗》。看进去之后方才知道老大的用心良苦，自己在处理工作中的事情时，不管用户是非对错，用户提出问题，我的思想老是照着用户的问题去解决问题。在这本书中针对我目前的情况有详细的解析。

这些书带给我的启发不仅仅是关于高级IT项目管理这门课程的，也给我今后的人生上了重要的一课。正如项目经理案头手册中提到的JM朱兰将一个项目定义为一个计划要解决的问题。该定义使我们认识到，项目管理是在大的规模上对问题的处理。我们生活中也在不断的遇到各种各样的问题，在进行项目管理的过程中，随着工作的进展，也给我们生活中解决问题指明了一条正确的思路和方法。项目问题就是人的问题，这些书启发我们在做事的时候不要怨天尤人，惟有付之行动，生活才会回报付出者；没有计划，就没有控制；要积极主动，不要被动反应；承担责任，争取权力；所有的行为只有从执行者的视角来理解才有意义；人最害怕的是被拒绝，最需要的是被接受；沟通技能是项目经理最应具备的技能之一。

书中有说到一句：“问题其实就是你期望的东西和你体验的东西的差别”。对于我工作中，用户正常使用TAJIMA的流程，就是我期望的东西，而体验到的东西都是，用户不按正常流程执行。问题就在于，用户更本不按流程走。而对于用户来说：用户期望的是可以直接改个供应商或直接改个单价就可以满足采购或财务的需要，而体验到的是在系统中供应商无法更改，单价在采购单更新后，财务部那边的出入库金额数据无法更新。所以用户的问题就是：采购单无法更新供应商，单价更新了无法满足财务的需要，怎么办？到底是谁的问题？当出现这种情况，我往往把用户的问题定义成了问题。想尽方法帮用户解决。书中还有说到：“在寻找问题定义的道路上疲倦地游荡时，不要忘记随时都回头看看，看看你是不是已经迷路了”，在工作中我经常帮用户想解决方法，哪种解决方法对于用户目前是最简单的？回头想想，有的时候真的帮用户解决到问题吗？没有！因为我在找解决方法的过程中，已经错误的定义了我在解决的问题。用户入库拒收的库位选错了，入错了库位。我首先将问题的定义为：将入错库位的数据调整至正确的库位。一股脑的想如何去调整，用哪种调整方案最简单？结果表面上是以经解决了，可过不了多久此类情况又会发生。其实遇到这种问题应该先想想，库位选错的原因是什么，是不是之前的培训没有到位？如何杜绝这种情况再次发生？现在该做些什么？应该教会用户在开单时就先确认库位。如在开单时就选错库位就点选取消，重新开过单据。还有一次，财务部提出采购部在采购单上更新了价格，但出入库记录的金额还是没有，希望我们帮忙解决。我首先想到的就是帮财务部将采购单上更新的价格导出给财务部，方便快速。但没有想到问题的起源是：采购部在入仓之前没有输入价格，而要在入库之后才补上，导致现在这种问题。要解决这个问题的方法是让采购部在入仓之前就把价格填上，在入库的时候就会自动获取价格，而不是给财务部导出价格。

书中有个章节“什么是真正的问题？”里面有指出：“每种解决方法都会带来新的问题”，回想过去的工作，的确存在很多问题解决之后，产生了更大的问题。针对这种现象,书中指出：“问题最难以处理的部分恰恰是去意识到它们的存在”,因为用户养成的习惯，慢慢的就会无法意识到它们的存在。如果采购部一直都是后补单价的话，就更本不会意识到后补单价是一种错误的方法。

因为时间的关系我没有全部看完这本书，有时间还需要经常翻看。在今后的工作中，需先将问题定义清楚，找到真正的问题，再去找寻解决这个问题的最佳解决方法：解决后产生的问题，没有解决前的棘手且最不棘手的解决方法。

书中有说到一句：“问题其实就是你期望的东西和你体验的东西的差别”。在一个项目的进行过程中，我们不可避免的要和用户之间沟通和交流，当然，在交流过程中，会遇到一些问题。不管用户是非对错，用户提出问题，我的思想老是照着用户的问题去解决问题。在这本书中针对这种情况有详细的解析。我往往把用户的问题定义成了问题。想尽方法帮用户解决。读完此书，以后在用户提出问题后，需先想想问题到底出在哪里？找出问题的真正定义！书中还有说到：“在寻找问题定义的道路上疲倦地游荡时，不要忘记随时都回头看看，看看你是不是已经迷路了”，在工作中我经常帮用户想解决方法，哪种解决方法对于用户目前是最简单的？回头想想，有的时候真的帮用户解决到问题吗？没有！因为我在找解决方法的过程中，已经错误的定义了我在解决的问题。书中有个章节“什么是真正的问题？”里面有指出：“每种解决方法都会带来新的问题”，的确存在很多问题解决之后，产生了更大的问题。针对这种现象,书中指出：“问题最难以处理的部分恰恰是去意识到它们的存在”,因为用户养成的习惯，慢慢的就会无法意识到它们的存在。

《项目经理案头手册》一书对整个项目过程进行了透彻的分析。刘易斯循序渐进地教我们如何从头到尾地计划、执行和控制一个项目，如何选择项目经理和能解决问题的项II团队，如何用WBS，PERT，CPM和甘特图编制项目计划，如何设计项目控制系统，如何利用挣值分析跟踪项目，如何与团队中各层次的成员进行有效沟通，如何在项目完成后进行经验教训总结。为项目经理展示了如何成功管理不同大小、不同类型的项目，内容讲解深入浅出，案例丰富全面，既深刻地分析了项目管理的本质及一些项目管理现象的内在含义，又简单明了地介绍了实践中具体应该如何 *** 作，很好地实现了理论性和 *** 作性的结合。

美国著名项目管理专家刘易斯为我们提出16步管理模型。从16步管理模型中可以看到项目的战略计划所处的位置：概念确立。就是对所要做的事情有一个框架性的设计，有一种思想；问题的定义。即对长远目标说明。第二步骤是对第一步的进一步细化和具体化；生成项目的备选方案和战略计划。就是提供思路、备选方案和战略计划总体思路；战略计划评估和选择。就是在选择方案的同时，有一个从总体技术路线到总体项目管理策略的评价和选择；战略的确立。就是确定具体的战略、目标；制订项目的实施计划。这是一个更加具体的、第二个层次的项目计划，就是怎样实施；项目干系人批准计划。这里的计划包括战略计划、初步计划、详细计划，在这些项目实施之前，有一个批准过程；签署项目计划。项目的批准人、参与项目的有关干系人要签署项目计划，对计划做出承诺，同时建立项目的跟踪记录，做一个项目进展情况日志或者周志、月志、记录，根据这些记录信息进行知识管理；执行项目计划。执行项目就是正式开展计划，进展这个项目；监控项目进展。计划开始实施之后，就要考虑计划执行得如何，有无问题，要对进展情况进行监控、监测和控制；审查项目定义。项目实施之后，需要做一些评审，评审包括对原来工作的评审，同时也包括对项目目标定义的评审，如有问题就返回到步骤二，重新修正项目的定义；对项目的战略进行评审。首先是评价目标或项目的定义，然后评审战略计划、战略制订是不是有问题，如果有问题就返回步骤四，重新修正你的项目战略；项目的实施计划。具体的计划工作流程、对一些细节要进行评审，有问题就进行修改；循环。按照整个过程不断地从计划的执行到监测、评审，有问题就要修改计划，然后再执行，再评审，这个过程一直延续到全部工作结束；总结经验教训。项目全部完成以后，及时总结经验教训，对一些问题进行归档，作为今后项目的指导和借鉴；结束项目。这是一个完整的项目管理流程，从这个流程可以看到整个项目战略计划实际上是在制订项目的详细计划和实施计划之前。在项目计划的时候，首先要有一个总体的战略计划，在总体的战略计划指导下再开展具体的项目计划。

书中指出项目在结束时失败，而是在开始时失败。在我们开始一个项目时，首先应该搞清楚项目的使命，前景，目标和目的。确定是否要进行此项目。当我们决定要开始一个项目后，就应该制定相应的战略计划，战略要回答“我们怎样对这项工作展开活动”这样的广泛问题，而制定实施计划则要求一丝不苟，换句话说，制定实施计划有关怎样做这项工作的详细事宜。制定计划涉及回答的问题包括：做什么、谁来做、何时、何地、多长时间和怎么做。

其次要对项目进度进行详细计划。项目进度计划编制既是一门科学，又是一门艺术。关于进度计划，真正的重点是为在最短的时间完成项目，找出并行尽可能多的活动的方法。项目管理科学的一面涉及到资源的平衡，它通过计算机运算完成，并存在许多算法。但是，同首次进行项目人力资源分配应用的技术相比，其结果差不多。

另外，资源计划也是重要的一环。完成一项活动的时间取决于分配给它的资源，并且如果没有相应数量的资源，工作就不能按计划完成。如果项目经理不能解决资源分配的问题，项目进度计划就不会成功。

此外，要对项目控制和评审。要达到项目目标，有必要采取适合的项目控制和评审。项目检查有三种类型：即状况、设计和工作过程检查。状况检查主要检查项目是否在进度计划和预算之内、范围是否正确、绩效的要求有没有问题。而设计检查仅仅适用于包括设计工作的项目，检查中经常要问的问题是达到规范了吗？用户界面友好吗？我们有能力制造吗？市场需要我们开发的产品吗？投资回报及其他的产品开发理由荏苒适合吗？之所以进行项目需要检查时因为：随着项目管理水平的提高，同时提高项目绩效；确保项目工作质量不居于进度和成本问题之后；尽早找出开发问题，以便提前采取措施；识别应采取不同管理方式的其他项目领域；确保业主获知项目状况。

在项目即将结束之时应该总结经验教训，若失败，则分析失败原因，可以从以下几个层次进行分析：（1）项目管理环境中的失败 。这些失败的根源可以追溯到项目组织与项目目标、项目任务、高层管理部门以及更大的环境之间的不适当的“配合”。它们包括使用对于项目目标和项目环境来说不正确的项目管理方法或模型，以及缺乏高层管理部门对项目的支持等。 项目不具备正确的组织结构、项目经理或者团队（以技能、经验、权力、正规性、复杂性来衡量）来“配合”项目。（2）项目管理系统中的失败 。这些失败的根源可以追溯到项目领导及错误实践。它们包括项目经理在项目生命周期中对系统方法的忽略，以及项目管理技巧的错误应用等。具体的可以归结为：不胜任的项目经理 ；忽略了项目的系统本质 ；管理技巧不恰当或者错误的运用 。（3）在计划和控制过程中的失败 ：项目中没有良好的沟通 ；没有用户的参与 ；不充分的项目计划；不充分的项目定义；糟糕的时间和资源估计；不正确的工期安排和资源处理；在执行阶段为数众多的变更 ；不恰当的控制 ；项目终止的计划很拙劣 。同样项目成功也应该总结经验。要取得项目成功，项目的目标定义、项目的系统、整体系统控制、整体计划，包括战略计划、实施计划、日程计划要通过详细、认真地预算、估算，保证项目能够得到充分的资源。在项目的实施过程当中，要通过经常性的审查、控制和评审来保证项目能够按计划不断地推进。 除此之外，组织目标的实现还需要在组织上保证。包括项目经理的领导艺术、项目经理的管理才能、管理技能以及相关的技能、组织结构和团队建设方面。所有的这些，都是保证项目走向成功必不可少的环节。

《微软研发制胜策略》和《微软项目求生法则》两本书也给了我很多启发。求生法则从求生心态、求生准备、逐步迈向成功以及完成任务几方面向我们阐述软件项目是如何存活的。作者利用在研究与工作中获得的经验告诉我们项目开发过程中的规划、设计、管理、质量控制、测试与完工所需的策略与观念，并利用大量技巧建立一套精简可靠的框架来成功的管理项目。软件项目的存活不是一种意外的结果。要让一个项目成功所需的努力并非特别困难或耗时，只是需要从项目开始进行的第一天就勤奋努力到最后一天而已。软件项目是发现与发明的过程。发现与发明融合为一的最佳方式是透过“阶段性完成”的做法，将产品的功能分阶段完成，而最重要的功能最早完成。当项目进行时，许多活动交互重叠，把产品由抽象概念转化成具体成果。项目进行中的源代码倾向以S形曲线而非线性成长，而大部分的程序代码都是在项目中间第三部分完成的。追踪程序代码的成长提供对项目状态的洞悉力。执行良好的项目也可以由一名上层主管选择最有成效的一组来进行追踪。

软件项目被切分成三个概念阶段。在项目初期，焦点摆在“发现”，特别是发现使用者的真正需要。透过技术性调查、与使用者访谈和建立接口雏形，把不确定性的概念转换成确定的观念，这就是第一阶段的特色。在项目进行中期，焦点移到了“发明”上。往大方向看，开发人员要发明软件构架与设计方式。细节的地方，如每个函数式或对象类别也不能忽略。如同发现阶段般，发明阶段的特征在于将不确定的概念转换成确定的观念。如果还有别的特征，就是发明阶段的不确定性要高得多。在发现阶段，开发人员可以确定答案“就在”某个地方。可是在发明阶段，就不能以此类推。在项目的最后部分，焦点又转移了，这次摆在实作上。不同于发现与发明阶段的是，实作阶段的不确定性少多了，故可发掘出许多已确定的观念并可实现成具体成果。

本文提供的项目规划依循着“阶段性完成”的轮廓进行。由于她将项目中开发的软件分阶段完成，而不是到了项目结尾才一次完成，这种方式称做“阶段性完成”。 在每个实作阶段中，项目团队进行细节设计、程序写作、除错与测试，在每个阶段都建立出可能推出的产品。分阶段完成有以下好处：关键功能更早出现；早期预警问题；减少报告负担；阶段性完成可降低估计失误；阶段性完成均衡了d性与效率。阶段性完成的做法听来似乎毫无缺点，其实则不然。阶段性完成的做法要付出相当代价。因为项目团队需要时间准备各种可推出的软件，在每个阶段重复测试已经测试过的功能，推出软件前进行相关的版本管制工作，提供试用的不同版本软件没预料到的问题的解决方案（如果阶段性完成的软件真的拿出去给人使用），还有规划阶段性发行这种做法的好坏等等，都会提高项目的负担。阶段性完成并不是万灵丹，不过总合起来，那些额外的负担相对于明显改善了的状态、质量与时间的匹配、精确预估与降低风险等来说，不过是一点小小的付出而已。

《微软研发：制胜策略》一书中，作者详细描述了他在美国领导项目的各种实际的策略方法，教我们如何开发高质量的软件。卓越的领导者从不同的角度看世界。若是公司被大火烧得精光，他非但不为丢饭碗惊慌，反而利用火焰来烧烤一顿大餐。当每个人都摇头离去，卓越的领导者仍有充分的信心保持乐观，对每件事都从正面角度来思考。就因为凡事都看光明面，卓越的领导者并不把失败当失败，反将其当作学习克服障碍的经验。正因如此，卓越的领导者乐意尝试各种稀奇古怪的想法，并从中获得重大的突破，即使不成功，他只把这次经验当成获得信息的方式之一。这种***不一定要有经验，而是需要强烈的进取心和明确的理想，能够将理想与他人沟通，鼓舞他人共同追寻理想的能力，再加上一点机会，这就是能将理想实现的卓越领导者。坐着告诉我们开发项目要制定详细的目标，包括你要求的输入和输出的目标、长期和短期的目标，项目组要时刻被各个具体目标的实现所鼓舞和激励；不要浪费时间在错误的问题上，一定要先确定真正的问题在哪里，然后才去改正它；人们开口要求的东西未必是他真正想要的，处理他的要求之前，请务必先确定他究竟想要做什么；如果您能够先明确定义自己的需求，再向别人提出，这是避免在沟通上发生误会的好方法；任何不能改善产品的工作，都是浪费时间或偏离方向；项目组每部分的进度要协调一致；一旦发现错虫就立即清除掉，别拖延；程序设计前要先确定它的优先级表，比如稳定性、可移植性、速度和效率等；绝对不要答应别人自己做不到的事情，这样对双方都有益无害；注意定期会议的价值，确定它是否值得每个人放下手中的工作召开会议之前，请确定本次会议的目的是什么，达成这个目的的条件是什么，然后，务必达到开会的目的；会议尽量安排在一个时段的最前面或最后面，尽量减少工作的中断与时间的切割；最会误导项目发展、伤害产品质量的事情就是过份重视进度，这不仅打击人员士气，还会迫使组员做出愚蠢的决定；为了保持创意的活力和团队士气，必须让每个小项目都有令人兴奋的结果；不要让设计师的学习停滞不前，要让程序设计师有机会磨练不同领域的技术，培养十八般武艺样样精通的组员。组员的技术和知识应该精益求精；员工应积极学习新的技术、养成良好的工作习惯，做事更有效率，把握有限的时间，增加你个人对公司的价值；不要用年终考评来订立学习目标，要利用年终考评来记录个人的成长；不要给使用者次品，宁愿延期交货，务必追求质量完美；将程序的可共享性当作优先考虑的目标之一，否则程序设计师将经常做重复的工作；如果您创造了一项资源，并且让别人知道，那么总有一天会派上用场的；主管应该把自己视为团队的一分子，与其他人平等，而不是高高在上；健康的生活是一切创意的源动力。这些经验也同时告诉我们做人的道理。

《人月神话》一书对我的触动很大。作者详细讨论了包括工期规划、团队组成、文档、排错等软件项目进行全程中的方方面面。当我捧起《人月神话》，马上就被深深的吸引了。书中很多细微之处都对我的思维造成了冲击。上一本给我类似感觉的书是那本四人帮的《设计模式》，已经很久没有看到这么好的书了，郑重推荐。

把感触比较深的几点记下来，顺便整理一下自己的思路，与大家分享。

1，保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念，但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明确的文档化，而没有成为所有开发者共同的概念。在其他开发者编码的时候，就可能会生成与概念相抵触的东东（模块，功能，算法），导致整体结构的恶化。这个时候总设计师一定要即时发现，做出更正。

概念的完整性，对于很多小规模软件，由于开发人员不多，开发经理一般都能控制住所有的代码，概念完整性在组织层面就维持住了。但要注意以后的Bug修改，功能扩展的时候，也要时刻留意与最初的设计是否概念上相容。对于大规模的软件系统，则必须通过树状组织结构，层层控制，总设计师还是一到两人，每一层都有对下层的绝对把握能力。我以前参加过一个15人左右的项目组，就是分为两层。感觉整体概念完整性的控制效果还不错。我没有更多人数项目的具体实践经验，希望以后能有机会参与比较大的项目。

2，“一个拿2倍工资的人，生产率可能是其他人的10倍。”我和我的同学，一个小公司的技术总监聊起这个，他也是十分的认同。不知道其他公司的程序员们如何看。我的同事中有一个牛人，做出的贡献特别大，应该相当于我们公司普通的十个程序员，不过工资最多也就是普通程序员的二倍。是不是有些不公平呢？我也说不清楚。因为那些普通程序员也十分的努力。不过，我觉得，作为公司，应该给最好的人最好的待遇，或者说给比目前更高的待遇。

组建一个团队，最好的就是那种精英团队，大家都是牛人，效率会特别高。微软就是这种思路吧，把最聪明的人集中在一起，想不成功都难亚。

3，进度落后与增加人力。记得当年看《C＋＋编程思想》，Bruce说“十个妇女不能在一个月内生下小孩”（大意），于我心有戚戚焉。而本书作者Brooks得出的结论是对我是震撼性的：“向进度落后的项目中增加人手，只会使进度更加落后”。

以前，增加人手基本是挽救进度落后项目的主要办法。这个办法行不通的话，难道只有“加班”一条路了？但长期加班是对个人的摧残，我更愿意利用业余时间去看书，例如看这本“人月神话”。：）

如果不想加班，不想削减功能，不想推迟发布日期，那么。。。。。唯一的方法还是只有…加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见（特别是加入的人中有比较强大的设计者）。那么，就当作，新组建了一个团队吧。交流，培训新人，就设计达成一致，继续向者目标前进。

VUCA一词起源于上世纪90年代的美国军方，是Volatility（易变性）、Uncertainty（不确定性）、Complexity（复杂性）、Ambiguity（模糊性）的首字母缩写。VUCA概括了后互联网时代的世界特征——复杂多变。我们所处的世界变化越来越快，知识边界不断被突破，项目管理也不例外。

传统的项目管理虽然认识到项目具有渐进明细的特点，但在计划、执行、监控过程中还是明显强调瀑布特点：制定计划前要“清晰、完备、准确地界定项目的工作范围(SOW)，作为整个项目工作的基础”，然后是“分解出足够详细的工作步骤(WBS)”， 把WBS作为整个项目计划、执行、监控的核心。虽然传统的项目管理中也提到滚动计划，但还是以稳定为基调，把适应变化作为辅助，而VUCA时代恰恰是以变化为最大特点，传统的项目管理方法很难适应这个前提，从而使得计划赶不上变化，项目计划往往成为一纸空文。

传统的项目执行出现问题，多归因为项目工作范围界定不够准确、项目计划不够详尽。应对的策略也很粗暴：一方面是在合同谈判的时候尽量界定清楚、不含糊其辞；另一方面在合同执行的时候，据理力争，合同约定之外的尽量拒绝。

由于各种原因，合同约定一般很难满足SMART原则，“聪明的”乙方则会跟客户约定以“签字后的需求规格说明书”作为验收依据。这样“需求规格说明书”就成了双方的“必争之地”。在项目费用、执行周期固定的情况下，甲方项目经理自然希望乙方能提供更多的、更高品质的功能，至少可以更好地向领导交差；乙方项目经理则希望能以最小的资源投入、冒最少的风险、尽快交付，能拿到更多的项目奖金。

在“合同谈判”胜过“合作共赢”的情况下，乙方项目团队虽然在需求调研上投入大量的精力，但客户不愿配合、拒不签字的场景时有可见，更有甚者乙方会设计晦涩的需求文档、复杂的变更流程，甚至应用了多种心理效应，就是为了约束客户不要再变了。

对于第一种变更，乙方需求分析人员如果有丰富的领域知识与实 *** 经验，能设身处地地分析，大多能够避免。但由于人的思维定势及碎片化倾向，一次很难考虑周全，难免会有遗漏，譬如酒店管理系统中的入住功能，“团队入住希望能住到相邻房间”这样的约束，可能事先很难想到，只有在系统投入使用后才能发现这个不便。为避免这类变更，传统的做法是加大需求捕获与分析的力度，这容易事倍功半，也容易造成“过度工程”的问题。

对于第二种变更，传统的项目管理中一般归到风险范畴，譬如甲方换了领导或项目负责人，组织结构调整，外部环境发生重大变化、设备不到位等等，这些都是风险，都会给项目工作范围带来变化。传统的应对策略是识别、分析、跟踪、应对风险，增加缓冲资源与时间。但风险的概率特性，为管理层提供了侥幸的借口，风险缓冲很容易被上级砍掉，风险被直接转嫁给员工，通过员工的加班加点来弥补。

第三类变更，不是由于问题变了，而是解决问题的方式变了。在汽车没被发明的年代，客户希望更早到达目的地，只会想要一辆更快的马车，而福特却造出了汽车。同样的问题不同的解决方案，效果自然不一样，项目工作范围也会截然不同。

VUCA时代，复杂与变化已经成为主旋律。在这个强调以客户为中心，强调为客户带来价值的时代，项目还要因循计划、不拥抱变化，一方面确实不易做到，另一方面也一定会损害客户关系。

VUCA时代的IT项目管理该如何开展呢？

什么是项目管理？

经过人们长期探索总结，项目管理在发达国家中已经逐步发展成为独立的学科体系，成为现代管理学的重要分支，并广泛应用于IT、金融、服务、航空航天以及工程等诸多行业。由于其诱人的高额年薪以及广泛的就业前景，项目管理目前已经成为超越MBA的最炙手可热的“黄金职业”。 项目管理无疑将会是未来二十年中最热门的行业。那么到底什么是项目管理？

项目管理的定义有很多，按照教科书的理解是：项目管理是在运作方式和管理思维模式上最大限度地利用了内外，去完成项目目标。项目管理包含很多层面：团队管理、风险管理、采购管理、流程管理、时间管理、成本管理和质量管理资源等。

笔者的理解是：项目管理，就是通过合理地组织，利用的一切可以利用的资源，按照计划的成本和计划的进度，完成一个计划的目标。在项目实施过程中，目标很可能会发生变更，那么成本和进度都需要做相应的调整。

项目主管如何解决问题？

按照白猫黑猫理论，评价项目管理是否成功的唯一标准就是项目是否保质保量按时完成。现在的项目实施一般都是主管负责制，项目主管重任在肩，要达到项目成功这一目标谈何容易。

在项目管理过程中，笔者就要经常思索以下问题：

如何在选择余地不多的情况下，组建一支得力的项目组？

项目组成员的挑选非常重要，假如在一个关键的岗位安排了一个不合适的人选，这个项目很可能会出师不利。当然在现有的人力资源中，不一定能顺利选到优秀的人才并组建成一只能战斗的队伍。笔者就碰到这种最恶劣的情况：项目组只有主管有经验，别的成员都是刚刚毕业的大学生，那么主管的任务就不仅仅是管理，而且需要花费大量时间精力来培养这些新手，让他们能尽快进入预定的角色。

如何界定项目成员工作的范围和定义他们之间的工作接口？

这个问题就是俗语说的"派活"。要把活分出去可不是一件简单的事情。项目主管首先需要对项目组成员非常了解和熟悉，知道他们的知识结构和能力水平；其次要对项目情况非常清楚，并能对项目实施过程进行划分和功能模块的细化，并结合每个人员的特点指派具体的任务；最后要重点注意的是，尽量让组员之间的工作接口简单和接口定义详尽，避免将来产生互相推诿和扯皮。

如何准确衡量项目成员的工作量？

做过主管的人都碰到过这种问题：分配给甲的工作，要求一周完成，但是一个月过去了，他还没干完；分给乙的工作，要求一周干完，但是他一天就干好了。实际上现在的项目管理中，工作量的衡量往往靠主管的经验来加以主观判断，而且这种判断也不是因人而异的。主观判断会造成较大的误差，这些误差的积累最终导致不可控制的因素增加和项目风险扩大。

如何在不打扰项目组成员工作的情况下，及时进行沟通？

现在很少有单q匹马就能把项目全部搞定，往往需要团队来完成，那么团队的合作精神就显得尤为重要。在一般人的眼里，技术人员都普遍比较孤傲，不好管理。主管不仅仅要掌握良好的沟通技巧，还要擅于感情交流，帮助解决项目组成员工作上和生活上的实际困难，使他们集中精力干好本职工作。良好的上下级和同级关系创造了融洽的工作气氛，项目成功的可能性大大增加。

如何评估项目执行状况，随时掌握项目进展？

在项目运作过程中，如果靠员工的报告来掌握项目进展是不够的。事实上，员工都愿意报喜不报忧，在项目初期就出现的问题苗头，如果不能传递上来，将在后续阶段造成大的纰漏。笔者认为除了要定期听取项目组成员的报告，还要专门有一个品保组来监督项目的执行情况。品保组就像廉政公署一样，不参与项目的具体实施，专门给别人"挑刺"，或者写一些测试程序来发现问题。

如何与客户单位沟通与协作？

有时候，项目都已经执行到最后阶段，客户单位突然提出了新的要求，这会让主管非常为难。一方面要尽量满足客户的需求，另一方面又不能对系统做太大的改动，影响进度计划。这种情况往往是与客户的沟通出现了问题，说明在需求阶段做的不够好，同时在实施过程中没有与客户有密切的联系。

如何在诸多不确定因素和限制条件下，按时完成项目任务？

项目成功与否受太多的风险因素影响。所谓“风险”，是损失的不确定性；是给定情况下，一定时期内可能发生的各种结果间的差异。它的两个基本特征是不确定性和损失。项目开发是一项可能损失的活动，不管开发过程如何进行，都有可能超出预算或时间延迟。很少有人能保证开发工作一定成功，都要冒一定的风险，也就需要进行项目风险分析。在进行项目风险分析时，重要的是要量化不确定的程度和每个风险的损失程度。潜在的问题都可能会对项目的计划、成本、技术、产品的质量及团队的士气产生负面的影响。风险管理就是在这些潜在的问题对项目造成破坏之前识别、处理和排除。

如何在完成项目任务同时，保证甚至提高交付结果的质量？

笔者的同事曾经做过一个项目，按计划按预算完成了，但是系统不稳定，某些关键技术指标不能满足国标。造成这种情况的原因有：没有划分清晰功能模块和接口关系，成员相互指责，最终难以定位不稳定的根源，；没有成立质保组，没能很好地实施项目过程控制；过分注重项目的时间进度，忽略或隐瞒了前期的小问题。

如何成为优秀的项目主管？

笔者认为：一个优秀的项目主管首先是一个乐观而自信的人。他凡事都从正面考虑，不把失败当失败，反而将其看作成功之母，吸取经验教训，在那里跌倒又在哪里爬起。优秀的项目主管不一定要很有经验，但是要有强烈的进取心和明确的目标，并能够与他人良好沟通，鼓舞他人为共同的目标一起努力。

IT项目管理的特征探讨

IT项目具有非常明显的特点：紧迫性、独特性和不确定性。下面分别讨论一下这些特点含义和项目管理的相应对策。

紧迫性

IT项目的紧迫性决定了项目的历时有限，具有明确的起点或终点，当实现了目标或被迫终止时，项目即结束。随着信息技术的飞速发展，IT项目的生命周期越来越短。有的项目时间甚至是决定性因素，因为市场时机稍纵即逝，如果项目的实施阶段耗时过长，市场份额将被竞争对手抢走。

在开始一个项目前，主管就必须明白项目的时间约束。具体到每个人、执行项目中的每一个任务都必须明确时间要求。一旦没有按照进度完成，必须要有充分的客观理由，否则就要追究相关人员的责任。

独特性

IT项目的独特性在IT服务领域表现得非常突出，厂商不仅向客户提供产品，更重要是根据其要求提供不同的解决方案。即使有现成的解决方案，也需要根据客户的特殊要求进行一定的客户化工作，因此可以说每个项目都有区别。

项目的这种独特性对实际项目管理有非常重要的指导意义。项目主管必须在项目开始前通过合同（或等同文件）明确地描述或定义最终的产品是什么。如果刚开始要提供什么没能定义清楚，或未达成一致，则最终交付产品或服务时将很容易发生纠纷，造成不必要的商务和名誉损失。即便是定义清楚了项目的目标，但是客户单位仍然会经常调整实现指标，这种变更很难控制，这就需要项目组与客户单位有良好的沟通渠道，否则改来改去，永远改不完。

不确定性

IT项目的不确定性是指项目不可能完全在规定的时间内、按规定的预算由规定的人员完成。这是因为项目计划和预算本质上是一种预测，在执行过程中与实际情况可定会有差异。另外，在执行过程中还会遇到各种始料未及的“风险”，使得项目不能按原有的预测来运行。

针对不确定性，在项目管理中就要注意制定切实可行的计划。笔者在工作中就发现科研工作，特别是国家级的项目，往往有一个“后墙不倒”原则。也就是说，设定一个项目的最终完成时间，具体的实施过程中，时间进度的安排就没有计划。在具体实施中，这种方法的最终结果是要么后墙倒了，要么后墙勉强没倒，做出来的产品满足不了质量要求。

还有一种不好的做法是过度计划，即将项目中非常微小的事情都考虑清楚才动手，但如此“详细的计划”其实是在试图精确地预测未来，也是不切实际的，在执行中会发现难以与实际一致，而不得不频繁地进行调整。具体问题具体分析。尽管有项目计划，执行过程中仍会碰到各种各样意想不到的问题，且往往没有现成的处理方法，这就要求项目经理必须掌握必要的工具方法，掌握整体过程和关键要素，灵活面对，妥善解决。

几个迫切需要重视的问题

项目管理有一些规律，但是还要具体问题具体分析，如果照搬硬套肯定会事倍功半。下面三个案例就是笔者在管理中遇到过的，现在拿出来一起探讨。

管理新手的重要性

一个项目组除了主管，全是新手！其实能有几个项目主管会如此幸运，项目组成员全都身经百战经验丰富。很多人认为，新手加入在短时间内对项目毫无益处，不仅帮不上忙，还需要别人来传帮带。笔者认为恰好相反：新人的加入是将会给整个项目组带来一些新鲜的想法，挖掘和引导这种的想法对新人的培训和很快的上手工作是非常关键的。公司花了钱招来的新人往往经过了人事部门的过滤，都具备了一些基本知识，主管可以先给他们分配一些具体的工作，调动他们的积极性非常关键。

在培训新人时就应该注意：

项目内容培训，让他尽快了解项目组的工作内容，项目的方向、目的，用到的知识、技能；

给他在项目组中的角色做个定位，明确他的职责，并提供必要的支持；

告诉他项目组管理方面须注意的问题，让他尽快融入到项目组里来；

尽量与目前项目组的工作结合起来培训，如让他尽快熟悉项目已经完成的工作，告诉他以后的计划，以及他马上要做的工作等等；

保持良好的沟通，了解他的进展，根据实际情况调整培训计划。

管理文档的重要性

让项目主管最痛苦的事情莫过于：当一个重要成员半途离开项目组时，才发现他根本就没有留下任何可用的文档。天下没有不散的宴席，项目组的成员也是在动态调整中，文档就是成员之间交接的重要工具。很多主管很容易陷quot;重技术实现，轻文档"的误区。他们总是认为项目实施时间紧迫，为了节省时间，可以在项目收尾阶段突击写文档。要是项目周期稍长，到了最后，成员还会记得清清楚楚每个实现细节吗？没有文档的项目铁定是一个失败的项目。

从过程控制的角度看，项目的实施质量控制，最重要的就是文档的管理控制。通过文档来显示表明每个基线，每个成员的工作量和完成质量，达到项目的风险最小化。

管理平台的重要性

笔者最初的几个项目都没有管理平台，所以没有量化的概念，管理手段非常落后。去年笔者在公司率先引入了微软PROJECT2000作为核心的项目管理软件，并根据项目的需求，以现有的计算机网络系统（Network）为基础，建立了内部的INTRANET项目管理平台。经过一年多的使用达到了以下效果：

使用PROJECT2000建立项目计划信息共享门户，使技术人员、主管随时看到与自己相关的任务信息，并通过建立状态报告，达到了解技术人员各自工作完成情况；

利用研发内部网站、电子公告板等共享信息系统，提供有效的信息沟通途径；

根据项目计划，建立动态提醒机制；

建立项目数据管理系统(Data)：对与项目有关的数据和与数据有关的过程，进行有效地管理；

电子文档管理系统(Document)，对图纸、文件、资料等文档，采用集中管理的方式，进行有序地组织，实现充分的共享和重复使用，实现了通过IE浏览器访问项目文档功能；

建立数据记录体现变更控制记录，项目文档记录。

结束语

就中国现状而言，项目管理还是一个全新的尚待开发的领域，很多项目管理人员和笔者一样都是在实践中不断摸索和思考。

从现实来看，只有那些跨国公司和国内的大型企业才对项目管理提出要求；从教育来看，项目管理的系统教育基本上就是空白，甚至目前中国还没有项目管理这一学科设置。同时，在中国，你所能够获得的有关项目管理的出版物以及资料都极其有限。

好在国内的教育部门已经发现了这个问题，各种PMP的培训班广告也开始出现在各类媒体中。那么我们是否都需要这个一个证书呢？

曾记得庄子在《庄子·养生主》中谈到的解牛的庖丁，在外人看来，技艺高超的庖丁解牛时，一招一式，轻松自如，姿势优美，其节奏如美妙音乐的旋律。而庖丁自己在历经多年的实践后，解释他的高超技艺的境界是："以神遇而不以目视，官欲止而神欲行，依乎天理，批大隙，导大，因其固然quot;

项目管理还是有"天理"可循，假如有机会还是应该带着实践中的问题多看书多学习，最终会达到所谓的管理艺术。(IT工程技术网)

IT企业多项目管理的实施难点与对策

导语：IT企业因其在经营过程中比一般企业面临着更多的不确定性和环境的动态性，给多项目管理的实施带来更大的难度，现针对多项目管理的实施要点展开讨论。以下是我为大家精心整理的IT企业多项目管理的实施难点与对策，欢迎大家参考！

1、多项目管理理论回顾

多项目管理是站在企业层面对现行组织中所有的项目进行筛选、评估、计划、执行与控制的项目管理方式。它是在假定存在多个项目的前提下，如何协调和分配现有项目资源、获取最佳项目实施组合的管理过程。未来多项目管理发展趋势主要有：领域范畴不断扩展;未来项目与企业战略需求更加紧密相连;多学科知识的交融;多项目管理信息技术支撑平台的建立。对IT企业来说，多个项目的实施和良好的多项目管理可以降低项目成本，优化企业资源配置，从而提高企业的利润率。

2、多项目管理实施的难点

IT企业在应对单个客户需求时，可能具有较好的d性及其应变优势，企业领导者也可以对资源进行有效协调指挥，但当项目增加到一定程度时，势必又要增加管理层次来保证有效的领导，这就与其精干、扁平化的组织结构相违背。另外IT项目还涉及信息系统应用单位的组织、管理的调整与经营过程、业务流程的重构，单靠信息技术是无能为力的，这些促使企业之间的依存关系日渐加强，往往需要根据企业的环境变化进行适应性调整或重新安排。

3、多项目管理实施对策

当面临多项目并行管理的时候，我们不可能象管理一个项目一样进行从头盯到尾，并且关注其中出现的任何问题，这从精力上来说是不现实的，而且如果你确实企图如此做，唯一的结果就是把自己弄得很忙碌，而且会突然发现，你不断处于救火的过程中。那么基于此，应该如何进行管理呢(1)判断轻重缓急，确立优先次序;(2)建立多项目管理机制;(3)利用时间差，尽量避免资源争夺;(4)清楚各项目团队能力，适当授权解放自我;(5)建立信息共享机制;(6)建立良好的绩效考核机制。

4、多项目管理实施的难点

多项目管理的产生和需求原因来自多方面，既是企业内部环境转变的结果，也是企业外部因素所致。这些因素将集中表现在企业分工与组织的变化、开发技术的变化、技术和管理的创新等方面。这种方法要求从参与项目活动的所有人那里收集到工作绩效方面的反馈意见，包括职能经理、同事和下级甚至客户。一方面这在结构层次简单的IT企业中较易实现，另一方面能全面发现个人的长处和短处，为提高绩效水平制定行动计划。关于这方面的讨论读者可以参考相关书籍。

注意事项

总之，随着更多的IT企业参与到国际竞争当中，跨国界、跨文化的项目日渐增多，多项目管理体系将更加多样化、复杂化。针对多项目管理实施过程中的难点，各种各样的对策方法将在实践中得到检验。当然本文探讨的对象也可由IT企业扩大到一般企业，因而企业在吸取项目管理理论精华的同时，更应该结合企业自身特点，有选择、有步骤地将最新成果应用到实际项目当中去，这样才能不断获得项目管理带来的喜悦。

;

以上就是关于如何做好IT项目经理全部的内容，包括:如何做好IT项目经理、项目管理读后感、VUCA时代的IT项目管理（一） ——困境等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！