业务架构：需求传递之困
1. 业务模式
某科技公司的业务模式可以概括为：以软件基线为核心，按客户需求进行定制，通过合作伙伴完成交付。
其产品形态包含四个层次：
- 硬件：嵌入式设备（NAS 基型），支持容器化（ARM/x86）以及 RK3588、RK3576 等硬件平台。
- 软件：微服务化的软件基线，按能力平台组织，每个能力由多个服务组合提供。
- AI：部署于设备端的推理服务。
- 云平台：运行于运营商基础设施，支撑业务运营。
客户类型为大型企业。公司不直接面向客户销售，而是通过合作伙伴渠道完成销售环节。
战略背景：不直接面向客户销售是初创阶段的战略选择——公司需要利用合作伙伴的客户纽带关系切入市场，建立与政府和大型组织的合作关系。面向个人消费者是非常远期的计划。这一模式意味着合作伙伴既是销售通道，也是需求入口。
2. 利益相关者
基于 TOGAF 利益相关者分析框架，识别出以下关键角色：
| 利益相关者 | 类型 | 参与环节 |
|---|---|---|
| 客户（大型企业/政府） | 外部 | 提出需求 → 验收交付 |
| 合作伙伴（经销商、系统集成商） | 外部 | 需求转交 → 现场交付 |
| 产品人员 | 内部 | 接收需求 → 拆分需求 |
| PM | 内部 | 需求拆解 → 任务分配 → 验收 |
| 研发团队 | 内部 | 接收任务 → 实现 |
| 测试团队 | 内部 | 测试验证 |
| AI 团队 | 内部 | AI 优化/定制（按需） |
| 架构师 | 内部 | 重大方案评审（偶尔） |
| 售前/技术支持 | 内部 | 需求阶段技术评估 |
| 供应链/采购 | 内部 | 硬件定制阶段 |
| 高管/决策层 | 内部 | 重大方案或资源调配 |
3. 核心业务流程
从客户需求到最终交付，业务链路如下：
客户需求
↓
合作伙伴（销售角色，收集需求）
↓
公司产品人员（接收并汇总需求）
↓
产品 + PM（共同拆解需求，口头传递）
↓
研发团队（进行硬件移植和软件裁剪）
↓
解决方案交付
↓
合作伙伴 → 客户
这一流程中，产品人员扮演着客户与合作伙伴的需求收集枢纽角色，在公司内部与 PM 协作完成需求拆解。拆解后的需求以口头传递为主流方式进入研发环节。
4. 需求传递机制
基于访谈，需求传递的实际运作如下：
4.1 需求入口：合作伙伴 → 产品
- 接收形式：拜访、电话、会议，以口头沟通为主，少部分有邮件记录
- 信息质量：合作伙伴作为经销商/系统集成商，传递的需求描述往往"非常单薄"
- 存储位置：口头传达，少部分邮件散落在个人邮箱，无统一归档
4.2 需求拆解：产品 → PM
- 拆解方式：无标准模板或 PRD，依赖产品人员的个人经验进行口头拆解
- 输出物：无结构化文档，无用户故事，无功能清单
4.3 任务分配：PM → 研发
- 传递方式：口头交代，无书面任务单
- 评估机制：无工时评估，无资源确认
- 优先级规则：由 PM 直接指定，无正式排期流程
4.4 信息格式与可追溯性
| 信息类型 | 当前格式 | 可追溯性 |
|---|---|---|
| 需求规格 | 口头约定 | 不可追溯 |
| 硬件配置 | 口头约定 | 不可追溯 |
| 交付时间节点 | 口头传递 | 不可追溯 |
| 测试报告 | 文件传递 | 可追溯 |
| 设计文档 | 内容管理平台 | 部分可追溯 |
5. 组织架构与职责
公司组织扁平化，与业务运作直接相关的板块包括：
研发板块
- 系统能力平台：AI 应用、存储、网络、安全、混合云、IoT 网桥、新平台底座（硬件与 OS）、功能部件产品化、第三方应用管理、图片与媒体业务、互联网数据聚合等
- 大客户产品一组：产品、前端、后端、测试
- 大客户产品二组：产品、前端、后端、测试
- 研发管理办公室
平台板块
- 供应链
- 产品组
- 设计组
- 技术支持服务组
- 市场拓展组
- 行政/人事/财务
访谈补充：研发管理办公室的核心职责是协调资源，参与需求评审和资源调配，但不直接介入日常需求拆解。大客户产品一组和二组无明确的行业/区域划分，而是根据项目负载和人员能力动态分配。
角色职责分工
| 职责领域 | 产品人员 | PM |
|---|---|---|
| 需求沟通与收集 | 主导 | 不参与 |
| 需求拆解与定义 | 主导 | 兼任部分 |
| 任务分配与排期 | 不参与 | 主导 |
| 人力协调 | 不参与 | 主导 |
| 验收 | 参与 | 参与 |
6. 业务目标
公司当前的业务目标以定性描述为主：
| 目标维度 | 具体目标 |
|---|---|
| 设备侧业务 | 支持客户完成软硬体系的交付，满足合作伙伴的交付目标 |
| 云端业务 | 保持自营业务的服务质量，支持合作伙伴和甲方的方案云端建设 |
| 基线演进 | 软件基线持续迭代，支撑更多硬件平台和客户场景 |
7. 异常与分支场景
7.1 需求不可行
| 环节 | 现状 |
|---|---|
| 发现时机 | 研发阶段（已投入开发后） |
| 决策人 | 商务 |
| 回退路径 | 口头通知 PM → 口头通知产品 → 口头通知合作伙伴 |
| 客户沟通 | 无明确责任人 |
7.2 交付后缺陷
- 反馈渠道：口头通知，无工单系统
- 处理流程：无 SLA，无优先级分级
- 根因分析：无复盘机制
7.3 需求变更
- 变更频率：频繁（具体次数无记录）
- 评估机制：无重新评估工期和影响范围的正式流程
- 记录状态：无变更记录
8. 交付周期
交付周期：平均 3-5 个月。
存在"在不明确需求的情况下先推进部分任务"的做法。
9. 工具与系统使用现状
| 工具 | 部署状态 | 实际使用 |
|---|---|---|
| Confluence | 已部署 | 需求管理未使用 |
| Jira | 已部署 | 需求管理未使用 |
| GitLab | 已部署 | 代码管理使用 |
| 测试平台 | 已部署 | 测试流程使用 |
10. 治理机制现状
| 治理维度 | 现状 |
|---|---|
| 业务复盘 | 几乎没有 |
| 流程回顾 | 无 |
| 知识沉淀 | 无 |
| 绩效度量 | 无定量指标 |