如果你负责的项目偏离了预定轨道，困难重重，人心涣散，你会怎样挽救败局，把项目重新带回正轨呢？

可以试着通过如下四个步骤来拯救：

1. 停止相互指责

项目团队是一个特殊的群体，成员之间的工作是互补型。在实现目标的过程中一旦发生什么意外，应共同承担责任，指出问题所在，停止问责，将精力转移到寻找解决方案上为主。

2. 关注事实

真实数据是你当前最靠得住的朋友。深入挖掘每个阶段的问题所在和原因。

寻找每一个失败点的问题根源，“就像剥洋葱一样，需要抓住核心。比如，假设一个关键组成部分未能准时出现。原因何在？未来又该如何预防？”

重要的是，不要受到任何无法验证的观点或假设的影响。先做审计，然后再说事实。

每当出现问题的时候，人们总是倾向于迅速得出结论——而这本身往往便是一种麻烦。

3. 保留原班人马

如果你决定彻底改变项目的方向，可能的确需要招募具有不同技能的人。但如果项目的战略目标不变，则不要动任何人，继续跟他们合作。

这么做似乎有些违反直觉，因为管理层，比如你的上司，“通常看不到一样的人马怎么能够干出不一样的结果。但在大多数情况下，你需要改变的是团队在做什么，而不是团队本身。”

威廉姆斯表示，他见过许多项目陷入困境，因为他们在关键领域的人手不足，或者因为项目经理“高估了一次就能完成的目标。你或许要对项目范围进行更准确的定义，以便按阶段实现项目目标，而不是连爬都不会就想跑。”

4. 经常进行清晰的沟通

作为项目负责人， “你需要保证所有人了解他们正在做的工作和为什么要做，让所有人朝同一个方向努力。”

这一点听起来浅显易懂，然而许多项目失败的常见原因是“出于好心的人过于专注自己那部分工作，他们所做的决定并没有首先与团队其他人沟通，结果导致整个项目受到影响。”尤其是在转变的初期，你可能更需要做一位微观管理者，避免这样的事情发生。

另外一条建议：留神你所采用的技术，不管用的是什么技术。看看这项技术到底是在为项目目标服务，还是产生了相反的效果？

一个项目设计要想成功，必须以策略为核心，然后是人，继而是流程，最后是技术。必须按照这个顺序。将技术放在首位只会让你更快陷入麻烦之中。

目设计要想成功，必须以策略为核心，然后是人，继而是流程，最后是技术。必须按照这个顺序。将技术放在首位只会让你更快陷入麻烦之中。

日丽软件，三个月拯救一个项目，六个月改变一个团队。

上周给大家介绍了对项目经理来说非常重要人际交往技能，这周简单说说项目经理另外几个技能。
技术技能
在管理项目时，项目经理要能够使用不同的技术；在开始管理之前，项目经理还要能够学习不同的技术。
■对于项目中的问题以及如何解决这些问题，项目经理不需要知道二者的具体技术细节，但是如果一点都不了解问题和解决方案的专业知识，项目经理就很难做出好的决策。
■不懂技术的项目经理，不要试图遮掩自己技术上的不足。要敢于承认自己的不足，雇佣聪明的人，而且可以在了解项目的技术点时咨询这些聪明人。如果项目经理能够坦诚表明自己的弱点，并表示出学习的意愿，团队是愿意帮助你成功的。
■理解不同的生命周期模型，知道哪一种最适合你的项目。
■能够安排项目的日程规划。
■能够估算任务，或者指导其他人完成任务估算。
■知道如何评估风险、管理风险。
■清楚如何度量项目状态，以及如何报告项目的状态。
■知道如何处理已完成和未完成的工作，可以使用速度图表或是挣值。如果没有上面这两种度量方式，要能理解软件配置管理系统中的数据和代码的状态。

业务需求技能
软件项目的项目经理要能理解业务需求，要知道如何了解设计是否完成、如何评估技术风险和日程风险，要知道软件配置管理系统的作用以及如何有效使用，还得知道测试人员能够提供什么样的信息。项目经理要能够从不同的工作流程中，帮助项目团队选出最适合当前项目的工作流程。
这并不是说项目经理必须要知道如何完成这些任务，但项目经理应该知道如何组织项目各项工作，促成上述任务的完成。要想知道如何进行这些工作，项目经理要具备一些业务需求和业务解决的专业知识。

专业需求是指理解项目要解决的难题。业务解决是指理解系统如何利用解决方案来解决项目的问题。
项目经理能够快速获得对业务的理解，特别是理解业务相关的需要解决的问题。如果不知道项目要解决什么样的问题，又怎么能知道项目何时算是完成了呢？再说，如果项目经理不了解业务方案，就不能了解技术风险。你可以不了解所有的技术风险，但是如果不了解业务，项目经理甚至不知道问什么样的问题。
注意，这里并没有说项目经理要亲自阅读或是编写代码（或是测试）。成为好的开发人员或是测试人员，虽然有助于你了解软件项目的状况，却并不意味着你一定是好的项目经理。功能性技术是不一样的。当然，项目经理要懂得的技术可以更多，可如果要是知道业务需求太少，那项目经理就很难有效管理项目了。使用专业工具的技能
如果使用黄色即时贴或者小白板来管理日程安排，那么你不需要任何项目管理软件。但是，我推荐还是使用一些专业的项目管理软件，如微软的projects，开源的redmine等。项目经理不一定要精通管理工具，但至少得知道如何让工具符合自己的要求，或是有个助手知道也行。

日丽软件，三个月拯救一个项目，六个月改变一个团队。

出色项目经理技能

——人际交往技能

如何成为一名可以挽狂澜于既倒，扶大厦之将倾，能够拯救濒危项目的资深项目经理呢？考PMP？考高级项目管理师？

错！只有练习、练习、再练习。

不过，要想成为出色的项目经理是有要求的：为了与团队一起工作，你要提升人际交往技能；为了了解和管理项目的风险，还要提升或维护足够的技术能力。

项目经理需要的技能大致可分为如下几类：人际交往技能、功能性技能、业务知识、工具使用知识。

提升人际交往技能

项目经理的人际交往技能，也就是你如何与人打交道，对于项目的成败至关重要。基本上所有的项目经理都需要掌握下面这些人际交往技能。

项目经理75%~90%的时间都是沟通，如果沟通都成问题，那项目就没法进行了。

■ 倾听技能。项目经理要倾听团队成员的言谈，还要从他们那里了解项目的状态。

■ 谈判技能。项目经理要争取资源、交换资源和信息。

■ 写作技能。项目经理要能够编写计划，让每个人都可以理解计划以及做出的妥协。只有一些简单的列表是不够的。

■ 以目标为导向。项目经理要能够完成一个项目，还得帮助大家把注意力都放在项目的目标上。

■ 了解和尊重项目相关的工作人员。项目经理不必成为每个人的朋友，但是必须要能看出别人什么时候陷入困境，什么时候出现了问题，什么时候一切正常运转。

■ 能够应对信息不足的状况，也就是可以适应信息不足的情形，并且做出决策。我还没有见过哪个项目信息是完备的，也存在一定的不明确性。

■ 能够管理细节。即使项目经理不是一个细心的人，也必须学会管理项目的细节。

■ 解决问题的技巧。项目经理要识别出哪些问题当前必须解决，哪些问题可以推迟，以及如何解决问题。

■ 辨别、寻找进度的障碍、并消除它们。

掌握项目的能力。要观察目前的状况，指出项目当前方向与你最初的规划有何不同，并可以引导项目进入新的状态。另外，针对乙方项目经理，还需要下面几点：

■ 与甲方负责人交朋友的能力，这是项目开展的基础。怎么交朋友也是有讲究的。不是说一味的给予物质，或者掏心掏肺整天摸着良心说话。其实，关键一点，就是要从对方的角度去思考问题，同时潜移默化的让对方理解你的难处。

■ 汇报的能力。汇报的目的，向谁汇报，怎么汇报，汇报什么。这几点要想清楚。尤其要考虑，向甲方领导汇报与乙方领导汇报的区别。

■ 与甲方统一认识、确定事项的能力。如果没有这个能力，那么会造成因双方的信息误差，产生步调不一致等问题。

很多刚刚从程序员转行项目经理的朋友，觉得口难开，不知道如何与人沟通。我认识的一位资深项目经理给出的经验是，打车时，主动与出租车师傅聊天，从上车到下车，不停的聊。慢慢的，就不惧怕开口了。

下周我再给大家说说项目经理需要掌握的功能性技能。

日丽软件，三个月拯救一个项目，六个月改变一个团队。

上次的文章，好几个兄弟说我花里胡哨，只贴图，不说人话。通过这件事我发现，看这个公众号的，都是认真看字的好兄弟，那么好，从这周开始，咱们不玩虚的，少贴图，多写字。

今天，我们聊聊烂项目

可能有项目会自辩，作为一个项目本身，老子活的好好的，老子甚至活了好多年，你凭啥说我是烂项目？你说说，你要说说不出个所以然，老子弄死你。
OK，从你这句自白，我就知道，你八九真是个烂项目。项目有个特点，就是有始有终。软件项目，超过1年的，就不小了。你竟然持续了好几年没死，你是研制原子弹，还是载人航天呀？ 今天，我就给大家吹吹常见的烂项目有啥特点。 第一个，也是咱最常见的，只开花不结果。一个老程序员，带着一批小程序员，春夏秋冬，起早贪黑，披星戴月，做得那叫一个辛苦，加班费都发了不少，可老板就是看不到成果。 我见过许多IT公司都是让系统集成部门赚苦力钱，养着软件团队，指望软件长大成人反哺公司，可这孩子就是断不了母乳。

前些年，大部分国企事业单位，比如电信，银行，电力。。。都有软件部，各种项目组，但最终软件部的工程师们，都因为项目难产，一个个从工程师变成了甲方项目经理。最终还是外包靠谱些，做不好，有个顶包背锅的。 第二个，好不容易拉关系中了个标，庆功宴还没凉，甲乙双方已经吵的不可开交。有开始时就吵的，有中途吵的，总之乙方感觉甲方各种难缠，甲方觉得乙方各种不靠谱，甲乙双方互推责任，项目处于奔溃边缘。 第三个，运维单位与客户一起成长，项目1，2，3期持续多年，现在系统越来越不稳定，维护越来越难，升级越来越多，客户关系越来越差，不做吧，这是公司的生命线，做吧，哭，我怎么做啊。

第四个，在老外那边见过，项目一期眼见要失败了，负责人赶快跑。新负责人上台，提出新计划，于是开始二期，二期眼见要失败了，负责人赶快跑。新负责人上台，提出新构想，走上新平台，换个名字，从头再来。。。。。。反正花的不是自己钱。

 烂项目的最大特点，在外人看来，那就是没完没了啊~~~ 

日丽软件，三个月拯救一个项目，六个月改变一个团队。

考PMP就能当项目经理了吗？

答案参考如下：

买了老婆饼就有老婆了

报了MBA就能当老总了

看了成功学就能成功了

如果你认为答案是肯定的

我只能说，幸好你没看这两本书

PMP认证，只能证明你很舍得花钱

毕竟七千块呀

而且善于考试

但是并不能说明

你在管理这些项目时有多么成功。

赵括纸上谈兵的故事，

你懂伐？

这不是说学习PMP认证就毫无价值。

价值在于学习，

并能将其中的知识应用到项目中。

手到擒来

不过一张PMP证书并不能保证

你就有项目经理的能力。

因为现实比想象“有意思”的多

日丽软件——项目拯救专家，

三个月拯救一个项目，六个月改变一个团队

见过项目日程安排游戏吗？
我遇到一些组织，他们有个不成文的规定：绝不讨论项目日程。这种情况我见得太多了。管理层想要一个日期，项目团队就会说：“当然，没问题，就节前吧！”但他们不会明说是哪个节。劳动节、国庆节、春节应该是项目组最怕的三大节了。

最后，当某个节到来之时，已经过了不少日子了，人们开始讨论日程安排。而这时项目已经错过不少里程碑的交付日期，甚至有可能几个早先期望的项目结束日期都已经过去了。
我曾跟这样一个项目团队共事，他们在5年之内没有达成项目日程中任何一个里程碑或其他任何要求。他们总是在反复制定优化项目日程。记得那时有个OA项目，立项时计划是10个月，国庆节出测试版本，然后拖到春节，在后面是劳动节。。。事实上，我5年后离开时，项目还没有发布正式版本。

我必须承认，长久以来，我很难理解人们怎么会陷入到这种日程安排游戏中。不过，我确实见过善于口舌的管理层，他们或威逼，或利诱，或用权力来“说服”项目经理以及团队，让他们相信可以满足管理层对项目日期的要求。这种所谓的“说服力”加上逃避困难话题的文化，足以让项目经理进行项目日程安排游戏，定期给出让所有人“开心”的日期。
有了这个开心的日期，组织中有些人（项目团队或项目经理）就可以让另外一些人（项目干系人，如高层领导或客户）感到心安。从某种意义上来说，大家都不认为日程有讨论的必要。项目团队想抚慰项目干系人，项目干系人也愿意得到安抚。
不要以为项目日程安排游戏只是某些特例，实际上很多项目组都有这个现象。我上半年刚刚拯救成功一个项目，但在我离开后，他们就开始了日程安排游戏。告诉客户，六月份会有一个大的变化，全新的产品。然后是七月。。。现在已经是八月了。。。

要阻止这个游戏的发生，你必须与组织一起在项目层面上工作。要了解你的团队，谨小慎微的进行计划，多考虑风险，不要为了领导或客户的喜好而给出不切实际的日程，最后还是要一步一个脚印的去督促执行。
如果你使用敏捷生命周期，一定要给出经过排序的代办事项列表。假如采取按阶段交付的生命周期，那么尽量使用短小的时间盒，比如以4个小时划分一项任务，这有助于人们不断取得进展，而且要让大家了解这些进展。
不要仅仅以里程碑日期作为项目项目的衡量标准。要想了解项目的真实情况，如果只使用单一的衡量标准无异于饮鸠止渴。可使用速度图表，让每个人都能了解进度。
不过，上述只是项目经理仅凭一己之力所能做到的。这个游戏揭示了组织的不一致性——大家只想彼此安慰，避免冲突。建设性的讨论（又名建设性的冲突）可以让组织更坚强。避免冲突和必要的讨论只会让组织变得更孱弱。

如何判定一个软件项目有没有挽回的可能？

别看这个问句很长，其实答案很简单，看老板的态度。老板支持力度大，自然不在话下。

但如何分辨判定老板的态度呢？这就要观察、分析，甚至于影响了。

下面几种情况，基本上不用分析：

1，这是一个中标项目，涉及公司脸面，必须搞定。

2，这是公司发展的新领域，一把手亲自过问，不在乎钱。

3，这是公司多年的支柱客户，没了这个客户，吃不了兜着走。

类似还有很多，总之就是四个字——不得不做。

还有一些是比较模糊的，特别是老板想做，又怕失败的时候，你如果想拯救这个项目，就要给老板信心，传递信心，制造气氛也是一个技巧活。

或许有人（杠精总是有的）说，不对，如果项目已经一团糟，继续投入还不如重新启动，你继续折腾就是浪费钱。

怎么说呢，其实啊，如果还是这帮人，重启依然是一团糟。当然，你肯定会追问，换一帮人呢？以我的经验，换一帮人更糟糕，新旧两帮人内耗的故事，我不知道见多多少，哈哈。

拯救一个项目，不仅仅是拯救项目，更是拯救一个团队。

日丽软件，三个月拯救一个项目，六个月改变一个团队。

我曾经见过一些项目经理，他们已经996很长时间，甚至8-1-7，疲惫不堪。“除了这个项目，我还顺带管另外几个小项目，进展得都不好。但老大觉得我应该可以管好三个项目。你说说，项目经理最多同时可以管几个项目？”

这个问题应该是没有标准答案的，最好的答案可能就是:“看情况。”

老大吹他同时管理过11个项目

如果你的团队能力超凡脱俗，知道如何协同工作，可以在内部解决问题，能够自己消除障碍，而且在没有项目经理的情况下也可以遵守规范、监督工作、掌控项目，那你就可以在管理这个项目团队的同时，再去管另外一个普通的项目团队，因为你的团队已经很优秀，他们不需要你时时刻刻盯着，你只要在里程碑节点前后关注一下即可。

但问题是，这样优秀的团队能有多少呢？

如果你在项目中要同时处理多个任务，而这种情况下，你还试图管理多个项目，你就得知道自己至少在一个项目上会打马虎眼，甚至可能你在潜意识里面，已经把目标定为让所有的项目都蒙混过关就行了。

成功的项目经理可以一次管理一个项目，想要同时管多个，你可能会把自己搞疯掉，而且基本上不可能成功。