跳至正文
一个稳定身份 默认由人工编写 为可移植性而设计
Topoloom by Relia1

评估指南 · 简体中文

测试一项 Service 变更。 判断下一步。

在决定扩大评估前,记录现有流程、部署投入、观察到的行为、尚未解决的限制和导出结果。

产品行为必须在评估环境中实际演示。

01 · 问题

选一个协调问题。

选择一项对团队重要的 Service 决策。在测试共享模型是否改变工作方式前,先记录现有步骤。

  • 被复制的服务描述

    选一个出现在多个文档或图表中的概念,然后记录各副本在哪里不一致,或需要分别维护。

  • 一次实质性变更

    选一个负责人、依赖、Runbook、SLO 或 Decision 的变更,审查者应能理解并批准它。

  • 可见的基线

    记录当前的审查耗时、副本数量、缺失的关系,或其他评估之后可以再次测量的证据。

02 · 评估准备

在演示之前把边界说清楚。

商定哪些内容进入评估、谁可以查看,以及什么算是有用的结果。当生产知识不适合使用时,使用合成内容或经明确批准的内容。

  • 数据集

    使用一个 Service、一个 Team、两份简短文档和一张图表来测试复用。只有与所选工作流相关时,才添加 Runbook、SLO 或 Decision。

  • 参与者

    指定作者、审查者、评估负责人以及任何只读观察者。记录每个角色应有的访问权限。

  • 环境

    记录产品版本、已启用的配置、集成、身份提供方,以及评估期间使用的任何外部服务。

  • 证据采集

    决定哪些截图、时间戳、导出和审查者笔记将支撑最终决策,同时不包含客户或生产环境的机密。

  • 退出标准

    设定决策日期,并商定必须演示什么、哪些可以保持未测试,以及哪些差距会阻止扩大使用。

扩大范围前,先约定工作。

与Topoloom团队一起使用这份清单。在开始更大范围的部署前,为每个项目记录答案和负责人。

  1. 人员和时间

    确定作者、审查者和评估负责人,约定会议、准备工作和每个人可投入的时间。

  2. 内容和迁移

    从简短的合成或已批准文档开始。当前导入支持Markdown、纯文本、CSV/TSV、HTML、DOCX,以及从Confluence导出的Word文件,每个文件上限为1 MB。先测试一个,再列出规划更大迁移前需要手工整理的内容。

  3. 设置和连接

    确认可用的部署方式、登录方式、已启用功能和连接器。当前版本中,由部署运营方添加Workspace成员;没有邀请或自助注册。记录哪些数据会离开环境,以及谁可以访问。

  4. 支持和费用

    约定谁负责设置、问题和事故。以书面确认评估费用、后续价格和包含的支持;不要假定演示已确定这些条款。

  5. 决策和收尾

    设定审查日期,将结果与基线比较,再决定停止、继续测试还是扩大范围;同时约定导出、保留和删除步骤。

03 · 示例工作流

跟随一个概念,从编写到退出。

请产品团队在商定的环境中演示每一步。不要仅凭幻灯片、图表或术语推断某项能力。

  1. 编写

    使用普通的编写界面创建或导入一段简短的技术说明,并记录哪些内容仍是自由格式。

  2. 识别

    选中重要概念,询问其身份、类型、编写状态和当前状态是如何表示的。

  3. 复用

    从第二份文档或图表引用该概念,然后检查产品创建的是引用,还是另一个独立副本。

  4. 变更

    提出商定的负责人、依赖、Runbook、SLO 或 Decision 变更,并观察审查者在批准前能看到什么。

  5. 发布或保留

    演示已配置的发布与版本工作流,然后记录哪些内容变为不可变,哪些仍可编辑。

  6. 导出并检查

    生成可用的导出,在产品之外打开它,并把内容与文档化的导出清单进行比较。

对每一步,既记录成功路径,也记录在权限、提供方、网络或校验条件阻止完成时的行为。

04 · 权限与数据

提出能用证据回答的问题。

答案取决于被评估的部署及其配置。要求演示、配置依据和具名负责人,而不是接受笼统的保证。

  • 谁可以读取、编写、审查、发布、导出和管理所选资源?

    针对评估矩阵中的各角色,至少测试一个允许的操作和一个被拒绝的操作。

  • 当内容被搜索、引用、导出或通过集成展示时,授权在哪里评估?

    记录哪些检查已被演示,哪些仍停留在设计说明或配置假设。

  • 哪些数据会离开评估环境,出于什么目的?

    为每个已启用的集成或提供方列出目的地、字段、触发条件、保留和删除路径。

  • 哪些日志、分析、备份和支持流程可能包含评估数据?

    确认该特定环境的运营负责人和保留策略,而不是假定存在一个全局策略。

  • 当外部提供方、网络路径或集成不可用时会发生什么?

    观察哪些编写和审查任务继续、哪些暂停,以及不完整或过期的上下文如何标注。

  • 哪些安全、隐私和法律文件约束这次评估?

    只使用由其所有者提供的已批准文件;本指南不能替代这些材料。

05 · 导出与退出

在决定扩大之前先测试退出路径。

导出的名称不是完整性的证据。索取包含与省略信息的清单,然后用 Topoloom 之外的工具检查该包。

  • 可读内容

    确认哪些文档和图表表示形式可以在没有运行中的 Topoloom 环境时打开。

  • 结构化上下文

    检查被评估的导出是否包含退出计划所需的身份、版本、关系、来源、审查记录和映射。

  • 已记录的省略

    列出每一个未导出、被转换或需要单独管理流程的已评估字段或行为。

  • 可重复性

    从受控状态运行两次导出,并解释任何对下游使用或审计有影响的差异。

  • 删除与收尾

    商定评估结束后如何保留或移除评估 Workspace、提供方数据、账户、备份和证据文件。

06 · 决策记录

写下这次测试确认了什么。

将这八个字段复制到决策记录中。对每项结果标记为:已演示、经配置后演示、不可用或未测试;链接证据,并为每项差距指定负责人。

  • 范围与负责人

    记录 Service、文档、图表、测试的变更、作者、审查者、环境和决策日期。

  • 当前基线

    记录 Topoloom 测试前的现有步骤、重复编辑、审查时间和任何差距。

  • 观察到的工作流

    记录对象 ID、引用、第二次更新、审查结果、部署投入和人工清理,并附上证据链接。

  • 访问与数据

    记录一项被允许和一项被拒绝的操作、启用的数据流、各自负责人和尚未解决的问题。

  • 故障行为

    记录所测试的提供方、权限或校验失败;说明哪些操作继续进行,哪些内容变为陈旧或不可用。

  • 导出与退出

    记录哪些内容可在 Topoloom 外打开、包格式、省略项、重映射和收尾工作。

  • 比较与差距

    将同一项变更与基线比较,包括第二次更新。为每项差距指定负责人和解决日期。

  • 决策

    记录停止、延长或扩大;说明证据、尚未测试的假设和下一次审查日期。

下一步

测试工作流。 记录界限。

在会议前用术语表统一用语,然后围绕团队选定的范围明确的工作流和证据申请一次演示讲解。

产品截图