职能 01
产品
判断哪些需求值得做、按什么顺序做，把散落在客户现场的问题整理成一条能走下去的路线。
- 年度版本的路线说明与阶段目标
- 需求取样的场景梳理与优先级排序
- 功能上线后的效果复盘
从 v1.0 到 v2.4.x，华体用四十余次迭代打底
挑一套要长期跑下去的系统，光看眼下有哪些功能还不够，得看这家公司有没有把产品一代一代做下去的耐心。华体把账号、双端和记录编号当成底盘反复打磨，一路推到今天的 v2.4.x 序列——你接手的时候，前面每一步都还查得到。
- 首次公开发布
- v1.0
- 累计小版本迭代
- 40 次以上
- 团队规模
- 约 120 人
第一个版本
先解决“明年还能不能接着用”
v1.0 面向公开之前，我们陪一批企业团队跑过很长时间的试用。他们提得最多的不是“能不能再加个功能”，而是“这套东西明年还能不能接着用”。
一个版本能上线不算本事，能让人放心地在上面跑三年、五年，才是我们要解的那道题。
围绕这句话，华体在最早期就定下三条原则。它们不是功能清单，而是后面每一次迭代都要回头看一遍的底线。
-
01
一个账号，两端通用
安卓端和网页端共用同一套账号体系，收藏记录与下载记录实时同步。换设备、换场景，不用重新认识一遍系统。
-
02
每条记录都带编号
版本、批次、文件各自有稳定的标识，翻旧账的时候不用靠记忆去比对，说得清是哪一次改动带来的变化。
-
03
上一版随时找得回来
回退到早先版本、比对两个版本之间的差异，对不少团队是刚性需求，所以这件事从第一天就当成标配来做。
迭代序列
四十余次迭代，每一轮都在解一个具体问题
从 v1.x 到 v2.4.x，版本号往前走的节奏基本是固定的：先收集真实使用中卡住的地方，再排进下一轮，改完留档。下面这条轴上的五个阶段，是客户感受最明显的几次变化。
-
v1.0
把底盘定下来
首个公开版本只做三件事：账号体系、双端入口、记录编号。功能不算多，但它决定了后面所有能力都能挂在一个稳定的结构上，而不是加一次功能补一次窟窿。
-
v1.x
让两端真正变成一套
这一批版本集中处理同步问题。安卓端上和网页端上收藏的内容、下载过的文件保持一致，出差在路上标好的资料，回到工位打开网页就能接着看。
-
v2.0
版本号变成三段式
序列重构之后，每次改动落在哪个小版本上一目了然。版本专栏公告按 v2.4.0 这样的小版本号逐条归档，你翻到任意一条公告，都能对回当时的发布节点。
-
v2.2
把用法也一起交付
功能越多，上手成本越高。这一阶段我们把操作指引按安装、账号、数据、版本四个主题拆成 12 个分类，累计整理 180 余篇，遇到问题先查再问，节省双方时间。
-
v2.4.x
当前的发布序列
v2.4.x 是目前在跑的序列，仍然按小版本号往前推。它承接的能力包括双端同步、历史版本回看和资料分区检索——都是客户日常用得最频繁的部分。
团队分工
约 120 人，四个职能围着同一件事转
产品、研发、内容运营、客户成功四个职能分头负责，谁都不能只做自己那一段——客户的反馈要在四个环节里都跑过一遍才收口。
职能 02
研发
负责安卓端与网页端的实现和稳定性，保证同一份数据在两处看到的结果一致，不出意外。
- 双端功能的同步发布与灰度验证
- 数据一致性与历史记录回看的保障
- 信息安全管理体系与等级保护要求的落地
职能 03
内容运营
把每次变化写成能看懂的文字——资讯、版本公告、操作指引，让客户不必靠猜来理解更新了什么。
- 工作日傍晚的资讯上新与栏目归类
- 小版本公告的逐条归档与批次编号
- 教程按安装、账号、数据、版本四个主题维护
职能 04
客户成功
企业客户从试用到上线全程有专人跟着，上线之后也不会断线，季度回访和版本升级提醒会按时找上门。
- 试运行、试点、全量上线的落地陪伴
- 季度回访与使用情况沟通
- 新版本升级提醒与迁移协助
合作生态
六十余家伙伴，把服务铺到现场
一家公司自己跑不远。华体与行业媒体、技术服务商和区域渠道伙伴保持长期协作，客户在本地就能找到能上门解决问题的人。
伙伴类型 A
行业媒体
保持长期内容往来，让产品动态与版本路线能更快到达关注这个领域的人手里。对客户来说，选型阶段能多一个了解渠道，不用只靠销售口径判断。
伙伴类型 B
技术服务商
承担接口打通、周边系统衔接这类工程活。你如果有既有的业务系统要接进来，可以借这条链路缩短调试周期，不必从零摸索。
伙伴类型 C
区域渠道伙伴
负责所在地的对接与现场支持。碰上需要当面沟通的部署安排，由本地伙伴就近响应，减少来回奔波带来的等待。
归档方法
资讯、版本、资料，各走各的架子
这三种内容的使用场景完全不同：有人是来追动态的，有人是来确认改动的，有人是来找一份旧文件的。混在一起放，谁都不好找，所以从早期就分成了三条独立的线。
资讯
日常动态按栏目走
版本发布、产品动态、行业观察、活动公告四类标签分开放。工作日傍晚准时上新，全年大约 250 期，习惯定期翻阅的人不用每次都从头翻。
版本
改动按小版本逐条留痕
每一条版本公告对应一个 v2.4.0 这样的节点，写了什么、影响哪些模块都落在同一条里。排查问题时顺着编号往回翻，很快能找到变化发生在哪一步。
资料
历史文件按年份分区
9 个年度分区、320 余份历史版本文件分开存放，同一批次里既有安卓端安装包，也有网页端的配置说明。按年份筛选之外，还能用版本号、文件类型、发布批次缩小范围。
新接触华体的话，首页底部的帮助文档栏目能找到安卓端与网页端的安装和登录入口，跟着走一遍就能上手。
年度路线
每年一份路线说明，让排期有依据
采购和运维的同学最怕的是“说变就变”。华体每年发布一份年度版本路线说明，把当年的迭代方向与重点能力提前讲明白，你据此安排内部培训和验证窗口。
路线说明里写了什么
- 当年迭代的几个大方向，以及每个方向要解决的问题
- 重点能力的大致先后顺序，方便判断哪些可以先内部试用
- 与小版本号归档方式的对应关系，公告出来时对得上号
- 往年在推进过程中做过哪些调整，以及调整的原因
拿到路线之后可以做什么
- 把版本升级排进内部维护窗口，避开业务高峰
- 提前安排操作培训，减少上线后的提问
- 向客户成功团队反馈优先级，纳入下一轮评估
- 结合季度回访，确认上线后的使用情况
企业客户从试用到上线一般要多久？
走的是试运行、试点、全量上线三段式节奏。企业客户配有专属对接人，从试用到完成上线平均用时 11 个工作日，具体时长会随接入范围和内部审批流程有所浮动。
上线之后如果遇到问题，找谁？
先查使用教程栏目，安装、账号、数据、版本四类问题都有对应步骤；如果仍然卡住，通过咨询服务提供的渠道联系我们，工作日有专人跟进。
已经在用的旧版本还需要保留吗？
按你们的内部规范办即可。需要回看或下载时，资料下载区按年份分区存放，找起来不费劲。