面向企业的2B的产品,如何实现标准化?

B端产品先天性受制于客户的采购、付费决策,多数情况下都难以摆脱甲方的硬性限制条件和要求,导致整个产品在交付、使用等方面完全取决甲方,经常性(习惯性)不得不向甲方妥协。

面向企业的2B的产品,如何实现标准化?

我们通常的做法是寄希望于销售或者售前,尽可能的在销售过程中和合同上少做一些不合理的承诺,想办法让客户接受现有的产品功能,来规避一些不必要的定制需求。

这种策略无异于是“大道朝天,各走半边”,想让销售对客户说 “NO” ,往往难以操作也很难见到成效。但,并不等于完全没有摆脱完全定制化的机会。
想要做到这一点,必须要在产品、技术的顶层设计方面具备足够的领先性和前瞻性,也就要求PM对所处的行业有足够深入的理解,并能适当的引导客户。这将是一个综合性全方位的专业要求,涉及到企业管理、业务再造、产品设计、项目管理等多维度的要求。

今天我们讨论的就是如何在底层的产品架构和技术设计上,来适应更客户的个性化需求。

01、前瞻性的产品架构

我们在此前的系列文章中,深度分析了2B和2C的产品差异性,也阐述了B端的诸多特性,这些特性差异总结起来包括如下几个方面:

  • B端产品的客户和用户的不可调和性分裂;
  • b端客户在管理模式、理念和组织架构的独特性;
  • B端客户的自身业务的特殊性;
  • B端客户对数据的独占性、敏感性。

2B的产品,之所以总是陷入“需求变更”的泥潭,本质上是“客户提出一个想法,我们就认为是一个新需求”,“客户提出一个需求,现有产品就做不了”的尴尬局面。

所以,就不得不频繁的“重构”,似乎 重构是解决问题的终极法宝。不断的修改调整产品自身的目标定位往往是根本原因,进而也导致一部分产品经理,在“功能经理”的泥潭中越陷越深,他们不得不承接各种各样甚至千奇百怪的业务需求,画原型,出方案,提计划,催进度。

没有谁去思考,当前的业务是否已经偏离了产品的初心,是否偏离了既定的定位,是否扭曲了原本的架构。

这就好比原本只打算盖10层楼的房子,不知不觉中加盖了30层,还要问应该如何豪华装修一样。

想象你见到的每一栋房子,它其实是完全依据“架构”的概念来进行设计施工的。

房屋的 “架构” 决定了整栋房子的布局,决定了它有多少层,有多少间房,层高多少米,这些东西是不管怎么装修,都改变不了的事实。而我们平常说的 “客厅”、“餐厅”、“主卧”这些功能区域,则是我们在使用某些某个产品的时候,所对应的功能模块。

面向企业的2B的产品,如何实现标准化?

对这栋房子而言,每个“业主”可以自行决定装修的风格和设计,可以改门改窗,甚至还可以把原来的一房一厅改成两房一厅,但房子的支柱、承重墙是再装修的时候都不能动,要动就得大动手术,甚至干脆推到重来。

所以,在你买房的时候,必须要搞清楚自己的需求,房子的既有格局,朝向,位置,甚至周边的环境,否则一旦成交悔之晚矣。

从房子的 “架构” 概念,你就发现,如果从“功能模块”的角度出发,任何产品(房子)都有它所面向的独有客户对象,它无法去适应和满足所有人的诉求。而实际情况是,我们总想着如何去满足所有人,妄想一套模式适应所有客户。

从这个角度看,想要真正规避“无穷无尽”的定制化,首要解决并不是产品的问题,而是驱动产品的业务模式,单纯的“销售驱动”必将陷入定制化循环困境。坦白说,这不是一线产品经理所能解决的问题。PM们所能做到的,就是依据一定的模式,来设计更具有前瞻性的产品架构,充分考虑到各种场景的复杂性,扩展产品的边界,努力把定制降低到可控的范围。

更为重要的是,PM们不能再沉迷于 只知功能不知业务 的窘境,一定要深入到实际的一线业务当中,准确把握实际的业务应用场景,有效的引导客户共同寻找最恰当的解决方案,最忌人云亦云不能自己。

下图是笔者之前操刀的一个O2O产品的架构图,在这个简化后的图上我们能够清晰的看到整个的产品价值定位,我们将要服务的业务对象,想要解决的具体问题,这个图描绘了产品的边界,告诉我们能做什么,有了它我们就能够把资源投入在应该投入的地方,我们要做的是如何更好的优化它的实现,而不是不断的谈判那些是新需求。

面向企业的2B的产品,如何实现标准化?

产品架构可以指导产品经理思考如何解决用户的问题,如何满足用户的期望。作为产品的指南,“产品架构”解决的是如下三个问题:

产品方向

按照产品架构图的结构和路径,产品的RoadMap也就可以被清晰的拆解出来,同时它还能指导技术架构的选型,比如业务的容量,扩展性等等,为未来的产品发展指明了方向;

产品边界

不做什么,很多时候更为重要,明确一个产品的基本边界,可以让这个产品少走很多弯路,降低很多的风险和不必要的成本。这对于创业团队来说,有些时候非常关键。

产品路径

产品架构设计了各个功能模块的业务范围,针对每个功能的内外关系有清晰完整的定义。当一个产品的架构被确定后,也就确定了产品的迭代周内的范围,并且能够帮助上下游清晰的理解产品的结构、功能和复杂度。

深入研究产品的架构设计,从其解决的问题来看,我们也能很清晰的了解,一个好的产品架构图的基本要求:

  • 功能经过抽象,做到标准化、互相独立
  • 清晰的功能边界,架构分层明确
  • 具备迭代优化的能力

02、可扩展性的技术设计

频繁的定制需求,还有一个重要原因就是 “目前的技术方案实现不了”,经常听到类似于的话就是“没有字段”、“ID对应不了”等等解释。

为了简化这个问题,我们举一个简单的例子。假设某公司有一个IT部门,有员工张三,我们在设计系统的数据库时这样处理。

当组织规模较小,业务量一般,这种设计基本都能覆盖。现在问题来了,某天公司架构调整,原本的“IT部”变成了“开发部”,原本张三 是IT部门的人,现在这样一个调整,之前的员工信息还显示为IT部,就变成了组织架构的调整,导致开发部查无此人了。

任何一个产品,在做技术设计过程中,一定要重复考虑到系统今后的硬件能力扩展、软件功能扩展等多层面的延伸,只有如此才能最大限度的增强产品的价值,最大限度的适应业务应用的需求。

其最基本的原则是始终遵循面向数据价值,围绕业务应用,注重实效的方针。充分考虑到系统的开放性和可扩展性,才能提高系统的稳定性和可靠性,满足用户需求不断发展变化的要求,便于以后的升级扩展,减少二次开发或定制开发的工作量从而降低成本。

通常来说,可以从以下几个方面考虑:

功能组件化

通过封装成独立实现的组件,并通过标准接口联系在一起。使得每个组件在业务功能上互相独立,又能够根据客户的实际需求进行灵活配置、组合来实现产品的平滑升级和扩容,形成一个可根据具体需求来增加或者减少功能模块的解决方案。

工作流(Workflow)可以说是这种设计思路的一种典型应用。

为了实现某个业务目标,通过将系统的各个工作任务分解成定义良好的角色,然后按某种预设规则和过程来执行这些任务并对其进行监控,达到提高工作效率、更好的控制过程、有效管理业务流程等目的。

工作流定义了任务的触发顺序和触发条件,每个任务都可以由一个或多个软件系统完成,也可以由一个或一组人完成,还可以由一个或多个人与软件系统协作完成。

接口标准化

接口的标准化是最基本的要求。整个系统的所有功能模块的数据通信和引用交换都必须通过标准接口完成,才能实现功能组件对扩展性和集成性的适配。换言之,也就是通过标准接口,来预留未来的业务空间,不至于因为一个基础的接口就需要重构业务层代码。

架构分层设计

基本思路是把界面展现、业务逻辑和数据服务的进行分割设计,通过各自独立的“层”来分别负责实现的相关的功能,且互不干扰。比如用户界面层完全不需要考虑底层的数据服务如何实现,只需要保证接口稳定即可。这样高度的模块化设计,就能够保证系统功能的可扩展性来适用不同的业务需求。

多租户模式是一种典型的分层应用。所有新增的租户,都可以通过调用可复用的服务来快速实现自身的业务逻辑,而且对现有的租户不会产生任何影响。

通过租户模式,可以实现不同客户间的快速部署,而无需过多的二次开发,客户也无需过多的关注底层数据问题,而专心于业务本身。整个产品可以实现一套逻辑,多套用户界面的效果,就像一栋房子了,不同的业主可以有自己不同的风格,而无需关注这栋房子的地基问题一样。

顺便多说一句,有技术背景的产品经理确实更有优势一些,他能够更深入的理解产品功能的实现,能够更自如的应对各种需求。

本文由 新媒体之家 作者: 产品微言 发表,其版权均为原作者所有,文章内容系作者个人观点,不代表 新媒体之家 对观点赞同或支持,未经许可,请勿转载,题图来自Unsplash,基于CC0协议。
0

发表评论