原文地址
http://blog.csdn.net/walzer/archive/2007/12/12/1930699.aspx
上个周末我在家里无聊,就陪父亲去逛园博园的教育园区,实际上是陪他去巡视工地。那是他们公司的一个建筑工程项目,元旦才对公众开放,现在正在处于项目收尾阶段。他们公司作为厦门国有十大集团公司之一,我对他们的管理制度和管理方法一向十分崇拜。但在巡视工地时遇到案例,有些事情和软件项目管理上都是异曲同工的,看来项目管理真的没有神话。
一、上级意志介入,需求变更没有经过审核
建筑项目:我们走到了教育园门口,一排三层楼高的房子在拆屋顶的瓦当,全部重新铺,父亲说这是市领导视察后的意见,觉得教育园都是用的黑色瓦片,而外面这排用于学生夏令营的楼却用了红色瓦片,不协调,全部拆了重做,这个修改花费估计在50-60万左右,政府买单。他们应该庆幸市政府领导既是上级,同时也是他们的客户,客户提出变更后得为额外开销买单。
软件项目:软件开发中,客户提出需求变更也是很正常的。但最大问题是我们的客户是代表最终消费者的事业部,按道理需求应该是在市场调查之后定下来的,而实际上很多需求是某些决策者拍脑袋定下来的。我对这种缺乏实际调查的做法十分反感。拍脑袋出来的某些需求增加了项目周期,提高了开发成本和风险,但最终消费者不见得为这些需求和变更买单。
评论:我曾经考虑用技术委员会来仲裁需求变更,审核和限制事业部领导拍脑袋定下的高风险需求和变更活动。但父亲说我这种想法这是不切实际的,最后情况会演变为技术委员会全部附和领导意见。并且存在的致命弱点是,充其量只不过是改领导一个人拍脑袋为你们一群人拍脑袋。所以限制领导意志介入的最好办法是,由更上一级管理者上做出限制,把决策带来的收益或损失与决策者的利益强制挂钩,这才能真正起到约束作用。而作为下级执行者,应该按照领导意志完全照办,而不是自己再拍一次脑袋。另外,在中国式的管理中,领导具有绝对权威,这和项目管理书上看到的理论是不一样的,在实践中照搬理论没法处处行得通。
二、遗漏的设计细节,在工作中临时确定需求细节,没有经过需求审核
建筑项目:在路边的草地上,他们买了一个喷雾机,用来把水雾化后喷出,保持周围植物生长所需的湿度。喷雾机是个一人高的绿色铁皮箱子,放在植物和石头堆中很扎眼。于是父亲叫来工程师,说把这个喷雾机外壳喷上仿石材的材料(这材料有个名词,我搞不懂),然后放到石头堆里就不扎眼了。这属于项目管理者自己临时确定的需求细节。
在另外一块草地上,下水道井盖的高度超过了草地的高度,本来也会比较扎眼的,但工程师说他自己做出决策,搞了些花盆摆到井盖上,把这个问题解决掉了。这属于工程师临时确定的需求细节
软件项目:在软件开发中,如果使用成熟度模型,那么一定是先有了全部细节的设计,才能开始编码;编码时必须严格按照设计来做。而实际情况是,设计时还没有具体接触到问题,所以遗漏一些细节是在所难免的。这时候如果在编码过程中发现了设计疏漏,我们一般懒得再去更改设计文档,而是直接几行代码把问题解决了,甚至是擅自决定了小的需求细节。而这块地方是没有经过审核的。
评论:这种做法是否合理?是否所有细节都必须被纳入设计文档?从软件项目管理以前的案例,和这次建筑项目管理上的案例来看,我认为这是合理的。架构设计和需求设计只需把握住关键部分,至于一些边边角角的细节问题,完全可以让团队成员自由发挥。
三、设计错误,返工
建筑项目:在教育园中心的一个大殿外,内庭地面的高度居然低于排水沟的高度。工人不得不把地面的所有砖全部挖起来,重新填土垫高地面,最后再重新铺砖。此次设计错误导致的额外成本开销,由建筑设计院负主要责任,审核单位负次要责任,施工单位无责任。
软件项目:相比于建筑设计,软件设计中具有更多的未知性和不确定性,设计错误导致返工的例子实在不胜枚举。不过还好我们有快速迭代开发模型可以解决这个问题。如果建筑项目搞类似快速迭代开发和代码重构的做法,那真回赔本赔到死。
评论:看来通过审核来避免设计错误也不是什么神话。建筑项目是非常严谨的瀑布模型,设计->审核->定计划->施工->验收,即使在他们已经很严谨和流程成熟的瀑布模型中,仍然难免出现设计错误导致返工的现象,那软件项目就更不用说了,到处充斥着设计错误,随时需要代码重构。所以我觉得无论项目再赶、周期再短,软件开发走瀑布模型试图一次性完工绝对是不可能的,只有快速迭代开发才是正确出路。
综上,我很遗憾地得出这个结论:项目管理真的没有神话。再严谨的流程之下,也会充斥着临时变更、需求疏漏和设计错误。所以除了在审核阶段应多下工夫减少疏漏和错误之外,同时还应着手提高团队的变更响应速度,在发现疏漏和错误之后,能在尽量短的时间内、以尽量低的成本修复和完善。所以, 审核把关和变更响应,两手抓,两手都要硬。
http://blog.csdn.net/walzer/archive/2007/12/12/1930699.aspx
上个周末我在家里无聊,就陪父亲去逛园博园的教育园区,实际上是陪他去巡视工地。那是他们公司的一个建筑工程项目,元旦才对公众开放,现在正在处于项目收尾阶段。他们公司作为厦门国有十大集团公司之一,我对他们的管理制度和管理方法一向十分崇拜。但在巡视工地时遇到案例,有些事情和软件项目管理上都是异曲同工的,看来项目管理真的没有神话。
一、上级意志介入,需求变更没有经过审核
建筑项目:我们走到了教育园门口,一排三层楼高的房子在拆屋顶的瓦当,全部重新铺,父亲说这是市领导视察后的意见,觉得教育园都是用的黑色瓦片,而外面这排用于学生夏令营的楼却用了红色瓦片,不协调,全部拆了重做,这个修改花费估计在50-60万左右,政府买单。他们应该庆幸市政府领导既是上级,同时也是他们的客户,客户提出变更后得为额外开销买单。
软件项目:软件开发中,客户提出需求变更也是很正常的。但最大问题是我们的客户是代表最终消费者的事业部,按道理需求应该是在市场调查之后定下来的,而实际上很多需求是某些决策者拍脑袋定下来的。我对这种缺乏实际调查的做法十分反感。拍脑袋出来的某些需求增加了项目周期,提高了开发成本和风险,但最终消费者不见得为这些需求和变更买单。
评论:我曾经考虑用技术委员会来仲裁需求变更,审核和限制事业部领导拍脑袋定下的高风险需求和变更活动。但父亲说我这种想法这是不切实际的,最后情况会演变为技术委员会全部附和领导意见。并且存在的致命弱点是,充其量只不过是改领导一个人拍脑袋为你们一群人拍脑袋。所以限制领导意志介入的最好办法是,由更上一级管理者上做出限制,把决策带来的收益或损失与决策者的利益强制挂钩,这才能真正起到约束作用。而作为下级执行者,应该按照领导意志完全照办,而不是自己再拍一次脑袋。另外,在中国式的管理中,领导具有绝对权威,这和项目管理书上看到的理论是不一样的,在实践中照搬理论没法处处行得通。
二、遗漏的设计细节,在工作中临时确定需求细节,没有经过需求审核
建筑项目:在路边的草地上,他们买了一个喷雾机,用来把水雾化后喷出,保持周围植物生长所需的湿度。喷雾机是个一人高的绿色铁皮箱子,放在植物和石头堆中很扎眼。于是父亲叫来工程师,说把这个喷雾机外壳喷上仿石材的材料(这材料有个名词,我搞不懂),然后放到石头堆里就不扎眼了。这属于项目管理者自己临时确定的需求细节。
在另外一块草地上,下水道井盖的高度超过了草地的高度,本来也会比较扎眼的,但工程师说他自己做出决策,搞了些花盆摆到井盖上,把这个问题解决掉了。这属于工程师临时确定的需求细节
软件项目:在软件开发中,如果使用成熟度模型,那么一定是先有了全部细节的设计,才能开始编码;编码时必须严格按照设计来做。而实际情况是,设计时还没有具体接触到问题,所以遗漏一些细节是在所难免的。这时候如果在编码过程中发现了设计疏漏,我们一般懒得再去更改设计文档,而是直接几行代码把问题解决了,甚至是擅自决定了小的需求细节。而这块地方是没有经过审核的。
评论:这种做法是否合理?是否所有细节都必须被纳入设计文档?从软件项目管理以前的案例,和这次建筑项目管理上的案例来看,我认为这是合理的。架构设计和需求设计只需把握住关键部分,至于一些边边角角的细节问题,完全可以让团队成员自由发挥。
三、设计错误,返工
建筑项目:在教育园中心的一个大殿外,内庭地面的高度居然低于排水沟的高度。工人不得不把地面的所有砖全部挖起来,重新填土垫高地面,最后再重新铺砖。此次设计错误导致的额外成本开销,由建筑设计院负主要责任,审核单位负次要责任,施工单位无责任。
软件项目:相比于建筑设计,软件设计中具有更多的未知性和不确定性,设计错误导致返工的例子实在不胜枚举。不过还好我们有快速迭代开发模型可以解决这个问题。如果建筑项目搞类似快速迭代开发和代码重构的做法,那真回赔本赔到死。
评论:看来通过审核来避免设计错误也不是什么神话。建筑项目是非常严谨的瀑布模型,设计->审核->定计划->施工->验收,即使在他们已经很严谨和流程成熟的瀑布模型中,仍然难免出现设计错误导致返工的现象,那软件项目就更不用说了,到处充斥着设计错误,随时需要代码重构。所以我觉得无论项目再赶、周期再短,软件开发走瀑布模型试图一次性完工绝对是不可能的,只有快速迭代开发才是正确出路。
综上,我很遗憾地得出这个结论:项目管理真的没有神话。再严谨的流程之下,也会充斥着临时变更、需求疏漏和设计错误。所以除了在审核阶段应多下工夫减少疏漏和错误之外,同时还应着手提高团队的变更响应速度,在发现疏漏和错误之后,能在尽量短的时间内、以尽量低的成本修复和完善。所以, 审核把关和变更响应,两手抓,两手都要硬。