浅析“作坊式”开发（转）

“作坊式”开发虽然只是对软件开发形式的一种比喻的说法，但深究起来却还真是一个不小的话题。在此我粗浅地探讨一下作坊式开发被广泛采用的一些原因，不谈所谓“作坊式的企业”之类大的话题，只就“开发方式”层面上的相关思路理一理，对工程化管理内容也不再赘述。所述之言为个人观点，观者仁者见仁、智者见智。

　　这里讲到“作坊式”，主要是指传统手工作坊的生产模式而言的。所谓作坊式生产模式大同小异，一般情形是：由一个掌握了某种技能的“匠人”，带领几个不需太多技能的“伙计”进行全程生产，匠人的技能是由其师傅“口传心授”的，其他人基本上插不上手。生产过程中由匠人以他的一套“规矩”来安排，不需什么规程、制度，更不需要做什么“计划”、“方案”。匠人在作坊里的“技术权威”使得老板也不敢对其“指手画脚”，否则他会 “撂挑子”，事情成败取决于匠人的能力。在这样的情形下，生产过程基本上是无序的、无约束的，老板作为“管理者”角色的职能几乎谈不到，甚至受匠人的摆布，除非老板是一个非常高明的匠人。

　　果真以作坊式这样的含意来比喻我们的软件公司的开发过程，那我们的软件开发技术骨干们将无不怒发冲冠了，IT业毕竟被称作“高新技术”行业，而拿我们掌握技能的骨干技术人员比作小作坊的“匠人”，这无论无何是一种恶劣的、污辱性的诋毁！但不幸的是，我们大多应用软件的开发过程的确以“作坊式开发”比喻是较为恰当的。

　　公正地说，就以此方式我们还是成就了好多成功的应用开发项目，甚至可以说此法支撑起了软件开发的初期事业。比如，DOS时代国内众多的电脑编程高手开发出了一大批脍炙人口的个人软件产品，如严援朝的CCDOS，王永民的五笔字型，吴晓军的2．13，朱崇君的CCED，以及求伯君的WPS等等。DOS时期是个人英雄主义的时代，一个人就可以叱咤风云。

　　如果你承认我们几千年民族手工业正是由作坊里的匠人们支撑的，那作为刚刚有二三十年历史的应用软件开发业，沿袭了我们的民族传统，应该说不是什么丢人的事。同样，我们继承了DOS时代先辈们的一些生产模式，似乎也无可厚非。

　　但是，在我们的“作坊”里还是有了太多的项目失败，这种失败或者表现为无法实现的不可为、或者表现为开发周期的不可控制、或者表现为项目结果为用户所不认可、或者表现为项目最终的严重亏损，这种失败的惨痛出乎我们的意料，以至于我们无所是从。再加上技术人员、资金严重匮乏的困扰，软件开发管理举步维艰。

　　作坊式的软件企业中，很多东西都是装在开发人员的脑子里面的，往往会因为一两个开发骨干走了，就造成整个公司的瘫痪。赌注完全押在这一两个人的身上，资本投入风险很大，如果研发骨干一个人另谋高就，公司投资等就将全部付之流水，作坊式的运作模式严重阻障了软件企业的成长。

　　软件开发本身确实是一项复杂、艰苦而又充满着风险的工作，唯其如此，几十年来中外软件开发业的专家和学者们在大量的失败项目中总结着失败的经验和教训，陆续创立了相关的学说并应用于指导软件开发的实践，取得了一定的成果。在项目开发过程上借鉴一般工程过程建立了软件开发的“工程化理论”，在开发方法上总结有结构化分析方法、组件式开发、净室开发以及目前较为推崇的面向对象的分析开发方法等等，在软件开发质量管理上有CMM、ISO等一些成熟的体系。这些规范化理论和方法在不断的改进发展中日趋成熟和完善，并对软件开发过程的工程化管理和规范化实施起到了革命性的指导作用。

　　事实上，但凡专业的软件开发人员在大学里就学过《软件工程》这门课，所有上面提到的一些理论知识都全面涉及，在此就不讲其具体内容了。纵观这些指导性的理论以及我们所采用的开发方式，我们说，作坊式开发对小型应用软件开发项目是有一定的用武之地，在一定程度是不违背快速开发理论的；但对于稍成规模的小型软件（更不用说中、大型的软件）项目的开发过程，那就必须遵从于工程化理论的原则和方法，落实规范化的管理，否则失败的风险将伴随着整个开发过程，而且越到后期失败的可能性会越大，一旦失败，其经济损失也就会非常巨大。
那么，既然有这样的工程化理论，为什么往往不为我们所广泛忠实地采用和贯彻呢？这是问题的症结所在，值得探究！归结起来，主要有以下一些原因：

　　首先，市场对软件工程化开发的意义理解不够，没有形成广泛的支持。

　　“应用软件系统”本身的内含都包括哪些？对于用户来说往往只局限于“在计算机上运行的程序”这样一个肤浅的理解，不知道还应有计划、调研分析、方案、设计、质量监督、测试、培训、系统说明文档等等的内容；对于“程序是做什么的？应达到怎样一个目标？”这样一些问题一般没有从主观上得到重视，更难谈到从根本上把握。

　　之所以如此，就如同在规范化工程理论发展成熟的今天，我们仍以作坊式开发模式进行生产一样，信息化建设到了一个如火如荼的时期，而大多用户对其本质方面的认识还仅仅停留在“机器代替手工”这样的理解上，他们对软件产品应该具有的性能、适应性、安全性几乎一无所知，甚至对一个自己所需要的应用系统的功能范围都不是能够很好地定义。这样，用户是很少会对开发企业提出实质性生产要求的。

　　用户方往往将期望寄托于他们选定的开发企业，认为一切难题都会由开发方很好地解决。在这种情形下，他们不会想到软件开发的失败可能（认为是开发方的事），当然也就不会去了解会导致开发失败的风险因素，也就不会提倡以工程化的规范方法来约束过程了。孰不知，他们那“崇高的信任”很容易地被开发方强+奸了，许多的用户方在项目进行相当时间后才发现一些问题，在项目将完成时或试用阶段才与开发方发生争端，但最终认输的往往是用户，因为一个相对的软件外行与“内行”的开发方对峙，显然只能在大量的“事实”面前承认是自己的失误导致功能的不完整、项目的延期……。

　　这样“无知的”用户群广泛存在，是“作坊式开发”赖以生存的沃土，培育了“作坊”的勃勃生机。既然用户要的是包括其规划功能的、可以“跑得通”的应用程序，何必当什么工程来费时费力地劳作，敲出来不就得了！有那功夫还不如找些理由应对用户的“挑剔”。

　　软件企业在没有形成规范化管理体系时，不可能建立起“全面为客户信息化建设服务”的意识，企业没有能力将工程化过程要求提到应用实施规划内容当中，从这一层意义上说，其实是作坊式软件企业自己断送了自己的前程。

　　用户对应用软件以及开发过程的不理解，造成其对软件产品成本和开发周期的过低估计，从而使软件企业无力投入更多的人力和资金健全开发组织管理、规范整个工程过程。

　　第二，规范化管理理论不被软件开发企业管理者所重视、风险意识淡漠，人员组织和资金投入不够。
　　所谓规范化管理，是依据工程化理论，对项目实施的过程进行科学的、有条理的管理，这得有一整套的操作规范和监督机制。对于有一定规模的软件企业，得有一整套技术管理体系，包括得力的管理机构、人员配备和完善的管理制度，管理体系中应严格制定生产过程的步骤、监管方法，必须有专人监督制度的有效实施；要有一个确定的发展方向，制定企业的远景规划；根据需要，建立一支具有各技术层次、各技术方向的技术队伍；在整体上要形成一种团结、向上的具有凝聚力的企业文化。特别是对于软件开发过程，一定要坚决地贯彻落实前人总结形成的工程化管理理论和方法，这决定着一个软件企业的命运。

　　软件业是一个高投入，高回报，高风险的成长性极强的行业。在想获得高回报之前，首先应考虑如何规避风险、如何使自身得到成长和壮大。风险是伴随着应用系统开发的整个过程的，一旦风险失控，其结果对软件企业往往是致命的。作坊式的软件企业在小的应用软件的作坊式开发中尝到了些甘甜头，而对潜在的风险危机缺乏认识，为自己的“成型的”开发模式而沾沾自喜，这种模式实际上使企业的效率不能提高、市场适应能力低、企业内部危机四伏。可惜的是，软件企业的决策者们往往看不到这一点，短期利益的轻易获得导致最终的企业倒闭，这是领导者的失败。

　　按照工程化理论和规范化管理要求，企业须要投入更多的人力、财力于：客户关系管理、分析设计结果审查、流程化的过程管理、质量管理等等，而远非代码实现的人力支持。与作坊式开发模式相比，企业的管理者们首先想到的是投入太多，却看不到作坊式开发风险造成的亏损危机，反而不会积极支持以提高开发效率和系统可靠性的工程化开发；在没有必要的人力保障和过程指导的情况下，项目组规范化开发的尝试是弱不禁风的、没有结果的。在这种情形下，不可能有积极的实践活动，不可能建立起一个健全的机制来支持工程化规范开发的进行。

　　事实上，理论并不精确地指导实践，对于工程化管理和规范化开发，尽管可以罗列许多所需的管理机构和过程任务，但规范化管理本质上并不是要求具体“人”的行为，并不一定要求人力规模，而是要求建立一个机制、体系，严格工程的过程管理，所以，如果我们的管理者做一些“职能转变”、实施者多一份过程、质量管理意识，已是大的飞跃。理论是死的，人是活的，数以千计的软件企业的兴衰证明了管理的重要性，而软件企业管理的根本是软件工程化管理和技术管理。
   
   第三，软件开发技术人员对工程化理论的实践有抵触心理，认为增加了劳动量。

　　一些软件企业在项目完成后给用户进行培训讲课时，往往会以“用户文档滞后”来解释“产品说明、用户手册”之类文档的不健全。这似乎没有什么不妥，但如果将项目叫做“工程”的话，就可将其与建筑工程相比较，那我们也就可以说：大楼有了，图纸滞后。这是很可笑的。

　　作坊式开发过程中的技术负责人员一般是个“英雄”，应用系统的“设计”是在其脑子里完成的，在其意识里工作结果就只是一堆可执行的程序，既然能直接敲得出来，自然没必要再做写文档的“重复工作”。

　　这样做的结果是，由于设计思路和实现细节在项目组内的交流困难，大部分的系统开发过程由于大量尝试性、重复性工作而变得缓慢，后期调试会出现许多意想不到的大大小小的问题，狼烟四起之时大多数技术人员特别是技术负责人主要工作是“救火”。这样的项目，工程延期往往是普遍现象，“火势太大”情况下的人力再投入常常被“情非得己”地采用，工程越大越是如此。软件开发的特殊性决定了其工程效率与编程人员的数量并不成正比，没有过程文档支持下的项目到了后期，人员的投入反而有可能使工程进度减慢。工程进度失控将直接导致项目亏损，这是显而易见的。

　　所以也就不难理解，在作坊式的软件企业里，会“救火”的技术人员为企业所推崇和依赖，他就是掌握企业命运的英雄。可想而知，如果这样一个英雄半途离开，那没有任何文档支持的项目的中间结果对其他人来说基本上就是“一堆垃圾”而已，也就是说，企业前期投入的资金只是造了“一堆垃圾”。这时候，主管的脸色才真会不好看了。

　　先设计后施工。大楼在未动工时就在图纸上进行，可能发生的修改都在图纸上实现，可能造成的不利状况在图纸上被杜绝，在没有一砖一瓦的损失下做到各方面的满意。工程本身就是大家参预的，是共同智慧的结晶。这就叫工程！

　　如果有人告诉你：“有个国际飞机制造公司没有下属的飞机制造厂”，你信吗？如果相信，那你可能对“软件工程”有一些理解了。如果你不相信，那我说：建筑设计院无需组建自己的建筑公司，你同意吗？如果整个环境支持，我们何不只保留一个“设计院”来轻松攫取高端巨额利润呢？

　　软件企业在若干项目过程中逐步形成了自己的过程模式，其极致就是形成一种流水线式的规范模式，但如果流水线的某个环节存在问题，那开发新产品的过程会一样重蹈覆辙。正因如此，目前被大力提倡的CMM正是指导我们解决这类问题的。

　　第四，技术人员没有实现分层，对工程化开发不能很好支持

　　在一些软件企业里，技术人员疲于奔命，似乎有做不完的工作、有学不完的知识，但有一天他却失落地喟叹：没学到什么技术啊！多年前就讲知识爆炸，而IT实际上才是天天在知识爆炸，新技术，新工具层出不穷，一个比一个复杂，一个比一个玄妙。一个人能有多少精力、多少时间去应付这种爆炸过来的知识呢？

　　作坊式开发的实现，要求主要的项目实施人员得从各个方面来说都得是非常出色的，不仅要全面地掌握系统架构知识、具有业务分析和系统设计能力，而且还得是多种流行开发工具的专家、数据库的专家、网络配置的专家等等等等，这对于一个人来说是不大可能的，在这里，“英雄”的塑造之难可见一斑。所以也就不难理解我们都将程序员称作“Programmer”，而绝对不能学印度人叫做什么“Coder”。作坊模式下不切实际的实际技术需求就为工程的失败埋下了伏笔。

　　事实上，软件业在逐步趋向规范化之路的今天，软件企业内部逐步对技术进行细分，自然地对技术人员也就从所（需）掌握知识上进行划分，这就保证了技术人才的专业化和技术队伍的专业化。

　　从企业管理和工程技术角度来讲，整个软件企业的技术结构可以大体上分为四层，即技术方向决策层、技术研究组织层、项目管理实施层和程序代码编制层。

　　技术方向决策层是对于公司市场方向、产品方向和技术方向进行定位，以及组织技术队伍、规划实施策略等的一类宏观综合技术层。

　　技术研究组织层是对于项目工程进行规模确定、计划制订、方案设计、技术难点攻关和技术力量配置等的项目综合支持技术层。

　　项目管理实施层是对工程项目按计划按方案进行实施和过程管理的综合实施技术层。

　　程序代码编制层是指功能程序代码编制技术层。

　　系统分析员、需求分析师、高级程序员、程序员等，在对其知识、经验和能力的要求上从高到低，在项目中担当相应的角色、完成相应的任务。在具体项目实施中相应人员的工作内容和担当角色，依据项目规模大小和现有人员配置情况，可以逐级拔高使用，这也是人才培养所必须的。这里强调技术结构分层和技术人员划分，更多的是技术责任的明细，而非具体个人的技术定位，将技术任务和相应的责任划分到具体的岗位、将岗位落实到具体的人，这与具体技术人员身兼数职是不矛盾的。

　　对于高级程序员、程序员等人员，从技术方向、开发工具的分类上根据具体需要进行进一步的细分，这样会更趋合理和可靠。企业须有计划地进行技术队伍构建和人才吸收、培养工作，在规范化工程管理模式下这种工作才有实施的可能。

　　第五，软件高端人才真实含意被曲解，规范化管理人才的普遍缺乏直接阻碍工程的规范化实施
　　从大环境上来讲，制约软件业发展的瓶颈很多：资金不足，人才匮乏，没有核心技术等等。单从人才角度做个比较：在印度，软件企业约有1000家，拥有28万软件工程师，平均每个企业280人；然而中国仅仅有大约15万软件开发人员，分布在5000多家软件企业，绝大多数企业员工在50人以下。由此，专家们认为：在世界软件业进入工业化生产的今天，中国却依然在进行小作坊式生产。

　　专家们一方面唉叹资金不足，一方面埋怨人力的分散，但面对应用软件需求市场操作的不规范和经济规模的萎缩，软件企业如果盲目地扩充规模，将背起沉重的负担，这无异于自掘坟墓。软件开发方式并非由人力规模一方面因素决定，工业革命来自生产技术的变革，而非人力的巨增，工业化大生产是流水线操作，而非人海战术。软件开发方式的变革同样的关键在于技术的变革，这种技术并非所谓的“核心技术”，而是指导工程化过程和管理规范化生产的技术。

　　规范的工程化开发方式没有被软件业广泛采用，除了前面所讲的一些原因外，最主要的还是掌握规范化管理技术的高端人才的缺乏！

　　作坊式开发的软件企业里，一提到人才，马上想到的是会用什么工具、用过什么系统平台、掌握的“技术”是不是“主流”？最主要的看是不是“全才”、能不能“救火”？而讲到技术管理人才的时候，就看是不是能以其技术“镇住”麾下的技术人员了，所以往往在找不到这样的技术能人时，只好拿不沾边的高学历来吓唬人。这样的企业的管理者很少会想到人才对开发方式的理解、认识以及相应的生产实践经历。

　　对落后生产方式的坚持，决定了规范化生产的不被认可；对规范化管理的淡漠，抑制了相应人才的成长，甚至扼杀了其生命。在这样一种恶性循环状态下，高端的技术管理人才严重匮乏也就是自然的了。

　　在软件开发企业里，高端技术管理人才的职责是什么？我们大可以列出许多许多，但在国外软件业资深专家的著作里只是一句话：以最小代价为公司赢得最大收益。奇怪，这不是总经理的职责吗？但试想想，如果一个总经理360天围着一帮程序员，琢磨他们为什么要用一年的时间才做完了本应三个月完成的工作，他能搞明白吗？他能忙得过来吗？

　　作为一个企业，说穿了，其根本目的还就是两个字――盈利，企业做什么行业只是一种盈利手段而已。既然要做软件开发这个有其自身特殊性的行业，就得遵从其运营的基本规律和本质要求，采用相应的科学的生产方式和管理方法。

　　软件企业在谋求发展的同时也要考虑如何生存，面对软件业生存竞争和风险危机，软件企业的管理者需要有足够的规范意识和创新精神。