在IT领域从业六年中，大大小小的项目已担负了十几个。从项目行业上看，复杂的有大型ERP系统、银行贷款系统，相对简单的有OA系统、人力资源系统。从性质上看，既有解决实际需求的应用系统，也有属于技术攻关的科研项目。从这些项目的开发、治理中，有很多的感想，我认为是非常宝贵的经验。比如如何看待设计与编程，如何用好非凡程序员等问题。在项目治理上采取的方式是否是正确的、最佳的，项目开发成本有几倍、几十倍的差别。
在一个系统的开发过程中，作为项目治理者，经常要碰到一个要仔细衡量又极难把握的问题：设计与编程究竟各要花多少比例的时间？碰到这样的问题有时是由于项目组的成员水平参差不齐，有很多程序员只能开发简单的定义明确的程序，而不能就一个问题进行解答性的设计，这使得项目治理者经常考虑安排专门的人来进行设计；有时是由于项目治理者主观就认为设计与编程是相互独立的工作，理应该分配不同的人来承担。做设计的认为设计工作要占60%以上的工作量，是主要工作，做编程的认为编程工作要占80%以上的工作量，才是真正主要的工作。到底怎样的比例才是公平的呢？我们很难作出回答。
软件生存期在大部分项目中可以概括为如图的形式：
毫无疑问，开发过程的成本是项目的核心成本，其成功与否实际就代表了项目的成功与否。开发过程中最主要的工作就是设计与编程。
怎样确定设计与编程的工作量
确定的可衡量的工作量是文字，设计成果是通过文档表示的，程序是由代码组成的，两者的共同点就是由文字来表示成果。一个系统，设计文挡比如是10万字，编写的程序代码是90万字（不包含通过开发工具生成的代码），则可明确衡量的工作量之比是1：9。肯定有很多人口头上反对这种衡量方式，认为这是机械的、呆板的。假如只计算最终通过确认的设计文档、通过测试验收的程序代码，会发现这种方式经常是最客观地反映了项目组各成员的工作业绩。
做设计要思考，做编程同样需要思考，而且还要反复调试，可以说写同样多的文字，编程需要的时间决不比设计需要的时间少。公司招聘设计人员与招聘编程人员花的代价是不相同的，作为设计人员自然要求具有设计的水平和能力，作为编程人员同样要求具有编程的技术和能力。所以两者不能说自己的工作性质不同，写同样的文字需要的时间不同。否则，企业就太亏了。
从经验看来，在一个项目中，假如设计与编程人员都努力工作，没有松懈的时间的话，设计人员与编程人员的比例大概为1：5，设计人员与编程人员的个人工资比例大概是3：1，项目中工作时间之比大概是1：5。可计算设计与编程的时间成本之比为：
1*3*1：5*1*5=3：25约为1：8的比例
这个比例应该是比较公平符合实际的。而很多企业的软件项目盲目夸大设计工作的比重，如人员比例安排为1：3，工资比例为3：1，工作时间比例为2：1，两者最终成本之比为：
1*3*2：3*1*1=6：3=2：1
这就体现了不少人认为的设计占绝大比重的观点。而实际上，按这种比例带来的结果是，设计人员轻松得要命，但表现出来也很累，因为他们要不断地催编程人员的进度、等编程人员的结果。而编程人员却累得要命，拼命加班加点，还是很难应付过来，并且到头来还老挨设计人员的教训。
设计所需的工作时间实际是很少的，因为它主要在于设计者的经验、文字表述，而不需要调试。一个大型的ERP项目，假如设计者得其人，一人即够，而编程却需要上百人--真正的花时间的工作是编程与调试。为什么一些企业有那么多IT失败的项目，一个原因就是他们盲目的看重了设计的比重，在设计上投入了总预算的60%以上的成本，结果发现真正的主体工作是编程，到那时才发现剩下的预算成本已远远不够。 边设计边编程是提高效率的捷径
在设计与编程上，用得上一句老话：说一千句，不如做一件。实际上设计与编程是很难分开独立进行的，首先光做设计而不及早进入编程，项目极可能流产。边设计边编程，甚至以编程催动设计，是使项目成功的捷径。
因为只有编程了，才真正明白哪些内容需要设计，哪些是简单的。实际中我们也经常发现，花了好几天工夫设计了一个方案，结果编程者根本不需要理会你的设计，他只要几分钟时间就做好了。
在一个大型信息系统中，项目经理安排了三个人花了四天时间做一个客户可定制的菜单系统的设计，同时安排一个程序员钻研相关编程上的实现方法，四天后，设计人员拿出了设计，但总还感到不放心，当他们去和程序员交流时，发现程序员已经把菜单系统做好了，实际的功能还超过了他们的设计，这让三名设计者无地自容。假如项目经理据此认为编程工作简单，那必定又大错特错。设计，需要与当时的技术，程序员的水平与经验结合考虑，大部分情况下需要在编程中摸索，才能决定究竟是否需要独立设计，究竟有多少工作量。
这样说，并不是说设计就不值得一做了，设计仍然是相当重要的，非凡对于延续性的开发项目。但我们要看到，有时候，效率、速度是高于一切的，而且，在我们的IT队伍中，有不少程序高手，他们的确能制造奇迹。
一个朋友告诉我，当他在学校的时候，有一个机会参加了国家重点实验室计算机语音合成技术的研究。在他加入该课题时，课题组已有不少人研究超过一年以上，其中有博士和硕士。他们将设计看得很重，哪怕是汉字音节的录音，都几经计划，并录了好多次。在给他分配任务时，根本没认为他可以为研究项目提供什么帮助，只是泛泛的要他看看书、尝试做一些小程序。设计固然非常重要，但过分强调，就成了研究人员，非凡是“主要设计人员”状态松懈的借口，他们可以一周两周漫无边际地翻阅书籍，可以一月两月就某个“重要问题”进行“深入地、细致地”探讨。我们不能指责他们探讨交流不应该，但在那方面花费太多的时间已使得工作效率极其低下，课题进展非常缓慢。朋友参与课题研究后，没有象他们那样先设计然后再编程，而是一开始就编程，有任何一点想法就立即通过程序实现。因为有了想法后假如不实现，就不会有进一步的思考，而实现了则可以非常明确的对前一想法进行修正或进一步往前思考。在研究开发过程中，他也很少与同组人员进行讨论，因为一个明显的理由告诉他，对于不太复杂的问题，有讨论的十分之一时间，自己也能通过程序试验出来了。结果，他只花了三个月时间，就将语音合成的主要技术问题如音节/音素合成、词组处理、多音字处理、语音数据压缩、句式处理都解决了，并开发出了一个简单的但具备完整功能的语音合成程序。这在其他人看来是不可思议的。
另一个例子是，一个对自动控制完全外行的IT工程师，参与一个大型的自动控制项目。该项目属于国家重点工程。在那位工程师加入项目组时，该项目已开始半年多了，项目组原成员都是名牌学校自动控制专业的，都是硕士以上的学历。他们按部就班，安排了先分析后设计再开发的步骤。分析是一种比较虚或笼统的东西，哪怕在一个月的计划中已花掉二十九天没有成效也能在最后一天拼凑出一份分析说明书交差。设计就需要一定实力了。两个月的计划时间过去了，设计没有出来；再增加两个月，设计仍然没有出来；又拖了一个月，设计仍然没有解决根本的问题，项目组处于失望的状态，成员都已灰心丧气，这期间编程人员也随着浪费了大量的时间。那位工程师进入后，先预备花两周时间学习自动控制方面的知识和PLC的编程。第三周开始看需求。他是一边看一边编一些小程序来尝试的，结果就在第四面拿出了一份完整的设计方案，并在随后的两个月里全部实现了系统。他并非神奇，而是主要得力于他的编程经验和对程序控制方面的深入钻研。对于编程并不精通的人，假如让他们做设计，既是对程序员的欺侮，也是对公司资源不负责任的浪费。
优秀的设计者来自优秀的程序员
一个真正的设计者是从出色的程序员中产生的，一个好的项目经理也是从优秀的程序员中产生的。
认为只要学历高、名气大就可以招来做项目设计或项目治理的想法，大部分情况下都会导致失败。--除非公司的钱多到没处花，或者公司需要花哨的包装，才可以那样做。
一位已到日本做了四年IT的朋友告诉我，他所在的公司接到了一个保险公司的大单，约有两千万美元。他们的软件开发过程是非常正规的、工程化的，软件的分析、设计已做好，所花的成本约为五百万美元，公司计划开发工作交给中国的企业做，预算为三百万美元。项目的总时间约三年。他告诉我，他们公司很多项目确实都是这样做的；但他也告诉我，那样的项目假如是他原来在国内的企业接下来做的话，总的开发成本（包括分析、设计、开发）不会超过一百万人民币，总的项目时间不会超过一年。他们分析设计花的成本大，是因为里面做的“文章”太多了，在中国的IT企业中，那些工作几乎会全部被省略或者压缩到开发工作中。我们不要批评某些国内的IT企业开发过程不规范，要知道中国的IT技术曾经落后于国外发达国家几十年，我们要赶上去，就不能采用国外常规的方法，不能和他们一样的效率，我们要以他们几倍、几十倍效率的方法赶上去。正是我们国内一些IT企业，非凡是一些中小企业采用了高效率的做法，才使我们与世界的差距迅速缩小。
我们需要高效率，IT需要高效率，这是没有错的，只要在我们追求高效率的时候，保证了软件质量。 程序精英对项目成败至关重要
在我治理的一个银行项目中，很明显的显示了程序精英对项目的非凡作用。
XX银行为了提高新时代下的竞争力，要开发一套整合了各种贷款业务的贷款治理系统，因为系统的复杂性，他们先请国外公司做分析设计，花了大量的时间，花了一千万美元，得到了一份厚厚的系统需求与设计说明书，但那家国外公司不肯再做开发工作，该银行在国内找了好久也找不到愿意承担该项目开发任务的公司。他们最后放弃了该设计方案，重新在国内寻找项目的设计与开发者，预备先做一个简单系统，然后步步演进，逐步达到期望的目标。最后确定由我所在的公司承担该项目，项目总金额只有不到二百万人民币。接手项目后，我组建了一个只有四个程序员组成的项目组，但四人中有两个是很优秀的程序员。从分析，到概要设计，我担当了，花了两周时间。在客户的参与下，我让四个程序员各自独立地担当模块任务，包括具体设计、编程、测试及与客户的交流。结果，项目的进展相当快，两个优秀的程序员，他们虽然一开始没写什么设计文档，但他们与客户直接进行交流，充分地理解了客户的意图，他们几乎天天都能提交一个模块。只花了四个月的时间，基本系统出来了，又花了三个月的时间，系统在该银行的一个试点分行全面启用了。可从一些数字来看系统的开发成果：
数据库存储过程--1253个
操作界面数--1303个
报表数--320个
逻辑功能项数--278个
客户的反应是：没想到有这样的速度，也没想到系统能做到这种深度--已经达到了我们的最终期望。他们认为系统基本上已经一步到位，原来花一千万美元还只买了个设计，现在只花了不到两百万人民币，连设计带系统全部出来了。这种效率和成本是无法比拟的。
项目之所以能获得如此成功，非常要害的因素是项目组有两个非常优秀的程序员，而且充分发挥了他们的潜力。在七个月的工作中，他们几乎没有休过假，日以继夜是常事；他们虽然以前没做过银行系统，但他们对银行系统有很强烈的爱好，把成功和超越当作对他们聪明的挑战；他们实际承担了项目总开发工作量的80%多。他们是当之无愧的软件精英。
在一个新技术的起步和初始发展阶段，精英人才起着决定性的作用；在一个高难度高复杂的项目中，精英程序员同样起着决定性的作用；即使在大众化的阶段，精英也在各种场合下起着至关重要的作用。在当前我们的IT产业仍处于追赶状态的时代，我们需要精英人才。在IT行业，我们已经有了一批精英人才。在企业中，在项目开发过程中，重视精英，采取方式让精英人才充分发挥作用，效率可以成几十倍、几百倍的提高。
在这个银行系统的开发中，我并没有要求程序员一定要先拿出具体设计然后才能动手开发。因为设计工作已蕴涵在他们的编程思考中，也许设计方案在他们的头脑中会变化五次五十次，他们通过编程测试可以在几分钟几小时内确定可行的和最佳的方案。而一定要他们先写出来的话，写出一次变化的方案恐怕就得要一两天的时间，这又怎么能保证高效率、高进度呢。
一种好的项目人员组织方式是：确定项目组的相对精英，让他们作为主程序员，设计、开发一手负责，水平相对较低的程序员机动调配或划拨给主程序员安排。不要安排独立的设计者，只设计不开发的设计者最终会发现那是浪费（他们在项目过程中同样会让治理者觉得他们是很努力甚至很累的和不可缺少的，而实际上他们的工作对项目进展情况在大多数情况下是可有可无的）。
这样的组织并非表达一种设计没有必要的观点。只是表达设计工作的大部分是与编程交织在一起的，虽然词语上我们将软件开发过程划分为：设计、编程、测试，但实际的人员组织上并不需要明确地进行对应。
