【想成为一个优秀的软件企业，要培养自己的团队具有良好的产品思维、项目思维和工程思维。本文就产品思维、项目思维和工程思维进行讨论，帮助读者更好地理解项目管理、产品管理和工程管理之间的区别和联系。】
产品思维
软件研发，是开发出一个软件产品（软件服务可以被看作是一种产品，为了叙述方便，不严格区分产品和服务），借助产品的特性为用户服务，解决用户的问题，向用户输出价值。做对事情比正确的做事方式方法重要，创造（或定义）出一个正确的产品，比软件开发方法和技术更重要，所有产品思维更重要，是我们首先要讨论的。
我们经常说，做产品要对市场进行调研，清楚市场的需求；要了解客户，特别是要知道客户的痛点在哪里；甚至要懂得人性，知道人性有什么弱点。可以看出产品思维的出发点事市场、用户。“做产品的逻辑就是做人的逻辑，人生逻辑大于商业逻辑”，产品思维首先是基于用户的思维，具有同理心，要去研究目标群体——人的心理结构是什么样的？目标群体内心是如何活动的？顺应用户的潜意识，了解用户的真实想法，从而了解用户的真实诉求。 基于人的心理反应倒过来去想我的产品要怎么做，要遵循哪些人类共有的心理逻辑。
解决什么问题？真有这种问题吗？
为谁解决？可以进一步细分市场吗？用户画像
有多少人需要？市场规模多大？
产品具体价值（流量、转化率、现金流等）多大？
之前人们是如何解决的？我们的解决方案有优势吗？
产品思维就是用户思维，体现在从从用户角度想问题，扮演用户角色、设身处地为用户着想，理解用户的真实想法，帮助用户实现目标，注意观察用户行为，注重用户体验。有时需要透过用户的言语、绕过用户心理的防范，才能够获取用户的真实需求。具有同理心，我们就更能从用户角度去思考，设身处地为用户着想，理解用户在什么情况下会有一种愉悦心情、在什么场景下会表现出愤怒和恐惧。
产品思维的核心是产品及其使用者。关注做什么产品、关注做对产品——做出的产品确实是用户想要的，而不关注如何做。可以不断试错、不断迭代、不断演化，但必须向着客户期望的方向努力，逼近客户所想要的产品。产品思维关注产品结果，关注要交付的产品特性。虽然产品思维不关注项目的进度，但关注交付的时间，因为交付时间和市场需求要向匹配，不能过早、也不能过迟，在市场需要的时候适时交付相关的产品特性。正如产品愿景板所示，产品思维关注：目标群体（用户）、需求和商业价值。
产品思维是一种联结主义的学习思维。产品联结客观世界、过去与将来，产品联结当前用户以及其周围的潜在用户，产品思维关注和用户/市场的交互，能够随时向用户学习和适应市场，而且我们清楚市场具有不确定性，用户更具有不确定性，要看到这种不确定性，清楚市场的变化所带来的风险，所以不仅要持续关注市场、关注用户，而且尽力看透市场或用户喜好的发展趋势，预测市场或用户心理的变化。所以，产品的思维还要有前瞻性。
产品思维是一种持续迭代演化、逐步求精的动态思维。关注用户的反馈，积极获取用户的反馈，和用户保持交流。产品推出后，用户开始使用产品之后，就会产生真实的感受，至少有一部分用户愿意分享使用软件产品的感受，这些感受更能真实地反映软件产品这方面的特性是否适合用户的需求。如果获得用户的正面反馈，产品经理获得经验和自信。如果用户反馈是负面的，说明产品有问题，产品经理要反思自己忽视了哪些细节、哪些地方思考得不对等等。所以，产品思维关注用户的反馈，促进我们和用户交流、促进我们不断反思，不断提升产品的价值。
产品思维是一种创新或创造思维、发散思维、跨界思维，如勇于探索、敢于试错、打破平衡。产品需要创新，区别于其他产品，能够吸引用户。这种创新思维有助于我们从不同的维度（商业模式、用户操作方式、用户界面、流程、技术等）去创新，但这种创新思维，往往是用户驱动的，和用户思维结合起来。
项目思维
产品思维关注做对产品、做出用户所需要的功能特性，而项目思维更关注项目自身的目标实现，关注项目的产出，重点关注已定义的功能或软件的交付，甚至不管交付物是否来自错误的需求。项目思维时间观念比较强，把任何活动看作有始有终的、明确的时间段过程。在这段时间内要完成特定的目标——交付物及其质量要求，需要预算、资源（人力、物力）等，但同时预算、资源、时间都是有限的，构成项目的约束条件，要做好进度、质量、成本等控制，最终实现按时、按质、按量交付软件，虽然我们希望多快好省地完成项目，但进度、质量、成本等要素之间是相互制约的，所以项目思维是一种平衡性思维，具有艺术性（平衡艺术），要在多个目标、约束条件之间达到相对最佳的平衡，如图1所示。一般情况下，保持质量不受影响，就在任务、进度和成本之间平衡，加快进度就需要增加研发人员（增大成本）或者砍掉一个功能特性（减少要做的任务）。甚至有时为了赶进度，要交付的功能特性一个也不能少，加人也不是好办法（甚至更糟糕，见《人月神话》），只好牺牲一些质量。
图1 项目管理的平衡思维
项目思维是一种计划的思维、逻辑的思维，一开始就假设，由假定到推理（估算），设法弄清楚如何去实现预期的结果，最终得出项目规划——计划。项目管理者就是通过事先周密的计划来规划各项活动，创建一个具有目标要求和工作节点的时间轴。虽然我们强调计划是一个动态调整优化的过程，但计划书毕竟是大家达成的协议，对应大型项目，有时改变一个计划也是不容易的，项目的计划性特征还是很显著的。项目思维强调计划的合理性、客观性、完整性或系统性等。项目计划体现了客观理智地分析项目的范围、任务、风险等，科学地估算工作量，按阶段划分来设定合理的进度、安排合理的资源，制定出切实可行的计划。这种项目思维是有章可循，先有计划，后按计划执行；重视度量，收集数据，用数据来说话。
项目思维也是一种风险防范思维。有一本项目管理的书《与熊共舞》，说明在项目管理中，风险无处不在：
需求会经常变更，给设计、编程、测试等活动都会带来影响，常常给进度带来风险；
软件研发工作量的估算一般也不够准确，也会给进度带来风险；
由于业务复杂性，导致研发人员对业务理解的偏差，这给产品交付的质量带来风险；
单元测试不足会给系统测试带来潜在的影响，测试覆盖率不确定，自然是产品质量潜在的、比较大的风险；
代码内部逻辑的复杂性、代码不规范，给软件后期维护带来风险。
……等等。
风险很多，无法将所有的风险置于管理之中，需要关注严重的风险，即那些发生概率比较高且一旦发生会带来较大的负面影响或损失的风险，如图2所示，即优先考虑高度风险区的风险，然后再考虑中度风险区的风险，而不用关心那些低度风险区的风险。所以，项目思维另一个特点是按优先级高低来处理问题。
图2 不同优先级的风险划分示意图
项目思维也是管理者的思维，注重沟通与管理，不仅是团队内部的沟通协作，还注重项目利益相关者（项目干系人）的沟通，管理好干系人的期望。沟通是管理的润滑剂，协调各种矛盾，提升团队士气，调动团队成员的积极性。强调过程监督和控制，不断调整测试计划，试图达到最佳状态。
概括起来，项目思维是计划的思维、平衡的思维，也是风险意识很强的思维，注重假定和推理，更注重在不同要素之间获得最佳平衡，以应对会出现的各种风险。项目思维也是管理的思维，管理各种资源，加强沟通和协调，不断推动项目的进展。
工程思维
产品思维偏于感性，喜欢从人性、社会性角度去思考问题，从“人机交互”角度去思考，从用户、用户行为、应用场景、业务流程等角度去思考问题。而工程思维属于理性思维，喜欢从方法、技术角度去思考问题，从“数据交互”角度去思考，从数据流、业务规则、业务逻辑、异常条件、异常数据等角度去思考问题，如：
用户不登录能看到哪些数据？
系统登录时需要用户输入什么数据？
对用户名和口令建立哪些验证规则（字母大小写是否敏感、口令长度、含哪几类字符等）；
口令或用户名输错了给予什么提示？
口令输错多少次，账户被锁定？
用户可能会输入哪些特殊字符？
黑客有没有可能暴力破解口令？
黑客能否在字符串类型域中输入script脚本？
从这样的思维过程，我们可以看到工程思维的轮廓。工程思维之所以是理性的、科学的和逻辑严密的，是因为工程本身具有系统性、复杂性、集成性和组织性，而且会涉及人们生命安全和财产安全。工程方法强调以人为本、安全第一，要考虑自然、环境、经济、管理、人文、伦理、社会、技术，做到工程与自然的和谐、工程与社会的和谐，持续优化，达到高度的安全性。
工程思维类似项目思维，我们常常将“工程”和“项目”组合起来，形成“工程项目”，但工程思维不同于项目思维。从一个工程看，资源、成本、质量这些概念也都在，似乎也离不开资源调剂、成本控制、质量保障等要求，似乎也是工程思维的出发点，工程思维也关注质量和效率、关注流程，按步骤、按流程实施工程。实际上，两者有比较大的区别，项目思维侧重从资源调度、进度控制、风险管理等来实现项目的目标，包括计划、平衡、沟通等，侧重管理。如果简单地说，项目思维更多体现在管理思维上。而工程思维侧重用工程技术与方法来解决问题，从提出工程问题到分析问题、解决问题，更多体现了工程方法和系统工程的思想。
工程思维，首先是一种技术思维，更多是想通过技术手段、通过工具来解决问题。产品思维定义一个软件产品，工程思维就会想如何选择合适的技术架构、如何设计系统内部的逻辑结构、选择什么编程语言来实现，从而在性能、可靠性、安全性等方面满足软件系统的要求。追求高性能和高可靠性、用机器来模拟人的行为（机器人）和推崇机器学习等，这些其实都是技术思维的体现。就一个直播App的开发为例，产品思维会考虑用户如何使用这个App以及如何获得良好的体验，如用户不注册就能看到几个精彩视频选段和目前受欢迎的主播列表，一旦点击某主播头像，这时要求用户注册账号，注册完后就能点击某主播头像、进入主播房间看直播，看直播过程中可以互动（点赞、打赏、和主播聊天等）。而工程思维想如何实现这样场景，满脑子是音频和视频、视频存储格式、摄像头兼容性、视频编码（encode）、视频解码（decode）、内容分发（CDN）、音视频同步、最大容量、性能瓶颈、高速缓存、播放器SDK等。
工程思维是一种抽象思维，需要将复杂的工程问题进行简化，去掉不必要的信息，抓住问题的主要特征，构建起能够描述问题的抽象模型。模型可以指为了解决特定视点而简化某些事物的任何抽象，从而成为不同研发人员或不同团队之间沟通的最好载体。借助模型，不仅有利于团队沟通，有助于我们看清问题的本质，而且建立了一种大家认可的标准，从而有效、彻底地解决问题，如过程模型、架构模型等。
如何看清软件研发过程，从而建立研发流程？这就需要建立软件过程模型，包括瀑布模型、V模型、RUP统一过程模型、XP模型、Scrum模型、BDD模型等；
如何让我们看清楚系统的架构？就是借助架构模型来表达团队共同的系统结构关注点，有助于软件系统的结构和设计中做出特定的权衡。软件系统架构，通常用不同的视图来描述，如UML将系统架构分为静态视图（如类图、对象图、组件图、部署图、包图等）和行为视图（用例图、序列图、通讯图、状态图、活动图），而C4 模型使用容器、组件和代码来描述一个软件系统的静态结构（如图1所示）等。
工程思维是一种上下文驱动思维，上下文（context）在软件工程中是一个非常重要的概念，无论是选择怎样的过程模型、还是选择怎样的系统架构。图1中系统架构的第一层“软件系统”就是系统上下文，需要考虑该系统与用户、其他软件系统之间的关系，明确系统之间的接口，实现安全、无缝的集成。构建一个软件新系统，需要考虑的上下文，不仅是与之相联、相关的已有系统，还需要考虑其它上下文因素：
谁使用这个系统？有哪些用户？用户数量多大？同时在线用户有多少？
处在什么业务领域？是性命攸关还是使命攸关的行业？
是产品线开发还是一次性的项目？是现场开发还是外包到乙方的项目？
是全新版本开发还是在已有版本上进行版本升级（功能增强、修改等）？
团队掌握哪些开发技术？其技术水平如何？
公司的薪水是否有竞争力？团队是否稳定？
不同的上下文，工程的解决方案是不一样的。
工程思维是一种分析性思维、批判性思维，也是逻辑演绎的思维。软件工程的核心是分析问题和解决问题，在这过程中有很多假定和推理，需要我们做出正确的判断，在做出判断前，要质疑，所以软件工程中分析性思维或者说纵向思维是主导性思维，虽然也需要创造性思维、水平思维。分析性思维强调假定、推理过程，如果假定有问题、推理过程有问题，就需要质疑，所以常常需要用批判性思维武装我们自己的头脑，在评审需求、评审设计时，应具备良好的批判性思维，质疑其中模糊的、有歧义的描述，质疑某些缺乏可信度的信息来源或脱离实际的假设，从而发现需求和设计中的问题。如果假定或推理不可信，那么结论就不可信；如果觉得结论不靠谱，那问题就出现在虚构的假设或不合理的推理之中。例如，在综合考虑各种因素之时，许多情况下需要运用批判性思维：
利益相关方所提供的信息是否出于自己的利益？所以更相信利益无关方所提供的信息；
如果支持结论的证据不是客观事实或缺乏可信度，那么这个结论就值得质疑；如长时间从事于某工作的这一事实，并不等于对此拥有丰富的经验。
软件系统常常是一个复杂的系统，将复杂的问题逐步分解为简单问题，各个击破。工程思维往往是逻辑演绎思维。实际上，1968年软件工程诞生时，就提倡结构化分析与设计的方法，结构化方法的核心就是自顶向下分解，包括业务的分解和系统结构的分解，先分解再合成，通过将系统分解为模块，厘清和优化系统的结构，实现高内聚、低耦合，然后实现一个一个模块，然后经过单元测试、集成测试，最终合成为一个系统。
工程思维是一种系统性思维，不管是分析问题还是解决问题，而非“头痛治头，脚痛治脚”，要正确又彻底地分析和解决问题，必须具有系统性。工程思维往往把一个软件产品看成是一个系统，有哪些组件构成，内部逻辑结构是怎样的，能否分解为前端、中间件、后端等组成部分，强调系统性解决问题。在分析问题时，不局限于某一个方面，而是尽可能从各方面（如人与组织、流程、技术、环境、管理等）寻找问题产生的原因，类似鱼骨图、故障树分析方法，通过多层分解，不断细化、演绎推理，将思考的触角伸到该主题相关的地方，不漏过任何影响因素，确保分析的完整性。系统思维方式可以帮助我们更好地理解系统内部构成之间的关系、系统与外部之间的关系，例如在软件测试中，系统思维可以帮助更好地理解测试方法：
白盒方法：就是探讨系统内部结构，面向系统结构进行有针对性的逻辑覆盖测试，也称为结构化方法；
黑盒方法：就是探讨系统外部关系，把系统看成整体，了解系统的数据输入输出、系统运行的环境以及可能受到的限制条件，也称为数据驱动方法。
这里也看到工程思维，不仅是系统思维方法，而且离不开逻辑和数据。
工程思维不是数学思维而是比较、择优的思维，工程方案不是唯一的，一定有多种解决方案，其中必有一种相对优秀的方案，这样又把问题转化为“如何对解决方案的评价”，评价方法成了关键，且这种评价是多因子的综合评价，每个因子会有不同的权重。软件工程也就是在不断优化过程中发展起来的，从量变到质变。
软件工程思维也可以分为宏观思维和微观思维，宏观上要思考将事实与工程原则、价值观和想法区分开来，认识到技术、法律/法规、经济、环境和安全所带来的影响，思考解决哪些关键问题（类似产品思维）、技术解决思路、方案评估标准、制定工程规范的原则、简化工程、如何开展质疑活动等。微观上要思考具体的业务数据、具体的假定、识别和应用适当的模型、质疑不完整或含糊不清的信息、为设计结论提供适当的证据、分析解决方案和测试数据的差异等。
工程思维比较抽象、模型化，是系统的、科学的、量化的思维，经验、类比、评估、迭代等元素也存在，并不断趋于成熟。最后，通过一张表格（表1）了解产品思维、项目思维和工程思维之间的区别，而通过图2了解它们之间的关系，产品思维和项目思维之间交集偏少，而工程思维和项目思维、产品思维交集较多。
表1产品思维、项目思维和工程思维之间的区别
图2产品思维、项目思维和工程思维之间的联系
