笔者 09 年开始实习至今，分别经历了互联网产品→定制化项目→项目型产品三个阶段，在第一次转型时由于只是开发人员，对于转型的理解并没有那么深刻；在第二次转型时，由于已是负责人，需要站在更高的层面上思考以及转变，对于转型之痛深有感触，对于转型过程中所走的弯路也印象尤深，故以此文来记录自己的理解，叙述的内容带有工作领域的局限性，也希望与大家共同探讨。

前言

在开始撰文之前，先以福特创始人Henry Ford的一句话（真实性存疑）作为开头，此句也成了我在产品设计时的座右铭，“If I had asked people what they wanted, they would have said faster horses.”。

短短一句话，其实已经道尽产品思维的特性，产品越深入，对其越是感同身受。接下来，笔者将从定义、思维方式、团队构成、需求来源、商业模式、版本分支、配套工具等方面分享产品与项目之间区别和联系。

个人理解

1 定义

项目是什么

有学习过 PMP 或者高项的人，应该对于项目的定义是再熟悉不过了——项目是为创造某种独特的产品或服务所做出的一次性的努力，其具备的几个特征： 1) 目标性； 2) 独特性；3) 临时性； 4)渐进明细。

落到我们实际的工作中，软件项目的本质就是为了实现合同约定的建设内容或用户方的需求，通过程序开发\部署的方式将其以软件的形式实现，并将其与交付物一并提交给用户。

产品是什么

对于产品的定义，百科中给出一段相对绕口的描述——产品是指能够提供给市场，被人们使用和消费，并能满足人们某种需求的任何东西，包括有形的物品、无形的服务、组织、观念或它们的组合。

如果用更加贴近于软件开发方式来描述的话，那么软件产品是面向解决业务场景需求，持续迭代，并可在多个项目中被复用的一类具有通用性的软件形态。

笔者所在的公司中，存在着两种不同形态的产品，一种为业务应用类产品，其专注于解决业务场景方面的需求，并可在多个项目中进行应用，如电子证照、政务服务办理等；另外一种为底层组件类产品，其业务属性较弱，对于通用属性进行高度提炼并对业务进行拆解，如用户中心、表单中心等。

举一种实际生活中的例子描述这两者的区别：项目就是一次性杯子，目的是为了解决单次喝水的需求，目标明确且一次性；而产品就是陶瓷杯或者水杯，面向的场景是解决多次喝水场景的需求，而且还会根据喝水、喝咖啡、喝酒等不同场景衍生出不同的子产品。

2 思维方式

在笔者从项目负责人转变成产品负责人时，把思维方式从项目级别提升到产品级别是最大的挑战，两者之间的区别与联系很容易能让人感觉到迷惑与无从选择，就其内容而言，两者没有高下之分，但如果应用错了场景，就容易把简单的事情复杂化，而把多层次的内容应付了之。下面谈谈项目思维与产品思维之间的差异。

项目思维

在大多数传统软件开发公司中，基本上都是秉持着项目型思维在进行着公司的日常工作及软件的研发，那究竟什么是项目型的思维呢？

所谓项目思维，其思考的方式为——“完成”，其目标为——”任务“。

项目思维重点关注如何实现任务的完成，从时间、成本、范围、质量等多个相关指标上推动工作的进展，实现任务交付物的产出。具体到实际工作中，因为重点在于完成任务，项目组成员所有的工作都在围绕着项目的成功交付及验收推进，当接到项目需求时，考虑的是如何完成这项需求，完成的时间、成本，以及如何能够更快且保质地交付到用户方。

产品思维

相对于项目思维，产品思维，其思考的方式为——“透视”，其目标为——”价值“。

产品思维重点关注于挖掘有效的根源性需求，从业务场景的角度构建解决方案，提升产品价值及竞争力。具体到实际工作中，就是我们在进行产品构建过程中，重点不是在完成增删改查功能的堆叠，而是去透视需求背后的业务场景，什么样的应用痛点驱动需求的产生，如何去构建解决方案可以更好解决需求，提升产品价值并且复用到多个项目中。

项目思维，类似于被动驱动，以完成任务为目标；而产品思想，则是自我驱动，以提升产品价值为目标。

举一个在实际工作中曾经发生的案例来说说两者之间的区分：

• 用户中心

我们在某个用户中心分支的时候接到一个需求——”*在部门属性中添加中央业务指导部门代码和中央业务指导部门名称两个属性，属性对应于国家某平台接口，需要在 xx 前完成*“， 明确的用户需求以及时间节点要求，由于当时时间赶且团队缺少产品经理，我们小伙子就直接将这个需求在分支上实现了，并按时提交给对应的需求提出方。到此为止，这就是项目思维，以完成任务为目标。

在后续对于产品项目需求进行归纳中，我们发现了此需求，从表面上看，这只是一个增加两个部门属性的需求，但深入去分析挖掘后，可以发现这个业务指导部门属性的出发点是为了解决政府部门横向管理过程中条线管理缺失，实现业务部门的垂直化管理，如公安业务线、烟草局业务线等；而且省里面也会有实际的应用情况，县一级的一个部门，对应的上级部门可能是多个，比如 mh 县文体旅局对应的上级部门分别是 fz 市文旅局+fz 市体育局，在具体的执行中，是不同的处室对应到不同的条线管理；在用户中心使用上，也会有按照条线展示部门、用户、通信录等需求。所以在最终的产品设计中，我们在主线版本部门中扩充所属条线属性，并且增加条线管理，调整了相应对外服务接口。透过现象看本质，通过业务场景解决方案提升产品价值，这就是产品思维。

3 团队构成

产品和项目在定位和目标的区别，也很直观体现在团队构成上，包括对于团队人员素质相关要求上，建立好的团队结构能够让工作进展得更加顺利。

项目团队

项目团队一般会有以下必备成员：项目经理、技术主管、需求分析员、开发工程师、测试工程师、客服人员（按合同要求）。

很多实际的项目中，一人多职情况较为普遍，项目经理往往还兼着技术主管或者需求分析员的职务，而一些开发工程师也兼着需求分析员或客服人员的角色，而测试工程师大部分是由公司测试部门在关键时间节点上介入项目现场的。

产品团队

产品团队一般会有以下必备成员：产品负责人、架构师、产品经理、交互设计师、开发工程师、测试工程师、配置工程师、项目对接人员。

很多人会把产品经理跟需求分析员的职责定位混淆了，其实两者的区别很明显，需求分析员是带着项目思维的人员，适用于项目的推动；而产品经理就是要用产品思维带着产品持续往前走，提升产品价值的人员。

在团队构成稳定性的趋势上来说，产品团队相对于项目团队较为稳定，项目团队由于项目进展的情况，有可能会出现中间某一阶段需要大量人员，而其他阶段只需要少量人员继续推动项目的进展；产品团队由于产品的持续迭代、产品在项目中应用的持续增长，所以正常情况下产品团队不会出现人员的大幅变动。

在相同岗位的成员素质要求上，两者也不尽相同。项目团队对于成员的要求为能够快速进入状态，具备较高的承压能力，除了本职工作外，还能够兼任一些其他岗位的职责，比如开发工程师往往还需要兼着需求分析的工作；产品团队对于成员的要求是本职工作需要精，知其然且知其所以然，比如开发工程师需要去考虑代码的执行效率、代码并发能力、代码的容错性设置、代码规范等内容，通过自身专业上的深入提升产品的质量。

4 需求来源

定位上的不同、思维方式上的不同，也直接决定了需求来源的不同，清晰地区分项目需求与产品需求，才能避免在工作开展中陷入是是而非的矛盾与麻烦中。

项目需求

项目以客户的需求为驱动，通过用户访谈、问卷调查、可用性测试等多种方式明确需求内容及边界，并以书面\其他记录的形式协同客户对于需求进行评审和确认，项目组根据明确后的需求进行定制化开发。项目需求在本质上，其实也就是文章开头福特那句话的缩影，用户角度的需求就是faster horses。

就其整体而言，项目需求的特点很明显，来源明确、范围明确、工作量明确。

产品需求

产品以价值提升为驱动，需求围绕产品价值提升而展开，需求来源是多渠道的，国家及行业政策、市场需求、用户需求、项目需求等等；需求调研也是多样化的，政策分析、竞品分析、问卷调查、头脑风暴、用户反馈等等。

产品在需求管控上，更加趋向于敏捷模式，小步快跑，允许试错，以市场接受度决定需求的正确与否。

项目需求本质上是获取到“faster horses”信息，而产品需求本质上是获取到“faster”信息，并且考虑除了“horse”之外，还有其他什么方法措施可以满足这类需求。

在实际工作中，很容易存在几个认知方面的误区：

• 把项目需求当做产品需求去实现

项目应用是产品非常重要的一个需求来源，因为项目需求来源于最终使用软件产品的用户，反映了用户在实际业务场景中的应用痛点、行业性需求等多方面因素。

但这并不是说项目需求等同于产品需求，项目需求为项目所服务，具有项目区域性、业务性以及临时性等特征；在将项目需求沉淀为产品需求时，需要全面衡量可复用度、价值提升程度、已有业务场景破坏度、潜在隐性需求等等多维度影响因子，在此基础上对于项目需求进行产品适应性改造之后，才能够吸纳到产品需求中。

• 产品不介入到项目实际业务需求

结合前面的描述，项目工作内容不等同于产品工作内容，在实际的工作开展中，需要理清产品与项目之间的界限，避免产品做着做着变成了在做项目。

但这并不意味着可以矫枉过正，不能说产品版本发布且提供了二开机制支持后，在项目落地过程中的个性化改造就是属于项目组的事情，与产品团队没有关系。

为了长期的战略考虑，将产品团队与项目实施交付团队职能划定是必然的，但是产品团队与项目团队需要建立良好的沟通渠道，包括前期的产品方案提供、产品部署操作、产品升级操作等工作，还包括落地后的新增需求分析、解决方案指导、功能二开协同等，产品团队需要主动拥抱项目需求，以实战检验产品的优劣，通过应用成效进一步完善产品自身，定期对于项目需求轮询并归纳到产品需求，才能避免闭门造车还自我感觉良好，也避免由于产品团队和项目团队的冲突导致产品无法收集到项目需求。

• 未聚焦产品业务，无限制扩展产品地图

需求蔓延不止是在项目中需要去预防管控的，同样在产品中也是存在类似的问题，而且由于产品需求的不确定性，需求蔓延的可能性更加突出。

在产品推进过程中，产品经理的首先要务就是要十分明确产品的定位、产品所要解决的业务场景，在此原则上对于产品需求进行分析，分析切记不能浅尝辄止，也不能偏离主线业务无节制蔓延。

例如在财务辅助系统中，工程类付款涉及到工程所属节点以及核算的结果、人工成本报销单涉及到整体人力资源薪酬的核算与发放、付款涉及到与银企系统的对接对账等，但是这并不是说我们产品也要覆盖到工程管理、人资管理、银企等业务，而应该是聚焦在我们产品的主业务上。

产品需求需要决定做什么，但更要决定不做什么。

5 商业模式

天下熙熙皆为利来，天下攘攘皆为利往，抛开我们在可研社会效益中写到的那些伟光正，最终目的还是要实现公司效益的增长，但产品与项目创造效益的方式不尽相同。

在项目方面来说，谈不上商业模式，更加侧重的是如何降本增效，以项目验收为目标，采用多种可取的方法降低项目的人力投入、提高项目组成员的生产效率、加快项目验收时间节点，缩短公司的投资回报周期、并提高投资回报率。

而产品方面来说，承载着公司更高的期望值，追求溢价以及长期收益，通过战略投入加码未来，是公司进行产品化的根本动力。所以在进行产品规划设计的时候，需要考虑清楚商业模式的方方面面，包括产品成本结构、产品收入结构、产品定价策略、产品投资回报周期等信息，简单点说，就是需要能让人相信产品能够产生效益，而不是反向操作浪费资源。

在进行表单中心产品规划时，我们就表单中心的商业模式进行以下思考：

• 预估产品研发投入的人力、时间，产品落地项目投入所需成本——成本结构

• 是否采用云方式提供服务还是以私有化部署提供服务——成本结构

• 表单中心市场销售能力预估——收入结构、投资回报

• 是否按照功能列表、授权数量进行可定制化销售——定价策略

• 针对不同应用级别产品的销售报价、实施运维报价——定价策略

如果产品研发之前没有经过全面的商业模式论证，模糊的商业模式不止是让产品未来打了个问号，也让公司的销售无从下手。

6 版本分支

由于项目是一次性的产品，所以其版本管理相对来说比较简单明了，并不涉及到复杂的版本迭代及分支管理，在此文中我们不讨论项目的版本及分支管理。

由于产品会在多个项目中进行应用、项目应用中二开功能存在可复用、项目应用中二开功能属于个性化定制等等多种情况，产品的版本及分支版本管理制度，对于产品团队来说，直接决定了后续的产品运维的工作量。当然，在具体的管理制度制定方面，属于仁者见仁智者见智，没有标准答案。

以笔者所负责部的产品主线版本以分支版本管理制度侧重点与大家分享：

• 一主线版本、多个长期演进版本、N 个项目分支

熟悉 Java 开发的同学应该对此策略极其熟悉，我们采用的就是跟 JDK 版本管理相似的策略。

- 一主线版本

在产品的演进上，保持着产品只有一个主线版本，以主线版本作为产品的最新发布版本，按照版本规划内容定时进行封版发布。主线版本与产品内容规划保持一致，会根据产品演进的情况增加新功能、现有功能的优化改造、现有功能的移除等。

- 多长期演进版本

在主线版本的基础上，我们还会根据项目应用情况，选择项目应用较多的版本进行持续的长期演进工作，侧重于 bug 修复、功能完善的支撑工作。

- N 项目分支

由于项目难以避免存在个性化的需求，我们基于对应产品版本建立项目代码分支，并独立进行项目分支建设。

如在API网关产品中，我们存在的主线版本，目前已演进到3.2，但同时我们仍在对项目应用较多的1.3版本进行长期演进支撑工作。

• 产品发布及项目应用策略

在产品迭代上，采用分版本的迭代策略，根据研发节奏保持两个月或者三个月一个大版本发布，小版本根据实际情况进行发布，发布的同时并将升级更新履历日志同步到产品的在线文档中，供其他使用产品人员实时查看了解。

在新项目的使用上，默认以最新的版本版本分发。但这并不是绝对的操作，也会根据项目背景、项目所需功能、项目其他产品版本信息等，针对性选择之前的某个版本进行应用。

在产品的应用上，产品经理或者配置人员管理好产品应用的台账，包括项目情况、产品版本等核心信息，方便后续升级或者问题追溯。

• 不主动升级策略，重大安全问题主动升级

对于项目所使用的产品版本，采取不主动升级策略，只在采用的版本上进行适应性升级，而非跟随产品迭代步骤进行同时升级，避免由于升级导致项目建设范围不匹配或者引发其他潜在的问题。

对于协同的产品，比如作为政务中台核心支撑的API网关产品，我们在产品升级的同时也会主动通知对应的产品部门，保证作为一体化产品对外版本的一致性。

不过在涉及重大安全问题或者重大缺陷时，我们会采取主动升级策略，告知对应的项目组/产品组存在的问题及发送对应的补丁进行修复。

• 版本平滑升级策略

其实版本平滑升级策略，不管是产品还是项目，都是很基本的要求。对内，需要能够支撑产品自身的平滑升级，既要能够从 1.2 升级到 1.3，也需要能够支持 1.2 升级到 2.0；对外，需要能够保持接口的延续性，能够保证产品的升级对于现有的功能、现有的接口没有影响，而不是每次更新，周边对接系统都要同步修改。

7 配套工具

公司往产品化方向发展的时候，很多以前看似可有可无的人力投入就会一下子变得特别的突出，比如用户中心产品安装部署，除了自身应用安装之外还涉及到 JDK、MySQL、zookeeper、Redis 等中间件，且还需要对于配置参数、系统参数进行优化调整，正常项目组具有编程人员经验对产品进行部署，平均需要一天半才能完整部署一台服务器。按照目前用户中心产品五十多个项目应用数来说，这个人力投入就是极其可观的数量，针对此情况，我们采用基于 ansible 的一键式部署方案，十几分钟就可将用户中心部署完毕，大幅度减少产品部署的人力成本。

一个优秀的产品，除了需要考虑产品自身的发展之外，也需要去为产品的应用推广进行优化，降低产品应用推广实施的难度及工作量。

• 售前部门

产品白皮书、产品建设方案、产品宣传彩页、产品报价方案、著作权、专利等有利于售前部门推广产品的工具。

• 交付部门

一键式部署支撑、产品培训视频、产品二开机制方案、产品使用手册、产品运维手册等有利于项目组更好进行产品交付实施的工具。

总结

笔者自 16 年底开始转型负责产品之后，业务类产品及组件类产品均有涉猎，有成功也有失败，目前部门所负责的四个产品已在全国七十多个项目落地应用，支撑中台、大脑、省市县多级应用，并为外部系统提供稳定可靠赋能。

此文是对于自己最近几年转型心得体会的一个总结，希望能给在转型产品路上迷茫的人一丝帮助，产品与项目既有联系也有区别，把握好这里面的微妙关系，利用产品思维打造具有核心竞争力的解决方案，创造car。