面向B端的产品，如何由项目抽象出技术中台，以便于快速支撑B端项目的实施？

面向B端的产品，如何由项目抽象出技术中台，以便于快速支撑B端项目的实施？ - PMCAFF产品经理社区

你这个问题恰好今年我也遇到了，我们现在也在尝试让多个近似的项目能够运行到同一个中后台中。随手写一些，肯定不怎么全面，我自己还在摸索中。

这里边我觉得主要考虑几个部分：

1、业务抽象与分化

相对简单部分：

以我自己几个项目为例，先找它们业务流程上共同涉及的部分，比如账户系统、外部系统对接、业务模块的抽象与复用、前端框架选择及组件使用等等

相对复杂的问题：

不同项目的定制化需求、老项目迁移问题、新的架构对工作方式的改变这些

2、技术团队配置与开发资源倾斜

作为产品，我对技术细节了解的很烂，这算是我天然的劣势，只能遇到实际问题的时候听团队给解释解释好尽快理解问题想办法，所以只能大致从前端和后台的人员配置和开发方式上参与进去。这对开发团队的依赖和信任是非常高的。至少要让开发这边能在基本思想上达成统一。

像我们以前，前端部分跟后台的配合是比较割裂的。中间工作上的沟通主要是后台给API，前端和设计拿着原型PRD自己玩。

如果是现在这种开发方式，那就要求前端、UI这些都需要和后台共同约定一些更加标准、简单的开发方式，这一点至关重要。

举个例子，以前我们UI大致看看bootstrap的组件库，然后凭感觉照着产品原型画一堆高保真，前端再重组件库里自己找近似的现成组件。我知道这是挺low的方法，但同事都是好多年的老组合，也不怎么出问题，一直就沿用下来了。

现在的话，包括UI在内，需要学会对我们自己需要用到的前端组件进行定义，需要花更多时间在本地跟后台提交参数配合测试。比如这个项目是个单页应用，要求支持自适应，UI以前对技术部分了解很少，现在就要学一些组件相关的概念和描述需求的方法。

这部分主要目标是让同一套组件能覆盖多个项目类似的功能需求

3、产品部门对各个项目的抽象及功能设计

这个比较考验产品对各个项目功能的抽象能力，核心目标化繁为简，归纳出足够少同时尽可能满足功能需求的设计。

这是一个需要来回妥协的过程，产品在其中起到的作用是对功能需求的语义描述以及对最终功能组件选用的决策权，俗称背锅吧。

反而原型画的比较少，因为我们这个工作方式原型意义不大，还不如多给前端和UI更多的自由度，根据需求自己去设计才对实际产出有价值。

感觉写了一大串很混乱，也感觉没说到自己想要的点子上去，应该是我自己还没把这套思路给玩熟，要加深总结了。占个位置，希望多交流交流

Recommend