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