性格分析

策略

• 组织架构会影响一个事情的落地
• 业务还是技术重要
  • 当所有的人都在关注业务的时候/ 技术反而更重要
• 共赢
  • 人与人寻找到共赢的点
  • 获取别人的想法
    • 先不要假设别人是错的
  • 取得别人信任的能力
• 副作用
  • 任何东西都有副作用
• 让子弹飞出来
  • 突然有一个好的想法, 不要立马就去干, 有没有想清楚呢
• 做一件事之前
  • 先试探
  • 线下先跑通
    • 这件事之前发生过吗? 是怎么处理的
  • 有没有想清楚, 全面
    • 做这件事的完整的闭环
    • 做这件事怎么验收有没有达到标准
• 平衡
  • 超/强
    • 兵/伟
  • 产品与技术
  • 罗/梦/磊
• 布局能力

分析

• 产品
  • 所有符合这个标准的需求都可以接入开发
    • 排优先级
    • 不依赖产品经理
  • 产品线上的使用的表现
    • CAT
• 技术
  • 重要技术方案需要优先给出技术方案
• 哪些问题需要老板来决定
  • 风险以及应对
• 这个技术的问题还是产品的问题
  • 背后的逻辑是什么
• 怎么提高整体技术团队的产出效率
  • 引入一些激励的模式
    • 技术分享层层晋级
  • 拆分出非常多的小团队
    • 基础设施团队
  • 引入 python 作为微服务
• 提前思考转正答辩的逻辑
  • 分析
  • 演绎
• 老板在乎的是什么
  • 冯
    • 过程管理
    • 看中从外面引入了什么, 做了哪些效率提升的事情
    • 结果, 产出了什么
    • 老板怎么快速理解这件事
    • 不仅仅是做事/而且是做人
    • 业务架构和技术架构
      • 各个业务是怎么流转的
      • 技术层面是怎么支撑的
  • 敏
    • 需要有一张表格, 这么多技术的同学做的事情怎么看到
      • 各个产线需要有进展, 期望技术团队能做到更多的事情
    • 对产品提出要求
    • 技术需要解决技术的问题
    • 抓重点, 不用一个人来维护这件事
  • 磊
    • 产品人员技能缺乏, 怎么给童一定的压力
    • 罗老师怎么用起来
    • 应该怎么做规划
  • 我当前要做的
    • 识别出问题
      • 这个是根本问题吗?
      • 拥有足够的资源解决问题吗?
    • 什么方式来解决问题
      • 考虑性价比
    • 清晰化的梳理
      • 当前每个子平台分别处于一个什么阶段
    • 给人和事设定目标
    • 抓大放小, 分解下去
• 管理
  • 终极目标
    • 在不牺牲价值, 质量和安全的情况下获得尽可能低的成本优势
  • 管理不是监督, 而是激励
    • 管理不是督促, 而是协调自己解决问题
    • 管理不仅仅关注结果, 应该关注过程的可持续性
  • 管人
    • 对人性的洞察
    • 改变的是人
      • 态度
      • 能力
        • 对人工作能力的把握
  • 理事
    • 对事物更深刻的理解
    • 改变的是事
      • 流程
      • 效率
        • 识别出不合理的做法
        • 更高效的做法
  • 如何面试别人
• 怎么快速的去理解一个人
  • 当前遇到的问题是什么
  • 内心的渴望, 野心
  • 性格和行为模式
• 平衡
  • 技术与产品
  • 各个团队之间的平衡
  • 打破旧的秩序, 建立新的流程
• 说故事
  • 隐藏更深的一个动机
  • 稳步的推进

梳理

最近要做的事情

• 梳理项目
  • 所有项目在一张大表格中呈现出来, 从前端着手
  • 所有要做的事情应该属于某一个科目
  • 故事点
    • 确定做一件事情的难度和评估工时
• 敏捷开发的流程
  • 需求的粒度
• 梳理人员
  • 每个人未来的规划是什么, 他想要什么
  • 制定一个培养计划
• 参与到具体的代码中
  • 深入到一线中
• 总体架构
  • 冯比较关注细节
  • 技术文档本身也是产出
• 需要作出成绩
  • 做什么比知道怎么做更重要

系统梳理

• 前端资源
  徐超云、于佑全、张君歆、吴嘉伟

• SPUG-项目管理 需求：路燕梅 UX：钱程 前端：徐超云 后端：石涵
• SPUG-版本外发 需求：赫攀 UX：赫攀 前端：吴嘉伟 后端:李子林
• SPUG-分支管理 需求：路燕梅 UX：钱程 前端：徐超云 后端：石涵
• SPUG-GMSlab 需求：孙梦童

大禹项目

• 里程碑
  • 7 月底有一个迭代
  • 10 月底
• 完成整机的全流程覆盖
  • 项目/需求信息管理
• 外围系统打通
  • 梳理所有外围系统
• 人员分工
  • 效能洞察
  • 软件项目/需求信息管理

Java 项目人员分工

• Java 人员分为两个迭代线, 并行开发
  • 永强
  • 远超
• 前端一条迭代线条
  • 做业务
• 整体架构的演进
• 敏
  • 场测说服老冯
    • 技术上落地了部分总体 Tones 架构
      • 走通了整体的流程
    • 让业务反馈告诉我们的价值在哪
  • 阶段性的产出
    • 流程的东西没有人来落地
  • 邵刚
    • 易用性
    • UI
• 磊
  • 工作流和事件流 需要预研

部署架构

目标

• 从部署架构视角, Tones 是搭建在云原生的基础设施之上打造的一款弹性可扩展的分布式应用
  • 当前投入资源搭建并维护一整套云原生基础设施付出的成本较高
    • 同时在短期之能并不能给我们带来多大的价值
    • 暂时我们也没有丰富的流量来验证
  • 现阶段 Tones 应用负载并不大, 应用调度, 服务治理的诉求还比较简单
  • 所以整体上 Tones 拆分为两个阶段来推进部署架构的落地

概念对齐

• 应用
  • 我们这里的应用包括 Tones 的前后端应用
  • 即 Tones 的前后端应用都需要采用统一的部署方式
• 制品
  • 应用交付的制品为一个带有版本的 docker-image:tag
    • 一般来讲包括 3 个部分 Base Image + App + 配置项 组成
    • 在 CI 中最后自动生成最终的制品, 并推送到制品库中
  • docker image 使用 tag 来对应应用本身的版本 version
    • 每一个微服务 (包括前端微服务) 独立迭代, 拥有属于自己的版本号
    • 每次构建/发版时产生一个新的 image 需带上 tag, 并与应用本身的版本相对应

两个阶段

• 第一阶段完成容器化部署
  • Docker 化为后续迁移到 K8s 提前做了准备
  • 这个阶段我们的应用可以部署在虚拟机/物理机等底层平台上
  • Tones 所有用到的 中间件和应用 都采用容器化部署
• 第二阶段上 K8s
  • 将部分能力下沉到基础设施中来完成
    • 比如通过 K8s 来实现注册中心等
  • 用 K8s 原生的方式实现容灾备份等
  • 当 Tones 实现商业化或支持多租户, 独立出一个 Tones-helm 组件在标准的 k8s 平台上快速部署一套我们的产品

Docker 化

• 不同类型的应用使用相对应的 Base Image
  • 这里统一 java/nodejs 等的版本
• 中间件也采用 Docker 化来部署
  • 方便快速的复制一套环境

部署配置的管理

• Tones 通过 nacas 组件管理了应用本身的配置
• 这里制定通用的部署相关的参数配置
  • 这里的配置包括优化的 JVM 参数等, 不包括为特定环境设置的参数
    • 配置应该尽可能上去适应环境, 而不是一个写死的参数
    • 配置提供默认的行为
    • 配置提供命令行的选项来覆盖默认的配置
• 这些部署参数配置后续上 K8s 后迁移到 ConfigMap 对象来进行管理

预研课题

集成飞书的云文档能力

• 参考资料
  https://open.feishu.cn/document/uYjL24iN/uYDO3YjL2gzN24iN3cjN/introduction

工作流和事件流调查

• 参考资料
  https://blog.csdn.net/m0_37583655/article/details/121341137

工作内容

• 对外的沟通
  • 对上/对同级别的部门
  • 员工的工作的安排
• 技术的预研
• 项目的把控
• 参与到代码的编写
• 交接叶梅手头上的工作
• 文档写的详细一点, 领导也需要这个来说明价值
• 和敏哥对齐做事的思路和策略

应用架构

解决什么问题

• 业务问题都有一定的共性, Tones 的多个子业务中提炼出共性，找到解决业务问题的最佳共同模式
  • 产出物就是一套标准的脚手架, 快速 setup 一个微服务
  • Tones 定义良好的应用结构，并提供最佳实践
• 演进式的架构, 随着业务的不断融合, 应用架构需要比较灵活的支持业务的演进
  • 包括应用的拆分和合并

分层结构

应用系统处理复杂业务逻辑也应该是分层的，下层对上层屏蔽处理细节，每一层各司其职，分离关注点

• 适配层（Adapter Layer）
  • 负责对前端展示（web，wireless，wap）的路由和适配，对于传统 B/S 系统而言，adapter 就相当于 MVC 中的 controller；
• 应用层（Application Layer）
  • 主要负责获取输入，组装上下文，参数校验，调用领域层做业务处理，如果需要的话，发送消息通知等。层次是开放的，应用层也可以绕过领域层，直接访问基础实施层；
• 领域层（Domain Layer）
  • 主要是封装了核心业务逻辑，并通过领域服务（Domain Service）和领域对象（Domain Entity）的方法对 App 层提供业务实体和业务逻辑计算。领域是应用的核心，不依赖任何其他层次；
• 基础实施层（Infrastructure Layer）
  • 主要负责技术细节问题的处理，比如数据库的 CRUD、搜索引擎、文件系统、分布式服务的 RPC 等。此外，领域防腐的重任也落在这里，外部依赖需要通过 gateway 的转义处理，才能被上面的 App 层和 Domain 层使用

服务之间解耦

• 所谓耦合就是联系的紧密程度，只要有依赖就会有耦合，不管是进程内的依赖，还是跨进程的 RPC 依赖，都会产生耦合
• 遵循依赖倒置原则，统一使用 gateway 来实现业务领域和外部依赖的解耦

粉丝管理

• 整机粉丝
  • 通过 APK
  • 自动创建 BUG 到对应的 jira 仓库
• OS 粉丝
• 粉丝运营

小磊

• 需求需要封版
• 可以直接去找苏
• 容易钻牛角尖
• 形成一个机制, 做事的方式方法

TODO 代办事项

• 1v1
  • Tones
    • 现有系统和 Tones 的关系
      • 后续所有系统都转 Java 吗?
      • 长在 Tones 到底是做什么的, 已经具体落地的计划
    • Tones 现在整体的开发节奏
      • 场测抓紧时间研究
      • 目前 Tones 需求其实还不是特别明确
        • 我跟磊哥同步的想法是, 能先拆解出一小部分需求出来先跑
    • 目前开发每个人多 Tones 的理解可能都没有对齐
    • 分工不是特别的明确
  • 需求和项目的管理
    • 问题点
      • 需求可能会变动
        • 对方可能也没有想清楚
          • 怎么通过流程让对方想清楚
        • 通过版本来锁定
          • 建立一些规划和 check 的机制
      • 谁来做比较合适, 大约多长时间
        • 要深入进去看
      • 沟通效率的问题
        • 需求的对齐, 按照模块分解为 WBS
        • 进度的对齐, 通过甘特图
      • 优先级
        • 缺乏信息不好做判断
  • 现阶段
    • 梳理老的系统
      • 业务层
      • 能力层
        • 想把 k8s 这些能力使用起来
          • 我们有业务的流量其实可以打磨我们的能力层
        • 大家其实喜欢学习新东西
        • 增加整体的运维能力
          • 思路是想把这些东西沉淀到工具中去
          • 系统解决流程串联的问题, 框架
    • 沉淀到能力层次
      • 初步想法 ,看一下我们整体在基础设施层有哪些能力
        • os 粉丝, 其实我们打通手机日志上传的通道, 然后叠加了一些业务应用
  • 建立规范流程和秩序
    • 通过我的一些经验把事情做的更好, 更有体系化
    • 需求的入口和出口
      • 几个原则
        • 需求没有明确之前给不出来排期
        • 需求分为 p0/p1/p2
    • 需求拆解为两个工作项
      • 需求本身和业务方对齐
        • 并评估出工作量
      • 需求对开发资源的占用需要花费多长时间, 以及优先级
  • 看到我们一共有多少的资源再做多少的事情
    • 最终的目标是多少人做了多少的事情
• 调动人员的积极性
  • 我冲在前面给大家做标杆
  • 人员积极性调动起来
    • 了解每个研发技术的偏好和对自己对技术的想法
    • 为每个研发制定一个技术的目标
  • 每个人都可以写自己的提案来改进自己或者整个组织的工作流
  • 建立分享的文化
  • 人员转 Java 需要制定一个路线图
    • 这块和子林聊了一下, 愿意写 Java 的, 在 Tones 中做了一个应用架构, 提供一套标准的最佳实践, 告诉他们怎么做, 做几个迭代出来
• 识别出别人做事可能方式方法不对
  • 人员分工的调动
    • 老的系统谁来维护
      • 我其实是期望有人一起想办法来梳理
      • 具体需要梳理多少有没有遗漏这个其实为可能不太好判断
    • 前端
  • 手头上的项目
    • 场测项目的开发
      • 接口调试通过, 剩下的联调给到
    • Tones
      • 整体架构设计
      • 预研类的项目
    • 项目和需求的管理
      • 现有系统的梳理
        • Spug 系统维护+优化
        • 粉丝运营系统二期
        • KMS 项目
        • 榫卯亮灯看板 0631
          • 有一个整体的计划
      • 建立流程和规范
    • 开发带动起来
      • 搞一个技术的分享会议
        • 让 Java 的同学互相了解一下
  • 对外的沟通
    • 带着一个什么帽子

贺攀

• 场测报告回传给 SPUG
• 出货角色还在 SPUG 来完成
• 学习一些 Jira

周报

苏敏

• @张志佳 Spug 发版这块，有空和 @路燕梅 沟通下，拿亮灯这个功能试点下，一起承接起来的哈

沟通的话题

• 需求和项目的管理

  • 逐步建立

• Tones

  1. Tones 总体架构设计推进落地

  1.1 撰写部署架构和应用架构两个章节
  1.2 内部评审对齐

  1. 参与 Tones 需求和项目板块会议讨论, 新增两个预研课题
     2.1 Jira 和微软 TFS 调研 (未开始)
     2.2 自定义工作流和事件流调查 (未开始)
     • 可能需要做到动态的能力

• 海外场测系统

  1. SPUG 数据同步接口调通，代码提交, 后续联调交给@欧祖兵
  2. IPM 数据同步方案沟通, 具体接口确定, 代码提交, 后续@万伟志协助集成联调；
  3. 场测系统开发过程任务盘点和发现问题解决问题, 本周三再次确认里程碑
     3.1. 后端完成所有的接口并通过网关可以拿到数据
     3.2. 前端能基本完成 UI 部分的开发

• 榫卯亮灯看板

  • 验收完成, 并在 SPUG v1.22 版本中已上线

• OS 粉丝

  • 需求确定, 优先级安排在场测之后
  • 开发进度计划同步在甘特图

• Spug 系统维护+优化

  • 熟悉 SPUG 的发版流程, 在燕梅指导下完成 Devops 研发协作平台 V2.20
  • 梳理的过程拆分优化项, 推进自动化 SPUG 发版流程

• 其他

  1. 参与需求项目讨论会议
  2. 逐步从项目维度来看,现有的系统,人员分工情况
  3. 前端项目大致的梳理, 以及人工分工的协调

课题

Tones

• Tones 与现有平台的关系
  • Tones 核心是整合打通串联单个的节点成流水线的能力 (框架)
    • 包括流程的协同
    • 包括各种能力的集成
    • 用户体验
• 现有平台是否可以继续做好某个节点的能力 (工具)
  • 需要梳理后和看价值
  • 有可能会融合或者重构
• 目前明确比较明确的是 SPUG 里面的功能模块逐步融合到 Tones 中来

需求和项目的管理

• 目前两个问题
  • 需求变更和直接找到开发缺乏一些有效的秩序
    • 会打乱开发的节奏等
    • 产品评审, 建立版本等
  • 沟通效率的问题
    • 信息交给更适合的人来处理
      • 比如优先级重要程度等判断不出来需要汇报老大帮忙来判断
    • 进度和相互依赖的对齐
• 建立需求和项目的秩序, 每个需求根据各种的特点有序进行, 关键节点过程能被观察到
  • 初步和大家对齐
• 长期来看, 形成两张表
  • 需求项目表 (当前有多少需求, 重要优先级)
  • 开发资源投入 ( 每个项目投入多少资源做了多少事情, 哪些用户在使用, 反馈怎么样)

现有平台梳理和演进的方向 (设想, 比较粗粒度)

根据各自技术的特点和对人员的要求,大致粗粒度分为两个方向

• 偏业务类
  • 业务类的对沟通要求比较高一些
  • 业务类的比如用 java, 形成最佳实践
  • python 同学等直接对着之前类似的功能也可以直接上手参与项目的开发
• 偏能力类
  • 在支撑我们既有业务的场景中抽象输出解决方案
    • 比如 CI/CD 的能力, 首先我们自己的项目都用起来, 整个方案打磨好后, 可以在软件中心去进行分享
      • 这些能力沉淀到工具中, 可能是一个 Docker image, 别人开箱即可使用
    • 了解到我们有 3 块的粉丝管理模块
      • 能力侧可理解为实现了 apk 日志的收集通道
      • 业务侧按照不同业务部门的要求分发给他们驱动和协助业务
    • 比如 K8s 的能力
      • 业务层的流量可以帮助更好的验证和丰富 k8s 的底层建设
    • 能力侧的东西

人员分工

• SPUG 的需求来源
  • 每个模块是有 owner 的.owner 对接业务,然后结合自己判断过滤出来确定要做的就是需求了.
  • 版本外发是赫攀,主要对接 spm
  • 分支信息是燕梅,主要对接一些研发
• SPUG 的代码
  • 子林全部接起来
• 所有项目按照优先级来部分交付
  • 周兴杰 (后端)
    • KMS
    • OS 粉丝
    • 海外粉丝 2 期
  • 前端
    • 目前还比较乱

项目状态

• KMS 项目和需求状态

  • KMS 按月提交需求, 需求优先级通过优先级进行排序
    • 后续需求排期按照约定同频
    • KMS 7 月份确认 3 个紧急需求优先对应

• 同梦通沟通项目需求管理相关事项

  • 输出

SPUG 账户密码

• http://spug.transsion.com admin 3edc5tgbmju7
• http://10.150.98.32:8090/ admin transsion#123

运维侧

• 统一 CI 发布
  • 标准 CI 流水线
• 统一 CD 部署和备份容灾
  • 标准的容器化部署和容器化容灾备份方案
• 自动化运维能力
  • Ansible

周报

• Tones

  • 域名方案的整体规划讨论和设计
    • 需要考虑到 互联网/公司内网/黄区网
  • 权限模块需求评审后, 不进行自研, 采用公司既有的权限系统

• 海外场测系统

  • 场测试点需求项目管理规范
    • 1.0 需求分成几个大的流程进行产品验收
    • 讨论 1.1 的需求
  • 场测对基础组件的建设也纳入到需求进行管理
    • 包括底层服务的搞
  • 场测项目进度跟踪, 开发 100%, 联调 70%, 21 日提测 1.0

• 需求项目管理规范

  • 产品讨论并回答在 JIRA 管理需求的具体的细节
    • TODO 需要写出来
  • 完善并更新规划的文档

• Tones- 项目管理需求

  • 产品方案的评审并重新更新优先级

• 分支模块

  • 展锐需求方案的拉通

• 灾备工具链

  • 编写灾备工具链的设计文档初稿
  • 与唯丞讨论并对齐目标

• 其他

  1. 灾备演练 Web 系统相关梳理
  2. 资源协调任务排期等相关沟通
  3. SPUG 等相关系统的学习

• 会议纪要和代办

  • 展锐分支需求重要不紧急
    • 分多次迭代稳步推进
  • 确认本次迭代需要完成的的功能点
    • 预估改动点和工具量 ( 输入到 JIRA 中)
    • 并 同步 给业务方做成什么样子, 以及一个大致的交付时间
  • 分支演进/分支列表等联动本次不进行改造 (保持和之前一直)
    • 唯一的差异是本次所有的用户输入通过线上进行
    • 对 MTK 用户的行为没有新增任何新的认知负担

核心观点

• 工作时带着问题, 要知道 "当下是在解决一个什么问题"
  • 如果不知道应该主动去询问
• 对每个阶段的产出的输入输出提出对质量的要求
  • 比如产品需求未明确不应该急着开始开发
  • 开发规范逐步建立起来
• 几个原则牢记在心中, 指导日常快速的作出决策
  • 当前处于一个什么阶段
  • 可以做哪些动作来帮助我达成这个阶段的目标
    • 组织 codereview
    • 方案写出来邀请别人来 Review
• 找到研发的节奏和结构

推进技术规范和标准

• 抓关键的标准和细节
  • 接口定义的规范
    • 多人协作的契约
  • 数据模型的
    • 能做什么
    • 不能做什么

反映的几个问题

规划

1. 需要把一件事情想清楚

   1. 我一件觉得应该写出来, 还有哪些事情没有想清楚

   2. 比如我需要写代码了, 当下遇到了阻碍是什么, 我这两天就需要吧这个问题解决了

      • 比如代码分支规划, 我写代码, 就会破坏他们的环境

对一件事的分工其实看得出来整个组织的能力

• 存在吃大锅饭现象
• 大家都在做类似的事情, 做事的标准/产出是没有互相被 check 的
  • 流程是有成本的, 太重的成本, 反而会比较僵化
    • 沟通的成本
    • 流程熟悉和适应运营的成本
  • 原则其实是比较容易掌握的, 直接可以拿到做决策的

看到一个现象, 太容易轻易下结论

• 会思考的比较闭环
  • 建议这种东西其实比较容易给出来, 但是需要去适配, 需要去融合自己的环境
• 需求项目开发规范
  • 我怎么能保障需求 story 给出来的一定能匹配客户的需求
    • 需要业务确认
    • 其实业务并不关心你的目标, 他只关心能不能满足他的需求
    • 需求其实一直没有变, 变的是对需求的理解
  • 我怎么保证技术开发完整的实现了 story 的要求
    • 要求有没有说清楚
      • 不能单方面的开发觉得听懂了就可以了, 可能会作弊
      • 碍于面子
    • 开发有没有遗漏
  • 我怎么保证产品的质量

1. 做事的逻辑

   1. 既然做了这件事, 那就找到最高效的做事方式

      • 统计过开发的时间占比
        • 用于思考/写代码的时间太少, 都在用于去沟通/对接业务需求上面去了
      • 降低运营成本
      • 做一件事就是绕把这些是最后做到不需要投入
        • 做具体的事情 (工具)
        • 怎么做事情 (策略)
      • 方法论很多, 其实不一定适用, 找到底层的逻辑
        • 做事应该都是有方法论的, 纯理性的东西, 只是未必能找到
          • 做人包含非常多感性的成分, 软技能
        • 遇到个外面找了很多资讯和高管, 推进一些制定
        • OKR 这种东西其实存在的假设是每个人都真的从内心把这件事当作自己的事情
          • 起到带头作用
          • 靠影响力

   2. 需求

      • 这个事情想明白之后的执行是期望有保障的, 也就是话语权
      • 期望有机会去切入到别人的工作中, 深入去了解, 去合作
        • 产生连接
        • 做人做事, 喝酒

做到事情

网关建设

• 支持网络转化, 部署在深圳阿里云, 海外通过网关将接口接入到内网

基础组件建设

• 打通 SSO/ 用户中心/ 统一权限

PPT 的逻辑

个人介绍

1. 个人简介

   • 架构师/研发效能
   • 2007-2011/软件工程/安徽工业大学
   • 深耕在技术 10+ 年, 熟悉 Java/golang/ruby 技术栈

2. 主要经历

   • 云励科技, 票税垂直行业, 多租户下的 SaaS 化架构
   • 依图科技, 图像识别 AI, 基础架构的工具链团队
   • 麻袋财富, 互联网金融行业, 微服务化技术架构演进
   • 银联智慧, 基于银联交易流水大数据产品的研发

主要工作

1. 技术架构

   1. 微服务架构设计

   2. 引入 Web 开发微服务架构设计

   3. 应用架构

   4. 数据架构

2. 技术方案

   1. 设计优先的原则

      • 编写推进 5+ 以上技术方案评审
      • 概要设计
      • 技术方案
      • Code Review 和技术分享

3. 项目执行

4. web 研发流程规范

5. web 研发基础设施建设

未来展望

• 技术架构
  • web 微服务化架构
  • 完善和打磨 web 微服务化架构
  • 学习总结和优化其他那些的研发模式, 比如组件/ 整机, 提升研发体验
  • 沉淀业务组件, 避免重复建设, 解决可复用性问题, 更高效的交付业务价值
  • 技术架构, 识别和引入和推广更多研发效率的技术
• 深入业务
  • 梳理繁杂的业务活动, 不断打磨和沉淀业务模型

微服务的架构设计和解锁的部分

• 为什么需要微服务
• 交付物的制品就是一个可独立运行的 web app

场测在整个测试 Stage 的现在及不久的未来

• 任务分发网络
• 目前有多少人在使用

共性问题价值

效能提升的问题

• 分支做的比较
• 只有当你这个流程被固化并且是最高效的时候才能沉淀到每个人手头上

技术分享

• 拿场测中落地的技术组件如何使用的来组织分析
• 分享对业务的理解帮助研发更好的承接业务

知识库建设

• 完成至少 10+ 篇技术方向上的文档超过 100 comments

冰山的下面

1. 研发流程和工具是什么样子的

   • 用户看到的是冰山上面的部分
   • 看不到的是冰山下面的部分
     • 流程

传音做事的方法论

• 先切分一个小的市场做验证 - 点
• 模式得到验证之后, 垂直做深入 - 线
• 在平台被整合 - 面