反思软件开发：软件生产
欧雷 发表于
用人话说，「生产」是从无到有创造人们所需要的物品，可以是实物，也可以是虚拟的；软件就是那个被创造的「物品」，从无到有去创造软件就是「软件生产」。
先提了个问——软件生产是体力密集型劳动还是脑力密集型劳动？
流程
尽管细节各不相同，但任何物品的生产流程都能够抽象为需求、设计、实现、检验与维护这几个环节，视情况可以进一步简化为需求、实现与维护，并在此基础上循环往复直至产品或厂商的生命完结。
根据行业、领域等的不同，会在上述几个环节中各自加入一些细分环节。
以我所处的以 Web 相关技术为基础提供软件及服务的行业、领域为例，当前业内主流的生产流程为——
在接到需求后，要先对其进行分析，论证是否为伪需求以及概念、逻辑的完整性、严密性，若没问题就进入设计环节，包括产品设计、UI & UX 设计和软件设计。其中，UI & UX 设计也可被认为是产品设计的一部分。
不像单机应用那样只有客户端，当今的应用软件基本都包含客户端和服务端两部分，即前端和后端。因此，软件的设计与实现都要同时考虑这两部分。
软件设计主要包括软件的结构设计，即软件架构，以及技术选型。在进行结构设计时，要有一定的前瞻性，具备一些弹性，能够较为轻易地应对未来一定时间内的变化。
应该注意的是，软件架构受行业趋势和规则、组织战略目标和客户需求影响，技术选型受软件架构、团队规划和人员素质限制，而不是反过来。
以此为分界线，需求与设计是脑力密集型劳动，剩下的实现、检验与维护基本是体力密集型劳动。
在这整个流程中，需要辅以行政管理和项目管理手段进行资源调节与过程控制，以保障产品如期交付并符合要求。
分工
一般来说，不考虑管理人员，软件生产相关的分工是按照生产流程来的，以下就是按照软件生产流程的上下游关系排序的主要分工：
- 产品设计——产品经理、交互设计师；
- 外观设计——UI 设计师；
- 软件开发——软件工程师；
- 软件测试——测试工程师；
- 部署维护——运维工程师。
在不同企业或部门中，根据实际情况，可能会出现同一岗位的人会参与到多个环节中去，如一家企业或部门没有专门的测试工程师和运维工程师，产品经理、交互设计师和 UI 设计师会去兼做软件测试相关工作，而软件工程师就去做些部署维护的活儿；也可能会在某个环节中细化出更多的岗位，如软件开发这个环节细分出架构师、前端工程师、后端工程师等。
那么，由特定工具或场景所催生的岗位，如 Java 工程师、Go 工程师、微信小程序工程师、H5 工程师等算不算是分工细化呢？我认为不算——这类岗位受企业业务等变化影响太大，易变性高，随时随地会消失。
影响自己所处岗位稳定性的是解决自己所处环节的问题的能力，而不是自己所用所熟悉的工具是什么。假如你是通过「Java 工程师」的身份进的某个企业，某天该企业决定将 Java 全部替换成 Go，你是主动辞职或者等着被辞退，还是学习 Go？
分工细化的前提是流程环节比较复杂，并且因操作规范化程度不够或其他什么原因导致不能自动化，无法用机器取代人工，因而要拆分出子环节并找到对应的人去处理。
交付
从软件的交付方式上来看有项目型软件和产品型软件，会对流程细节和开发心态等方面产生影响。
项目型软件相当于一次性买卖，需要先投标或通过市场销售人员拉客户，与客户谈论具体需求后签合同。进入研发后，大家的心态就是——尽量早日完成，能用就行，可维护性、优雅什么的都靠一边儿去！
做这类软件，会被 deadline 倒逼着从一开始就集中火力，就像知道自己哪天要死，但在死之前一定要做完某件/些事一样，顶着巨大的精神压力尽全力、拼体力。
以项目型软件为主的企业或部门，若是项目需求多的话，在一个项目做完还没怎么喘息就要进入下一个项目，开启对个人来说的恶性循环——精神与肉体资源的消耗大于补给，在专业能力上成长甚微——只有项目不多、时间充足或人员足够这三个条件至少满足一个时才可能终止循环。
产品型软件则相对更加秉承长期主义，需要持续迭代、不断改进，不像项目型软件那样交付完就差不多等于结束了。
这类软件的需求主要是由产品经理来挖掘与把控，相比项目型软件，大家的心态更倾向于把软件做好，也更在乎各层次设计的美感、可维护性等。
从企业角度来说，产品型软件一般是对外的 XaaS 在线服务；但从部门角度来看，就是对内的中台服务。在这样的企业或部门中，个人在专业上的成长什么的也自不用说，开启良性循环的概率比做项目型软件为主的企业或部门更大些。
相较之下，产品型软件的生产是脑力密集型劳动，项目型软件的生产则是体力密集型劳动。
优化
为何要优化？因为——
「降本增效」是人们在生产过程中永恒不变的话题、永远的追求。
除非能找到像虫洞那样进行「跳跃（leap）」的手段，让想法刚一出现就已经完成，否则优化一件事的极限就是完成这件事所需的最小信息量/工作量——
要做成一件事需要固定的信息量/工作量，就看这部分信息/工作是做到哪里；要做好这件事就得达到这个信息量/工作量，少了就做不好，多了就是无用功。
然而，这个「最小信息量/工作量」只能是理论值，就像从一个地点去另一个地点的实际距离一定会大于它们之间的直线距离一样——影响一件事的要素超过一个时必定会或多或少地做「无用功」。
优化就是针对特定问题在特定场景下从时间和空间上寻找综合的最优解——像不像算法？就是算法！
生产流程中的需求、设计、实现、检验与维护这几个环节是必需的，就算在某些情况下看起来是消除了某（几）个，但实际并没被消除，只是被转移了。
比如当前企业或部门在生产时没有设计环节，并不是软件生产没有设计这个环节，而是设计这个环节被开源软件提供者或其他上游供应商做掉了。
软件生产的参与者往往有很多人，因此而产生的岗位分工重叠、信息传递失真等会导致做很多「无用功」，造成时间和空间上的资源浪费。
这么一看，优化方向很明确——削减分工的重叠部分，减少信息传递的环节等——以使面向业务的生产流程进行减员为目标提高生产力。
我觉得「以知识作为全链路的唯一可信来源（Single Source of Truth）」是一种方式，日后会在「聊聊中后台产研一体化」系列文章中详细阐述。
以我短浅的目光看来，至少近五年主流的分工形式不会有什么变化。但随着低代码开发平台的成熟，分工必然会发生变化。
现在的软件生产，几乎还是由一家企业或部门一条龙地从最基本的单元做起（忽略开源工具），逐渐变成完整的软件产品。若低代码开发平台比较成熟了，那些面向业务的企业完全可以在采购低代码开发平台后裁减大量原本用来开发、维护系统的人员，只留下不几个基于低代码开发平台配置或开发满足业务需求的功能的人员即可。
这种情况下，面向业务的企业就像那些传统企业一样，人员构成绝大部分是解决业务问题或维持公司正常运转的，只有一个由少数人员组成的 IT 部门负责系统功能的开发和维护，不需要很高的技术能力。
这样一来，做低代码开发平台的企业就成了面向业务的企业的供应商，那些做 UI 组件或其他基础设施的面向技术的企业又是做低代码开发平台的企业的供应商。
以低代码开发平台的成熟并崛起为契机，产业结构和企业员工构成会发生变化——从产业层面来说，完善了从原材料到可销售成品的生产链，分工变细了；从企业员工构成来看，面向技术的企业没有什么变化，而面向业务的企业在岗位上会缩减或合并，分工变粗了。
总结
人是人类活动各种问题的原因，人参与的部分越多，参与的人越多，效率就越低，能耗就越大，应将体力密集型劳动尽可能「外包」给自动化、智能化的工具或机器去解决，正如所长林超的一期视频里说的那样——
人们在解决了一方面问题的同时，会在另外一方面去制造问题，然后再去解决，如此往复。无论思想、方法论和手段如何变，人的本性和需求不会变，因此人类社会的发展是螺旋上升的——
历史不会重演，但会押韵。
道、法、术、器，越向后越易变，越不重要。求道，变法，换术，易器。
