Skip to content

前端团队Q3季度汇报

项目端

问题域

  • 1、遗留系统复杂度高如同「焦油坑」，导致团队行动迟缓。
  • 2、新增定制化需求多，开发前景不明朗，需要经常返工，导致人力成本浪费。
  • 3、质量问题方面，机构客户服务器、网络、数据等基础设施完善程度大相径庭，部署方式不统一，容易引发未知BUG。

Object

  • 对于存量机构客户项目，做好数量、质量和成本的平衡，并通过树立敏捷理念、逐步落地内建质量，做到目以高标准、高质量的持续交付，进一步降本提效。

Key Results

  • 架构升级2.0，让团队轻装上阵，加速业务迭代和技术升级。

    • 技术上：以「中央厨房战略」为指导方针，成立「外科手术队伍」，加速遗留系统的改造，清理技术债务，将复杂、模糊、严重腐化的遗留系统进行切割，形成简单解耦、易于把控、独立进化的小型系统。

    x

  • 独立通道/增量更新部署，减少风险范围，确保质量。

    • 以微前端的方式开发、维护、测试、部署独立的业务模块，减少了部署的范围，从而降低了相关风险。

    x

  • 锚定业务价值，基于稳定点设计程序，减少返工。

    • 业务上：深度理解讯兔产品，对用户故事持续归纳和抽象，隔离通用需求和定制需求：通用能力下沉为标准化产品、可复用业务能力；探索用户场景，利用专业能力引导用户、共创用户定制化需求。

    x

SaaS端

问题域

  • 1、前车之鉴 Mindera小程序存在代码分包不合理，发布流程受平台限制等问题，阻碍小程序产品快速迭代。
  • 2、从零开始，首次面向普通用户发布 SaaS 产品的数据安全性、鉴权逻辑等，都面临挑战。
  • 3、小程序与服务号受限与微信平台，让我们无法实现一个高性能、功能完善的大型APP。

Object

  • 买卖方产品上线，完成功能验证价值，同时应对未来多变的业务需求，提升技术架构的可扩展性，提供从流量到留量的保障机制。

Key Results

  • 1、重构小程序开发脚手架，依赖动态注入的方式，解决小程序分包问题，为后来的快速业务迭代打下基础。
  • 2、每日站会，沟通当天进度、阻碍，迅速反馈，立刻解决，同时关注线上问题。

x

  • 3、深度参与嘉实移动App跨端方案的调研、技术选型、开发规范制定、架构搭建、应用开发、trouble shooting，为未来 SaaS 侧跨端 App 研发做好技术储备。

基建：「中央厨房」战略

问题域

  • 1、散装的定制化需求耗费了大量人力成本，同时产生了大量不可复用的业务代码和临时方案，未来代码的可维护性增加难度，其根本原因是：我们没有自己标准化的基线产品。

  • 2、基线产品不是凭空设计出来的，需要时间与用户「共创」。

    • 而是在与客户的互动中，共创出来的。经受多方验证的通用能力下沉，稳定的业务能力形成了基线版本，核心业务概念涌现出来。

Object

  • 落实“中央厨房战略”，根据标准产品划分业务领域，继续拆分前端微服务，根据领域责任到人，形成各个领域的业务专家。

Key Results

  • 核心库升级，面向未来

    • 核心库升级，数据流与UI解耦。UI组件逻辑独立出来，方便未来与设计团队一起打造提供视觉一致性的共享组件库，重用代码减少开发工作量。

    x

  • 架构 2.0 改造持续推进

    • 前端继续推进架构升级，根据业务领域拆分微服务，形成从拆分到集成的标准化流程；通过流程规划化，降低技术门槛，让领域专家专注于业务迭代，提升从模糊概念产品到中央厨房标准产品的转化率。
    • 基于「中央厨房战略」的正确的方向 + 足够工作量的累积，产生质变。

    x

  • 垂线团队

    • 根据业务功能而不是技术种类，纵向划分一个个独立自治的小团队，并由一个小团队全权负责一个业务模块，符合「领域驱动」的理念，使得团队工作更有凝聚力。

团队成长

问题域

  • 1、为了落地「中央厨房」战略，我们划分了很多「垂线团队」，垂线团队内部高内聚：沟通、情绪、专业技术、领域知识的同频，追求高效与敏捷。
  • 2、而「垂线团队」之间低耦合，长此以往会出现生疏感、割裂感，甚至沟通与交接上的认知沟壑。
  • 3、提出 "Inter-Operate，Not Integrate" 的概念：我们希望消除同一技术种类的各团队间的割裂感，同时兼顾业务垂直团队内的内聚与高效。

Object

  • 推进知识网络星球计划的建设，定期组织技术、产品业务、数据相关分享，教学相长，充分激发团队活力，从成就感和成长性驱动团队成员的自驱力和团队凝聚力。

Key Results

  • 知识星球计划：团队内部每周四做一次代码评审或技术交流，整理、归档、沉淀成为团队财富。

下季度规划

首要问题

  • 随着「中央厨房」战略的逐步落地，我们对遗留系统核心模块完成了切分，在外部项目的迭代中，产生了12个基线版本子应用，但问题也随之而来：
  • 1、早期子应用较少，管理在同样一个项目下，各个应用独立开发、部署冲突较少，通过约定部署上线规则可以满足需求。
  • 2、随着应用增多，开发、部署、版本间的冲突显现，按照约定部署的过程中，需要等待、手动解决冲突，同时额外维持一张复杂的表来做版本管理。
  • 3、我们需要进一步提高开发效率，因此需要以上流程都能独立、并行无冲突、自动化，因此需要对子应用池项目进行拆分，从而进入 3.0 时代。
  • 相比上一代架构2.0，2.0 是逻辑上的微服务，而3.0 是物理上的微服务架构。

规划：架构 3.0

  • Object

    • 升级架构3.0，实现物理上解耦，优化 DevOps 流程，提升软件开发效率、运行时性能。

  • Key Resuls

    • 拆分子应用池，简化基线应用版本管理
    • 去除子应用间的重复依赖，提升运行时性能