“作坊式”开发虽然只是对软件开发形式的一种比喻的说法，但深究起来却还真是一个不小的话题。在此我粗浅地探讨一下作坊式开发被广泛采用的一些原因，不谈所谓“作坊式的企业”之类大的话题，只就“开发方式”层面上的相关思路理一理，对工程化管理内容也不再赘述。所述之言为个人观点，观者仁者见仁、智者见智。
这里讲到“作坊式”，主要是指传统手工作坊的生产模式而言的。所谓作坊式生产模式大同小异，一般情形是：由一个掌握了某种技能的“匠人”，带领几个不需太多技能的“伙计”进行全程生产，匠人的技能是由其师傅“口传心授”的，其他人基本上插不上手。生产过程中由匠人以他的一套“规矩”来安排，不需什么规程、制度，更不需要做什么“计划”、“方案”。匠人在作坊里的“技术权威”使得老板也不敢对其“指手画脚”，否则他会 “撂挑子”，事情成败取决于匠人的能力。在这样的情形下，生产过程基本上是无序的、无约束的，老板作为“管理者”角色的职能几乎谈不到，甚至受匠人的摆布，除非老板是一个非常高明的匠人。
果真以作坊式这样的含意来比喻我们的软件公司的开发过程，那我们的软件开发技术骨干们将无不怒发冲冠了，IT业毕竟被称作“高新技术”行业，而拿我们掌握技能的骨干技术人员比作小作坊的“匠人”，这无论无何是一种恶劣的、污辱性的诋毁！但不幸的是，我们大多应用软件的开发过程的确以“作坊式开发”比喻是较为恰当的。
公正地说，就以此方式我们还是成就了好多成功的应用开发项目，甚至可以说此法支撑起了软件开发的初期事业。比如，DOS时代国内众多的电脑编程高手开发出了一大批脍炙人口的个人软件产品，如严援朝的CCDOS，王永民的五笔字型，吴晓军的2．13，朱崇君的CCED，以及求伯君的WPS等等。DOS时期是个人英雄主义的时代，一个人就可以叱咤风云。
如果你承认我们几千年民族手工业正是由作坊里的匠人们支撑的，那作为刚刚有二三十年历史的应用软件开发业，沿袭了我们的民族传统，应该说不是什么丢人的事。同样，我们继承了DOS时代先辈们的一些生产模式，似乎也无可厚非。
但是，在我们的“作坊”里还是有了太多的项目失败，这种失败或者表现为无法实现的不可为、或者表现为开发周期的不可控制、或者表现为项目结果为用户所不认可、或者表现为项目最终的严重亏损，这种失败的惨痛出乎我们的意料，以至于我们无所是从。再加上技术人员、资金严重匮乏的困扰，软件开发管理举步维艰。
作坊式的软件企业中，很多东西都是装在开发人员的脑子里面的，往往会因为一两个开发骨干走了，就造成整个公司的瘫痪。赌注完全押在这一两个人的身上，资本投入风险很大，如果研发骨干一个人另谋高就，公司投资等就将全部付之流水，作坊式的运作模式严重阻障了软件企业的成长。
软件开发本身确实是一项复杂、艰苦而又充满着风险的工作，唯其如此，几十年来中外软件开发业的专家和学者们在大量的失败项目中总结着失败的经验和教训，陆续创立了相关的学说并应用于指导软件开发的实践，取得了一定的成果。在项目开发过程上借鉴一般工程过程建立了软件开发的“工程化理论”，在开发方法上总结有结构化分析方法、组件式开发、净室开发以及目前较为推崇的面向对象的分析开发方法等等，在软件开发质量管理上有CMM、ISO等一些成熟的体系。这些规范化理论和方法在不断的改进发展中日趋成熟和完善，并对软件开发过程的工程化管理和规范化实施起到了革命性的指导作用。
事实上，但凡专业的软件开发人员在大学里就学过《软件工程》这门课，所有上面提到的一些理论知识都全面涉及，在此就不讲其具体内容了。纵观这些指导性的理论以及我们所采用的开发方式，我们说，作坊式开发对小型应用软件开发项目是有一定的用武之地，在一定程度是不违背快速开发理论的；但对于稍成规模的小型软件（更不用说中、大型的软件）项目的开发过程，那就必须遵从于工程化理论的原则和方法，落实规范化的管理，否则失败的风险将伴随着整个开发过程，而且越到后期失败的可能性会越大，一旦失败，其经济损失也就会非常巨大。
那么，既然有这样的工程化理论，为什么往往不为我们所广泛忠实地采用和贯彻呢？这是问题的症结所在，值得探究！归结起来，主要有以下一些原因：
首先，市场对软件工程化开发的意义理解不够，没有形成广泛的支持。
“应用软件系统”本身的内含都包括哪些？对于用户来说往往只局限于“在计算机上运行的程序”这样一个肤浅的理解，不知道还应有计划、调研分析、方案、设计、质量监督、测试、培训、系统说明文档等等的内容；对于“程序是做什么的？应达到怎样一个目标？”这样一些问题一般没有从主观上得到重视，更难谈到从根本上把握。
之所以如此，就如同在规范化工程理论发展成熟的今天，我们仍以作坊式开发模式进行生产一样，信息化建设到了一个如火如荼的时期，而大多用户对其本质方面的认识还仅仅停留在“机器代替手工”这样的理解上，他们对软件产品应该具有的性能、适应性、安全性几乎一无所知，甚至对一个自己所需要的应用系统的功能范围都不是能够很好地定义。这样，用户是很少会对开发企业提出实质性生产要求的。
用户方往往将期望寄托于他们选定的开发企业，认为一切难题都会由开发方很好 地解决。在这种情形下，他们不会想到软件开发的失败可能（认为是开发方的事），当然也就不会去了解会导致开发失败的风险因素，也就不会提倡以工程化的规范方法来约束过程了。孰不知，他们那“崇高的信任”很容易地被开发方强奸了，许多的用户方在项目进行相当时间后才发现一些问题，在项目将完成时或试用阶段才与开发方发生争端，但最终认输的往往是用户，因为一个相对的软件外行与“内行”的开发方对峙，显然只能在大量的“事实”面前承认是自己的失误导致功能的不完整、项目的延期……。
这样“无知的”用户群广泛存在，是“作坊式开发”赖以生存的沃土，培育了“作坊”的勃勃生机。既然用户要的是包括其规划功能的、可以“跑得通”的应用程序，何必当什么工程来费时费力地劳作，敲出来不就得了！有那功夫还不如找些理由应对用户的“挑剔”。
软件企业在没有形成规范化管理体系时，不可能建立起“全面为客户信息化建设服务”的意识，企业没有能力将工程化过程要求提到应用实施规划内容当中，从这一层意义上说，其实是作坊式软件企业自己断送了自己的前程。
用户对应用软件以及开发过程的不理解，造成其对软件产品成本和开发周期的过低估计，从而使软件企业无力投入更多的人力和资金健全开发组织管理、规范整个工程过程。
第二，规范化管理理论不被软件开发企业管理者所重视、风险意识淡漠，人员组织和资金投入不够。
所谓规范化管理，是依据工程化理论，对项目实施的过程进行科学的、有条理的管理，这得有一整套的操作规范和监督机制。对于有一定规模的软件企业，得有一整套技术管理体系，包括得力的管理机构、人员配备和完善的管理制度，管理体系中应严格制定生产过程的步骤、监管方法，必须有专人监督制度的有效实施；要有一个确定的发展方向，制定企业的远景规划；根据需要，建立一支具有各技术层次、各技术方向的技术队伍；在整体上要形成一种团结、向上的具有凝聚力的企业文化。特别是对于软件开发过程，一定要坚决地贯彻落实前人总结形成的工程化管理理论和方法，这决定着一个软件企业的命运。
软件业是一个高投入，高回报，高风险的成长性极强的行业。在想获得高回报之前，首先应考虑如何规避风险、如何使自身得到成长和壮大。风险是伴随着应用系统开发的整个过程的，一旦风险失控，其结果对软件企业往往是致命的。作坊式的软件企业在小的应用软件的作坊式开发中尝到了些甘甜头，而对潜在的风险危机缺乏认识，为自己的“成型的”开发模式而沾沾自喜，这种模式实际上使企业的效率不能提高、市场适应能力低、企业内部危机四伏。可惜的是，软件企业的决策者们往往看不到这一点，短期利益的轻易获得导致最终的企业倒闭，这是领导者的失败。
按照工程化理论和规范化管理要求，企业须要投入更多的人力、财力于：客户关系管理、分析设计结果审查、流程化的过程管理、质量管理等等，而远非代码实现的人力支持。与作坊式开发模式相比，企业的管理者们首先想到的是投入太多，却看不到作坊式开发风险造成的亏损危机，反而不会积极支持以提高开发效率和系统可靠性的工程化开发；在没有必要的人力保障和过程指导的情况下，项目组规范化开发的尝试是弱不禁风的、没有结果的。在这种情形下，不可能有积极的实践活动，不可能建立起一个健全的机制来支持工程化规范开发的进行。
事实上，理论并不精确地指导实践，对于工程化管理和规范化开发，尽管可以罗列许多所需的管理机构和过程任务，但规范化管理本质上并不是要求具体“人”的行为，并不一定要求人力规模，而是要求建立一个机制、体系，严格工程的过程管理，所以，如果我们的管理者做一些“职能转变”、实施者多一份过程、质量管理意识，已是大的飞跃。理论是死的，人是活的，数以千计的软件企业的兴衰证明了管理的重要性，而软件企业管理的根本是软件工程化管理和技术管理。
第三，软件开发技术人员对工程化理论的实践有抵触心理，认为增加了劳动量。
文章来源于领测软件测试网 https://www.ltesting.net/