罗氏医疗（梁莉）：融合创新技术团队适应医疗行业的敏捷转型之路

微信扫码，打开到小程序

融合创新: 技术团队适应医疗行业的敏捷转型之路 梁莉 罗氏诊断 数字化平台技术产品总监 www.top100summit.com 梁莉 （Kylie Liang) 罗氏诊断 数字化平台技术产品总监 “ 产品经理： 传统行业（罗氏）- 负责领导产品经理和UI/UX工程师团队，从0到1构建数 字化平台和医疗健康数字产品。 科技行业（微软）- 从0到1构建全球Azure Spring Cloud平台服务，从1到 N拓展VS Code Java工具包以及开源软件和微软云计算平台Azure的集成 (如Spring、Kubernetes、Ansible、FreeBSD)等。 研发经理： 职业生涯始于英特尔，担任开发者后晋升为研发经理，负责Linux驱动和开 源虚拟化软件开发。 开源软件的爱好者： 在2016-2018年担任FreeBSD基金会董事。 ” 讲师简介 www.top100summit.com • 挑战与机遇 • 实践 • 天时 • 地利 • 人和 • 复盘 & 启示 • 下一步 目录 www.top100summit.com 2021年11月 2022年3月 2022年6月 2022年9月 2022年12月 2023年3月 2023年6月 2023年9月 现在 敏捷转型之路 - “我”的视角 适应度（我的感受） 成熟度（我的观察） • 医疗健康行业迫切需要数字化转型，来提升 服务效率和质量。然后传统模式与新技术间 存在矛盾，比如原始数据不出域、数据可用 不可见。 • 罗氏诊断中国团队希望通过自研数字化平台 和疾病管理应用，打造可扩展、安全、以患 者为中心的医疗服务生态系统。 • 由此，罗氏诊断组建了多领域人才融合的新 团队，而这只团队本身也是需要去学习医疗 健康行业的场景，才能去推动转型的挑战。 案例背景 流程 团队 技术 用户 www.top100summit.com 数字化转型： 核心 vs. 新生 线下 vs. 线上 壁垒 vs. 竞争 问题与挑战 流程： 项目 vs. 产品 瀑布 vs. 敏捷 技术： 新技术 vs. 已有系统 传统IT工具 vs.DevSecOps 团队： 互联网节奏 vs. 行业特点 理念差异 vs. 包容适应 用户： 内部用户习惯 vs. 变革 外部用户习惯 vs. 创新 天 时 地 利 人 和 www.top100summit.com 定义战略 • 界定产品与项目、应用的区 别 • 定位打造开放的医疗数字化 生态 破题思路 构建工作流程 • 融合医疗行业规范， 采用敏捷 开发与交付模式 • 定期回顾和展望，不断总结经 验，持续优化工作方式 确定混合云原生架构 • 积 极 拥 抱 新 技 术 如 微 前 端 、 DevSecOps等。 • 构建混合云架构，平衡多场景 部署需求。 提升新团队的凝聚力 • 建立共同的团队目标和工 作方式 • 开放包容地看待理念差异 • 发展学习型组织 明确以患者为中心的设计: • 深入研究用户需求，共创 模式来打造普适性的产品 • 组织转型来推动商业化 天 时 地 利 人 和 www.top100summit.com 破题方法 www.top100summit.com 定义战略 www.top100summit.com 核心实践 – 数字化转型 Why What How www.top100summit.com • 传统上,数字建设以项目方式推进,注重交付一次性成果。而数字化转型则需要持续迭代优化的产品思维。 • 数字化转型的本质之一,就是将数字化工作的主要形式从项目转变为产品,打造生态系统。 核心实践 – 推动持续发展 项目(Project) vs. 产品(Product) • 项目更加注重一次性的交付，解决某一具体问题或达成特定目标，完成后即结束。 • 产品关注长期的市场价值，需要持续优化和更新，以满足用户持续变化的需求。 产出(Output) vs. 成果(Outcome) • 产出(Output)指项目或产品的直接可交付成果，如软件系统功能、代码、文档等。 这是团队的直接工作结果。 • 成果(Outcome)关注交付后的影响效果，如提升的业务指标、用户体验、带来的商 业价值等。这是交付作用的最终体现。 一次性交付 持续输出客户价值 交付为重点 全生命周期运营 固定范围 迭代 规划驱动 数据驱动 Why What How www.top100summit.com • 传统上,数字建设以项目方式推进,注重交付一次性成果。而数字化转型则需要持续迭代优化的产品思维。 • 数字化转型的本质之一,就是将数字化工作的主要形式从项目转变为产品,打造生态系统。 核心实践 – 推动持续发展 项目(Project) vs. 产品(Product) • 项目更加注重一次性的交付，解决某一具体问题或达成特定目标，完成后即结束。 • 产品关注长期的市场价值，需要持续优化和更新，以满足用户持续变化的需求。 产出(Output) vs. 成果(Outcome) • 产出(Output)指项目或产品的直接可交付成果，如软件系统功能、代码、文档等。 这是团队的直接工作结果。 • 成果(Outcome)关注交付后的影响效果，如提升的业务指标、用户体验、带来的商 业价值等。这是交付作用的最终体现。 一次性交付 持续输出客户价值 交付为重点 全生命周期运营 固定范围 迭代 规划驱动 数据驱动 Why What How www.top100summit.com 核心实践 – 项目 H/W OS Web Server Project A H/W OS Data Base Login Config Users Roles Integration … HIS LIS RIS PACS Hospital System H/W OS Web Server Project B H/W OS Data Base Login Config Users Roles Integration … H/W OS Web Server Project C H/W OS Data Base Login Config Users Roles Integration … H/W OS Web Server … H/W OS Data Base Login Config Users Roles Integration … 之前 Why What How 挑战 • 不同外包商（难复用） • 一次性交付 （特定目标，难复制） • 每次更新要求CR（流程长，开发时间被压缩） www.top100summit.com 核心实践 – 项目转变成产品 H/W OS Web Server Product A H/W OS Data Base Login Config Users Roles Integration … HIS LIS RIS PACS Hospital System H/W OS Web Server Product B H/W OS Data Base Login Config Users Roles Integration … H/W OS Web Server Product C H/W OS Data Base Login Config Users Roles Integration … H/W OS Web Server … H/W OS Data Base Login Config Users Roles Integration … 项目(Project) -> 产品(Product) Why What How www.top100summit.com 核心实践 – 项目转变成产品 H/W OS Web Server Product A H/W OS Data Base Login Config Users Roles Integration … HIS LIS RIS PACS Hospital System H/W OS Web Server Product B H/W OS Data Base Login Config Users Roles Integration … H/W OS Web Server Product C H/W OS Data Base Login Config Users Roles Integration … H/W OS Web Server … H/W OS Data Base Login Config Users Roles Integration … 项目(Project) -> 产品(Product) 重复的开发工作 重复并且可能还是 不安全或不可扩展 的基础设施 Why What How 挑战 www.top100summit.com 核心实践 – 项目转变成产品 Product A Capability 1 Capability 2 Hospital A Physical Environment … Capability 1 Capability 4 Hospital A Physical Environment Product B Capability 1 Capability 3 Hospital B Physical Environment Product C Capability 2 Capability 3 Hospital C Physical Environment Foundation Capabilities & Ecosystem Services Capability 1 Capability 2 Capability 3 … Physical Environment Digital Platform Product A Product B Product C Product D … 项目(Project) -> 产品(Product) 产出(Output) -> 成果(Outcome) 自建平台：加快开发和部署 Why What How www.top100summit.com 核心实践 – 产品生态系统 生态化 架构安全 技术标准 应用市场 数据中心 统一及安全的部署环境 罗氏中国数字平台 … 生态体系服务及基础能力 D1 D2 D3 C1 B A1 A2 解决方案 X 解决方案… 解决方案 Y C2 解决方案 Z 合 作 伙 伴 客 户 加 快 开 发 、 发 布 和 部 署 易 于 发 现 和 购 买 汇聚丰富的数字化产品，全方位满足客户需求 Why What How www.top100summit.com 核心实践 – 定义战略：共建可持续发展的多元化医疗生态 生态化 自 研 第 三 方 产 品 解 决 方 案 Why What How 架构安全 技术标准 应用市场 数据中心 统一及安全的部署环境 罗氏中国数字平台 … 生态体系服务及基础能力 D1 D2 D3 C1 B A1 A2 解决方案 X 解决方案… 解决方案 Y C2 解决方案 Z www.top100summit.com 构建工作流程 www.top100summit.com 核心实践 – 医疗行业的软件开发生产流程 Example: Software Life Cycle Processes for Medical Devices 合规 • 医疗器械生产质量管理规范 (原国家食品药品监督管理总局 2014 年第 64 号) • 医疗器械生产质量管理规范附录 –独立软件 (国家药品监督管理局 2019 年第 43 号) • 医疗器械软件注册审查指导原则(2022 年修订版)(国家药品监督管理局医疗器械技术 审评中心 2022 年第 9 号) • 医疗器械网络安全注册技术审查指导原则(2022 年修订版)(国家药品监督管理局医疗 器械技术审评中心 2022 年第 7 号) • 人工智能医疗器械注册审查指导原则(国家药品监督管理局医疗器械技术审评中心 2022 年第 8 号) • 医疗器械生产质量管理规范独立软件现场检查指导原则(国家药品监督管理局 药监综 械管[2020] 57 号) • YY/T 0664-2020 医疗器械软件 软件生存周期过程 • YY/T 0287-2017 医疗器械 质量管理体系用于法规的要求 • GB/T 42062-2022 医疗器械 风险管理对医疗器械的应用 • IEC 62304: 2015,MOD Medical device software-Software life cycle processes • ISO 14971:2019 Medical Devices – Application of risk management to medical devices • ISO 13485:2016 Medical devices–Quality management systems– Requirements for regulatory • purpose • AAMI TIR45:2012/(R)2018 Guidance on the use of Agile practices in the development of • medical device software • IEC 82304-1:2016 Health software – Part1:General requirements for product safety … 示例：医疗器械软件的缺陷管理要求和可追溯性分析要求 Why What How www.top100summit.com 核心实践 – 业务流程 1. Pilot it* 2. Nail it 3. Scale it 4. Milk it 5. Kill it * product lifecycle definition from Lex Sisneys Why What How 挑战 • 医院信息化建设差异大 • 医院或科室需求多样性 • 从一个科研项目到普适性 的产品需要多次实践和验 证 www.top100summit.com 核心实践 – 软件开发流程 Why What How VS. 挑战 • 流程重 • 不确定因素大 www.top100summit.com 核心实践 – 融合 规模敏捷框架 (SAFe) 1. 业务敏捷：投资组合 2. 开发敏捷：迭代 3. 角色映射：BO, PM, Arch, RTE, PO 4. DevSecOps: 把合规和安全 融入到日常开发测试运营中 5. 充分利用每次冲刺或迭代的 回顾会议来评估过往的尝试，制 定优化计划。 Why What How www.top100summit.com 核心实践 – 利用工具链融入合规和安全的要求 Why What How Requirement Design Development Quality Assurance Deployment Feature Story Component Code System Test Case System Test Result UAT Test Case UAT Test Result Package Customer Requirement Doc Software Requirement Specification Software Arch Doc Test Plan Test Report UAT Plan UAT Report Baseline Defect OTSS Assessment Code Review [Traceability] www.top100summit.com 确定混合云原生架构 www.top100summit.com 核心实践 – 业务场景：共建可持续发展的多元化医疗生态 医院 互联网 公有云 本地 开 发 测 试 发 布 浏 览 购 买 下 载 访 问 Why What How www.top100summit.com 核心实践 – 构建混合云原生架构 注册 开发/测试 发布 审阅 订阅 下载 Why What How 应用市场 医院 互联网 公有云 本地 挑战 原始数据不出域、数 据可用不可见 隐私保护 www.top100summit.com 核心实践 – 构建混合云原生架构 Why What How Kubernetes 公有云 本地环境/私有云 数据平台 应用市场 门户 中间件 应用 算法 软件即服务 工具 公有云 本地 身份与权限 管理 监控和日志 ETL 部署引擎 短消息平 台对接 微信公众 号 微信小程 序 医院 • 原始数据不出域、 数据可用不可见 互联网 隐私保护 DMZ www.top100summit.com 提升新团队的凝聚力 www.top100summit.com 核心实践 – 敏捷团队合作的挑战 1. 怎么赋能团队？ • 不同职能 • 高度协作 • 快速响应 • 客户参与 • 自组织性 2. 怎么重沟通而不是形式？ • 展会 • 计划 • 评审 • 回顾 Why What How 敏捷就是快？欲速则不达 挑战 www.top100summit.com 核心实践 – 敏捷团队的构建 • 不同职能的角色映射 • PM vs. PO • PO vs. Scrum Master • PO vs. Tech Lead • 敏捷团队的构成 • 外包 vs. 自建 vs. 混合 • 增加医疗行业的规范和流程到日常工作 • 诊疗路径的定义 • 医疗数据的标准化 • 数据的验证 https://scaledagileframework.com/ Why What How www.top100summit.com • 不同职能的角色映射： • 一人承担多个角色；或者多个人分担一个角色 • 关键角色一定要承担责任Accountable • 敏捷团队的构成： • 混合 • 增加医疗行业的规范和流程到日常工作 核心实践 – 敏捷团队的构建 团队的组建 团队规模 (自建） 团队规模（外包） PM PO/Tech Lead Scrum Team 1 Scrum Team 2 PO/Tech Lead Scrum Team 3 Scrum Master Scru