软件工程搞了50年，作坊式软件开发的出路在哪里？

用作坊式来比喻我们的软件开发，这与高新技术的软件开发工作似乎很不切合，但不幸的是，我们大多数定制化应用软件的开发过程很形象的展示了“作坊式开发”特点。我没写过代码，但从事过长期的IT管理工作，程序员朋友可以从本文感受一个管理者眼中的作坊式软件开发及其出路。

20世纪60年代，计算机的应用范围得到较大扩展，对软件系统的需求和软件自身的复杂度急剧上升，传统的开发方法无法适应用户在质量、效率等方面对软件的需求，这就是所谓的“软件危机”。为解决这个问题，1968年NATO会议上首次提出“软件工程”(Sotfwrae Engineeirng)的概念，提出把软件开发从“艺术”和“个体行为”向“工程”和“群体协同工作”转化。其基本思想是应用计算机科学理论和技术以及工程管理原则和方法，按照预算和进度，实现满用户要求的软件产品的定义、开发、发布和维护的工程，从此也诞生了一门新的学科——软件工程。

50年过去了，我们今天环顾四周，作坊式的软件开发依然比比皆是。今天的定制软件开发普遍受制于老师傅的手艺，基本都是一个师傅带几个伙计的小作坊，可能大一点的企业为了统一各个小团队的工作，会有一些“规程、制度”，在管理上也要求一些“计划和方案”，不过只是一个个不同的很多小作坊罢了，因为其运作管理和今天其它行业的精细化管理比起来可以说是天壤之别，软件工程的管理体系和措施落地执行的普遍不好。

一、说你是作坊还别不服气，看看以下是不是招招致命

我摘录了网上一个程序员写的几条表现，主要包括无合理开发计划、需求不明确成为常态、无任何文档和评审一般都事后凑数、领导不了解技术和业务、版本管理混乱、鄙视管理科学推崇关系帮派，其实日常开发工作中可能普遍或多或少的存在这些问题，我认为作坊式开发的集中体现是有组织的管理难以落地，有以下几个主要问题：

（一）对“师傅”的依赖严重

师傅就是骨干工程师，很多东西都是装在开发人员的脑子里面的，往往会因为一两个开发骨干走了，就造成整个团队的瘫痪，如果研发骨干一个人另谋高就，公司投资就将全部付之流水。我们看到很多团队里的“技术权威”使得老板也不敢对其“指手画脚”，否则他会“撂挑子”，事情成败取决于师傅的能力，实际上说明工作缺乏组织的有效管理，在这样的情形下，生产过程基本上是无序的、无约束的，老板作为“管理者”角色的职能几乎谈不到，甚至受师傅的摆布，除非老板是一个非常高水平的技术大牛。

（二）老板对软件开发的过程无法介入，各层级之间也是以人为纽带的弱管理

老板大概知道要开发个什么东西，需要什么时候交付，但具体开发过程、产品工期、产品质量老板只能问技术总监，有趣的是技术总监也是个大概齐，更多的只能问项目的负责人，虽然越接近开发工程师，越了解实际情况，但项目负责人甚至都不知道手下的工程师今天倒底是写代码了还是打游戏了，这种粗放的管理水平在今天的其他行业是很难想像的。

（三）无文档式开发，设计都在师傅的大脑里，开发项目可持续的风险很大