软件开发一直以来都是一件非常困难的事情，《人月神话》出版四十多年来，一版再版，已然成为软件工程的圣经，告诉我们一个不爽的结论，就是软件开发太难了，并且很难有什么好办法。有关软件开发的书籍，大多是从技术的角度或者工程项目管理举措的角度出发，很少有从管理学的理论思考出发，来剖析软件开发行业存在的问题本源，以及解决问题的出路。

本文试图从管理学的分工和流程开始，来探究软件开发行业在运营管理中遭遇的困境，分析软件开发全过程数字化运营管理的主要障碍，结合技术创新的实践，探讨如何将软件开发从项目管理的层面推到流水线管理的层面，以及一些创新实践。

1. CMMI5流于形式，敏捷开发大行其道，违反管理学常识而迫不得已

1968年NATO会议上首次提出“软件工程”(Sotfwrae Engineeirng)的概念，提出把软件开发从“艺术”和“个体行为”向“工程”和“群体协同工作”转化。软件工程可以认为是一门新的学科，但并不完善，更多被定义在项目管理的层面，不过管理成本非常高昂。由于软件的复杂性、不可见性、一致性和可变性的存在，每一个特性都加剧了项目管理的难度，使得为了完成一个软件开发项目，团队必须要付出极大的沟通协同的努力，甚至远远超出代码编写本身的成本。

暂且把这种成本定义为不堪重负的管理，正是由于这种不堪重负的管理，导致在行业实践中出现了一系列创新来逃避之，迫使软件开发组织在实践中采取了众多有悖常理的创新，或者说采取了不少迫不得已违反常识的行动。

1.1. CMMI5拿到手里当摆设

在中国目前的软件开发行业实践中，你会很容易发现拿到CMMI5认证的企业很多，但落地执行的微乎其微，很多从业者会很直白地告诉你，“拿到CMMI5认证只是为了投标或者宣传，并不是拿来用的，用了就是找死”。

目前看，除了少数金融、支付方面的企业在软件开发过程中落地CMMI5，大多数企业基本上都流于形式。为什么呢？大体有两方面的原因，首先是成本太高，执行落地过于复杂不堪重负；其次是对需求的响应不及时，跟不上快鱼吃慢鱼的时代。

1.2. 详细设计普遍被抛弃

如果说软件工程是一门学科，属于工程项目管理的范畴，那么从常识逻辑来看，应该是需要很强的设计保障的，此所谓磨刀不误砍柴工，并且越复杂的项目越需要详细设计的指导。但在实践中完全不是这个样子的，软件开发的详细设计几乎在实践中被普遍抛弃。

为什么详细设计会被抛弃？不好用，用不好。详细设计本身的难度并不是主要原因，根本的原因在于详细设计的成果指导开发实践的难度太大，由于软件特性的存在，导致落地执行的要求太高，执行稍不到位，很容易就变成了设计和开发两张皮。一个开发团队如果没有强有力的执行保障，假以时日，加之执行成本太高，详细设计自然就会萎缩和放弃。有过实践经验教训的开发人员，如果没有得到强制性的指令要求，自然也是不会选择做详细设计的。

从管理常识出发，一个没有详细设计的项目实践，对于一个管理者来说实在是难以接受的，这就是软件开发给管理工作带来的迫不得已的现实。

1.3. 敏捷开发备受推崇，作坊式管理在实践中非常普遍

在中国，很多事情特别有意思，可能是由于我们的管理学教育和培训的历史比较短，我们的企业管理人员的普遍认知相较于西方会弱一些，主动拥抱管理的意识不强。华为推行IPD的时候依靠的是强制执行，据说IBM的Rational在IBM印度用的不错，但在IBM中国区死活用不起来，估计就有这方面的原因。

这也很容易导致我们对管理理念、管理方法、管理工具的片面理解，敏捷开发在中国的实践大体可以说是半生不熟的，更多是变成了弱化管理的理由，具体什么是敏捷开发应该如何去落地，并没有受到认真的对待。

对今天我们普遍的所谓敏捷开发的实践，可以形象地总结为：分田到户式的作坊式管理。用作坊式来形容高新技术概念的软件开发似乎很不切合，但不幸的是，大多数软件开发工作很形象地展示了“作坊式开发”的特点。作坊式管理的形象体现，就是普遍受制于师傅的手艺，一切都在师傅的脑子里，基本都是一个师傅带几个伙计，一些大一点的企业只是众多小作坊的集合罢了。

从常识出发，越复杂的工作，越要强化过程管理，用过程管理来保障结果导向，如果弱过程管理、只重结果导向，用分田到户的方式来替代必要的过程管理，一定面临遍布黑箱、可控性、可持续性差的境地。

1.4. 个体能力的重要性显著强于组织管理，全栈工程师的反分工倾向显著

个体能力的重要性虽然是软件开发的独特性决定的，但个体超能和管理无力共存，这是管理者和企业组织难以忍受的。人的重要性是第一位的，没有人会反对。但如何发挥人的更大效能，如何增强组织能力，如何改变管理无能的情况，是管理者必须面对的话题。

管理是以分工为基础的，今天热衷于全栈工程师的实践说明了管理的无耐和退让，似乎通过管理导致的得不偿失还不如在人上加强投入来得更快更好。但是从组织管理的角度来看，弱化分工、培养全栈工程师在逻辑上是非常反常识的，这只能更加说明软件开发行业的运营管理之难。

2. 软件开发行业从管理上看是一个缺乏掌控力的行业

对于管理者来说，在项目工程领域，从管理的无力感来说，估计没有一个行业能超过软件开发行业。如果排除行业中的极少数企业，从常识来看，现实中软件开发的管理实践似乎是普遍失控而无力的。

2.1. 开发一个系统就离不开一个服务商

不通用的开发框架、影响全局的黑匣子、可读性差的代码；小需求大工程，离不开特定服务商，自己想动动也非常困难。

2.2. 特定人员依赖非常严重

开发团队核心技术人员的流失容易造成重大风险，普通技术人员的流失都容易造成明显损失。

2.3. 质量规范难以得到贯彻执行

难以用人工的方式落实到位，落实执行的成本高昂。开发文档大多是后补的，与现实系统吻合度低，项目可维护性、可持续性差，还有刻意而为以提高他人进入的门槛。

2.4. 工期管控不精准

工期多以月来估算，人工成本多以功能模块和人月来估算，大型项目整体实施的风险高。

2.5. 软件外包风险不可控

目前存在的软件外包大多数都容易陷入无休止的扯皮，规范的外包合作极其罕见，更多的外包都变成了卖人头。

软件开发团队的管理者都是非常痛苦的，那些非技术出生的CEO们更是感慨无力，这在其他行业是不可想像的，这一点在中国大陆地区可能更为突出。

3. 软件开发行业数字化管理灯下黑

说到提高管理效能，今天我们很容易想到数字化，数字化在各行各业的应用，极大地提升了运营管理效能，今天不少优秀企业的运营管理很厉害，主要的功劳是信息系统对核心业务支撑的好，甚至是再造重构这样的好，从人的角度看管理团队的运营管理能力并不起主要作用，更多是因为沾了信息系统应用的光，日常运营管理的难度一下子降低了很多，呈现出更多的自动化运转、智能化运营的特征。

软件开发行业的数字化运营管理怎么样呢？准确地讲，在运营管理过程中以各类项目管理工具的应用为代表，初步实现了辅助性的项目管理的数字化，但与核心业务的数字化运营管理存在实质性的不同。如果以核心业务数字化来判断，软件开发行业虽然服务于其他行业的数字化，但其本身的运营管理并没有数字化，呈现一种“灯下黑”的状态。其已经应用的各种数字化的手段仅能起到辅助作用，人的主观操作空间过大，导致信息系统的效能并不显著，与数字化状态下人的行为围着信息系统转有着根本的不同。

在任何一个行业，核心业务实现数字化的标志都是核心业务流程自动产生客观数据，数据经过处理以支撑运营管理，也只有这样的数字化才能极大降低管理的难度，超越人的限制以扩大管理的广度和深度。软件开发行业的核心业务是什么？代码编写工作。如何实现对一行一行代码的编写工作的数字化，直觉上是极富挑战的工作，究其根源肯定还是因为软件特性导致的。

关于软件特性，《人月神话》里已经有过非常充分的描述，今天我们必须换个角度来看，不能再就具体而具体的探究，否则会陷在里面出不来。既然是管理问题，具体又看不清楚，那就抽象出来，从管理学的基本逻辑出发看看问题出在哪里。

4. 核心业务数字化的本质及管理学的基本逻辑

先引用一下陆奇博士关于数字化本质的一个描述，数字化的本质是什么？任何数字化都有这以下图中所列出的六个核心要素，信息的获取、表达、存储、传输、处理、交付，缺一不可。

在其他行业的数字化过程中，一般遇到最大的挑战都是信息处理环节，当然在一些中小企业数字化过程中信息获取是数字化的拦路虎。软件开发行业数字化遇到的问题是什么呢？恰恰是信息获取。

信息获取的前提是什么？是业务流程自动产生客观数据，产生能表达真实状态的客观数据，这一点至关重要。我们看到目前支撑软件开发的项目管理工具都需要填报各类流程节点的信息，在一般工程项目管理中应用效果可能会好很多，但在软件开发领域应用很容易造成人为信息失真，并且由于软件特性会放大这种失真，这种失真可能导致严重的主观因素，使得信息系统在运营管理领域的优势不复存在，更多地成为了一种统计汇总工具。

有效运转的业务流程的基础是什么？是以有效分工为基础的，对于组织管理来说，极端情况下没有分工就没有流程，不能建立起有效分工也就无法建立起可高效运转的流程。这一点并不是数字化的独特要求，而是管理的普遍要求，如果没有建立起以有效分工为基础的业务流程，有效的管理就难以开展，因为无法建立起一套显而易见的执行检查体系。

今天，软件开发行业普遍抛弃详细设计的实践，只能说明在有效分工上出了问题，分田到户式的开发方式、弱化过程管理的结果导向都在说明有效分工非常难，不得以采取了弱化分工的变通方法。

5. 导致软件开发困境的管理学本源

分工这个名词普通得不能再普通，却是管理学的基础，是有效管理的本源，没有分工就没有管理。管理的本质从抽象意义上来讲，可以总结为对规则的创建和使用，分工则是最为基础的规则。

什么是有效的分工呢？通常我们的理解包含几个方面，分割到一个人能独立完成，分工之间可以有联系但不能耦合关联；分割到尽可能精细的颗粒度，降低劳动者的技术门槛，并通过专业化分工提升劳动效率；最小分工单元（工序或者岗位职责）是趋向标准化的，可重现可重复的；分工执行的结果是容易检查的，通过人工或者机器都能快速便捷地得出检查结果。

我们今天的管理学的基础可以说是建立在有效分工基础上的对流程的管理，分工也好、流程也好都是规则，这就是上面为什么说管理是对规则的创建和使用的原因。

软件开发过程中的分工有什么独特的所在？软件开发的分工很容易导致耦合关联的情况发生，随之产生大量的工作协同，这本身就是逆分工的，如同悖论一般的存在；不可能精细到工序的层面，软件开发人员是典型的脑力劳动者，但也不同于管理岗位的知识工作者，它依然带有很强的生产领域属性，不过从最小分工单元的时长来看，会显著长于其他行业。由于最小分工单元的时长较长导致整体的复杂性较高，标准化非常困难，加之软件的特性，使得这一分工执行的结果是非常不容易检查的，很容易导致检查的成本过高。

这种成本是一种为了精细化管理所带来的内生成本，为了避免过高的成本，加之为了避免分工可能导致出现更多的内部耦合关联的情况，在实践中自然就会产生一种倾向，弱化分工，更多以模块化粗颗粒度的简单分工来组织开发活动，使得精细化的基于分工和流程的管理工作自然就失去了基础，当然这也是一种迫不得已的选择。

由于软件特性的存在，我们期望软件开发的分工也能像其他行业那样带来标准化、高效能的运营管理基本上是不可能的，但也不应该像现在这样的无力，精细化管理、数字化管理依然是行业的未来。

从目前的技术发展水平看，最小分工单元完全可以做到小时级，虽然相对其他行业还是长太多，但对软件开发来说已经够用了，剩下的关键就是如何消减分工带来的耦合关联以及显著降低对分工的检查成本。

也就是说，在技术上取得突破，通过技术创新有效消减分工带来的耦合关联，显著降低对分工的检查成本，是软件开发行业提升管理效能的基础和关键所在。

6. 猿开开的创新实践

猿开开通过独特的模式驱动技术创新，通过人工智能技术在软件开发过程中的应用，有效消减分工带来的耦合关联，显著降低对分工的检查成本，使得精细化管理成为了现实，成为了开放的支持原生开发的数字化运营管理开创者。

6.1. 猿开开目前已经取得的主要应用绩效

不改变开发人员的开发语言、开发环境和开发习惯，支持开放自由的高效能原生开发；

开发过程产生数据支撑的精准绩效考核成为现实，精细化管理成为可能；

开发文档100%自动生成，实时与项目实际相对应；

70%以上的代码自动化生成，自动可持续更新；

人月到人小时的工时精细化预算管理，越透明越精细越能挤水份，主开发阶段的工时可达10倍精减；

项目可持续性脱离对人员的被动依赖，普通开发人员1小时接手，技术小组长1天接手，技术经理1周接手；

主开发工作完全可以通过高可控的云技术部来完成，常备员工数量可以大幅减少，降低企业运营成本。

6.2. 设计驱动代码生产

猿开开通过智能方式，辅助快速详细设计，自驱动全过程代码生产线，含括编码、调试、提测、测试、验收等。将软件开发的核心价值更多聚集到详细设计阶段，核心技术人才越显重要价值，牛人干牛事，不陷入大量具体事务，而能牵一发动全身；

基于对开发全过程规范透明的精细化管理，大量普通程序员从事可计量可考核的具体编码工作，技术大牛能快速切入对开发人员的支持；

7. 从项目管理到流水线的飞跃

目前的软件开发管理还属于典型意义上的项目管理，更多是对活动任务的监测和管控，受人的主观因素影响较多，如果能有效消减分工带来的耦合关联、显著降低对分工的检查成本，通过人工智能技术的创新实现自动化操作，就具备了打造流水线的基础。

流水线思想，从管理学上来讲是个很老的话题，但几乎是人类高效能管理的基石思想，今天我们能够享受到如此充足的物质财富都离不开流水线思想的广泛应用。

对于软件开发行业，流水线肯定是梦寐以求的，但又普遍觉得是不可能的事情，在现实实践的反差下，像工厂一样开发软件似乎过于疯狂和可笑，但实际上，在技术创新的推动下，代码工厂已经触手可及。

软件开发的流水线与传统意义上的流水线肯定有所不同，经过猿开开的实践探索，通过设计驱动会为每个项目创建一个完全数字化的虚拟流水线并可持续调整，和其他行业的相对稳定的实体流水线有着明显的区别，但流程自动向前驱动的根本逻辑没有变，基于自动化的支持，通过流程向前自动驱动最大程度减少主观因素的人为影响。

8. 开发即服务（DaaS）才是云计算的重头戏

云计算发展到今天，提出了基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）这样的传统概念和定义，后来还提出了开发者即服务、设备即服务等各种新的概念和定义，但通过对其实际的社会价值进行分析可以发现，真正带来社会效能显著提升的还是IaaS，PaaS聊胜于无，SaaS有贡献，但并不可喜，更多是依存于IaaS带来的自然的变化。

从IT投入进行分析可以发现，相对于基础设施的投入，软件开发的投入巨大，一般企业这两者投入的差距多在十倍以上。对于一个有自己基础设施和技术团队的企业来说最需要的云计算服务除了IaaS，估计就是开发即服务了（Development as a Service，DaaS），能够把开发能力和开发服务变成云计算形态，产业规模估计也将远超IaaS的规模。

IaaS的实践对企业提升创新能力、加强成本控制有着显著的作用，现在已经很少有自建而不购买IaaS服务的企业了。DaaS的对社会效能提升的贡献可能更为突出，除了产业规模巨大外，直接降低了创业创新的技术门槛，不用考虑自建技术团队对绝大多数初创企业都是梦寐以求的，这将极大促进各类创业活动的开展。只要软件开发行业实现了流水线式的数字化运营管理，DaaS就能成为现实，猿开开在实践中推出的云技术部服务已经可以商用，加以完善就是DaaS的起始。