大家目前应该是对于今日最新更新 大厂的 B 端产品 怎么做（5000 字干货）方面的知识比较感兴趣，所以今天小编也是特地在网络上收集了一些今日最新更新 大厂的 B 端产品 怎么做（5000 字干货）方面的知识来分享给大家，感兴趣的小伙伴就好好看下下面的文章吧。

文章目录 1.1 aPaaS 简介 1.2 aPaaS的特征 1.3 为何选择以aPaaS模式规划企业内部平台？ 2.1 目标差异 2.2 发展路线差异 2.3 优缺点对比 3.1 方案阶段 3.2 业务调研 3.3 整体方案设计 3.4 垂类业务平台解决方案细节 3.5 执行与迭代

声明：本文来自微信公众号“唐韧”（ID：RyanTang007），作者：星球成员：Suda，，授权站长之家转载发布。

一份完整的产品设计参考

今天这篇文章来自我们星球成员 Suda，一位来自某互联网大厂的 B 端业务中台产品经理。

同时，她也是一位会 20 多种中西乐器的小姐姐，金融本硕，如今在头部大厂做产品。

内容很干、很多、很有用，尤其建议 B 端产品经理以及对 B 端产品不了解的读者认真阅读。

在传统的内部流程平台基础上，她与她的团队做了aPaaS 化的构思，非常有参考性，今天也和你们分享下。

当然，如果你想认识她，文章最后也留了传送门。

导语：本文介绍了我们在策划一款内部管理平台时，为什么可以选择aPaaS 模式，内外部业务管理平台差异点在哪里，并以垂类业务管理平台为案例，阐述了设计 aPaaS 化内部管理平台的过程和方法。

aPaaS 全称是 Application Platform as a Service，即应用程序平台即服务，在我国叫“高效能应用开发平台”。

aPaaS是介于标准化SaaS和定制开发之间的一种形式，通过将业务或应用模块抽象和沉淀为通用能力，并以一个相对标准化的形式输出，支持较低成本进行二次开发。

Gartner 对其所下的定义是：“这是基于PaaS（平台即服务）的一种解决方案，支持应用程序在云端的开发、部署和运行，提供软件开发中的基础工具给用户，包括数据对象、权限管理、用户界面等。”

（1）低代码。业务人员能通过可视化界面构建自己业务所需流程，搭建自己团队所需的平台，部署快速且使用简易。

（2）扩展性强。与SaaS平台相比，aPaaS具有更强的扩展性，能灵活输出能力/组件，并针对业务需求进行二次定制开发。

（3）开放性好。易于与业务其他关联平台对接，实现平台间的集成和数据互通。

（4）灵活调整。低耦合，可通过前端配置调整，适应团队在使用过程中的业务变更。

（1）aPaaS较常规SaaS的Web平台更灵活。

对于标准化SaaS平台，不同行业/场景的团队往往有不同的定制化需求，需要在通用平台基础上进行较多二次开发。

而aPaaS平台能够灵活提供SaaS+PaaS+API的组合能力，团队只需要选择所需的SaaS，对PaaS进行较少的开发，并能将数据通过API与其他平台进行集成，实现较多的能力复用和更低的二次开发工作量。

由于SaaS平台存在个性化难满足、业务场景变化快、IT运维成本高等问题，目前众多SaaS厂商纷纷向aPaaS转变。

目的：①提供统一的平台，方便自身业务的发展；②给用户提供平台或服务，供其使用和二次开发。

（2）aPaaS模式指导内部管理平台，将更多考虑行业通用性。

这对于应对目前互联网企业内部业务场景的快速变更，以及业务海外拓展趋势和跨平台集成等需求来说，具有更好的适应性；同时对于软件能力商业化的行业趋势来说是一种周到的考量。

内部业务平台主要聚焦的是本企业的业务团队的效能与管理，商业化平台重心是“卖出去”，实现更多的价值回报。

内部业务平台是以业务场景为核心的一次性开发和持续运维，商业化aPaaS平台也是从垂直业务功能开始建设，逐步扩充需求场景，继而再扩充到行业的整体解决方案，实现数据资产化。

最终还将会以底层能力为基础，扩充生态伙伴，建设开放的生态平台。

举一个外部aPaaS协作平台“伙伴云”的例子：

第一阶段伙伴云用了三年时间试错，做成垂直场景的“伙伴云表格”；

第二阶段扩充场景，在“云表格”基础上，又推出了“云分析”、“云流程”两个产品，并打造客户管理、订单管理、项目管理等解决方案；

第三阶段扩展到行业，将上述产品进行扩展，形成巡检、招聘等行业解决方案；

第四阶段，搭建了数据驱动经营的零代码搭建应用平台，通过输出标准化组件能力+定制开发+解决方案咨询服务，获取了十余万企业用户，同时构建了社区生态。

内部业务平台具有良好的数据安全保障，对特殊业务和管理需求能支持高度的定制，同时具备企业内部的便利，能支持即时运维。

商业化aPaaS平台优势是成本低廉，基本不需要研发团队的成本和时间投入，能即订阅即用，但也有跨团队导致的运维响应慢的问题。

用aPaaS化模式建设内部业务平台，不仅具有内部业务平台的数据安全和运维即时的优势，同时还兼具功能通用性和定制化：aPaaS化的能力输出，支持项目根据自己所需的流程自定义配置工作流，并且能使用平台提供的PaaS和API能力进行更低成本的二次定制开发。

而由于aPaaS化的平台在功能模块设计上具有行业通用性，因此能支持不同团队多种业务场景，且适应团队的业务场景变更。

本文将以某垂类业务管理平台作为案例进行浅析，当团队在当前垂直领域的业务上具备良好沉淀，且行业具备较多的共性需求时，适合以aPaaS模式进行设计。

在初始的阶段，针对业务团队的痛点，团队决定做一款产品来解决这些问题，这时产品经理就需要开始进行方案的调研与输出了。

对于内部业务平台，是无需进行市场、竞品等分析的，仅调研清楚业务需求即可，但商业化平台需要进行完备的商业分析才能确定可行性。

用aPaaS模式规划内部平台，第一步也需要看竞品做分析，了解行业共性痛点，决定产品方向，首先要明确业务平台所处的行业情况、市场规模，同时找到业务平台的市场定位与对标的同类和直接竞品。

（1）行业和市场分析

以业务垂直型企业管理平台中的经营管理类这一垂直分支的平台软件所在市场为例， 2021 年市场规模如下（原始大盘数据来自艾瑞，二次计算）：

除了市场情况外，还需了解头部产品以及行业竞争格局，魔力象限是一个很好的参考。

（2）竞品分析与对比

对同类竞品的头部产品以及直接竞品，从战略、范围、结构、框架、表现层进行竞品分析，对于内部平台的整体功能规划，范围层最为具有参考意义。

以经营/项目/研发管理类产品为例，国内外发展比较快的有Jira，Asana，Trello，Smartsheet，中国市场有TAPD，ones，禅道，coding，智研等。

以其中具代表性的几款为例，范围层竞品对比如下：

（3）选择产品方向

产品方向即“为谁提供什么支持”。

举例来说，对于测试管理平台而言，是要做一款能为测试团队提供人工测试在线执行与可视化管理的平台。

在方案完成，选定了产品方向，需要开始整体功能的设计时，需要先对业务流程进行梳理，在线下业务中找到存在的问题，通过平台功能的设计去解决这些业务线下操作的痛点。

可以通过多种方式，选择具有多样性的样本进行深度调研。

（1）选取全面样本

①不同团队。不同的团队有不同的工作流和业务模式，在场景上会有差异性，需调研并形成通用方案。

②不同角色。对不同角色询问不同角度的问题，整体思路是向管理者问战略方向，向业务经理问管理思路，向执行人问操作过程和细节。

（2）深度调研

①作为业务人员执行作业

②调研竞品

③深度访谈

④批量问卷调研

（3）痛点导向

通过自行作业和深度调研，梳理业务团队作业的主干流程，在主干流程基础上扩充业务细节上的痛点。

以痛点为导向，挖掘线下业务存在的管理、效能、可视化等问题，并用平台设计进行解决。

（1）产品定位

在解决方案上，首先梳理整体的方案。

在整体方案上，需确定产品定位，锁定要解决的核心问题和痛点，明确产品的方向。

绘制核心流程图和拆分归类后的功能模块图，并进行业务开发前期的架构设计，最终确定实施的计划。

（2）核心流程

针对不同角色方，绘制跨阶段的业务流程图。

比如一个测试管理类的平台，通用性的流程图如下例。

（3）功能模块提炼

对业务全部功能性需求进行分类，抽象成不同类别的小模块和大分类。

同时，由于aPaaS特性，平台在IaaS和PaaS上均具备相应的非功能模块，功能模块和非功能模块均可独立输出，可拆可卸，因此功能模块和非功能模块均需作为独立的模块展示。

在此以Ones平台的模块提炼图为例：

另外，aPaaS模式有一个 721 说法：即70%通用化、20%行业化、10%定制化，因此每个模块设计时均需考虑通用性。

（4）架构设计

架构设计包括业务架构、应用架构、数据架构、技术架构，每层都需要考虑通用性、可扩展性、与内部和外部系统的连通性。

业务架构由产品经理设计，其他架构由开发人员设计。

a. 业务架构。即功能模块。

b. 应用架构。系统层次和开发原则，标注对于数据层、服务层、通讯层、展现层等所使用的应用服务；较为简单的项目起始可暂不做复杂的设计，以避免过度设计。

c. 数据架构。对系统所需数据、存储数据方式、数据架构进行设计。

d. 技术架构。包括技术分层、开发框架和语言选择、技术规范。其中技术规范上，可包含开发规范、安全规范、性能规范、数据规范、版权规范、兼容性等要求。

（5）实施规划

整体分为几期，每一期要实现怎样的目标。

（1）非功能层

①IaaS和PaaS模块

建设IaaS和PaaS模块可以实现更灵活的能力输出，辅助多样化业务的定制开发。

例如，SaaS模块+PaaS能力+API（或IaaS）灵活组合输出，将更易于本平台和其他业务团队的平台之间的相互集成。

a. IaaS：

API能力

海外部署、公/私和混合部署

b. PaaS：

支持对通用垂类工具和web平台的集成能力

打通常用的研发管理、代码仓库和流水线等上下游平台

多语言框架，支持切换语言和多语言适配

组件能力，如消息/帮助系统、登录系统等

②业务数据建模

对业务流程进行抽象化，进行数据层的建模设计，指导数据整合与存储，这决定系统的可扩展性和灵活性。

在业务流程的抽象化过程中，可以基于：构建业务数据模型、角色权限->绘制流程图->基于流程确定页面流转图->每个页面的具体设计 这样的流程进行逐层抽象。

③数据埋点

对于业务平台，通过在特定功能中进行埋点，可以了解用户对该功能的使用频率、接受程度，从中发现用户行为习惯，进行产品优化。

④权限

在平台设计之初，先对权限框架进行大致梳理，约定不同的用户、角色以及企业、团队对应的权限，在页面设计完成后，对页面细致功能权限的对应关系进行关联，同时再做与角色的一一对应。

（2）功能层

a. 工作流

每个大模块均保持低耦合，如测试管理模块和项目管理模块是相互独立可拆可接的；功能模块配置和列表的字段配置均设为部分可自定义。

b. 看板/报表

看板的目的主要是可视化，通过可视化的数据了解现状、发现风险，并及时处理和解决。

设计流程是业务分析->建立看板指标->设计呈现形式。测管平台的看板功能包括个人工作项看板、人员管理看板、项目情况看板和测试管理进度与质量看板。

c. 项目管理

支持对项目信息和项目人员的增删改查，支持项目与研发环境的关联。

d. 垂类业务管理

在整体方案和细节设计完毕准备着手开发之前要进行技术方案的设计，开发过程中需要进行需求排期和研发进度管理.

在整体版本上线后，对外需进行运营宣推，对内则需继续进行功能优化和版本迭代。

（1）技术方案。在产品的整体和细节方案都设计好之后，技术人员需要做技术选型和技术架构设计。

（2）项目管理与实施。把控研发进展时，除了需要控制整体的资源排期和版本发布节奏外，在产品角度还需把控需求方向和准确度，减少变更，研发促进按期转测和bug修复及时性，测试通过评审和度量指标等降低漏测率，从而提升整体项目开发效率。

（3）运营管理。在V1. 0 版本上线后，需要做向外的运营宣推，包括：①上线后的宣传、推广；②使用培训；③客户反馈的收集；④使用效果分析。

（4）迭代优化。确定合适的迭代模式和周期（如两周小步迭代和大版本周期），保证研发资源合理运营和开发的顺利进行。

以上就是我在以aPaaS模式设计内部管理平台过程中的前期构思和方法论浅析。

aPaaS 化的设计除了前期的构思外，更需要落实在每个具体功能的实现中。

本文到此结束，希望对大家有所帮助。

版权声明：转载此文是出于传递更多信息之目的。若有来源标注错误或侵犯了您的合法权益，请作者持权属证明与本网联系，我们将及时更正、删除，谢谢您的支持与理解。

标签：