专栏名称: 聊聊架构
在这里煮酒聊架构。
目录
相关文章推荐
高可用架构  ·  Feed 流系统的架构设计方案 ·  昨天  
高可用架构  ·  Java方法设计原则与实践:从Effecti ... ·  2 天前  
架构师之路  ·  架构设计中的后台任务:3种场景,2.5种触发 ... ·  2 天前  
奇舞精选  ·  vercel是如何做微前端迁移的 ·  5 天前  
奇舞精选  ·  vercel是如何做微前端迁移的 ·  5 天前  
51好读  ›  专栏  ›  聊聊架构

从企业软件的生产关系谈起 ,反思为什么我们总是加班

聊聊架构  · 公众号  · 架构  · 2017-01-09 19:38

正文

从软件产品的生产关系,看软件是如何被制造出来的。程序员们为什么要加班?

企业软件产品的制造与消费

用生产关系来分析企业软件的制造过程,是非常合适的,但很少见。

  • 软件的原材料是一些片面的知识,软件是对一些片面知识集成之后的固化产物。

  • 软件的版本更新,既源于对新知识的集成,也源于对旧知识的淘汰。
    源代码、机器码,是知识在计算机层面的两个形态。

  • 程序员编写源代码、编译器将源代码转换机器码,是对「知识」这个生产资料进行加工的「工艺」。

  • 知识的直接价值,可以通过「软件产品的交易」的方式得到体现——被最终直接用户购买和使用。

  • 知识的间接价值,可以通过「软件被软件集成」的方式得到体现——作为中间产品被最终用户间接够买和使用。

  • 解决普通实际问题的软件,即应用软件,需要根据不同的应用场景和软件的最终运行环境,对不同来源的代码进行集成,这就需要「集成方案」。

  • 「集成方案」也称为「解决方案」,它和具体应用场景和软件运行环境紧密相关,灵活性与复杂程度较高,但通用性不强。

  • 「集成方案」是一类专业知识,同样可以被加工为「集成代码」,其结果是固化了被集成知识的范围以及使用方法,也就是固化了知识作为生产工具、形成生产力的过程。

  • 「集成」决定了以软件作为生产工具,形成生产力的生产关系——如何加工数据,并形成「数字产品」。

  • 一个应用软件(系统)的整体,是集成多个复杂知识领域的结果。
    设计复杂系统的模块化划分原则,依据的是不同领域的知识点。

  • 在设计过程中,声明对其他模块代码的引用和依赖,即表达了对其他知识的潜在使用需求,产生了知识消费的意向。

  • 对软件产品进行公开发布,是对知识的产品化发布,一方面将自有知识转化为拥有自主知识产权的知识产品,另一方面也确定了对被集成知识产品的订购关系。

  • 完成一次软件产品的交易,等同于完成一次对知识商品的交易。

做软件的,为什么总加班?

1. 软件部门的工作内容

在软件部门,按工作内容定义的职位已经非常繁多,架构师、程序员、开发者、码农,这些概念既有能力上的交集,也有经验上的差异。

职位的划分方式,在不同IT规模的企业是不同的,有意思的是,这会呈现出千变万化组织结构——直接反应了企业内、来自人力资源的生产力。 (我想,这也是不少IT行业的研究图书,例如吴军博士的《浪潮之巅》,对企业组织结构进行研究的原因。)

单看企业软件制造过程的两个工作内容,还是比较简单的。

架构设计——制定集成方案

这是最为「烧脑」的「重脑力劳动」,要求从业者对「以知识作为资源进行开发」具备三个基本素质(生产力):「系统性理解、场景化抽象、灵活集成」。

被加工的「知识原材料」可以分为四类:「多视角的应用场景」、「可被集成的软件」、「运行的目标硬件环境」和「定制软件的实现工艺」,最终形成的设计产物,就是前文所提到的「集成方案」。

对这四类「知识原材料」的深入、系统性的理解,掌握每个部分的机理,是形成一个合理、优秀「集成方案」的先决条件。

这里的优秀,指的一个通过「集成方案」固化下来的复杂系统(包含软硬件),既能解决目前应用场景实际问题,同时能够保持长远发展所带来变更的「灵活适应性能力」。

「集成代码」是「集成方案」的软件形态,需要通过「编码」进行实现。

实现工艺——实现集成方案

编写源代码,是实现过程的首要环节,主要以敲击键盘、点击鼠标,并用眼睛观察计算机在显示器上给出的反馈,验证编码正确性构成。

编码既是体力活,也是个手艺活,它能够直接决定软件作为未来生产工具的生产力——性能,也就是看在相同条件下,能不能最大地发挥出计算机的通用计算力。

当然,人们已经深刻的认识到,人作为直接生产力,难以保证生产质量的稳定性,所以源代代码生成器(模板引擎,生成源代码的软件机器)也越来越多的涌现。

2. 到底为什么老加班?难以说清的工作环境

这里所说的工作环境,不是指有没有免费、美味工作餐,提不提供下午茶,配不配备高效的办公用户——个人PC。 当然了,这些都能够提高员工的工作效率,降低企业隐形成本。(干活不开心,哪有生产力)

从前面描述的工作内容中可以明显的感觉到,「知识原材料的不确定性」是难以定量描述工作环境的根本原因。

也就是说,「知识原材料」没有像实体经济、制造业的那样工业标准。很少见到一个软件产品会标注着「执行标准」。

多视角的应用场景

大多数来自于应用场景各个参与方,以文字陈述性质的「功能需求说明书」,经过无数人的转手,原始意图已经被转义为「不知所云」。

可被集成的软件

软件被集成的条件是能够开放互联,提供代码级的集成能力。

对于已有软件集成者,一方面,阅读文档是最为直接了解原作者设计思路和意图的方法,另一方面,阅读源代码的边界判断条件,是精确掌握已有软件功能特点的必要手段。

现实中的普遍现象是,普遍存在说明文档的过期或者缺失,这导致已有软件的集成者只能够阅读源代码对知识结构进行还原。

这对于一个需要集成复杂的、规模庞大、超过个人或者团队认知能力、学习能力的软件而言,无疑是一个盲人摸象的行为。

更不幸的是,当面对一些庞大、功能不稳定,只提供机器码,不提供源代码,说明手册描述不准确的软件,集成者看到的将是——末日。

运行的目标硬件环境

众所周知,软件是要运行在硬件之上,才能把硬件的「通用无目标计算力」转换为「特殊专项生产力」。

硬件的可靠性是基础,它的不稳定性可能来自于网络、来自于存储、来自于芯片,也可能来自于人为事故和自然灾害。

硬件的不稳定性,一样需要通过软件进行解决。

这些看不见摸不着的能力,不容易被应用层面的普通人理解,更难以体现价值,也只有发生系统故障、信息泄露、密码被盗才会被注意到。

定制软件的实现工艺

应用系统软件之中,一定会包含根据应用场景的「定制部分」。

定制部分的软件交付能力,现阶段不可能由一个人独立完成,也就是需要一个团队合作才能完成。

有合作,就会有分工,有分工就会有上游和下游环节。

从软件的设计、实现、交付、到维护,每个环节都是上一个环节的下游。

复杂的依赖关系,交付过程导致质量问题难以被追溯。生产事故的出现,下游为上游背黑锅,在IT运营能力落后的企业里,是一个普遍现象。

解决上述种种问题的手段,就是——加班。

提高软件行业生产力的方向

1. 制定企业IT运营能力基线

每个企业都会遇到IT系统的建设与持续更新问题。软件应用场景的变更是频繁的,计算机硬件设施的更替是缓慢的。

对于企业IT而言,首先要深入理解应用系统是「蛋糕式」集成的的产物,每一层对下层的集成,都应该按照不同的速度进行持续的「新陈代谢」。

每一层对上一层的支撑,应当形成企业内部的「可操作标准」,包括可靠性指标、集成模式、准确的文档说明,明确的责任关系,以及利益分配关系,有条件的还应当与财务报表相结合。

每一层对上一层的支撑,还应当形成「按需自助的发布订阅」机制,对于陈旧的知识所对应的过期软件,应当提供下架、下线的能力。

2. 改变以编码作为唯一集成方法的集成模式

固化的集成模式——根据已有经验,人工设计和组合已有软件——是企业IT系统为企业商业模式所带上的一副手铐。

应当把每个知识点——也是软件功能点——作为一个神经元,通过机器学习的算法讲企业生产力自适应的集成在一起。

3. 软件自主研发与商业采购并行

以交付产品为商业模式的企业,其核心竞争力是「应需而变」的柔性生产力。

交付「数字产品」企业,其生产力则直接依赖于企业IT生产系统,这一部分的软件产品,应当以自主研发为主,目的是保障商业模式所需要的专业知识与IT能力的高度一致。

与企业主要产品所需要的核心生产力不相关的软件,采购成熟商业产品(主要评估维护成本)。从0到1的学习知识,掌握知识的成本远比直接购买知识的成本高。

最后,推荐作者的个人公众号,对企业软件感兴趣的同学,欢迎关注。