【想成为一个优秀的软件企业，要培养自己的团队具有良好的产品思维、项目思维和工程思维。本文就产品思维、项目思维和工程思维进行讨论，帮助读者更好地理解项目管理、产品管理和工程管理之间的区别和联系。】

工程思维

产品思维偏于感性，喜欢从人性、社会性角度去思考问题，从“人机交互”角度去思考，从用户、用户行为、应用场景、业务流程等角度去思考问题。而工程思维属于理性思维，喜欢从方法、技术角度去思考问题，从“数据交互”角度去思考，从数据流、业务规则、业务逻辑、异常条件、异常数据等角度去思考问题，如：

• 用户不登录能看到哪些数据？

• 系统登录时需要用户输入什么数据？

• 对用户名和口令建立哪些验证规则（字母大小写是否敏感、口令长度、含哪几类字符等）；

• 口令或用户名输错了给予什么提示？

• 口令输错多少次，账户被锁定？

• 用户可能会输入哪些特殊字符？

• 黑客有没有可能暴力破解口令？

• 黑客能否在字符串类型域中输入script脚本？

从这样的思维过程，我们可以看到工程思维的轮廓。工程思维之所以是理性的、科学的和逻辑严密的，是因为工程本身具有系统性、复杂性、集成性和组织性，而且会涉及人们生命安全和财产安全。工程方法强调以人为本、安全第一，要考虑自然、环境、经济、管理、人文、伦理、社会、技术，做到工程与自然的和谐、工程与社会的和谐，持续优化，达到高度的安全性。

工程思维类似项目思维，我们常常将“工程”和“项目”组合起来，形成“工程项目”，但工程思维不同于项目思维。从一个工程看，资源、成本、质量这些概念也都在，似乎也离不开资源调剂、成本控制、质量保障等要求，似乎也是工程思维的出发点，工程思维也关注质量和效率、关注流程，按步骤、按流程实施工程。实际上，两者有比较大的区别，项目思维侧重从资源调度、进度控制、风险管理等来实现项目的目标，包括计划、平衡、沟通等，侧重管理。如果简单地说，项目思维更多体现在管理思维上。而工程思维侧重用工程技术与方法来解决问题，从提出工程问题到分析问题、解决问题，更多体现了工程方法和系统工程的思想。

工程思维，首先是一种技术思维，更多是想通过技术手段、通过工具来解决问题。产品思维定义一个软件产品，工程思维就会想如何选择合适的技术架构、如何设计系统内部的逻辑结构、选择什么编程语言来实现，从而在性能、可靠性、安全性等方面满足软件系统的要求。追求高性能和高可靠性、用机器来模拟人的行为（机器人）和推崇机器学习等，这些其实都是技术思维的体现。就一个直播App的开发为例，产品思维会考虑用户如何使用这个App以及如何获得良好的体验，如用户不注册就能看到几个精彩视频选段和目前受欢迎的主播列表，一旦点击某主播头像，这时要求用户注册账号，注册完后就能点击某主播头像、进入主播房间看直播，看直播过程中可以互动（点赞、打赏、和主播聊天等）。而工程思维想如何实现这样场景，满脑子是音频和视频、视频存储格式、摄像头兼容性、视频编码（encode）、视频解码（decode）、内容分发（CDN）、音视频同步、最大容量、性能瓶颈、高速缓存、播放器SDK等。

工程思维是一种抽象思维，需要将复杂的工程问题进行简化，去掉不必要的信息，抓住问题的主要特征，构建起能够描述问题的抽象模型。模型可以指为了解决特定视点而简化某些事物的任何抽象，从而成为不同研发人员或不同团队之间沟通的最好载体。借助模型，不仅有利于团队沟通，有助于我们看清问题的本质，而且建立了一种大家认可的标准，从而有效、彻底地解决问题，如过程模型、架构模型等。

• 如何看清软件研发过程，从而建立研发流程？这就需要建立软件过程模型，包括瀑布模型、V模型、RUP统一过程模型、XP模型、Scrum模型、BDD模型等；

• 如何让我们看清楚系统的架构？就是借助架构模型来表达团队共同的系统结构关注点，有助于软件系统的结构和设计中做出特定的权衡。软件系统架构，通常用不同的视图来描述，如UML将系统架构分为静态视图（如类图、对象图、组件图、部署图、包图等）和行为视图（用例图、序列图、通讯图、状态图、活动图），而C4 模型使用容器、组件和代码来描述一个软件系统的静态结构（如图1所示）等。 

图1  软件系统架构C4模型示意图

工程思维是一种上下文驱动思维，上下文（context）在软件工程中是一个非常重要的概念，无论是选择怎样的过程模型、还是选择怎样的系统架构。图1中系统架构的第一层“软件系统”就是系统上下文，需要考虑该系统与用户、其他软件系统之间的关系，明确系统之间的接口，实现安全、无缝的集成。构建一个软件新系统，需要考虑的上下文，不仅是与之相联、相关的已有系统，还需要考虑其它上下文因素：

• 谁使用这个系统？有哪些用户？用户数量多大？同时在线用户有多少？

• 处在什么业务领域？是性命攸关还是使命攸关的行业？

• 是产品线开发还是一次性的项目？是现场开发还是外包到乙方的项目？

• 是全新版本开发还是在已有版本上进行版本升级（功能增强、修改等）？

• 团队掌握哪些开发技术？其技术水平如何？

• 公司的薪水是否有竞争力？团队是否稳定？

不同的上下文，工程的解决方案是不一样的。

工程思维是一种分析性思维、批判性思维，也是逻辑演绎的思维。软件工程的核心是分析问题和解决问题，在这过程中有很多假定和推理，需要我们做出正确的判断，在做出判断前，要质疑，所以软件工程中分析性思维或者说纵向思维是主导性思维，虽然也需要创造性思维、水平思维。分析性思维强调假定、推理过程，如果假定有问题、推理过程有问题，就需要质疑，所以常常需要用批判性思维武装我们自己的头脑，在评审需求、评审设计时，应具备良好的批判性思维，质疑其中模糊的、有歧义的描述，质疑某些缺乏可信度的信息来源或脱离实际的假设，从而发现需求和设计中的问题。如果假定或推理不可信，那么结论就不可信；如果觉得结论不靠谱，那问题就出现在虚构的假设或不合理的推理之中。例如，在综合考虑各种因素之时，许多情况下需要运用批判性思维：

• 利益相关方所提供的信息是否出于自己的利益？所以更相信利益无关方所提供的信息；

• 如果支持结论的证据不是客观事实或缺乏可信度，那么这个结论就值得质疑；如长时间从事于某工作的这一事实，并不等于对此拥有丰富的经验。

软件系统常常是一个复杂的系统，将复杂的问题逐步分解为简单问题，各个击破。工程思维往往是逻辑演绎思维。实际上，1968年软件工程诞生时，就提倡结构化分析与设计的方法，结构化方法的核心就是自顶向下分解，包括业务的分解和系统结构的分解，先分解再合成，通过将系统分解为模块，厘清和优化系统的结构，实现高内聚、低耦合，然后实现一个一个模块，然后经过单元测试、集成测试，最终合成为一个系统。

工程思维是一种系统性思维，不管是分析问题还是解决问题，而非“头痛治头，脚痛治脚”，要正确又彻底地分析和解决问题，必须具有系统性。工程思维往往把一个软件产品看成是一个系统，有哪些组件构成，内部逻辑结构是怎样的，能否分解为前端、中间件、后端等组成部分，强调系统性解决问题。在分析问题时，不局限于某一个方面，而是尽可能从各方面（如人与组织、流程、技术、环境、管理等）寻找问题产生的原因，类似鱼骨图、故障树分析方法，通过多层分解，不断细化、演绎推理，将思考的触角伸到该主题相关的地方，不漏过任何影响因素，确保分析的完整性。系统思维方式可以帮助我们更好地理解系统内部构成之间的关系、系统与外部之间的关系，例如在软件测试中，系统思维可以帮助更好地理解测试方法：

• 白盒方法：就是探讨系统内部结构，面向系统结构进行有针对性的逻辑覆盖测试，也称为结构化方法；

• 黑盒方法：就是探讨系统外部关系，把系统看成整体，了解系统的数据输入输出、系统运行的环境以及可能受到的限制条件，也称为数据驱动方法。

这里也看到工程思维，不仅是系统思维方法，而且离不开逻辑和数据。

工程思维不是数学思维而是比较、择优的思维，工程方案不是唯一的，一定有多种解决方案，其中必有一种相对优秀的方案，这样又把问题转化为“如何对解决方案的评价”，评价方法成了关键，且这种评价是多因子的综合评价，每个因子会有不同的权重。软件工程也就是在不断优化过程中发展起来的，从量变到质变。

软件工程思维也可以分为宏观思维和微观思维，宏观上要思考将事实与工程原则、价值观和想法区分开来，认识到技术、法律/法规、经济、环境和安全所带来的影响，思考解决哪些关键问题（类似产品思维）、技术解决思路、方案评估标准、制定工程规范的原则、简化工程、如何开展质疑活动等。微观上要思考具体的业务数据、具体的假定、识别和应用适当的模型、质疑不完整或含糊不清的信息、为设计结论提供适当的证据、分析解决方案和测试数据的差异等。

工程思维比较抽象、模型化，是系统的、科学的、量化的思维，经验、类比、评估、迭代等元素也存在，并不断趋于成熟。最后，通过一张表格（表1）了解产品思维、项目思维和工程思维之间的区别，而通过图2了解它们之间的关系，产品思维和项目思维之间交集偏少，而工程思维和项目思维、产品思维交集较多。

表1  产品思维、项目思维和工程思维之间的区别

图2 产品思维、项目思维和工程思维之间的联系