关于软件构造

    "构造"  听起来是个很响亮的名子,可是没有多少人真正的理解它,它的英文名子是" Build ",  从源码到产品的过程,当你做一个很小的项目时,你感觉到不到 Build 的存在,其实你每隔几分钟都会 Build 一次,可是如果产品很大,由成千上万个模块组成,你就会发现, Build 是个漫长而又极易出错的过程. 如何有效的控制它们呢?

    用友的U8的构造过程,真是让人难以理解, 找一个专门的人手工来处理这些事情,然后不停的制作错误,不停的与人沟通,没有人愿意搭建一个快速有效的工作过程,并且过程改进起来受到太大的阻力, (谈论的关键的问题,就会想到如何逃避责任)
     
     我一开始觉得做一件事情,需要莫大的勇气和决心,可是现在更深刻的体会是:重要的不是勇气和决心,要有持续沟通的动力和持续改进的本领.如果一个想法很好的话,正常情况下实现这个想法需要 2周时间,可是如果想征求同意,至少得 1 个月的时间,并且同意的结果还要把以前的方案改动的很大. 我在想,如果持续这样,年轻人的创造力就会被持续的消减.

   很早之前我就想搭建一个自动编译,自动打包,乃至自动环境创建的系统,这样至少会改变整个U8 的构造过程,几倍的效率提高和有序, 可是似乎没有太多的赞同,公司高层的意思需要稳定,需要质量,可是却不关注于过程改进.而且高层是不理解细节的,所以很多决策过程写在 ppt 上是很完美的,因为 ppt 无法关注到细节. 如果把这些关键的细节问题导致的反馈到高层,并且说服高层采取极大的魄力去解决问题. 我想这一切都会很顺利. 问题的难点在于什么呢?
   创造一种有效的和领导协调的机制, 员工是没有办法创造这种机制的,因为大部分情况下,员工是非常忙的,忙到根本没有时间去想事情的来龙去脉. 可是通常情况下,80%的忙只创造了20%的改进效益. 我们说投入是失败的!!