格致GEZHI · GZ
3F · 工作室工作室

只放完全自己做出来的东西:平台级项目、飞书技能包、技术点拆解,外加一篇平台白皮书。

工作室UNIT S18 · HyperTree:把产品树、技术树和货架装进一个系统

STUDIO · SPEC SHEET · UNIT S18

HyperTree:把产品树、技术树和货架装进一个系统

品类管理方法设计 胡安更新于 2026-09

角色独立开发(业务+工具)
场景产品树 / 技术树 / 货架工具
技术栈产品树 · 技术树 · 在线多方案选择
成果201 类品类四件套,共享率报告秒级生成
封面:HyperTree,把产品树、技术树和货架装进一个系统
图 · S18 · HyperTree
产品树五层分解:整机、单机、组件、单元、器件,逐模块判定 CBB 并计算共享率
图 · 一棵产品树:从整机到器件五层分解,货架有成熟 CBB 的模块记为共享

之前写过一人手写的 CBB 管理系统(HyperWeb),那条线解决的是"货架数据放哪"。但品类管理真正吃工具的三个动作——拆产品、管技术、控物料——分散在表格和文档里:产品分解靠 Excel,技术规划靠 PPT,多方案选择靠线下填表算共享率,一份报告人工要算一两天,还算不准。方法想长在流程里,得先长在系统里。这篇文章写我们把三本账装进一个系统(HyperTree)的过程:它不是什么高深平台,就是一棵产品树、一棵技术树和一套货架规则的容器。

一棵产品树:共享率自动算

一棵产品树:共享率自动算

产品树是整个系统的骨架。整机往下分解成单机(模组屏、主板、电源板、遥控器)、组件(背光组件、WIFI 模块、遥控接收组件)、单元(LED 灯条单元、功放单元)、器件(电阻电容),每一层都对应货架上的一个格子。新建机型时,逐模块从货架上选择 CBB:有成熟模块的直接挂接;产品没有的功能选"无此功能、不涉及",计算共享率时自动排除;货架上没有的选"无成熟 CBB 需新开发",并注明新开发的技术路径和必要性说明——比如"新开低成本摄像头,成本控制在 50 元以内"。

选完的那一刻,共享率自动算出来:每个层次各模块权重相等,货架有成熟 CBB 记为共享,逐层汇总。之前:共享率靠人工对表计算,一份多方案选择报告要翻几天物料清单,口径还常常对不齐。现在:点一下"报告",几秒钟生成一份完整报告,逐模块列出选型、编号、共享率,未填或无 CBB 可用的类别自动标红,整机共享率合计到小数点后两位——某 65 寸机型的报告里是 88.57%,摄像头、远场语音板、底座三处标红,注明了替代计划。报告可以直接导出 Word 归档。

多方案选择在线化:线下 Excel 填表变成系统在线选型,报告一键生成
图 · 多方案选择在线化:共享率从几天的人工对表,变成几秒钟的自动计算

产品树还承担多方案选择的活动管理:仅项目成员可编辑本机型的选型,编辑记录全程留痕;货架使用中发现的数据缺失和资料问题,由产品线反馈给系统设计与管理部,再由后者对研发各部门点评督办。

一棵技术树:让技术对齐产品

技术树五个分解功能:技术分类、需求分类、技术平台、产品平台、细腰架构
图 · 技术树五分解:同一批技术项目,按专业和按产品功能各组织一遍

如果说产品树回答"产品由什么组成",技术树回答的是"技术怎么支撑产品"。系统里技术树有五个分解功能:技术分类按专业梳理产品应用的所有技术、完成定义并挂接预研项目;需求分类按产品功能特征(图像、声音、外观、交互、系统支撑)把技术和项目重新组织一遍,直观呈现某个功能需求下的技术进展;技术平台把支撑同一功能特征的相关技术整合成整体方案;产品平台是产品系列的公共平台,由技术平台支撑;细腰架构则把技术—技术平台—产品平台的支撑关系画成一张全景图。

同一批项目,按专业看一遍、按产品功能看一遍,很多问题自己就浮出来了:哪些预研迟迟没有落到产品功能上,哪些功能需求下技术储备是空的。技术树还逼着我们分清三个容易混淆的概念:关键技术是产品开发中不可或缺的,但不一定独有;独有技术是独有的,但不一定必不可少;核心技术是两者的交集——既领先于竞争对手,又在开发中占据重要地位。围绕核心技术和关键技术自己开发,其余技术外包,资源配置的优先级立刻清晰。

品类管理:201 类物料的一级约束文件

品类管理四件套:现状分析、设计规范、管控规则、优选库,按部门统计完成度
图 · 品类管理四件套:目标 236 项,每一项的完成度都有人盯

品类管理模块管的是第三本账:所有品类的设计规范、管控规则和优选库。品类树涵盖产品树分解的关键模块加上电子电气、电视结构、光学件、包装印刷品,共 201 类电视用全部物料类别;每个品类挂四件东西——现状分析、设计规范、管控规则、优选库,由各品类负责人上传维护,文件命名里带上类别关键词,系统自动归位。

系统做了两件人工做不好的事。一是更新留痕:文件更新记录实时滚动,哪个品类、谁、哪天更新了哪份规范,一目了然,每日更新情况可统计——规范"活着"还是"死在文件夹里",看一眼便知。二是完成度总账:全部品类目标 236 项(硬件 124、结构 61、显示 45、软件 6),按现状分析、设计规范、管控规则、优选库四类自动统计各部门的完成情况,缺口直接暴露在总表上。

桌面版到 Web 版:工具跟着组织长

这个系统最早是桌面客户端,本地数据库,够用但封闭——只有维护者能更新,产品线要看数据得拷文件。后来迁到内网 Web 版,浏览器直接访问,产品线、研发中心、系统设计与管理部在同一套数据上工作:产品线检索 CBB、看货架说明、做多方案选择;研发中心维护数据、申请 CBB 编号、补交付资料;管理方看完成度、做审批。CBB 编号申请走线上审批流,交付资料统一挂到 PLM 存档,货架记录 PLM 地址一键跳转——之前资料散在个人电脑里,现在货架上的每个 CBB 都能追溯到原理图、测试报告和使用说明书。

踩过的坑有两个。一是属性设计贪多求全,最初给每个 CBB 配了十几项属性,填的人叫苦,后来收敛为"每项属性必须体现产品需求或技术方向、概念清晰、无重复",砍掉近一半。二是共享率口径:曾经把不在货架上的模块也手工记成共享,数字好看却失真,后来规则改成"货架上没有的一律不能记为共享",报表可信度才恢复。

演进时间线:从桌面客户端到内网 Web 版,工具跟着组织长
图 · 工具演进时间线:每一次升级,都是让更多角色站到同一套数据上

方法不进系统,就只是墙上的制度;进了系统,方法才长出牙齿。

信息图:方法不进系统,就只是墙上的制度
图 · 三句话记住自研工具这条线