软件过程一直是一个争议不断、模糊不清的领域。许多IT组织在引入CMMI之前，往往对其寄予厚望，期待它能解决研发、管理中的关键问题。尽管CMMI实施后出现了一些改进，但很多根本问题依然未能彻底解决。而且，某些问题的解决似乎并不能完全归功于软件过程的改进。
直到今天，以下问题仍然难以给出清晰的回答：
软件过程的问题到底出在哪里？
前几天一口气读完了与戴明同时代的现代管理大师彼得·德鲁克（Peter Drucker）所著的《技术、管理与社会》一书，感触颇深。德鲁克早在20世纪50年代就提出了 “知识经济” （knowledge economy）和 “知识工程师” （knowledge worker）的概念，并准确预见到知识经济和知识工程师将深刻改变我们的社会与生活方式。他以通俗的语言向我们阐述了通过知识获取进行制造的过程与传统依靠体力的制造过程截然不同。德鲁克穷其后半生，致力于解释如何管理知识工程，如何通过知识获取生产出用户需要的产品，即所谓的“知识产品” 。
合上德鲁克的书，我有了豁然开朗的感觉：软件过程存在一个严重缺陷，我们将软件视为传统产品，而不是知识产品。所以我们自觉不自觉将传统产品开发（依赖机械活动、可重复的过程）的管理实践套用到软件开发。虽然许多软件实践者意识到这些缺陷，比如敏捷的先驱们和部分软件工程大师，但我们一直没有从根上纠正这些问题。
如果我们把软件视为知识产品，那么软件工程实际上就是知识工程，这意味着软件开发过程是一个知识获取的过程。简而言之，在开发软件时，我们需要掌握业务知识、技术知识、运营知识以及工具知识等，最终将这些知识转化为代码。
根据知识获取的特点，软件项目大致可以分为三类：
已知类：我们已经掌握了开发所需的所有知识，或知道如何获取剩余的知识。
未知类：我们对项目所需的知识缺乏了解，也不确定如何获取。
混合类：项目同时包含已知和未知的知识。
CMMI对过程的定义是：“一系列相互关联的活动，将投入转化为产出，以实现既定目的。”很明显，对于未知类活动，几乎不可能设计出完全符合这一标准的过程，因为你无法为从未做过的事情设计出一个正确的过程。许多软件过程问题的根源在于我们将适用于已知类的过程错误地应用于未知活动上，而大多数软件项目（如研发项目）都属于未知类或混合类。
当我们意识到这一点后，重新审视诸如估算难题、功能交付不完整、效能度量难等问题时，就可以更清楚地看到这些问题的真正原因。
如果软件是知识产品，软件开发是知识获取的过程，那么软件过程应该是什么样的？要全面而深入地回答这个问题可能需要一本书，这里我仅分享十点初步的看法。
1.不同类型软件项目需要不同类型的过程，针对未知类的项目，我们需要重新审视过程的内涵是什么。
2.软件过程必须是动态的，研发中获取的新知识应该用易理解、可复用的形式保留下来。
3.必须将已知类的项目过程，用自动化工具形式实现，有如此清晰的需求，不用IT实现，对一家软件组织来说是一件耻辱的事。
4.应该给未知类的软件过程留出足够的创新空间，允许试错探索。
5.德鲁克正确地观察到，传统制造业生产率度量方式并不适用于知识工程。
6. 德鲁克另一个观察是，在知识工程中，外人不可能给你提供一个最好的过程。所以软件过程的改进应该由使用者主导。
7.在知识获取过程中，计划与执行应当紧密结合。在知识获取框架下，我们可以更清楚地看到敏捷和精益实践的价值。
8.华为IPD 2.0提出的“让不可能变成可能”改进目标，正是支持创新与未知类项目开发的典型例子。
9.在CMMI框架下，可以通过指南和价值度量来支持未知类软件项目。
10.AI大模型也许可以为未知类项目提供高效的过程支持。
软件过程的最终目标应该是解放软件知识工程师们，让他们从日常重复任务中解脱出来，专注于重要的知识获取工作。这也是每一个软件开发人员所期待的理想过程。
注：文章中的许多观点还需要更深入的探讨，以后有机会将通过一些具体案例，进一步探讨未知类过程以及它与敏捷、精益、CMMI之间的关系。
推荐阅读
2. 软件定义装备！
3. CMMI认知的四个级别
4. CMMI和 “屎上雕花”
三尺讲桌就在这小小二维码，长按二维码“识别”关注
