[I.2] 个人作业：软件案例分析

软件工程第二次作业

项目	内容
这个作业属于哪个课程	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR
这个作业的要求在哪里	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR/homework/15609
我在这个课程的目标是	建立系统的软件工程思维
这个作业在哪个具体方面帮助我实现目标	通过对软件产品的深度调研与对比，练习专业化的 Bug 分析与用户调研方法，并尝试从项目经理的角度进行产品规划与团队进度排期。

第一部分 调研，评测

软件使用

（体验基础操作）

（编辑别人发布的界面，体验共享编辑功能）

软件分析：描述产品使用的基本流程，是否能够解决用户的需求？软件在数据量/界面/功能/准确度/用户体验上各有什么优缺点？

产品使用的基本流程：

Notion这个软件主要解决的是人们在工作时难以使用同一个软件同时记录多种信息的困境。要使用该产品，用户只需要在主页里创建一个新页面，就可以在这个页面上对于信息进行记录。它主要支持空白页面和数据库两种数据格式，在这个基础上可以创建出几乎所有记录数据的形式，用户只需要按照需求来选择对应的页面类型即可。

在页面的具体记录上，Notion做的像是一个简化版的、没有代码基础也可以看懂的markdown编辑器。它把所有字体、大小等设置都整合进了"/"这个命令里，甚至插入表格、插入图片的操作都可以使用命令来轻松完成。从设计来说，它很好地整合了常规所使用的几乎所有对文档的操作并简化为了"/"可以召唤出的命令，只需要选择对应的命令就可以实现不同的操作，大大简化了文档编辑的时间。同时，相比于其他文本编辑它最大的优势就是可以支持页面里嵌套页面，这对于梳理不同信息的逻辑十分有帮助。

同时，该软件还整合了多人合作模式，即可以支持多人共同修改同一个文档，这对于团队协作具有很大帮助。另外，它还同时具备了日程管理、AI代理、邮箱管理等辅助功能，这为工作者管理时间、项目进度、项目具体内容全部在一个软件里完成提供了可能。

该软件主要面向的是有着大量项目、知识管理需求的用户，例如学生、科研人员、个人开发者、创业者等。对于这个需求，对于我这样的学生群体来说，我认为它可以满足我对于知识系统梳理、时间规划、活动规划的需求。例如，在实验室开组会时，我们就使用Notion来汇总各自的进度，并在汇报时直接使用Notion里的文档来讲，省去了制作PPT的麻烦工作。有些情况下如果客户有一些比较特殊的工作需求，那么它并不一定可以满足。例如，如果客户要经常在飞机等无信号的场景下办公，那么Notion在离线模式下的孱弱性会使得操作很困难；再比如如果有人需要管理并分析一些规模很大的表格数据，那么Notion没有Excel那样专业的信息处理功能。总之，如果客户的功能是追求在正常环境下追踪并整理一些多模态、多形式的信息，那么Notion可以基本满足用户的需求。

在数据量的处理上，Notion 提供了几乎无上限的云端存储空间，允许用户上传大量的图片、论文 PDF 或是实验录音，这对于需要长期积累资料的科研和学习场景非常友好。然而，当单个页面内的“块”数量过多，或者数据库的关联层级过于复杂时，软件的响应速度会明显下降。在处理百万级数据行时，它无法像专业数据库或 Excel 那样流畅。印次，它更适合作为数据的存储与整合库而非计算工具。

在界面设计层面，Notion 通过侧边栏和无限嵌套的页面体系，让复杂的知识结构变得可视化。最出色的地方在于其多维视图的功能：同一套实验参数或文献列表，你可以一键从表格视图切换到看板视图（查看进度）或日历视图（查看截止日期）。这种灵活性极大地降低了信息整理的视觉压力。但缺点也显而易见，由于自定义程度极高，一开始使用的新用户在缺乏引导的情况下，容易对着空白页面不知所措；同时，缺乏系统思维的用户很容易把页面做得异常臃肿，导致在查找信息时陷入“套娃式”的路径迷宫。

功能方面，Notion 的最大特点是样样通而样样不精。它通过 / 命令集成了文本、代码块、数学公式的编辑，并且还顺应时代引入了AI助手来提升工作效率。但是，它的任务提醒机制不如专门的 Todo 软件细致，表格的计算逻辑也远逊于专业表格软件，用户往往需要在“一站式管理”和“专业化工具”之间做权衡。

在准确度与同步稳定性上，Notion 由于其高度依赖实时云端同步，只要网络环境稳定，多端协作的数据一致性非常出色。但在弱网或离线环境下，它的表现略显挣扎。这意味着Notion的使用高度依赖于网络环境，这对于一些没有网络环境的特殊用户并不友好。

最后从用户体验来看，Notion 具有“高上限、低门槛”的特征。新手可以快速上手记录文字，但想要搭建出一套自动化的科研管理系统或个人工作流，则需要一定的逻辑构建能力和学习成本。

改进意见：对产品有什么改进意见？

从上面的分析不难看出，该产品的主要问题就是对于网络环境的依赖、深度分析功能的缺失以及缺乏经验的用户难以高效构建页面的问题。因此，针对这三个问题，我分别对应提出改进意见。

首先，针对离线模式下的功能受限的问题，需引入更深层级的本地缓存与同步机制。 目前的离线功能更像是一种临时的页面缓存，无法支撑长时间的断网办公。如果能借鉴类似 Git 的版本控制逻辑，实现真正的本地优先编辑，并在联网后提供更智能的冲突解决策略，将极大地拓宽其在无信号场景下的使用边界，从根本上解决用户对数据丢失或无法读取的焦虑。

其次，为了提升功能的深度，可以在特定模块上增加更细颗粒度的配置选项。例如，在表格功能上，如果能支持更多高级的统计学分析函数，或者允许用户通过简单的 Python/JavaScript 脚本直接处理库内数据，那么它将覆盖更多的需求，让很多原来只能使用Excel处理的工作可以整合到这里完成，让“一站式”功能更加全面。

最后，针对缺乏经验用户难以高效构建页面的问题，我认为可以使用目前流行的AI代理来辅助。目前Notion自带的AI代理几乎只能解决文本生成的问题而无法实现对于Notion原生页面的编辑。如果AI可以具备对于页面进行管理编辑的功能，将对于用户管理信息起到更大的作用。例如，面对新用户冷启动困难的问题，AI可以提供详尽的指导；对于一些逻辑不清晰、信息臃肿的页面，AI可以自动分析页面逻辑并重构页面使得逻辑更为清晰。这不仅能降低学习成本，也能有效防止页面结构走向臃肿和混乱。

用户调研

（体验不同功能）

• 调研对象及需求：赵敏智，计算机学院三年级同学，软件工程为吴际班，主要需求为安卓应用开发课程应用设计与冯如杯项目中组员之间的信息同步。

• 采访形式：线下采访

• 采访过程（由录音转文字生成，部分文本为了连贯性进行了润色）

• 我：个人学习和团队项目有没有信息整理与共享的需求？

• 赵：有，比如正在搞的冯如杯、上学期安卓开发的团队任务；还有我自己考研知识与错题的梳理。

• 我：在这个过程中使用过哪些信息记录与梳理/团队协作的软件吗？

• 赵：考研的错题整理主要用的 OneNote，把相同类型错题整理到一起。团队开发时主要使用的是腾讯共享文档与飞书里的同步文档功能，代码同步使用的是 GitHub，但日常沟通和发文件其实主要是靠微信。

• 我：你觉得在使用的时候这些可以满足你的全部需求吗？或者这些有什么不方便的地方吗？

• 赵：知识整理方面，有时候文件一多就极其不好找，尤其是很久之前的东西，记不清放在哪了，搜索功能也不太给力；共享文档方面，一开始用不惯，和 Word 区别挺大，找不到一些功能；而且团队之间一起编辑的时候格式特别容易乱，尤其是往里面贴代码的时候，缩进全毁了。

• 我：现在我在调研 Notion 这个软件，我觉得做得不错，可以解决你的大部分需求，你可以试试。

• (随后，我协助他注册了网页版的 Notion，并带他体验了 / 快捷键、Block 拖拽、代码块高亮，最后让他尝试将冯如杯项目的任务清单用 Board 视图搭建出来作为测试)

• 我：你认为对比你之前使用过的那些软件，这个软件有什么优势和劣势？

• 赵：优势挺明显的，它的块做的不错，比Markdown都方便很多，排版极其自由。而且敲 / 就能直接调出代码块，对咱们敲代码的人来说体验比腾讯文档好太多了。劣势的话，感觉学习成本有点高，那个数据库的概念我一开始有点懵，关联属性设置起来有点像在建关系型数据库表，不如普通的 Excel 直观。另外就是网络加载偶尔会转圈。

• 我：现在你愿意说服你的队友改用这个软件来同步进度吗？或者你愿意把考研的一些知识总结放到这个上面来做吗？

• 赵：考研和专业课的笔记我绝对愿意搬过来，它的无限层级嵌套和双向链接用来建个人知识库太完美了。但是团队进度同步的话我可能还得犹豫一下。迁移成本比较高，加上队友里有不用这玩意的，让他们专门去学 Database 怎么筛选任务，估计会被骂。

• 我：这个软件目前有付费功能，就像这个页面所展示的，如果有需要，你会愿意为它付费吗？

• 赵：现阶段应该不会。它免费版的 Block 数量限制对个人来说已经完全够用了。团队版按人头按月收费太贵了，对我们这种毫无预算的大学生比赛项目组来说不太现实，除非它提供非常大力度的教育优惠。

• 我 ：那么你觉得这个软件目前需要改进的地方有哪些？

• 赵：我觉得最重要的是多给一些新手模板，尤其是数据库筛选那块，应该做个引导弹窗，不然新手上来真的不知道怎么玩。如果没有你指导我，对着这个简洁的界面我还真不知道应该怎么做。腾讯文档这块就做的不错，上来给你一个示例的文档，还有新手指导，比这个做的好。

• 总结

  • 采访对象实际使用的产品栏目：Page页面编辑模块、数据库编辑模块
  • 采访对象使用软件的过程中会遇到的问题和亮点
    • 输入体验极佳：块的概念打破了传统的文档排版限制，自由度极高，且 / 快捷键呼出代码块的功能对程序员群体极其友好，体验优于传统协作文档（如腾讯文档）和纯 Markdown 编辑器。
    • 对于信息模块整理的适配性：无限层级嵌套和双向链接的设计，完美契合个人考研笔记、错题本及专业课知识库的构建需求。
  • 采访对象觉得从用户体验的角度来说需要改进的地方
    • 学习曲线陡峭：数据库的底层概念较为硬核，属性关联逻辑类似关系型数据库，对于习惯了常规 Excel 表格的用户来说初次接触会感到发懵。
    • 团队推广阻力大：由于上手门槛高，若在团队中强行推行，会面临较高的学习和迁移成本，队友可能产生抵触情绪。
    • 网络与定价局限：网络加载偶尔存在延迟；且团队版按人头按月收费的标准对没有经费预算的高校团队过于昂贵。

评测结论：经过这么多工作，你一定有充分的理由给这个软件下一个评价:d) 好，不错

Bug分析

Bug 1：协作编辑模式下，非创建者图片块删除权限失效

1. 测试环境

• 操作系统：macOS Sonoma 14.x (于 MacBook Air 运行)
• 软件版本：Notion 网页版 (基于 Google Chrome v122)
• 网络环境：常规校园网
• 前置条件：账号 A（页面创建者）与 账号 B（协作者，被赋予 "Can Edit" 权限）同时对某一 Page 进行协作。

2. 可复现性及具体复现步骤

• 可复现性：特定条件下必然发生。特定条件为：协作者视图下，针对页面中的图片执行删除指令。
• 复现步骤：
  1. 账号 A（Owner） 创建一个全新的 Notion Page，并上传插入一张本地图片（Image Block）。
  2. 账号 A 点击右上角 Share，通过邮箱邀请 账号 B，并将其权限设置为 Can Edit（可编辑）。
  3. 账号 B 登录系统，进入该共享页面。
  4. 账号 B 尝试对文本块（Text Block）进行修改和删除，操作一切正常。
  5. 账号 B 鼠标单击选中账号 A 刚才上传的图片，按下键盘上的 Delete 或 Backspace 键；或者点击图片左侧的 ⋮⋮（六点菜单），尝试寻找 Delete 选项。

3. Bug 具体情况描述

• 具体现象：当拥有 Can Edit 权限的账号 B 试图删除该图片时，系统无任何响应。按下 Delete 键图片依然存在，且点击 ⋮⋮ 菜单弹出的列表中，缺失了常规的 Delete（删除）按钮。这意味着，名义上拥有整个页面“编辑权”的用户，实际上被剥夺了对特定媒体资源的删除权限，导致协作过程中若需替换图片，只能由原上传者操作。
• 配图说明：
  

4. Bug 分析

• 可能成因：从架构角度推测，Notion 采用的是基于块的 CRDT（无冲突复制数据类型）结构。对于纯文本块，权限继承自父级 Page；但对于图片这种富媒体资源，其底层文件实际托管在 AWS S3 等云存储中。该 Bug 的成因极可能是底层资源鉴权与前端页面角色鉴权脱节。后端生成删除 S3 资源的 Token 时，错误地进行了强校验（即要求 Action_User_ID == Asset_Uploader_ID），而前端 UI 为了避免触发后端的 403 Forbidden 报错，干脆在非上传者的视角下直接屏蔽了删除操作。
• Bug 的严重性（评级：中度缺陷）：
  • 系统功能：编辑功能存在割裂，未能完整兑现权限承诺。
  • 安全性：不存在数据泄露风险，属于权限收得过紧而非越权。
  • 用户体验：用户在不知情的情况下敲击删除键无反应，且没有任何报错弹窗提示原因，容易让用户误以为是电脑卡顿或软件死机。

5. 团队未在发布前修复的原因

个人认为主要原因包括以下两点：

• 具体的设计质量不高：在 RBAC（基于角色的访问控制）设计阶段，系统架构师未能将“页面级权限”完美映射到“跨域媒体资产的生命周期管理”上，导致富媒体块的权限逻辑出现了“硬编码”式的历史遗留问题。
• 测试把关不严，敷衍了事，没有注意在特殊的配置或环境下测试：协作类软件的测试极度依赖矩阵式的用例设计。QA 团队在执行回归测试时，可能仅仅跑通了“Owner 对页面的增删改查”以及“Guest 对文本的增删改查”，遗漏了“Guest 对他人创建的富媒体进行删除”这一交叉边界测试（Edge Case）。

6. Bug 改进建议

• 评估软件此处的正常行为：任何被赋予 Can Edit 或更高权限的用户，在页面内的所有行为应当拥有对等的一致性，即：可以随意增删改查页面内的任意 Block（无论该 Block 是谁创建/上传的）。
• 可能的实现方案：
  1. 后端重构权限校验逻辑：当接口接收到删除 Block_ID 的请求时，鉴权中间件不应仅比对资源的 Uploader_ID，而应向上溯源获取该 Block 所属 Page 的权限配置树，只要发起者的 Role 包含 Write 或 Edit，即放行并下发底层存储的删除指令。
  2. 前端 UI 补救（若后端改造困难）：若短时间内无法解决 S3 强绑定的问题，前端至少应该恢复 Delete 按钮，并在用户点击时弹出一个友好的 Toast 提示：“您无权删除他人上传的源文件，但已将其从当前页面移除”（前端做软删除屏蔽，保留云端文件引用）。

Bug 2：移动端网页版横向手势冲突导致侧边栏意外激活

1. 测试环境

• 操作系统：Android
• 浏览器环境：Google Chrome 移动版
• 发生时间：2026年3月
• 前置条件：用户通过移动端 Chrome 浏览器访问 Notion 网页版，进入一个包含横向滚动 Database 视图（如 Timeline 界面）的页面。

2. 可复现性及具体复现步骤

• 可复现性：满足特定条件下一定发生。特定条件为：在页面中间偏左操作区域对需要横向滚动的元素向右滑动。
• 复现步骤：
  1. 用户进入包含一个复杂 Timeline 视图的任务管理页面。
  2. 为了查看更远的日期范围，用户将手指触摸点放在屏幕的中间偏左区域。
  3. 快速进行向右的滑动屏幕。

3. Bug 具体情况描述

• 具体现象：用户原本的意图是横向滚动查看页面内容。然而，由于手势捕捉逻辑未能精准区分“滚动内容”与“激活导航”，Notion 系统有时会错误地捕捉到用户的动作，直接将左侧的侧边栏拉出，遮挡侧边栏的内容。
• 配图说明：
  

4. Bug 分析

• 可能成因：从实现角度推测，Notion 移动端网页版的鉴权和导航逻辑在捕获侧边栏拉出手势（由左边缘向右滑）时，缺乏对手势“起始位置”的强约束。底层算法错误地赋予了全局侧边栏拉出手势最高的优先级，即使手指触摸点明显不在屏幕左边缘，也会触发导航栏的激活，导致手势冲突。
• Bug 的严重性：中度缺陷：
  • 系统功能：编辑和浏览功能被外部导航频繁打断。
  • 安全性：无安全性风险。
  • 用户体验：严重影响效率。

5. 团队未在发布前修复的原因

个人认为主要原因包括以下几点：

• 测试把关不严，敷衍了事，没有注意在特殊的配置或环境下测试：协作类软件在移动端网页版的测试矩阵非常庞大。QA 团队可能偏向于测试原生应用（App）的用户体验，或者在测试网页版时，仅仅在桌面端通过 Chrome DevTools 的手机模式进行模拟，并没有在真实的触控设备上结合复杂 Database 视图（如时间轴、看板）进行深度场景测试。

6. Bug 改进建议

• 评估软件此处的正常行为：移动端系统的侧边栏激活手势应当具有最高的精准度，且不应干扰页面内部元素的正常滚动。即：只有当用户的指尖触摸点极度临近屏幕左边缘时，且操作意图为从左向右滑动时，才应触发导航栏激活。当操作点位于页面内容区的 Database Block 内时，应当赋予 Block 内部手势最高的优先级。
• 可能的实现方案：
  1. 后端/底层手势算法层面：增加一个手势激活的“边界锁定”权重。如果用户的起始触摸位置（startX）不满足某个临界值，则该手势将无法触发导航拉出。
  2. 前端逻辑控制层面：检测到手指触摸点位于可横向滚动的 Database Block内部时，暂时禁用外层侧边栏的触发捕获，直到用户的手势离开该区域或手指松开。

第二部分 分析

1. 工作量分析

前提假设：团队人数 6 人（均为计算机专业大学毕业生：2名前端、2名后端、1名测试、1名PM）+ 1名专业 UI 支持。
目标：将软件从零开发至目前 Notion 的功能完善度（包含块级编辑器、多维数据库、实时协同、多端同步）。

结论预估：要达到 Notion 目前这种工业级的成熟度和复杂度，该团队至少需要50-60周的持续高强度开发。

具体排期拆解如下：

• 阶段一：底层架构与 Block 编辑器基建（约 12 周）
  需攻克以块为单位的前端渲染逻辑。摒弃传统的富文本编辑器，从零手写一套基于 React 的块级渲染引擎，并定义跨端的数据结构。
• 阶段二：Database（关系型数据库）核心业务（约 16 周）
  开发 Notion 最核心的数据库模块。实现 Table、Board、Timeline 等多视图的无缝切换，以及复杂的后端数据聚合与前端状态管理逻辑。
• 阶段三：CRDT 实时协同与后端高并发处理（约 16 周）
  需要引入并定制 CRDT（无冲突复制数据类型）算法或基于 WebSocket 的协同机制，解决多人同时编辑同一个 Block 甚至同一张表时的冲突合并问题，并搭建高可用的云端存储架构。
• 阶段四：跨平台适配与回归测试（约 10 周）
  适配 Web、macOS/Windows 桌面端以及 iOS/Android 移动端。处理复杂的移动端交互逻辑，并进行全面的压力测试、安全渗透与多端 UI 走查。

---

2. 软件质量分析

2.1 产品优劣势与同类竞品对比

软件名称	灵活性	易用性	扩展性	协作与网络	适用场景
Notion	极高	较差	极强	一般	中小敏捷团队
Jira	极低	极差	极强	优秀	重度研发项目管理
Obsidian	极高	极差	极强	极差	个人深度知识图谱
腾讯文档	较低	极优	较弱	极优	国内泛领域轻量办公
飞书	较高	中等	较强	极优	国内中大型企业协同

2.2 团队在软件工程方面可提高的重要方面

具体建议：强化跨平台边界用例测试与场景化回归测试。

• 目前团队的研发重心过度倾斜于 Web 端的核心功能，而对移动端触控交互的特殊配置环境缺乏严谨的真机测试。
• 在 RBAC（基于角色的访问控制）系统的测试用例设计上存在盲区，未能覆盖所有 Block 类型的交叉权限判定。
• 建议该团队的 QA 部门在发布流程中引入更严格的矩阵式用例覆盖，并在自动化测试体系中加入针对移动端复杂手势冲突的拦截脚本，避免为了快速发布新功能而牺牲了边缘场景的用户体验。

三、建议和规划

市场现状

Notion 主要解决的是知识工作者信息碎片化的问题。其市场规模庞大，直接用户涵盖了大量的高校学生、科研人员、程序员和初创团队。潜在用户则是目前仍在使用本地传统办公软件或简单备忘录，但未来存在在线协同需求的人群。

目前市场上的竞争产品主要分为两类。一类是 Jira 等重度研发管理软件，另一类是腾讯文档、飞书等偏轻量级的在线办公软件。Notion 的定位介于两者之间，属于高度模块化的工作台。其优势在于极其自由的页面构建能力和丰富的生态，劣势在于缺少纯离线模式，且对于没有技术背景的普通用户上手门槛过高。在当前的竞争态势中，Notion 基本占据了极客群体和个人深度知识管理赛道的头部位置，但在国内的大众轻量级办公赛道上，普及度还不及腾讯文档等本土软件。

市场与产品生态

该产品的核心用户群主要是 20 到 30 岁的青年群体，如一二线城市的大学生和互联网从业者。典型用户往往是计算机及相关专业学生，或有大量资料整理需求的人员。这部分人群的表面需求是寻找一个好用的笔记软件来记录课堂知识、错题或项目进度；而潜在需求则是希望构建专属的个人知识库，并追求软件界面的极简美学。

Notion 的用户群体之间存在很强的相互依存关系，天然形成了一个模板生态。部分动手能力强的极客用户会利用底层数据库功能开发出复杂的项目管理模板，并分享或售卖给不愿耗时折腾的普通用户。这种创作者与使用者的关系，不仅降低了新用户的上手难度，还增强了社区黏性，将工具本身转化为一个内容沉淀的社区。

产品规划

在现有软件功能的基础上，可以设计一个面向研发团队的代码与实验状态同步面板。这一设计的出发点在于，团队通常需要将代码提交到 GitHub，并在本地运行实验，但项目文档和进度总结又必须记录在 Notion 中。这种工作流导致了代码与文档的严重割裂。因此，若能在软件内直接绑定代码仓库，实时同步提交记录，甚至通过接口将实验跑分结果直接回传至看板，将极大提升团队协作效率。

NABCD 模型分析如下：

• N（需求）：研发团队和科研小组需要在编写需求文档和总结报告的同一平台上，直观地查看代码开发进度和实验数据，消除多软件频繁切换的痛点。
• A（做法）：在软件内部新增一个专用模块，允许用户授权并绑定代码仓库，系统自动抓取进度数据，并在数据库看板中实时更新对应的卡片状态。
• B（好处）：团队成员只需留在一个软件生态内即可完成文档流与研发流的闭环，大幅降低沟通与管理成本。
• C（竞争）：Jira 虽具备代码绑定能力，但对于几人规模的学生小组或敏捷团队而言过于笨重；而常规的在线文档又无法深度对接开发者工具。此功能恰好填补了轻量级研发管理的市场空白。
• D（推广）：可将其封装为“敏捷开发专用模板”或“科创项目管理模板”，发布在官方模板社区及各大技术论坛中吸引目标用户。

针对该功能的开发，若由 6 人团队在 16 周内完成，考虑到功能的交互复杂度及接口对接工作量，角色配置建议如下：1 名项目经理兼 UI 设计，负责把控整体进度与界面交互；2 名前端开发，负责页面交互逻辑和新模块的渲染；2 名后端开发，负责对接外部代码仓库接口及数据处理；1 名测试人员，负责各网络环境及终端的功能测试。具体排期规划如下：

• 第 1-2 周：确定具体的需求细节和页面设计原型，前后端人员讨论并敲定技术选型与接口数据格式。
• 第 3 周：搭建整体开发环境，完成后端底层的数据库表结构设计。
• 第 4-7 周：进入 Alpha 版本的核心开发阶段。实现授权登录、代码仓库绑定等基础功能，期间可引入结对编程等敏捷开发实践以保证代码质量。
• 第 8 周：在团队内部进行 Alpha 版本的里程碑发布，跑通最基本的单向数据拉取与展示流程。
• 第 9-12 周：进入 Beta 版本开发阶段。完善交互细节，处理网络延迟、数据同步冲突等异常边界情况，并优化前端的错误提示机制。
• 第 13 周：由测试人员主导进行全面的功能测试、安全测试和压力测试，开发人员集中修复暴露的 Bug。
• 第 14 周：邀请周边正在进行课程大作业或比赛的真实用户群体进行灰度测试，收集实际使用反馈。
• 第 15 周：根据前期收集的用户反馈，进行产品发布前的最后细节微调和文档完善。
• 第 16 周：按期发布该改进版本，并组织团队复盘会议总结研发经验。