B端产品解决方案设计方法论:以业务和需求为导向_第1页
B端产品解决方案设计方法论:以业务和需求为导向_第2页
B端产品解决方案设计方法论:以业务和需求为导向_第3页
B端产品解决方案设计方法论:以业务和需求为导向_第4页
B端产品解决方案设计方法论:以业务和需求为导向_第5页
已阅读5页,还剩5页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

B端产品解决方案设计方法论:以业务和需求为导向B端产品解决方案是产品开发的指导性框架,想要顺利进行B端产品的开发,产品解决方案是必不可少的。本文从上至下对产品解决方案进行了梳理,并给出了设计过程中的建议。解决方案通常是指针对某些已经体现出的,或者可以预期的问题、不足、缺陷、需求等等,所提出的一个解决整体问题方法的方案(一般以文档形式体现)。对于B端产品的研发过程,解决方案是针对业务本身或者解决某些业务问题,所提出的产品设计方案。在B端产品研发和实施过程中,解决方案是十分必要的。不同于C端产品的研发,需要采用MVP模式,强调小步快跑、敏捷迭代、快速试错。B端产品的需求对应的业务和问题,都是固定存在的。所以,我们需要在产品研发启动前,就设计解决方案,作为研发过程的指导性框架。解决方案从顶层定义了,我们针对需求要做什么产品,该怎么做,什么时间完成。同时,解决方案在项目立项时,是重要的基石;在进行与客户进行商务沟通时,是获得客户信任的重要凭证。在现实场景中,B端产品的解决方案,有多种用途。比如,作为商务或者销售活动的材料、作为产品立项的依据、作为项目的整体设计等等。针对这些使用场景,产品经理一般需要设计三类解决方案:整体解决方案;细节解决方案;技术解决方案。这三个方案既有独立的用途,又是相互关联的。整体方案细化和添加更多的内容后,就是细节设计方案;技术方案很多时候,是作为细节方案的其中一部分存在的。当然,对于B端产品的解决方案,重要的针对需求、业务和问题的产品设计,而不是写出一份文档。所以,作为产品经理,如果我们要出具一份解决方案,我们就有两部分工作要做:一是设计解决方案;二是写作解决方案。对于写作,其实只要我们完成了「设计」工作,就相对比较简单了。因为,解决方案对内容只要求简单明了即可,在某些时候我们甚至可以用PPT制作解决方案。而设计解决方案,是一个系统性的过程,通常需要多个角色甚至部门参与,特别是细节方案和技术方案的设计。一、整体解决方案现在我们从整体性解决方案开始,介绍如何设计产品解决方案。首先,整体性的解决方案主要包含产品背景、核心流程、产品定位、产品架构、功能模块、演进蓝图、资源投入。这些内容,并不是完全固定的,需要根据我们所处的场景适当调节。其核心目的,是要构建出一个产品的从无到有的过程,以及将这个产品呈现给他人。在设计解决方案和产品时,B端产品建议采用自顶向下、由粗到细的思路。下文在来分析一下各部分应该如何设计,含有那些内容。产品背景产品背景主要介绍产品的行业背景和需求背景,以及产品可行性分析。这部分内容,主要是产品经理需要将产品的业务调研、业务诊断、需求分析的内容展示出来。业务调研是指业务的战略方向、经营模式、管理方法和业务模式;业务诊断需要体现出,客户对于业务提出了什么问题,我们从业务中分析出了什么问题;需求分析则是结合用户提出的需求,去分析场景、角色和业务。在进行呈现时,一般呈现依据和结论既可。核心流程核心流程是需要分析并展示出业务的核心流程。在分析核心流程时,需要与角色分析结合,最终需要以跨角色的流程图展示出业务的核心流程——核心流程是之后我们设计各个业务系统,各个产品功能的起点。产品定位产品定位是对产品的整体性描述。简单来说,就是要描述清楚我们要做一个什么样的产品。这部分也需要与需求、业务和问题结合,阐述清楚针对什么业务做产品,产品解决了什么问题,带来了什么价值。产品架构产品架构指的的产品的整体性结构。在产品架构设计时,我们需要首先进行业务架构的分析,然后设计产品的系统结构,再梳理出产品的核心系统,最后基于以上内容设计出产品的架构图。业务架构分析,主要是分析出针对业务,产品需要哪些系统;系统架构设计,是分析出系统间的组织形式和交互过程;核心系统梳理,是指分析和定义出产品的最核心的系统,其它系统都是围绕该系统运作的。最后,可以用架构图来展示展示我们产品的架构。在设计产品架构时,除了依赖于业务的分析,还要结合我们的经验。同时,还要考虑一些产品的非业务场景。比如,兼容老系统的业务系统架构,与外部系统对接的产品架构等等。功能模块在设计产品架构的时候,我们已经分析出了我们的产品需要哪些系统。现在我们需要在对这些系统进行细化,设计出构成这些系统的功能。一个系统可能是由多个功能构成的,所以我们也要整理出功能的层级和交互关系。功能是对需求和业务理解并分析的最小维度。如果说产品架构是产品的骨骼,功能就是填充在骨骼中间的血肉,并构成一个个系统。演进蓝图演进蓝图通俗点说,就是迭代计划。迭代计划是以功能为维度来设计的。B端产品的迭代规划设计,是以实现业务闭环为目标,即先建立核心可用业务,再逐步扩展到整个业务流程,直至完成业务闭环。基于业务闭环的迭代规划,强调由核心业务向整个业务拓展,业务的方向和规划,一定是明确和可靠的。设计好功能的迭代计划后,需要根据技术的可行性调研,然后与研发人员合力,明确演进蓝图的时间表。在设计迭代计划时,我们还需要根据业务背景和团队背景,预留出一定的时间作为异常情况的缓冲区间。在设计演进蓝图时,我们还可以根据产品开发的标志性事件或者业务小闭环节点,来设计出相应的里程碑计划。成本预估成本预估就是评估在整个产品开发过程中,我们需要投入那些资源,换算成成本是多少。成本估算的评估要和演进蓝图结合,划分到完成那期功能需要投入多少资源。资源投入除了整体性评估之外,也需要细化到具体的开发人员组成、服务采购等具体的研发投入。二、细节解决方案细节方案多用于B端业务型产品开发。在我们进行产品研发的过程中,往往还需要更为细致的解决方案,来指导我们技术人员的开发。细节方案,也可以看做是PRD等研发文档的Plus版本。在整体解决方案的基础上,需要增加业务建模、数据建模、功能设计、技术方案、产品原型设计、附加文档,将整个解决方案,细化到产品细节层面的设计。技术方案下文单独分析。业务建模业务建模主要梳理详细的业务流程。包含各子业务的流程,各系统的业务流程,各功能的运行流程,还要使用用例图分析出角色和系统的关系。完成业务建模后,我们对整个业务的脉络就非常清晰了。之后,依据业务的建模,我们才能完成功能逻辑的设计。业务建模是产品经理对业务梳理和分析的最终成果。数据建模数据建模主要是分析系统中的角色和各个实例,在产品的系统是有那些数据字段构成?实例间存在怎样的关系?再将实例和关系抽象成数据模型——数据模型会关系到数据库表的设计,影响到功能设计和技术方案,所以我们要尽早设计数据模型。在设计数据模型时,我们要保证模型的全面性和扩展性。而分析数据模型时,最典型的就是使用ER图来进行分析。功能设计在整体方案时,我们已经分析出了产品包含哪些功能。现在,我们要具体设计每个功能。设计功能时,要明确功能要展示哪些数据,功能有那些操作,功能的操作流程是怎么样的。设计好功能后,要将功能整理成功能清单。同时,我们还需要考虑一些不直观的设计。比如,字典设计、数据权限设计、账号系统等。在设计功能时,产品经理很多功能采用一些通用的范式,比如权限设计、报表设计、首页、导航等。产品原型设计产品原型则是依据功能清单,根据产品平台的设计和交互规范,将功能清单转化为线框图。产品原型也要包含产品的交互设计。在设计产品原型时,我们要准备好相关的说明文档。同时我们一定要明确,对于B端产品UI和交互的设计,要配合业务和功能的设计。产品文档产品文档指我们在设计详细解决方案时,也需要提供产品设计的一些必要文档。最好,可以将这些文档整合到解决方案中,常见的有PRD、UML图、流程图、交互文档等。三、技术方案技术方案一般都是由技术人员设计。他们会根据细节方案中的产品设计,设计出可行的技术方案。但是,难免会出现产品需求和技术冲突的时候。此时产品经理作为决策者之一,也会参与其中,决定最终的技术方案设计。产品经理也需要在产品需求和技术间,做出各种抉择。为了设计出更好的技术方案,产品经理应该懂一些技术。特别是某些以技术为核心竞争力的B端产品。对于B端产品,应该会数据库表的设计和SQL语言,最好还会一门语言。我认为,一个优秀的B端产品经理,应该是对于软件工程有深刻理解的。在设计技术解决方案时,产品经理关注点在于技术成本、实现周期、技术风险、安全性和未

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论