十年产品人,分享产品和项目的思考

编辑导读:产品人的工作,就是在一个一个项目中度过的。不同的产品人,对项目的认知程度不同。本文作者身为一个有10年工作经验的产品人,对产品和项目有自己的思考,从七个方面进行了深入的分析,希望对你有帮助。

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

前言:

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

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

01 定义

1. 项目是什么

有学xí过PMP或者高项的人,应该对于项目的定义是再熟悉不过了——项目是为创造某种独特的产品或X所做出的一次性的努力,其具备的几个特征: 目标性;独特性; 临时性;渐进明细。

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

2. 产品是什么

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

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

笔者所在的X中,存在着两种不同形态的产品,一种为X应用类产品,其专注于解决X场景方面的需qiú,并可在多个项目中进行应用,如电子证照、zhèng务XX等;另外一种为底层组件类产品,其X属性较弱,对于通用属性进行高度提炼并对X进行chāi解,如用户中心、表单中心等。

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

02 思维方式

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

1. 项目思维

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

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

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

2. 产品思维

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

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

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

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

1)用户中心

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

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

03 团队构成

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

1. 项目团队

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

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

2. 产品团队

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

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

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

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

04 需qiú来源

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

1. 项目需qiú

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

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

2. 产品需qiú

产品以价值提升为驱动,需qiú围绕产品价值提升而展开,需qiú来源是多渠道的,X及行业X、市场需qiú、用户需qiú、项目需qiú等等;需qiú调研也是多样化的,X分析、竞品分析、问卷X、头脑风bào、用户反馈等等。

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

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

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

1)把项目需qiú当做产品需qiú去实现

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

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

2)产品不介入到项目实际X需qiú

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

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

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

3)未聚焦产品X,无X扩展产品地图

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

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

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

产品需qiú需要决定做什么,但更要决定不做什么。

05 商业模式

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

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

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

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

  • 预估产品研发投入的人力、时间,产品落地项目投入所需成本——成本结构
  • 是否采用云方式XX还是以私有化部署XX——成本结构
  • 表单中心市场X能力预估——收入结构、投资回报
  • 是否按照功能列表、授泉数量进行可定制化X——定价策略
  • zhēn对不同应用级别产品的X报价、实施运维报价——定价策略

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

06 版本分支

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

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

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

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

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

一主线版本:

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

多长期演进版本:

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

N项目分支:

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

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

2)产品发布及项目应用策略

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

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

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

3)不主动升级策略,重大安全问题主动升级

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

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

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

4)版本X升级策略

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

07 配套工具

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

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

1)shòu前部门

产品X、产品建设方案、产品X彩页、产品报价方案、著作泉、专利等有利于shòu前部门X产品的工具。

2)交付部门

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

08 总结

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

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

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 十年产品人,分享产品和项目的思考 https://www.xiongfawang.com/1293.html

常见问题

相关文章

十年产品人,分享产品和项目的思考-海报

分享本文封面