目录
1.3 版本发布总工程师（需求 + 开发 + 测试）=》 技术总管
系统架构部门是一个组织内部由一群技术大拿组成的群体，他们负责组织内部所有产品的架构，他们对产品架构的作用和决策权就像组织内部的高层管理层对组织职能部门架构的作用和决策权。他们决定了组织内所有产品线的组成架构、未来走势、产品系统级需求任务。
如果把每个产品看出是一个职能部门的话，那么所有的产品就构成了组织内的所有职能部门，产品群架构就构成了组织的架构。单一产品的架构就是职能部门的架构。
另外，一个组织的架构，通常要与业务架构相适应，可以看出，系统架构部门对组织的影响力是多么的大。
本文就是阐述这个神秘组织的角色。
| 输入 | 职责 | 输出 |
| • 组织的产品发布路线图 • 软件版本发布路线图 | • 领导推出端到端解决方案 | • 架构概念提案 • E2E 功能 |
| • 潜在商业需求的技术内容/支持 • 为端到端的方案提供技术支持 | • 潜在商业机会的技术支持 • 为端到端的方案的可行性研究 | |
| • 与主要合作伙伴（产品经理、组织管理层）一起定义合理化的产品架构和平台/产品路线图/演进图 | • 产品架构演进图 • 平台演进图 | |
| • 负责参与、贡献行业论坛，例如 3GPP、行业组织等。 | • 标准战略 | |
| • 对紧急客户问题或主要内部技术说明进行快速技术研究、支持等 | • 快速技术支持 | |
| • 负责部门内与部门间的沟通 | • 有效的部门内信息沟通 • 有效的部门外的沟通 | |
| • 人员和人才管理（成长、能力、敬业度、留任、继任计划） • 运营管理（质量、进度、预算和资源） • 确保实施组织内的工作方式 | • 人员流动报告 • 运营管理报告 • 工作实施报告 |
在一个复杂的产品系统中，会涉及到很多领域，一个人很难涉及多有技术领域，如硬件、结构、软件、平台、RF层、物理层L1、L2、L3、OAM.
每个领域都需要该领域的架构师，并且每个领域有多个架构师组成的架构师团队。领域首席架构师是指在特定的领域的所有架构师中处于首席的位置。这个首席的位置，并不是“人员”管理的职位，而是技术方案拍板的权力和职责。
| 输入 | 职责 | 输出 |
| • 端到端系统参考架构 • 产品参考架构 • 产品的技术演进路线 • 行业技术演进线路 • 最新的一流的技术 | • 创建和维护领域参考架构及其与产品和技术组件保持一致的演变 | • 领域架构指南 |
| • 与 项目经理和组织内的架构师一起，负责领域的架构的相关优先级、投资平衡、业务案例分析等 | ||
| • 负责领域内的最佳设计 | ||
| • 最多种架构方案中进行拍板与决策 |
在大型组织中，会同时进行多个不同产品、不同版本的软硬件的开发与发布，并且有一定的重叠性。针对某个特定的发布版本，需要有一个技术架构师。
如果说，领域首席架构师负责产品长期架构演进，那么版本发布总工程师负责某个产品发布内的架构选型和实现。
| 输入 | 职责 | 输出 |
| • 来自客户的产品功能列表 • 来自内部改进的产品功能列表 • 版本发布内容计划 • 版本发布时间计划 • 产品架构的需求 • 问题与故障列表 | • 版本发布的技术负责人（所有技术冲突的升级点，解决复杂的技术问题并做出决策） | • 发布技术文档的审核和批准 |
| • 参与复杂的、长期的、影响系统架构的、影响产品性能的功能的版本发布计划。 • 针对跨网元故障提供技术指导和技术解决方案的牵头。 • 确保版本发布关于产品架构的范围得以实施。 • 对版本中心增加的临时性的改动进行技术评估和技术审批。 • 在实施阶段，负责协调和领导跨技术领域问题的解决。 • 在产品维护阶段，领导负责问题的解决。 | • 定义版本发布中关于产品架构的需求规格说明和技术解决方案。 • 定义版本发布中关于基础性功能的需求规格说明和技术解决方案。 • 定义版本发布中包含的功能列表 • 复杂问题、跨技术领域、跨网元问题的技术 解决方案。 | |
| • 识别和描述版本发布中的技术风险。 • 参与OAM配置参数的定义。 | • 系统发布的技术风险 • 技术风险应对计划 | |
| •确保第三方组件的法律和知识产权合规性 | • 第三方软件的合规报告 |
产品架构师直接面对客户，负责客户产品架构的需求定义，根据客户的要求和行业对同类产品的演进要求，确定组织内该产品架构的研究。不同的产品架构师，负责不同的产品或产品线。
| 输入 | 职责 | 输出 |
| •业内端到端参考架构 | • 与客户、利益相关者、供应商进行合作，建立高层次的产品和架构愿景、信息模型和需求文档。 | • 产品/解决方案和架构愿景 |
| • 负责产品的参考架构、目标架构、版本发布架构 • 第三方技术组件技术分析和选择 | • 产品架构遵循的规范：参考架构、目标架构、版本发布架构 | |
| • 参与组织内端到端方案演进的技术讨论 | • 端到端技术方案的演进报告 | |
| • 定义子系统以及受影响的接口 • 指导子系统架构的实施 | • 产品架构决策 • 产品架构演进计划 | |
| • 为功能团队创建可追溯的产品架构需求，并将架构改进功能映射到目标版本 | • 产品/解决方案架构设计 | |
| • 创建并维护下一版本之后的产品架构演进路线图 | • 架构演进和路线图 | |
| • 长期领先的功能和产品演进管理 • 有助于技术探索以确定潜在的未来 | • 技术预研报告 |
技术主要关系技术的实现的可行性与所需要花费的人力资源，不太关注客户的需求来源。
| 输入 | 职责 | 输出 |
| • 功能演进路径 • 功能需要 • 产品架构规范和需求 • 功能发布计划 • 技术改进需求 • 功能改进需要 | • 技术领域的领导者，与利益相关者一起，确定技术的演进方向 • 确保功能的技术实现符合架构定义 • 负责特定领域的问题的技术解决方案 • 负责特定领域的流程改进 | • 特定领域的技术方案 |
| • 可行性技术分析之前，对特定领域的功能需要进行技术性阐述。 • 可行性技术分析之前，对功能进行人力资源和费用的评估 | • 技术阐述规范 • 人力资源和费用资源的评估结果 | |
| • 可行性技术分析 • 对功能进行人力资源和费用的评估 | • 可行性技术分析报告 • 人力资源和费用的评估的初步结果 | |
| • 功能的帅选 • 领导复杂功能的技术分析和决策 | • 功能帅选的结果 • 技术分析结果 | |
| • 文档需求规范的评审 | • 评审意见 |
平台技术经理，主要负责平台的技术演进，为产品提供技术支撑。是技术经理在平台领域的实例。
平台主要是给上层的物理层应用提供技术支撑和支持的的。
| 输入 | 职责 | 输出 |
|---|---|---|
| • 竞争信息和基准 • 组织战略 • 组织技术战略 • 参考和目标架构 • 组合项目或产品的演进计划（领导计划） • 产品系列计划 • 平台计划 • 平台定义 • 平台架构 • 平台需求 • 设计规范 • 技术路线图 •研究组合/结果 • 技术开发组合/结果 • 3GPP 标准化路线图 | • 跨产品的技术平台的技术管理
| • 平台定义 • 项目管理团队支持 |
每个产品都设计到安全问题，安全是多层面的。产品安全带头人对产品的所有安全问题进行负责。
| 输入 | 职责 | 输出 |
|---|---|---|
| • 客户需要 • 行业内安全标准 • 功能列表 • 发布计划 • 安全规范 | • 安全架构 • 安全规范 • 安全防护 | • 安全架构 • 安全规范 • 安全防护 |
| • 安全技术文档的审批 | • 安全技术文档的审批 |
系统工程师主要负责客户需要到产品需求的转换，成为组织内部产品（软件或硬件）开发的规范。
在产品内部的不同技术领域发生冲突的时候，进行技术决策。
| 输入 | 职责 | 输出 |
|---|---|---|
| •系统架构规范 •客户的功能需求（来自产品经理） •故障报告 •变更请求（CR） •产品功能需求 | • 技术可行性分析 • 行业标准的研究 • 客户需求到内部产品的规格化 | • 可行性研究报告 • 3GPP标准一致性申明 |
| • 负责系统级客户需要的规格化 • 系统级接口定义 | • 系统级功能需求的规格化 • 系统级接口规范 | |
| • 网元级内部需要的review • 用户文档的评审 • 系统级测试用例的review • 网元级测试用例的review | • 技术决定 | |
| • 领导复杂客户故障的解决 • 产品需求的澄清 • 内部需求变更 • 作为技术专家参与产品的维护 | • 培训 • 问题的解决 |
| 输入 | 职责 | 输出 |
|---|---|---|
| • 系统/解决方案架构规范 • 功能列表 • 产品组合/发布计划 • 仿真请求 | • 根据仿真项目经理创建和维护的计划，在仿真器的功能范围内设计和实施一种或多种替代算法 • 运行仿真，根据目标验证算法的性能 | • 模拟报告 |
| • 根据仿真结果调整算法 | • 模拟器增强了新功能 | |
| • 解决自身技术领域的复杂工程问题 | • 自有责任领域的技术解决方案 | |
| • 维护模拟器平台 • 保持与领域架构和需求 的一致性 | • 模拟器平台 | |