项目如期完成是有多难?

简介: 【4月更文挑战第5天】项目如期完成是有多难?

总是看到一些统计说,80 %左右的软件项目是失败的。然后就是有一堆的理由来说明为什么失败。

今天又看到一个数据说 73 %的软件项目是失败的。并且当前正在进行的项目中,有超过 50 %的正在走向失败,而有一些项目已经有了走向失败的趋势。

不管怎么看,软件项目都是有很大的风险的。失败的原因呢,基本上归结为如下几点:

  1. 预算少;
  2. 人员能力差;
  3. 管理有问题;
  4. 沟通有问题;
  5. 计划不精准;
  6. 估算不精准;
  7. 依赖条件导致;

总之,就是人财物配置的不合理。

从我的经验上来看,项目的失败中管理是最重要的原因。(因为项目管理是仁者见仁的,所以应该有很多和我不一样的声音。)
管理是什么?就是计划人财物,然后监控过程、管理风险等,团队气氛也是管理中非常重要的一个环节。

计划

说说计划。计划在项目管理中有着提纲挈领的作用。所以在我的项目中,我都会先做一个计划,计划合理不合理都要先做个计划。
在过程中可以修正,但是切记切记要有“计划”。
因为计划不管是正确的还是错误的,都有标杆的作用。
即便计划是错误的,在实际的任务进度监控中,也可以通过实际的情况,对计划进行修正。
这一观点需要花很长时间才能从习惯的规定起止时间点就叫计划的思维中转变过来。
特别是我们做项目中有些时间点还属于规定死的时间。计划就更重要了。
在一个不太成熟的团队做项目的过程中,我规定了大家必须把任务的计划时间维护出来。
然后项目结束后,我对具体的任务完成时间进行了统计。
并且和计划时间做了比对。结果如下所示。

image.png

从上图就可以看到,计划和实际的任务完成时间,从趋势上来说真是非常完美的匹配了。

而这个项目阶段,也确实按预期的目标完成了。
我觉得是个非常成功的项目。

在这个过程中需要考虑什么呢?

  1. 计划的合理性;
  2. 监控计划的偏差;
  3. 解决偏差和风险;

但是怎么知道偏差呢?那就是靠项目管理的人的经验了。

没经验的项目管理人员大部分都处在救火的状态。
有经验的管理人员是先做好规划、计划、以及预见风险。
把事情做到前面比做到后面代价要小得多。

记得我在一个项目中,项目管理者可以说每天都在处理焦头烂额的救急的事情。本来可以提前预见的风险也没有去处理,最后把整个 项目组的人都拖累得不想再干了。团队气氛当然也好不了。

管理有几个姿态:

  1. 压迫式:对于压抑式的管理方法,团队气氛必须不好,因为大部分人也都是有自己想法的,对这种压迫式的管理方法基本上都是反感的。
  2. 放任式:这种谈不上管理,成败只能取决于团队成员的努力,这种管理者完全可以不要。
  3. 事必亲躬式:这种累死自己的管理方式是不可能管理好团队的,因为团队是需要合作的,而不是你代其他人做事。
  4. 理性式:这是最合理的方式,只是理性需要自身多反省;心智要求较高。

风险

风险的管理非常有艺术性。

  1. 预见风险而规避。应该项目中的风险是肯定会提前暴露出来的,有些管理者就视而不见,直接出问题了再处理。这种管理者是不称职的。
  2. 预见不到风险,无法规避。这种情况的出现非常少。对一个理性的管理者来说,对这类风险会先判断后果,然后决定处理方法。

预见风险之后如何规避?就像在我的一个项目中,大家的研发任务都已经列出来了,但是都没有定时间。各小组长也不说自己能按时完成,也不说完不成。我觉得这就是风险。
但是他们自己不觉得这是风险,反而觉得把计划做出来如果做不到的话,计划就没有存在的意义了。
我说计划为什么一定要做得到呢?计划是个尺子,是用来做偏差分析的,而不是限制条件。
所以我就让他们把任务的计划时间都维护到管理工具中。
就像前面的那张图一样,在做之前,我说了要维护计划中的时间,其实我是觉得肯定计划的时间和实际的有非常大的偏差,结果反而偏差不大。
也就是说团队成员是看着这个计划在做事情的。
但如果没有标杆呢?那怎么才能看到风险并处理呢?只能靠个人的主动性了。

偏差在项目管理中有什么用?

我觉得有了计划中的人、财、物、时之后,在监控项目进度的过程中就可以很清晰地看到偏差,除非管理者自己视而不见。
偏差出现之后就要考虑如何去平衡,有两个方向:

  1. 查找偏差的原因,并处理掉;
  2. 修改计划;

那怎么能看得到偏差呢?拿费用来算吧。如下图所示,如果在计划中维护了任务、人员、费用、时长等信息之后,当任务出现了偏差,就会体现出来。
比如说进度绩效指数SPI。当任务出现偏差的时候,它就会暴露出来。当然进度超前了是好事情,那它就会大于1,并且越大说明越超前;如果进度落后了呢,那就会小于1,越小落后越多。

image.png

有其他的参数可以看到偏差。
当看到这些偏差之后,去查明原因,并规避掉,才有可能让实际的任务进度慢慢回到计划上来。

理性的管理者一定是先做计划,尽量把事情做到前面。而不是等着出问题之后到处救火。那些天天救火的项目管理者,一定是不合格的,纵然很努力很辛苦,也是规划能力不足的体现。
所以对任何一个事情来说,如果可以把各种细分的任务都想清楚的话,计划基本上会和实际的进度一致。只有这样才是直正的管理。

另外,管理者一定要先考虑团队的整体气氛,团队气氛不好是直接影响任务进度的,生产力低下会直接体现到计划中。对这样的团队,先肃清气氛更为重要。

目录
相关文章
WK
|
14天前
|
机器学习/深度学习 人工智能 算法
那C++适合开发哪些项目
C++ 是一种功能强大、应用广泛的编程语言,适合开发多种类型的项目。它在游戏开发、操作系统、嵌入式系统、科学计算、金融、图形图像处理、数据库管理、网络通信、人工智能、虚拟现实、航空航天等领域都有广泛应用。C++ 以其高性能、内存管理和跨平台兼容性等优势,成为众多开发者的选择。
WK
37 1
|
3月前
信不信?工作这么多年,还有很多网工不知道光模块光衰的正常范围?
信不信?工作这么多年,还有很多网工不知道光模块光衰的正常范围?
318 2
|
开发工具 git 开发者
面对躺平同事,我开发了一个插件治好了我的精神内耗⚡⚡⚡
面对躺平同事,我开发了一个插件治好了我的精神内耗⚡⚡⚡
|
监控 前端开发 jenkins
新来个技术总监,给团队引入了这款开发神器,同事直呼哇塞
带团队时间久了,就能发现整个 Team 都渐渐疲了。前两年老板还专门买了个系统搞 OKR,现在也不大提了;Scrum 我们也搞了,用起来也就那样;项目管理工具试了好几个,禅道、Worktile、现在用 Coding,反正有一个能用的就行;微服务化改造从去年开始在吭哧吭哧搞,我们自己搞得觉得很厉害,但业务部门那边就觉得没啥差别,搞不懂你们研发部门每天在弄些什么,赶紧做我们提的需求要紧。
新来个技术总监,给团队引入了这款开发神器,同事直呼哇塞
|
算法 测试技术
|
监控 测试技术 BI
热饭的测开成果盘点第十三期:接口测试平台(一)
本期介绍的是接口测试平台的原型,区别于公众号内直播教程,原型平台的外观更古老但细节很多,可惜后台架构并不如直播版强壮。当时带了3-4位测开新手,边教边做。
热饭的测开成果盘点第十三期:接口测试平台(一)
|
测试技术
热饭的测开成果盘点第十四期:接口测试平台(二)
本期介绍的是接口测试平台的原型,区别于公众号内直播教程,原型平台的外观更古老但细节很多,可惜后台架构并不如直播版强壮。当时带了3-4位测开新手,边教边做。
热饭的测开成果盘点第十四期:接口测试平台(二)
|
存储 运维 Kubernetes
独家交付秘籍之招式拆解(第一回)
上一回说到经历种种交付难题的王小锤一行人,意外发现一本交付秘籍,打开了新世界。本次他们带着具体交付场景来到阿里云,与交付宗师阿莫探讨秘籍中的招式以及招式背后的秘密。
独家交付秘籍之招式拆解(第一回)