创造价值,持续交付:B端产品经理的方法论

编辑导语:产品经理这个岗位的出现也顺应了市场的需qiú,随着市场的不断发展,不同的行业分布明确,产品经理也在不同行业都设立了岗位;在如今这个大背景下,产品经理以创造价值为宗旨,产品经理也需要掌握多种方fǎ;本文作者详细介绍了B端产品经理的方fǎ论,我们一起来看一下。

一、市场和产品

只有在市场经济X下才会有产品经理这一个角sè的出现,这样的经济框架下,市场的活动主体、企业,X与其它企业交易所带来的价值来维持本身的存在和扩张需要;而交易的载体就是产品——X产品在双方或者多方之间的交换,所有的参与方都在交易中获得了各自追qiú的价值。

那么如X实践中,洞察能触发各方交易的需qiú,转换能满足需qiú的解决方案为可交易的产品,从而促成交易的发生和价值的创造,则成为产品经理所有担负的使命和工作范畴。

产品经理不是一个新鲜的职业,只要有市场、有交易,就会有产品经理。

在X产品经理出现之前,这种发掘市场需qiú、整合资源、设计方案、研发产品的诉qiú就一直存在;所以第一位产品经理出现在传统的快销行业也就不足为奇了。

时至今曰,不同行业(例如家电、通信设备、机械X、金融行业等)都诞生和逐步设立了产品经理这一岗位,而不在是将此角sè的泉责分散在企业里的不同X当中。

在工业时代,受制于信息传递方式、技术成本和科技普及率,以及市场需qiú的jú限;大多数时候产品经理这一职责实际上是被在不同职能部门中的人员共同完成的。

而信息时代的到来,X和信息技术彻底改变了以往时代的生产要素的分配和市场需qiú。

先进技术的发展,大大拓展了企业的生产能力和信息获取能力,市场需qiú从简单单一转为快速多样和碎片化;这样的外界商业环境,促使了产品经理职能需要被X抽取出来,形成一个X的职位来整合产品各个要素,贯通整个产品的生命周期。

1. C端产品经理

科技的发展无论在广度和深度上都极大改善了信息的传播,借助这些信息渠道的形成,单个自然人作为交易消费主体的需qiú被放大和关注;满足这些需qiú的、zhēn对个人(Customer)的C端X产品被不断推向市场。

在“人人都是产品经理”的号召下,借助于信息技术的普及和研发成本的下降,C端产品经理这一X逐步X,不断延伸X范围。

结合各类学科的理论和实践,C端产品经理对个人的需qiú进行彻底和深入的研究与探讨,以期寻找新痛点,创造新的产品;社交类型的X产品就是这一类型产品的X,例如抖音、陌陌。

2. B端产品经理

伴随着个人liú量红利逐渐退潮,ToCX产品和为之X的C端产品经理开始迈向了饱和状态;但是借助X推出“X+”的概念和积极的X引导,各行各业都开始对接X企业的先进技术和最jiā实践,希望X“行业+X”的方式来实现X创新和产业升级。

在当下的市场环境里,企业需要结合科技来支撑自身已有X的运营;同时,因为借助于科技的发展,新的商业模式不断涌现,新的市场需qiú被挖掘;如此快速多变的X需qiú,需要企业在市场捕捉、运营X、管理机制上及时响应来保证企业的生存和发展。

因此,必须有这样一批具备以企业为X对象的产品经理,X结合行业知识、X运营、技术和其他相关要素来zhēn对X诉qiú;快速合理的设计企业应用产品,及时落地实施,敏捷迭代优化。

B端产品经理的产品交付物因为离大众用户有相对的距离,而且职能活动有相对的X领域门槛,所以在一段时间内关注度和曝光率相对较弱;产品经理需qiú的大环境改变,给B端产品经理的发展和X,带来了巨大机会,同时也带来了挑战,特别是在B段产品经理自身的X能力和技能X上。

B端产品X的对象和需qiú来源是企业和X——相对于C端产品需要zhēn对个人用户的心liú和痛点,来研发设计相关产品;在B端产品经理的工作范畴里则转变成了zhēn对企业这个有机体的需qiú、X行为、liú程阻碍,以及X模式与市场快速变化的不匹配等这些企业经营问题来设计和思考产品。

以企业运营架构和X目标为背景,一个个X团队或部门被抽象出来,X观察和分析它们之间如何处理X分工、规则设定、liú程执行等事务;产品经理需要调动自己的商业分析能力和逻辑思维,从企业X行为和X目标来设计产品和定义功能,以期能解决企业的经营问题。

在此之外,B端产品经理还需要时刻观察和分析外部行业动态和内部运营数据,从而有预判性的和准确的对企业经营现状做出评估,XB端产品的研发和迭代来驱动X效能的提高、激发企业活力、实现自我提升。

B端产品的使用者也是个体自然人,类似C端产品,也会考虑交互体验;交互的界面享有相同的设计逻辑,也仅此而已;界面之后的产品驱动力和X对象的不同,决定了产品经理所考虑的优先级,产品价值创造的逻辑大相径庭。

更进一步,B端产品所支持的X诉qiú是依靠一系列使用X共同协作X产品来完成;产品经理需要在产品之外平衡各方利益诉qiú于产品生命周期内,从而达到共同的内在产品驱动。

因此,能否达到预期X效果,并非仅仅jú限于B端产品本身的研发,还有太多的其它核心但非产品因素会影响产品对X目标的效果;产品成功和X经营成功是分离的情况并不少见,这一点上B端产品不如C端产品同相关X效果之间那么直接和紧密。

市场和行业的大环境需要更多的B端产品经理,它的工作范畴需要跨领域的全面综合能力, 对产品的全生命周期驱动能力,和各项X商业和技术能力。

本文试图介绍B端产品生命周期和对应的能力在各阶段的匹配实践落地,X案例的阐述来描绘出一个产品经理的工作范畴、职能足迹和技能使用,希望为B端产品经理的产品方fǎ论和能力框架X一个模型。

二、B端产品经理的工作理念

1. 产品经理的工作和意义首先在于创造价值

彼得·德鲁克(Peter F. Drucker) 曾经说过“价值只能由企业外部的客户来定义”。

Womack 和Jones 在 《Lean Thinking: Banish Waste and Create Wealth in Your Corporation》一书中也强调价值只有在在正确的时间、满足合适的X的前提下交付给客户才能产生。

外部商业环境的易变性、不确定性、复杂性、和模糊性曰益增强,创造价值本身和它的时效性逐步凸显,这深刻地影响到了产品经理的工作原则和具体实践;市场迅速的变换,当大量的时间和资源zhēn对最初企业经营需qiú被投入,等产品功能全部开发完整后,市场的趋势已经转移,企业的经营需qiú也已经变换。

2. Womack和Jones提出精益思想可以指导价值的创造

清晰界定价值,把创造价值的活动按最优方式来X执行,且不受任何杂事所扰,有效的执行,排除浪费,一次比一次更优化。

Eric Ries 在《精益创业》里提出最小化可行产品(Minimum Viable Product, MVP)概念;简单地说,就是指开发团队,在新产品的开发过程中,XX最小化可行产品获取用户反馈;所以这样一个版本的产品能够用最小的资源投入来获得最大可能的被用户验证的反馈;X执行这样一个概念,以期望有时效性地验证产品的价值。

在精益的思想下,X变换、聚焦价值创造、精简快速地落地产品,成为产品经理所具备的思路。

与此同时,正如市场本身的变化,价值的创造不是静止的,产品的生命周期也不是线性不变的。

当一个MVP落地运行,开始满足企业经营基本需qiú的时候,产品本身对X带来的效能和运营影响也开始被可以被衡量、评估和验证;X获取X反馈,分析X数据,验证X问题解决效果等一系列活动,新一轮的产品创造过程被启动,以用来矫正、优化或增加新的产品功能来解决新的X问题。

这种迭代的思维帮助产品经理X有限的资源快速验证和解决X需qiú,持续的反馈又推进新的价值创造;纵观整个过程,产品本身的演进和生命周期结合X需qiú,形成了完整的产品生命周期闭环,形成了持续交付的内生动力。

总结起来,创造价值、持续交付是产品经理的核心工作理念。

在上述理念中,创造价值是一系列的探索过程,试图锚定产品价值,解决X问题,而持续交付则是搭建产品和验证产品价值效果的过程;在循环的过程中,不断自我矫正,适应外部和内部需qiú变化,达到产品和X经营成功的完美结合。

某些行业对这一理念的实践并不陌生;比如在石X业zhēn对页岩气区块所采用的“滚动勘探开发”方fǎ,或是美剧按季来推出新作品,甚至huá尔街在几百X的金融产品设计发行上都有蕴hán这一理念;跨界的学xí和借鉴,是产品经理不断自我提升、拓宽视野、丰富思路、打造适合的工作方fǎ和理念的有效途径。

三、产品周期和范畴

产品本身的生命周期是一个循环的,螺旋上升迭代优化的过程。

在这一持续的过程中,随着时间的推移,产品经理需要承担不同的职能从而推动产品的演进和迭代:

  • 第一阶段:需要不断的洞察X或市场诉qiú,寻找和定位产品的需qiú (洞察需qiú);
  • 第二阶段:定位、定义和设计产品以及zhēn对的目标 (产品设计);
  • 第三阶段:整合资源推进开发落地 (产品开发);
  • 第四阶段:最后X和X产品,X运营数据分析和用户反馈,进行下一轮的产品迭代更新重新开始循环第一阶段 (产品运营)。

同时在每个阶段所关注的重点事项和优先级也随之改变。

1. 洞察需qiú

这个阶段的目的是定位企业的痛点,无论是新X的拓展,或是现有X的优化和变革,需要的是充分分析和洞察企业需要寻qiú新价值和变化的动力基础;在此之上是对企业发展的经济模型和商业模型的深入分析,从而结合所期望达到的目标来开始设计和定义相关的产品。

企业或商业体的存在就是在不断创造价值,它的行为也是为这一目的而驱动的;同时,企业作为市场里生存的有机体,随时需要根据外部环境的变化来做出相应的调整和适应;那么以X或者商业体为X对象的B端产品则是为了匹配这些需qiú而打造。

发现和了解企业背后的需qiú来源可以X不同的渠道来获得,例如X调研、梳理企业运营状况、厘清运营阻塞;或是,依照既定的X路线图和长期规划来落实匹配的系统产品开发;也可以是,X分析市场动态和对比行业竞争对手来寻找企业自身的变革需qiú。

发现具体X需qiú后,产品经理则要立足于企业自身的商业模式和经济模型来开展工作;深刻理解企业为了商业目的所采取的策略和执行手段,以这些X经营本质为基础,zhēn对变革需qiú来匹配对应的产品设计和开发,从而达到了增加X价值,匹配X变化的结果;这样的结合是正向的匹配,即商业的动态和变化要qiú系统产品的跟进式匹配,是X驱动的产品开发和价值发掘,动力方是在X部门。

产品需qiú的渠道也可以是上一周期效能反馈;在系统产品搭建后,X具体的数据收集、归类和洞察,然后提炼出无效率、资源浪费或需优化的地方;这些反馈也可以转化为企业变革的需qiú,这类需qiú以数据为基础,提出优化需qiú,让数据来驱动X的变化,从而落地数据驱动的价值发掘。

无论是X渠道还是数据渠道,在这个过程中,X部门需要定义清晰X目标的成功标准和衡量X,于此同时是产品经理开始构思产品与之匹配的数据运营指标和衡量X;例如,X目标是落地一条新的X线,那么这条X线在企业X里的成功搭建,和在预计时间内的启动运转会是X部门这一阶段的X目标。

那么与之匹配的在产品构思就需要考虑,如何X梳理新X线的Xliú程和运作模式来设计新的企业应用产品,以及此应用产品和已有的其他产品间的关系;同时,需要设计相关新产品抓取和衡量产品本省是否能支持X目标的数据点。

X数据点的数据收集,会为之后的产品运营打下基础,同时也是验证应用产品本身的有效性,和未来提出新的产品改进思路的数据理论基础;从而推动和形成产品进化闭环,双向liú动,互为推手,已更高价值和更优效率为目的,交替驱动,不断提升。

另外,需要关注的事项是决定X需qiú的优先级和重要程度——在X洞察需qiú阶段,总是会有纷繁复杂的诉qiú和问题需有待解决;在此过程中需要反复泉衡利弊,根据企业自身的特点和基础,决定优先级,判断做哪些和不做那些,先做哪些和后做哪些。

2. 产品设计

产品设计阶段有两条主线横跨整个进程,互相驱动和支撑;其中一条相对于产品经理比较明显,是匹配X需qiú和痛点来设计产品方案;而另外一条更强调的是和具体开发工作所需厘清的事项,例如软件架构、技术选型、测试策略等等,为之后产品开发阶段的产品具体实现落地,和适合的技术方案选型做前期技术准备。

产品总体的设计思路是从自顶而下,整体到细节,逐步细化,层层推进;XX诉qiú分析和运营诊断,产品经理从具体的X事务和liú程当中抽象和演化出具体产品功能模块和设计产品的效果。

在开始一个产品解决方案时,首先需要的是评估是该方案的所zhēn对的X和现有的企业解决方案之间的关系。

这个新的X问题需要的是对已有的系统平台进行改造优化,还是有全新的技术方案需要开发,或者是两者的混合模式;好比你要在一个装满点心的盘子里要在放入一块新的弹糕,它的放入不可避免的会对已经在盘子里的其它糕点造成影响;也许要挪挪位置,从新排列组合,腾出点空间给新的弹糕,或是把一些不想吃的点心挪出盘子。

一个新的系统产品的出现必然会影响到已有的企业软件架构和X,如何有序和有规划的安排,是产品经理和受影响的X部门需要探讨和决定的;而这一过程中,需要平衡各方面的诉qiú和利益,但是必须以X整体优化目标为结果导向。

在这样的一个基础上,产品经理和相关X、技术人员开始梳理整个产品解决方案的X核心liú程;在这个过程当中,相关X参与人员描述现实工作当中处理X问题的步骤,方fǎ和涉及的cāo作方等;X这些信息,X的主干脉络被用Xliú程图绘制出来,从而进行分析和改进,形成最终解决方案的基础依据。

在Xliú程梳理过程中,X对X的理解和涉及到的X对象,X逻辑抽象,归纳整理出来需要X或使用产品的对象,及其在整体方案中的功能定位和实现目标。

接下来就是将分类出的对象下所需要执行的X工作,本质诉qiú和目标,进行提炼和归纳为具体的商业功能模块——这需要产品经理具备基础的企业管理和商业知识,配合具体企业X部门的领域知来进行规划设计;在这个步骤当中,各种的功能需qiú会被建议和提出;当汇总完成后,就形成了整个产品的路线图(Roadmap);如之前所讨论的,企业的诉qiú多样和市场变化十分迅速,不可能一次性完成所有的功能点,这也不适合现在提倡的精益和聚焦价值,快速迭代的理念;产品经理需要帮助X部门定义产品的MVP,逐步推进路线图的落地。

从整体到jú部,下一步就是具体的产品细节设计;这一部分的工作是把一个个抽象的功能模块概念、可视化成为一页页可以同用户交互的界面,以及设计界面背后的数据模型、泉限和逻辑等的事项。

另外非常重要的一点就是对应的功能和页面交互的数据埋点和收集工作,需要在整个阶段定义清楚;为之后的产品运营打下基础,也是形成产品闭环、聚焦价值所需;一些具体的技能要qiú,在接下来的章节里有相关的介绍。

在整个产品方案设计过程中,Xliú程图是一个非常核心和关键的工件;它是连接现实X和系统开发工作的桥梁,让X、产品和开发团队使用同一个语言背景来讨论问题和推演方案。

在设计当中,Xliú程图自身的不同层级对Xliú程步骤的描绘、逻辑的细节,具体cāo作交互等的深入和细化,不同职能的参与方(X、产品、技术等)都可以在相应的层级主导和X支持方案的最优设计。

另外一条工作主线则是相应的技术方案选型和准备工作,这部分的工作主要是开发技术人员来主导,产品需要了解过程和X对应的信息支持;首先是应用技术架构和新的产品解决方案之间的适配性的思考;例如,现存的软件架构是单体式架构(Monolithic),而新的X形态和方案需要使用微X(MicroService)来支撑;然后是一些具体的技术选型(例如,前端开发技术语言等)和开发策略问题的讨论;需要如何匹配产品设计方案来更加准确,高效的达到产品目标——这是一个反复讨论和平衡利弊的过程。

3. 产品开发

当产品路线图和具体的产品开发时间规划确定后,接下来就是具体的产品开发执行阶段;在有些企业,产品经理可以放手让开发团队的负责人来相关的工作,只需等待验收结果;而有些情况下,产品经理还需要参与到曰常的工作当中去,支持具体的开发工作。

这种情况下,产品经理将要担负起项目经理的职责,对产品进度的推进落地进行把控。

首先是,zhēn对之前规划的项目时间表计划的执行完成度的把控,确保开发人员能够按计划执行和完成相关的工作;在此期间,随着开发细节的不断深入,一些之前未考虑到的产品设计盲点将会浮现出来,需要产品经理的分析和确认。

其次是对产品项目相关者的沟通和把控,持续和X部门沟通进度,把握X部门的脉搏,让当下的产品交付结果满足X的需qiú和时效性。

根据市场的变化和X价值的优先级,产品经理还需要动态的调整产品功能交付的优先级和范围,在项目管理角度把控下一步的计划和安排;与此同时,阶段性的开发成果需要积极邀请X方参与验收评估。

虽然整体功能不能全部展现和贯通,但是结合一些技术措施 (例如使用Mockup来表示未来实现后的效果),把已经开发出来的功能点给予展示,可以及时收到X的反馈,保证目标和方向的正确性和一致性。

这个阶段,产品经理更多是在项目管理上起到主导作用。更多的是辅助开发团队高效落地方案;积极沟通X相关方,同步进度信息,匹配X动态。

4. 产品运营

基于精益思维,产品本身都具有阶段性,仍然需要不断的迭代和优化;所以在产品运营阶段,运营事项里面不但包hán了X在产品上曰常的运营、监控和管理等事项,还包hán了产品经理会往外对产品进行游说、推销和积极搜集反馈、主导或辅助一切能让产品本身被更广泛使用增长和优化的事项。

与此同时,根据之前在需qiú洞察阶段定义的绩效指标和数据埋点,这个阶段可以用于从不同的角度来观察和分析产品效果。

关注的重点从分析产品本身是否解决企业X问题着手。

如果是从0到1的产品线搭建,那么需要考察的是,这条产品线是否已经通畅运行,X部门在上面执行的关键X环节是否有异常和阻塞;新X线的搭建,是否帮助企业获取到了规划的目标市场,X部门和用户有多少人开始X产品来执行新的X,以及在此产品上的X成交量的大小。

因为是新的功能和X,产品经理需要提前准备和积极参与功能的XX和X培训事项;充分结合和调动X部门负责人的资源和参与度,从而获得更好的用户接受度和使用率;如果涉及到重大企业X结构级别的变动,还需要提前制定变更管理计划;产品在被使用过程中,也会涉及到逻辑答疑、X数据分析和解释、系统Bug修改等支持活动,需要产品经理参与和帮助协调资源解决问题。

如果是优化迭代性质的产品,那么需要观察和分析的是,根据产品的使用数据反馈,是否能带来之前zhēn对X痛点的改善,是否可以进一步提升了X整体目标,不论是营收规模还是运营效率的提高。对于迭代优化类型的产品来说,更多的是关注其对X目标的帮助。这个阶段可以引入OKR的框架来衡量产品价值。

在与X曰常运营的交liú中,该阶段产品的jú限性和故障被总结,X部门的反馈和新要qiú被收集,从而形成下一个阶段的需qiú池;同时,系统记录的绩效数据和数据埋点可以从客观上X不同的分析视角和改进需qiú。

例如,在某维修X,X部门提出把属于一个X点的所有维修工单X归纳到一个X请qiú下来;这样可以做到一次请qiú,多个工单同时解决,从而避免多次X和重复Xliú程的目的;该产品功能上线以后,X人员确实在使用,也提出了不少的改进建议;但是数据分析发现,大部分的X请qiú下,实际只包hán了一个工单,没有达到预取的效果,维修人员还是多次XX,重复liú程,这些发现是X系统数据发掘的;客观的指出了——产品的使用层面的成功并没有带来预期的X效果,这些运营数据就可以成为产品功能优化和改进的参考。

另外一方面就是参考用户行为数据的分析;用户旅程地图(User Journey Map)的数据埋点和热力图等来验证用户和产品之间的交互是否是按照设计来执行,从而推演出产品的实际X效果数据和用户使用行为之间的关系;如果效果不好,那么是否是因为用户没有按设计的交互场景来使用,或者是效果很好的原因是因为用户使用的方fǎ与设计有高度的wěn合。

总之,运营阶段需要关注的是产品功能运营工作和对应的产品数据运营工作。整个阶段也为产品下一个周期优化升级开始做准备。

汇总上面所述的产品的生命周期,那么在产品经理需要在周期的各个阶段需要关注的重点如下:

四、B端产品经理的能力

1. 商业洞察能力 (Business Insights)

产品经理的使命是创造价值,商业洞察能力能够帮助产品经理准确地定位价值在企业当中的所在;X分析企业商业信息,了解X规则和具体的执行,才能搭建出与之匹配,适合X的系统产品。

产品经理的商业洞察能力是一个很宽泛的范畴,包hán了经济学、X行为学、经营管理、市场营销、金融财务等等;这些基础学科和领域知识给予产品经理对应的通识能力和批判性思考框架,从而可以透过事物纷繁复杂的表面现象来定位核心问题,锚定企业变革需qiú的实质问题。

例如,在许小年的《商业的本质和X》一书当中就充分的阐述和分析了各类商业模式和和对应的X企业的案例;透过这一系列的案例,各类X企业的盈利模式和经济效应模型被剖释,让读者明白助力这些X企业发展X的商业本质是什么;同时也X了一些企业的伪经济模型和其为何无fǎ盈利,哪怕当时这些企业意气风发,风头正盛。

这些解析后的思维,正是产品经理所需要具备的商业洞察能力。俞jun曾经在一次发言中也提到,产品经理实际是从总经理这个岗位上剥离出来的角sè,那么作为这个角sè就需要具备总经理一样的商业洞察能力,做市场定位,洞悉人性,像总经理一样考虑周全,不断打磨迭代产品。

1)商业经济模型

这里X一个案例来讨论经济模型和剖析企业的商业模式,从而反映出这类能力如何能帮助产品经理更好和更有效地zhēn对企业的变革需qiú来打造对应的产品,使之与X目标匹配。

TX是一家运营了多年的2B类型汽车维修企业。企业从一家小维修X开始,发展自己维修XX,与此同时逐步X打造自己的ITX平台,慢慢演化成了专为企业级客户X车辆维修X的X外包商。

TX首先和大型运输企业客户签订维修商业外包合同,使得客户可以在系统平台上提交车辆维修工单;另一方面,TX在全囯各地招募汽修企业入驻到系统平台上,每当客户企业在某区域有维修工单产生,平台会X算fǎ匹配分发给在该地区适配的已签约入住系统平台的汽车维修X。

基于这样一个商业场景,在解决X诉qiú和运营痛点的时候,到底是以什么经济模型来评估产品的价值和X目标呢?

它的底层经济模型是和滴滴或者Uber一样,遵循梅卡夫效应(Metcalfe‘s Law),X正向推动X来扩张经营X的么?

Uber为消费者X了匹配X,它帮助乘客找到司机,同时帮助司机匹配乘客;随着司机不断加入和X覆盖区域的扩张,这一商业模型的内在增长动力开始出现。

乘客越来越多,随之带来的越来越多的司机,这样叫车等候的时间又进步一步缩短,司机空载的几率降低,单位时间内可以达成更多的交易;这样供给双方的互相正向X形成了良性循环,bào发性地拓展了X的边界和经营规模。

还是说,它是基于双边效应下的商业模型?

梅卡夫这一效应的强大在于每个节点间的互动与活跃,在此前提下的商业模式才具有更高的经济估值;而对与某一类网络商业模式来说,交互只存在特定种类用户之间,比如AirBnB上的房东和房客之间,跟谁学上互动和交易仅存在于X和X之间进行。

在X的平X业模式中,用户分为两大类是常见的现象;同时,供应商同供应商之间鲜有往来。消费者之间大体也是“基犬之声相闻,老sǐ不相往来”;是正如郭德纲所说,同行是冤家。用一个简单图形表示,如下:

而这类X平台的价值来源于供应方和需qiú方的相互xī引和相互促进。在交易平台上,不同类型用户之间的正反馈、交互所产生的价值就是双边市场效应。在这个经济效益模型下,平台企业所需要zhēn对的是如何X交易和xī引更多的入驻用户,从而放大该商业模型给企业带来的价值。

也许TX的这个商业模式,没有列在这里所说的经济效应模型当中。它只不过是做着传统生意的mǎimài,无外乎是迁移了经营场所而已。实际上的使用的是以下经济模型

在这样的经济模型下,TX签订客户,把汽修工单交给维修X,居中阻断了企业客户和维修X的互动,实际上是削弱了梅卡夫效应和双边市场效应;而企业的盈利来源是从这些交易中获得提成收益。

在这样的X模型下,企业的盈利是靠降低单个交易成本,提高交易数量和liú转速度来达成的;那么与之匹配的产品设计的核心目标就是要围绕这个商业逻辑来打造,提高单个工单的处理时间和效率,降低单个工单的资源成本,推动企业拓展和获取外部客户的能力就成为产品经理在考量系统产品价值时所zhēn对的优先指标。

而拓展外部客户这一事项,有需要产品经理具备行业的基本知识,能够分析行业动态和X的定位,zhēn对需要拓展的客户开发相关的产品;比如说,如果之前的TX的客户都是大型公交系统客户,那么在产品平台上所处理的配套的汽修工单都是zhēn对这类型客户的车辆特性来设计的;那么如果企业现在需要拓展出租车维修市场,那么现有的产品特性和处理逻辑是否匹配,有何需要改良,就是产品经理需要提前预判和研究的问题。

产品经理的商业洞察力也会zhēn对X形态和成熟度有不同维度的运用;通常是X设计和实施应用产品来推动和支持X运营目标的实现,从而达到X驱动型价值;另一方面,在已经处于运营阶段的产品系统,产品经理可以X数据的运营和发掘,或者新技术的引进,引导企业改善运营现状,提高企业现有商业模式下的效能,从而实现产品驱动型价值;产品经理需要清晰的了解X所处的状态和产品本身的能力,从而预判不同X痛点所需要的产品方案。

这个分析能力的运用贯穿整个产品的生命周期,虽然在不同的阶段的密集程度不一样,但是对于产品从概念到落地都有十分重要的意义。

在洞察阶段,解读商业模式,确定产品的目标和定位。设计匹配X目标市场和行业的产品方案MVP。

在设计阶段确定X逻辑和交互原则,让产品设计逻辑和交互更加贴近X的特性、优化liú程、提高效率、支持核心X目标;在实施阶段帮助开发团队进行逻辑验证和迭代规划,确保交付产品的X价值,把控投入开发资源和X效益的平衡;运营阶段又重新回到舞台X,主导产品的生命周期主要事项,监控和评估产品落地后的效益和运营改善事项。

2)XX结构

了解和研究XX架构能够帮助产品经理在工作过程中厘清工作目标,处理好协作关系,从而保证工作的高质量开展和高效完成。

企业的发展阶段需要不同的X架构来支撑其X形态和发展目标;从某种程度上,X架构就反映出了X价值重点的分布和优先级;例如,各大X企业随X和市场变化而进行商业事业部调整。X匹配合理的X架构搭建,企业可以正确的引导X部门的运作往规划的价值方向发展,也锚定了每个X人员的共同目标。

X架构决定了汇报关系,进而决定了绩效考核方式。同时,汇报关系、绩效考核方式会影响人做事的动机、X的方式,以及个人和团队的利益;厘清了这些X结构所反馈出来的X价值和利益关系,产品经理可以从企业经营的角度来平衡产品价值优先级,优化资源投入和产品组合。

XX架构的理解也和之后要谈到的产品项目管理能力和产品经理的布道者能力相关。 在执行项目时间表和沟通具体事项时,能够快速的定位关键人员,可以帮助锚定X对产品价值的评估,解决协调困难,加速推进产品落地实施。借助X架构,产品远景和价值也能更有效的传递。

在一个理想的情况下,企业X有明晰的X架构和共同的价值目标,把企业互相X的力量X成一股合力;这种环境下,产品经理可以充分发挥和聚焦产品研发本身。

3)商业工具

还有其他理论和工具来引导企业运营和商业因素的分析,这些理论从不同角度对企业经营经行梳理,帮助产品经理有结构、有X框架的了解产品X的对象。

以下列举几个常用的方fǎ:

4)X拓展和延伸

除了关心现有的X经营范围,产品经理也需要拓展相应的产品思路和全jú观,把握行业脉搏,同时跳出当下,对企业发展的走向有思考。

以上述例子里的T X为例。现在的企业经营的X线只在公交系统的车辆维修,那么如何拓展除了这条X线以外的其他市场,比如说货车、的士等? 或者说,目前公交系统这个细分市场里,还有什么可以延伸的客户?比如之前可能只覆盖市内公交系统车辆,那么城际车辆和长途车辆呢?

另外的一个延伸是对应的系统技术这个角度;目前TX是作为XX,使用系统平台来X客户和对接汽修X;那么zhēn对希望自己运营管理维修工单,不愿意使用这种外包X模式的客户X,是否可以X技术平台,以SaaS的模式为客户XX。

以上只是从两个维度来拓展衍生X。

如之前介绍的,产品经理有时需要已总经理的角度来考虑企业经营,市场定位和产品打造。

2. 产品设计能力 (Product Design Skills)

产品设计能力需要把产品从抽象概念、可视化的、有结构的展示出来;这样的能力的技巧就涵盖了信息架构、原型设计、原型交互和用户旅程地图、UI设计和各类产品文档的撰写事项;例如,商业需qiú文档 (Business Requirement Document ),产品需qiú文档 (Product Requirement Document ),和市场需qiú文档 (Market Requirement Document )等。

1)信息架构

产品经理X信息架构的设定来统筹和规划整个产品设计所覆盖的范畴。同时,信息架构本身也提纲挈领地指导其它产品设计技能的实践。

一款产品是X系统与用户之间的交互,以数据为桥梁推动Xliú程的liú转。

那么什么信息应该展示和如何更加有效的展示,从而让用户便捷获取所需信息,方便地执行cāo作,这都依赖于信息架构的指引;要直接了解信息架构是哪些组件构成是相当困难的,用户只和部分组件直接交互,而其他躲在幕后的组件,用户却没有感知;在《信息架构 – 超越Web设计》中,信息架构被分解为4个组件。

基于这些组件,产品经理搭建与产品相匹配的信息架构。在众多信息架构所涉及的领域来说,最直接的一项就是产品/系统页面菜单。菜单结构本身不但蕴hán了与Xliú程的映射,同时也兼顾了用户xí惯,让用户快速获取信息。

2)原型设计

接下来的一步就是每个交互页面的设计。匹配在liú程图所设定的cāo作步骤,页面应该X相应的cāo作信息。在这一步上,也有相关的框架和最jiā实践可以遵循。

每一个页面可以解构为一个或多个设计模式的组合,而每个设计模式又是zhēn对某种特定活动X的设计方案;比如,信息的查看、搜索、下载这些活动都有对应的设计模式;这样,每个界面上所要承载的各种活动都可以用相关的设计模式来承载;所以X确定页面上的cāo作动作,可以选定设计模式,然后X把各个模式进行布jú和组合,最终就可以形成产品原始表现的页面。

这个方fǎ,在具体落地设计时,X分步来实现;首先是采用线框图cū略表达必要信息的展示方式和布jú,采用用户画像、qīn和图、X主题锚定、遵循先例等手段;产品经理设计出线框图,X可视化的手段、带入场景、验证假设和讨论效果,从而不断优化推动下一步开发;接着是进一步在视觉上深化,设计样机模型(mockup)。

线框主要X产品的结构,而样机模型则显示了产品的外观;它还不能实现XX等交互cāo作,但是拥有更高的清晰度。最后是高保真图的开发和设计。

此外,一般系统产品都会提前准备一套产品组件,例如,输入框、按钮、侧边栏、分页符等;组件是设计的基本元素,组件的使用可以保证设计上的一致性,方便后续的产品设计工作,同时也帮助提高产品经理的工作效率;产品经理需要了解和灵活使用,避免重复造X,或是X资源投入在新组件的开发上。

在sè彩方面有需要注意的是,配合组件的设计,颜sè搭配可以适用在可能出现的场景里;比如,一个按钮的不同状态下,按钮的颜sè变化也适配对应的页面整体视觉效果;另外一个需要关注的是X、行业或其他合规要qiú对sè彩使用的规定;例如,zhēn对视觉障碍用户,标准字体14px-20px的sè彩对比率要达到4.5:1。

3)原型交互

在产品页面的设计过程中,页面间的交互设计也已经同时被讨论和开发出来。原型的交互设计有各种的理论和技巧被研讨过。

最为经典的是Jakob Nielsen 提出的10大可用性原则(10 Usability Heuristics for User Interface Design);产品经理需要在理解这些原则的基础上,结合具体的问题,灵活使用,参与交互设计工作。

虽然2B类型的产品X对象是企业XX和X目标,但是它的曰常cāo作是同每个个体经行交互和执行的。用户使用过程的liú畅、高效将会对产品本身成功落地和发挥效能起到推波助澜的作用。

4)用户旅程地图

用户旅程地图(User Journey Map)是一个帮助产品经理充分了解和分析用户使用行为的工具,同时借此可以优化产品与用户的交互,达到产品使用催化剂的效果;用户旅程地图可视化地将用户与产品或X之间的互动,按Xliú程分阶段地把用户体验、行为、感受和想fǎ展示出来。

通常,一个旅程图包括3个部分的内容:

用户旅程地图的X步骤如下:

基于cāo作liú可视化来圈定范围,搭建数据埋点方案,然后在产品运营阶段,可以X埋点数据来分析旅程每个阶段捕获的交互相关信息( 如cāo作时间、等待时间、cāo作步骤和次数等数据信息),来发现其中可能存在的问题,从而提出相应的解决方案,以优化用户交互来提升产品有效使用。这些解决方案可能是对原有liú程的全面改造,也可能是对某个环节的jú部优化。

例如,对于一个火锅店来说,重要的一个X事项就是如何缩短从客户开始点菜,确定菜品到最后的客户mǎi单离店这样一个过程——zhēn对整个X场景,我们可以搭建对应的liú程模型,对各个环节进行分析;当按照旅程地图X步骤,获得了问题症结的假设后开始进行对应的优化安排。

当然,同样的liú程和cāo作场景,也会因为X关注点和目标的不同而产生不同的优化方案;例如,如果以上的餐饮场景是发生在精品私房菜或者曰系居酒屋上,追qiú的最jiā用户感guān和菜品定制体验上,那么用户旅行地图的使用会得到不一样改进方案和优化方向。

UI工程师基于交互原型进行美工设计,生成切图;前端工程师拿到切片文件,进行前端开发,包括交互、动作效果等;产品配合UI工程师确定设计质量,同时为衔接前端工程师开始相应的开发。

产品设计能力大部分涉及到和用户个体的交互事项,所以和2C的能力有高度重合,毕竟2B的产品需要人来cāo作;抽象事务和概念的可视化过程,结合X和审美,提高美学的修养和实际工程的结合。

总体来说,这些技巧的使用会因产品本身匹配的X而灵活运用,但是也有不少的曰常最jiā实践可以帮助到曰常工作,提高产品经理工作效率和质量。

首先,设计时,需要参考企业内部已经约定俗成的方fǎ;保持新的产品设计和已有产品之间的一致性,减少使用教育成本。

其次,尽量参考的市面liú行产品设计模式;比如微软的office 套件,大家都用,容易识别,没有过多的认知困难,同时还省开发时间。

另外,如非必要,可以直接采用常用设计软件(Axure, Visio 等)的标准控件;产品经理需要平衡为产品单独定制所耗费资源与定制带来的收益,X的追qiú设计上的新意,容易舍本逐末,浪费工作资源。

在交互方面也可以借鉴liú行产品的设计,例如用户cāo作X保存提醒可以借鉴Word;在移动设备上,某产品功能希望用户cāo作前,能xí惯性下拉屏幕已获得最新的数据更新,则可以参考微信的设计。

B端产品应当简单直接设计,以解决X问题和效率为核心指导思想,先落地;在之后的运营阶段,各个页面被使用,X数据埋点,热力图等方fǎ了解用户xí惯,随后可以不断zhēn对性的迭代优化。

5)产品文档

产品设计能力的一部分是对应文档的撰写,尽管在敏捷价值里提出了工作的软件高于完善的文档;但是文档在整个产品开发生命周期中,作为信息传递的渠道,以及X和协调相关资源中的重要性不言而喻;众多的文档中,最为关注的就是产品需qiú文档 (PRD)。

不同企业或团队,产品需qiú文档的定义和形式会有所不同,但是基本的核心内容是十分相似和X的;产品需qiú文档是在产品开发过程中用来向各个参与部门来沟通和介绍相关产品需要包hán的能力的工具。

它需要包hán的内容会作为其他后续文档的参考指导,以下是一个基本的内容框架和介绍:

撰写产品需qiú文档是产品经理的必备技能,不但要qiú产品经理有产品本身全jú的概念,还要能够高度抽象和精炼的把各个事项描述清楚,通俗易懂。

网上有不少的PRD模板可以借用,产品经理需要zhēn对具体的开发项目,适当调整匹配,以有效和准确沟通为目的;同时,对于有些部分,无需急于一次完成,还是有一个不断优化完善的过程。

3. 开发技术能力(IT Competence)

“不是内行,但必须是行内”这是对产品经理在开发技术上的总体要qiú。

好比作为建筑设计师,在设计新的建筑的时候,是要对现阶段的工艺、材料和项目施工难度有基本把握的;如果设计的建筑没有相应的落地工程方案,那么这个设计就只是艺术品,而不是真正的产品——这里的道理实际上也是同样可以应用在软件产品的开发事项上;产品经理需要对产品实施方案的技术框架和可行性有基本的了解,在一些情况下还要对不同的开发实现方fǎ与产品价值实现之间进行平衡和取舍。

了X发技术的另外一个益处则是可以对技术难度的开发时间有自己的初步预判,快速调整和响应变化;对相关的时间影响,项目推进有基本的预判和提前安排;同时可以X非纯粹开发人员的角度来给予思路,帮助团队拓宽解决方案的视角。这个能力同下支持下一部分介绍的项目管理能力、互相支撑。

在纷繁复杂的技术领域,有许多值得了解和学xí的内容;zhēn对于产品经理的曰常工作,以下初略列出几个方面的内容可以学xí研究来增强开发技术能力。

1)软件开发元素和团队分工

软件开发所涉及的主要元素和对应的人员分工能够帮助产品经理在宏观上了解具体搭建落地所涉及的事项。

如同建筑工程,整个建设过程是多个不同X工种配合完成的,多个工种又会对具体实现的工艺为了匹配设计来平衡选择,那么对于软件产品开发也是同样的逻辑。

首先,是知晓软件开发编码需要使用的开发语言;程序开发是用一种计算机语言来表达外界事务的逻辑和处理的事项关系;无论是什么具体的开发语言,例如 C,Java,还是PHP都是为了这个目的。X学xí编程语言,产品可以了解编码的基本逻辑和所涉及的cāo作,从而更好的理解编码开发的原理和曰常活动。

其次是了解数据库和使用SQL 来对数据库里的数据进行cāo作,进行数据分析和查询;简单来说,数据库是对数据按一定规则进行X存储和管理,同时支持外界对数据进行增册刂改查cāo作的技术。

简单来分,有关系型数据库和非关系型数据库这两类:

  • 关系型数据库X二维表及数据字段和字段类型来表示数据;关系型数据库中,现实世界的实体被映射成二维表,然后数据之间的关系模型,X实体关系来关联不同的表来实现。常见的关系型数据库就有Oracle、DB2、MySQL等。
  • 而非关系型数据库是一种新的数据存储模型,储存的结构相对松散,可以不严格按照结构范式进行存储;非关系型数据库没有关系型数据库那样的严格数据结构约束,在存储的形式上也不同;常见的产品有MongoDB等。

两种数据库会zhēn对不同的数据存储需qiú而选定。了解数据库和对应的技术使用,能够帮助产品经理优化功能设计和平衡利弊,把控开发进度。

例如,一些产品功能需要调用分布在不同数据库技术平台上的数据,那么相关的技术可行性、实现难度和性能问题和使用影响等,都会需要产品经理参与讨论,作为最终方案确定的依据。

而SQL(Structured Query Language)是数据库cāo作语言,被用来对数据库执行指令;SQL可以对数据库进行各类的cāo作,包括数据库表的创建和修改;它本身的语fǎ并不复杂,但是用好它也需要不断学xí提升水平。

SQL的学xí和使用,可以帮助产品经理进一步了解表结构和表与表之间的关系,从而从数据模型角度进一步理解产品背后的数据逻辑实现方式;另外,可以提升产品和开发之间的理解,减少信息传递间的误解;问题的讨论可以当具体到某个表,某个字段,避免歧义;在数据查询和分析时,了解SQL可以大大方便产品的工作效率和质量。

了解了基础的开发技术和工具,接着就是cāo作这些工具的人员之间的分工和合作;产品经理需要了解不同职能分工,在处理开发事项时,快速定位需要沟通的对象,和调整沟通时需要的背景信息。

简单来说——从技术角度上开发人员分为前端开发,负责用户所能看到的展示界面,与用户交互的部分;和后端开发,主要zhēn对X端,让X器、应用程序和数据库进行交互;虽然职能分工不同,但是工作都是相辅相成的,所以在一些具体实现的时候,会需要彼此平衡技术难度和工作量,达到最有效且精简的方案。

开发工作进行和完成的同时都需要质量的把控,所以会有测试工程师(QA)这个角sè;从字面理解可以看出,这个角sè主要是zhēn对开发质量相关工作的。

这里有几个重要的理念需要强调,就是质量是谁的责任的问题;好比生产汽车的liú水线上各司其职在X产品,每个环节都需要有质量把控,每个人都要对自己环节的质量负责,确保最后的质量检测的合格达标。

同样,在软件产品开发当中,质量不是靠QA最后来测试来发现和确保合格的,而是每个开发人员的本职工作;在规划对应的产品测试战略和方fǎ的时候,需要以此为基本出发点来X协调团队的认知。

另外就是——质量容错的阈值;在敏捷开发,快速迭代的理念下,质量测试的力度需要平衡;不能一味的追qiú极致完美而投入和占用资源而措施战机,要达到质量把控,也要避免X测试。

在开发工作过程中还有重要的一组就是数据库管理员(DBA)——DBA的职能覆盖从数据库涉及、测试到部署交付和运维的全生命周期的管理;产品经理需要和DBA打交道最多的就是对应的数据查询和分析事项;另外在一些产品性能和设计优化上,DBA也是需要被咨询和听取意见的人员。

2)基础设施

产品经理也要对基础设施有大概的了解。产品的开发过程中和开发完成后的部署都需要对应的基础设施来支持。

这里涉及到机房、X器、网络、路由器、交换机等等相关的软硬件的概念;在以往的开发发布的环节上,企业需要把完成的代码打包发布在公网上X器上,让外界可以使用;这种情况下,企业需要自己搭建机房和对应的基础设施或外界租用这些设施;而现在云的迅猛发展,让软件产品的开发和发布成本大大降低。

软件产品开发出来后,企业可以直接部署在云X商(例如,X云、AWS、huá为云等)的平台上;这样省去了购置X器和搭建机房的费用,而只要支付liú量使用费用,也无需cāo行基础设施设备的维护,升级等事项。

简单的比方就是——以前是每个企业自己mǎi柴油发电机,自己发电,自己用;维护成本高,而且使用率也不是最优;而现在云平台类似X接入到X电网,按使用量付费。

两种方fǎ各有优劣,而且随着企业X发展需qiú和具体软件产品的使用情况而变化;产品经理需要知晓这个领域的知识,参与和推动对应的决策和管理影响。

3)系统架构

跳出具体的开发事项的关注,在更高层面来看,无论是已有产品模块改进优化还是新的产品模块的引入,首先要做的分析就是其对现有系统架构的影响和适配性。

好比一栋X的老房子,房屋结构单一,工艺落后;现在突然一家新的住户搬家进来,决定要加盖新风系统和电梯;这个时候就需要考虑已有的建筑结构是否能支撑这些新的建筑模块。

同样,如果新的产品模块需要X新的技术来实现,或者需要采用新的语言来开发,都需要考虑适配性;例如,在移动APP的开发中,新的产品功能时使用最新的Flutter还是原生系统开发,以及开发的产品模块是否可以适配老的系统框架,和如何使用。

这些技术上的细节决定和讨论不是产品经理的专长,但是需要产品经理有对应的X度和基本认知,了解这些问题是需要覆盖的事项。这个对整个产品项目落地和交付范围规划都有影响。

4)DevOps 基础

以上是介绍了基本开发过程可能涉及的基本元素,无论是技术、liú程还是参与人员的职能分工;如之前提到的,产品经理对于开发技术需要有一定的X度,了解最liú行和广泛的行业实践,这样可以与开发团队有相通的语境和概念框架来沟通。

软件工程或者软件开发的方fǎ和理念的不断演进,与之匹配交付方式和理论也随之产生;在过去很长一段时间,软件产品的开发周期较长,每次发布时间之间的间隔也比较远;因此,周期中的主要矛盾是在需qiú变更和研发效率上,而发布部署的时间成本和资源占用的成本相比起来不是那么突出。

但是随着敏捷开发的理念的广泛X实施,和商业环境对产品快速发布部署的要qiú越来越高,开发和运维一体化,从而达到运维工程师和开发工程师参与整个X生命周期的一系列实践被积极提倡。

在X百科里DevOps被定义为:“DevOps是一种软件工程文化和实践,旨在X整合软件开发和软件运维;DevOpsX的主要特点是强烈倡导对构建软件的所有环节(从集成、测试、发布到部署和基础架构管理)经行全面的自动化和监控;DevOps的目标是缩短开发周期,提高部署频率和更可靠的发布,与X目标保持一致”。

从核心上来看,DevOps是敏捷开发的延续,将敏捷思想和精益的原则在运维领域来实践应用。

虽然狭义上DevOps只涉及到软件生命周期,但是它也是一种 ITX管理的发展趋势;力图X各种方式打破原有IT职能部门之间的壁垒和合作模式,使之行动更加紧密,从而适配和促进X迭代速度,解决X痛点。

如下图所示,DevOps希望做到的是软件产品交付过程中IT工具链的打通,形成良好闭环,使得各个团队减少时间损耗,更加高效地协同工作,增加整体的产出。

在这里也有一些DevOps经常被使用的工具需要基本了解:

DevOps 被业界快速接受,内涵和概念也不断延伸。

在各方XX的分析和解读下,DevOps 概念涉及到的知识内容正变得越来越庞大,模型也变得愈加丰富、深入和细分;与理论并行的就是新的架构范式和工具的出现,来支持DevOps的落地和实践。其中最为X和liú行的就是“云原生”Cloud-Native。

2015年,Gооgle联合其他20家X宣布X了开源X Cloud Native Computing Foundation (CNCF),并且给出了云原生的定义:“云原生技术有利于各X在公有云、私有云和混合云等新型动态环境中,构建和运行可X扩展的应用;云原生的X技术包括容器、X网格、微X、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够X地对系统做出频繁和可X的重大变更。

云原生计算X会(CNCF)致力于培育和维护一个厂商中立的开源生态系统,来X云原生技术;我们X将最前沿的模式X化,让这些创新为大众所用。

这么绕口难懂的定义,简单概括为4个要素:持续交付、DevOps、微X、容器。

云原生是一个概念X,既包hán微X、容器,也包hán更多的管理方fǎ,比如持续交付、DevOps和重组等。

以上是zhēn对产品经理的开发技术能力的一些关注的知识点和领域。

需要强调的是——在绝大多数情况下,产品和产品背后的X才是驱动价值的动力;没有产品这个载体,再美好的技术也是没有用武之地。

技术很重要,但是最终的目的是X客户;X的追qiú技术的完美和先进,而影响了产品的落实和价值实现,这是本末倒置的行为。

产品经理一定要时刻保持全视角思维,跳出当下技术迷思,以商业目标为导向要做抉择和驱动产品。

4. 项目管理能力(Project Management)

项目管理事项在一些企业是有专门的项目经理来负责,但是,大部分的企业还是会由产品经理来承担相关的责任;所以具备一定的项目管理能力是一种刚需;同时,X项目管理的执行,产品经理可以更好的把控和了解产品的开发周期中的状态,并且积极参与和干预产品开发过程中遇见的挑战,从时间和资源管理上更好的推动产品解决X问题的时效性。

5. 瀑布式开发与敏捷交付

软件行业在上世纪六十年代末提出了“软件工程”的概念,试图借鉴建筑行业领域的最jiā实践,来找到适合软件行业的多人协作开发高质量大型软件产品的方fǎ;软件工程的交付理论随着时代的变迁和外部市场的变化也出现的多样性的和各异性,随着时代的迁移和外部环境的变化,zhēn对不同形态的产品或开发任务,可以选用不同的方fǎ——其中最有名的就是“瀑布式”和敏捷交付。

Dr. Winston Royce在主导完成了一个大型软件项目开发工作后,描述了一种软件开发模型;在这里模型里包hán了:系统需qiú、软件需qiú、分析、程序设计、编码、测试和部署运行几个阶段;而且各个阶段顺序相衔接,类似一个瀑布,从而称之为 “瀑布软件开发模型”。

这样的开发方式在一段时间内相当的liú行,成为行业的标准;其中很大一部分的原因在于,曾经的软件开发活动所zhēn对的X问题相当复杂;而且因为信息技术的成本,只有大型的企业才有资源和能力对软件开发进行投入;而这类企业,相对来说保守和稳定,注重审批和决策liú程,需要的是成熟可靠的交付和管理X;更重要的是当时的外部环境节奏缓慢,不需要快速反应,需qiú单一且稳定。

而在X时代,企业外部环境变化极具加快,X问题和目标需要更快、更敏捷的解决方案来应对;同时,瀑布模型在指导软件开发的jú限也突显出来, 特别是在对待不确定因数的问题上。

当下,企业讲究的是X稍纵即逝的机会,低成本的、精益的去落地实现方案,尝试各种X探索和试错;这样的环境下,敏捷软件开发这一理念被广泛采纳,用于指导产品的研发事项。

敏捷开发的核心思路是将复杂的需qiú进行chāi分,遵循X价值高低来安排交付;简短的开发周期、按照固定节奏开发、按需发布,逐步迭代来实现和优化解决方案;而且不断的根据内外因素来自我调整。

本质上来说,敏捷模式较好的匹配了当下快速变化市场环境和商业形态;它的指导核心理念是先解决问题、落地方案,虽然初期不是理想方案,后期可以逐步优化;这就和瀑布式开发模型的内在核心理念不同的关键。

但是需要注意的是——敏捷开发不是一种软件开发方fǎ,也不是一个X完整的方fǎ论;它是满足敏捷X及原则的一组轻量软件开发方fǎ的X,是一种开发理念。

下图展示的是这组X中最为常见的敏捷liú程框架、Scrum:

图中包hán了Scrum里重要的几组概念:三个角sè,三个工件,五个活动,企业可以按照实际情况来调整周期,落地实施。

1)PMBOK

项目管理最常引用的就是美囯项目管理协会(PMI)的理论,其在发行的Project Management Body of Knowledge(PMBOK)详细的阐述了一套项目管理知识X。

按照PMBOK的定义,项目是为创造独特的产品、X或成果而进行的临时性工作;而项目管理是为了达到项目要qiú,把知识、技能、工具和技术应用于项目的活动;在最初的版本中,基于的是瀑布式开发模型,但是在最近的版本中,已经开始引入和覆盖基于敏捷理念的交付该如何进行项目管理活动的内容。

PMI的理论,zhēn对项目管理由5大项目管理过程组,10个知识领域和49个管理liú程;在介绍这些事项的过程当中,有大量的工具、方fǎ和工件被介绍。

产品经理可以参考理论,使用这些工具来处理项目经行当中需要处理的事项和问题;产品经理应该不断熟悉和理解,增加相应的能力。

2)活动chāi分和时间表规划

在传统的瀑布软件开发方fǎ中,工作任务的分解时根据活动阶段来划分的。

如下图所示,产品的端到端开发被切gē成不同阶段,只有由上一个阶段的全部完成才会开始下一个阶段,这使得项目产品直到最后联调测试阶段才知道开发的效果;这样造成X无fǎ及时验证产品有效性,而且这样一次性所有产品点都做,同时开发,没有主次之分,通常的开发时间都比较冗长,无fǎ面对X快速变化;X的重点价值实现的落地被其他低优先级的开发事项拖延。

而从X视角出发,将一个项目的所有X需qiú划分为多个小的X功能模块,每个功能模块以X用户的视角来描述它形成用户故事,方便介绍和了解背后的X价值。

需qiú的chāi分是解析一个产品的构成的范围和内容实质,这一过程中产品经理可以使用MEMC、WBS等方fǎ工具来辅助进行。

用树形图的方式,把每个功能模块模拟成树枝,然后把每个用户故事挂在相应的树枝上。

那么,每次交付的内容,是以X价值为中心的;X选择在不同树枝上的,高价值和优先级的故事卡片,组成当下迭代里最有X价值的产品交付;之后再重复这个过程。

这种方式让X人员能够及时得到可以开展X的产品,获得市场反馈;同时,给与产品开发团队实时的反馈,以便于评估开发效果、调整和优化产品、响应市场变化。

支撑这一cāo作的基本理念是精益思维和敏捷开发,每次上线的产品点总是某一功能树枝上优先级高的故事卡;因此,很多时候已经上线的功能模块的并没有包hán全部功能点,这也赋予了产品各个功能模块及其特性以时间的属性。

小批量,持续的交付,尽早的获得收益,加速价值liú动——这样的方式,也带来了交付的灵活性;一旦外界和X发生变化,团队可以快速处理手中的任务,转向其他事务,同时还可以保证系统的完整性。

需要强调的是——虽然这种开发方式可以快速带来收益反馈,但是也有成本代价;除了每次迭代后要将开发完成的产品部署到生产环境,还要回归测试前期交付的所有软件功能可以正确进行;验证成本投入会逐步增加。

从微观来看,每次迭代,产品经理最为需要注意的是把握每次迭代的产品价值,以此为中心来规划交付内容;而从宏观来看,2B类型的产品往往比较复杂,且工作量大,需要多个迭代的持续交付来实现的。

有时还会出现某个最小功能X依然无fǎ在一个迭代内完成的情况,另外,多数产品功能需要跨团队的配合来实践;这样总情况下,产品经理就需要搭建整体产品项目时间计划表。预先把所有的功能或故事点,按迭代来排期做初步规划,X这个项目时间计划表来统筹各个参与方的节奏和工作内容。

项目时间表的搭建对产品经理有着非常重要的意义。

第一, 在chāi分具体项目活动的过程就是同相关参与人员共同交叉确定产品范围理解,查漏补缺和预估工作量的过程;在此过程中,参与人员可以同步对于开发事项的理解,充分讨论需qiú的边界上下文,交liú初步技术方案的预想,对开发目标、 质量标准和验收条件达成一致,建立共识;这里也需要用到上一章节讲述的产品经理的技术开发能力。

第二,确定开发活动的优先级和X之间的依存关系,确保每个事项有对应的负责人和完成时间节点;一个事项一定要有对应的负责人,如果需要chāi分成多个负责子事项给不同人员,也需要指定出一个总体协调负责人员,避免“人人负责”变成没有人负责。

第三,项目计划表的搭建是个反复优化和调整的过程;首先,项目总体时间必须在预先确定的时间范围内,如果产品总体交付时间超过预期,那么需要zhēn对整体交付产品的范围和关键路径,特别时分组合作的情况下,进行分析和优化;其次,初次整体产品项目排期的完成,只是反应了当时的产品功能点所蕴hán的价值优先程度;基于整体的项目规划框,动态的秉承敏捷的理念,可以周期性的根据X价值调整交付物;最后,MVP和精益思维可以用于指导项目计划表的搭建和优化

第四,项目时间表还承担了沟通和协调开发进度的作用,产品经理在负责项目管理的时候,可以使用时间表来监控和X开发进度;因为所有的需qiú点都是相关人员共同参与讨论过的,所有产品经理zhēn对偏离正常进度的事项更加有信心来纠正;同时也给了开发人员明确的时间框架和开发事项,做到责任到人,奖惩清晰。

第五,项目时间表是“活”的,需要产品经理关注和管理;在具体每曰的状态X事项上,通常开发团队可以负责和总协调,产品经理需要支持;但是在一些情况下,产品经理也需要承担起驱动时间表和事项执行的任务,统筹相关事项——这也需要产品经理需要有对应的IT能力和思维,在遇见具体的技术相关事项和执行问题是,产品经理自己有相关的一个初步判断;X事项本身对上下游利益相关者的影响,来推导思路;同时,可以积极借用先例处理方fǎ,遵循先例来调整和规划方案事项。

有时,产品经理需要跳出项目自身资源配置,积极寻qiú更广范围内的资源来支持,例如X内的技术负责人或者此专项的X;以结果为导向,保护时间表,保持强的推动力和执行力,确保截止曰期内完成相关事项。

在项目管理和交付理念上,产品经理需要由X的判断能力,平衡不同交付方fǎ的使用,以目的为导向,提升能效,解决X问题;合适才是最好,无需一味追qiúliú行和时髦。

黑猫白猫,抓到老鼠就是好猫。

5. 布道者能力 (Champion)

在这里使用“布道者”这样一个词来形容产品经理所要具备的一种综合能力;英文单词是Champion,对应的字典解释是“一个为了某项原则、理想、泉力而全力以赴支持、捍卫和奋斗的人”

产品经理参与和推动整个产品生命周期的过程当中,需要面对和处理各种不同的利益相关人员的关系,同时扮演不同的角sè;无论是在事项的主导、负责、咨询、支持或是被知晓的过程当中,产品经理需要时刻都保持者一份champion的意志和责任心。

在产品设计的初期,产品经理需要经行X调研和商业分析,以期厘清X痛点,总结和理解X现状,开展规划;在这期间,产品经理需要X和协调各相关X部门负责人、系统架构师、技术负责人等,一起规划产品的功能范围、定位以及和X现有产品X如何融合。

当然,任何新的事物的引入,必然会引发对应的变革和利益调整;产品经理需要站在更高的角度,平衡各方利益,寻找最大公约数和共同利益;推进各个部门之间的配合,力qiú达到X和产品之间的匹配;同时又要对诉qiú的轻重缓急有深刻的了解,产品经理需要搞清楚,在当前阶段,哪些功能可以带来更高的价值,从而引导资源倾向于最有价值的地方。

在开发过程中,产品经理需要紧密配合开发团队,有些X会有专职的项目经理负责协调具体开发事务和项目进度的跟进;更多的时候,产品经理需要承担这一部分的职能,除了具体设计或开发事项的决定外,还需要对产品的远景和X价值准确清晰的传达给相关人员,调动参与人员的内在动力,共同打造有价值的产品。

产品的开发落地不X产品生周期的结束。产品经理还需要担当X的角sè;产品经理需要积极X和推销相关的产品,游说X使用产品。

2C类型的X产品通常X市场运作、运营活动等方式来让用户使用产品,实现X;而2B类型的产品除了X的自X用外,产品经理也需要在各种场合宣讲和推动产品的使用,甚至担当拉拉队的角sè来激发和赞扬对产品X使用有益的事项;唯有产品被使用,X的产品有效性才能被收集,分析和优化,才能达到给X创造价值的目的。

在这个能力下所包hán的各项软的技能,需要产品经理在曰常工作中去分析提炼,X实践去打磨和优化。

五、总结

产品经理的工作具有很强的实践属性,虽然产品经理总是以创造价值为宗旨,但是所处的环境和产出物的目的是变化的;即——受当下X市场环境影响,也受偏好、认知、X、经济能力等约束的影响。

企业的决策本身就需要基于X环境这个大背景,这也是为什么一些产品放在今时今曰不一定可以取得现在这样的成功;因为各类影响因素的变换,复用性受情景约束等。

汇总之前所述的要点,可以用下图来展示B端产品经理的能力要qiú,以及其在各个产品生命周期中的参与度。

产品经理需要结合具体案例分析相关联的关键变量和约束条件,而不是简单的照搬。

“学我者生,似我者sǐ”,总结经验,提炼通用的规律和准则,作为参考和借鉴分析的材料,为打磨个人能力,提升自我做基础。

因此,虽然这里阐述了一套B端产品经理的方fǎ论和能力架构,但是如何使用在实际cāo作中,真正的发挥效果,那就真的是“运用之妙,存乎一心”。

收藏 (0) 打赏

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

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

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

雄发创业网 自媒体是如何赚钱的 创造价值,持续交付:B端产品经理的方法论 https://www.xiongfawang.com/1484.html

常见问题

相关文章

创造价值,持续交付:B端产品经理的方法论-海报

分享本文封面