项目成功和失败的几大因素

 

① 正确的管理方式 项目管理 尽管任何一套管理方式被证明是绝对正确的，但是如果一个项目要真正走向成功的话，他还是需要正确的管理方式。一种管理方法可能会有缺点，不是很完美，但只要它是正确的就可以了。 正确的管理方式应该包括正确的项目目标、合理的开发计划以及合理的责任分派等等。正确的管理方式可以让项目少走很多弯路，它是保证项目走向成功的前提。

② 一套完善的开发框架 开发框架 一套完善的开发框架，可以减少攻城师们的工作量，简化他们工作的难度，对于每个开发周期都很紧张的项目来说，一套完善的开发框架，是项目走向成功的关键因素。

③ IT救火队 IT救火队 不是每个项目都会着火，但只有着火的情况下才能体现出IT救火队的作用。这些IT救火队与普通的救火队不同，即使这个项目暂时不需要他，他也不会闲着，他会待在其他的项目上，随时等待候命。 通常来说，只有项目周期延误或者项目周期缩短的情况下，这些救火队才会出现。此外，由于IT救火队的成本很高，只有一些大公司才有这样的救火队。

④ 技术大拿 技术大拿 一个公司、一个项目总要有那么几个技术大拿，你的项目才得以成功的交付。尽管大多数情况下，技术大拿的态度不怎么好，沟通不是那么顺利，但是他们是解决各种疑难杂症的专家，能够解决他人解决不了的问题，为项目排忧解难。 不是每个项目都有救火队，当项目频繁的发生问题时，救火队也不一定能及时赶到，所以项目要走向成功，技术大拿是必不可少的。

⑤ 和谐的团队 和谐团队 尽管我没有亲历过不和谐的团队导致项目失败的情况，但是我亲耳听到了某项目因为团队不和谐而造成项目失败的情况。后来，这个项目被XXX公司认定为十大最烂的项目之一。 当团队出现不和谐的状况时，应尽早解决。因为不和谐的团队即使不会造成项目失败，也势必会造成项目延期。尽管不和谐的团队很少，但这种情况一旦出现，就是对项目致命的伤害。

 

失败的因素

  ① 糟糕的项目管理--按任务分配，而不是按功能或模块分配（Responsible）

 

 

    原来我觉得这个因素不太重要，但是随着项目拖延的周期越来越长，这个因素所占的比例也越来越大，由原来的10%增大到现在的30%。

 

    按任务分配，而不是按功能或模块分配，会降低团队成员的荣誉感和责任心，团队成员在修复缺陷的时候往往带有抵触心理，甚至出现踢球现象，这势必造成工作效率低下，导致项目延期。

 

    ②糟糕的项目管理--更换团队成员

 

 

    更换团队成员的风险会像上图所示，随着项目开发周期先升高再降低。尽管很多PM都明白这个道理，但实际证明在大多数情况下，PM并非像想象中的那么重视这个风险。这就是所谓的PM比PM2.5更危险。

 

    ③采用加班模式，而非任务模式

 

 

 

    如果白天完成了任务和白天完不成任务都要加班，那么团队一定会把平时放在家中做的事情，拿到公司中来做，比如购物、聊天、看新闻等。这样他们就可以在晚上加班时有事情可以做，然后受到领导的表扬。

 

   ④糟糕的项目管理--恶劣的开发环境

 

 

 

    没有什么比糟糕的开发环境可以降低团队的效率再明显不过的了。恶劣的开发环境包括办公环境是否嘈杂，团队成员是否沟通通畅，网络环境是否通畅，开发环境是否稳定。

 

    在1M/S的速率下工作的员工是无法想象在10K/s的带宽环境下的员工是如何工作的，这个只有亲身体验过后才知道。

 

    ⑤只解决当前的难题，而不是从全局考虑

 

 

 

    你很难想象在前期设计时，不把报表考虑在内，后期对数据统计时会发生什么样的情况。是的，我也想不明白为什么要这么做，但事实上我们确实这么做了，所以现在我们深陷报表的泥潭。

 

    ⑥重要的信息没有在团队内共享

 

 

 

    让团队内的每个成员都了解项目的重要信息，包括项目的开发计划，里程碑，发版情况等。如果这些信息对团队内的成员不共享，那它们就会觉得这些事情对他们无关紧要，也就不会为了一个里程碑或发版计划去加班。

 

    让一个团队高效工作的方式是引导和激励，而不是命令和任务。

 

    ⑦过多的演示

 

 

 

    在项目开发过程中，仅仅为了给领导做演示而去停止当前的开发工作，使用mockup数据来使表单美观。如果一次两次真的没什么，过多的演示势必造成开发的拖延。

 

    如果使用敏捷开发就没上面这种问题了，因为持续交付可以保证系统在任何时候都是可运行的，并拿出来进行演示。