协作工具使用规范通常围绕沟通、文档、任务、通知和权限五类行为提出要求，明确在什么场景用什么工具、信息放在哪里、由谁维护、如何通知他人以及谁可以查看和修改。它约束的是成员可观察的日常行为，与系统参数配置、接口对接和数据迁移属于不同层面。下面逐类说明具体要求，并给出一个跨角色协作的完整示例。
要点总览（TL;DR）
- 协作工具使用规范约束成员行为，覆盖沟通、文档、任务、通知、权限五类要求，回答在什么场景用什么工具、信息放在哪、由谁维护、通知谁、谁能看。
- 沟通要求按事项性质选渠道，群聊与私聊各有用处，结论要写回文档或任务并说明存放位置，@他人时讲清请求和期望时间。
- 文档要求明确存放位置、命名规则和负责人；任务要求明确负责人、截止时间等最小字段，并由负责人及时更新状态。
- 通知要求控制发送对象与频率、约定免打扰时段和紧急例外；权限要求按最小必要原则申请与授予，并区分内部共享与外部协作边界。
- 使用规范约束人的行为，工具配置约束系统参数，接口集成与旧平台迁移属于其他主题；规范需要指定维护人并定期复核。
协作工具使用规范是什么，边界到哪里
协作工具使用规范是一组面向团队成员行为的共同约定。它回答的是“遇到某类事情时，人应该怎么做”：在哪个渠道发起讨论、结论写到哪里、任务由谁建、状态何时更新、通知发给谁、资料开放给哪些人。规范的价值在于让不同角色对同一件事形成一致预期，减少信息散落和重复确认。
规范约束的对象可以归为五类行为：
- 沟通行为：选择渠道、区分群聊与私聊、把结论沉淀到可留存的位置、使用@提醒的方式与响应预期。
- 文档行为：文档存放位置、命名与目录约定、负责人与更新责任。
- 任务行为：任务创建的最小字段、状态更新的时机与责任人。
- 通知行为：通知的发送对象与频率、免打扰时段、紧急事项的例外处理。
- 权限行为：权限申请与授予方式、共享范围、外部协作的边界。
规范不包括三类内容：系统接口配置与消息集成，属于企业应用与消息集成主题；账号开通与组织架构维护流程，属于系统管理范畴；旧平台数据迁移，属于研发工具替代与迁移主题。把这三类内容写进使用规范，会让文档变成配置手册，成员难以判断哪些条目与自己日常操作有关。
沟通行为要求：在哪里说、说什么、怎么留痕
沟通类要求解决的是信息流向问题。判断标准可以概括为：事项的性质决定渠道，结论必须落在可留存的位置，提醒他人时说明需要对方做什么。
渠道选择与群聊、私聊的边界
规范应约定按事项性质选择渠道。需要多人知晓并形成记录的讨论，放在项目群或对应工作项下；涉及个人安排、评价反馈或敏感信息的事项，使用私聊；需要长期查阅的结论，写入文档或任务描述。群聊适合同步进展和快速确认，私聊适合一对一沟通，两者都不适合作为最终结论的唯一存放地。
结论留痕与@使用礼节
群聊中形成的决定、分工和时间点，应由发起人或记录人整理后写回文档或任务，并在群内说明存放位置。@他人时应说明具体请求和期望时间，例如“请确认这份需求清单的第三项，明天上午前回复”，避免只发一个@符号让对方猜测意图。响应预期也需要约定：普通@在当个工作日内回应，标注紧急的事项按团队约定时限处理。判断示例：一次关于上线时间的讨论在群聊中完成，结论应写入发布计划文档，并在群内附上文档位置，而不是让成员翻聊天记录查找。
文档与任务行为要求：信息放在哪、由谁维护
文档与任务类要求解决的是信息归属问题。每条要求都应能回答“放在哪、谁负责、什么时候更新”。
文档的存放、命名与负责人
规范应指定各类文档的存放位置，例如项目资料放在对应项目的文档空间，制度类资料放在团队公共目录。命名约定要便于检索，常见做法是“项目名-文档类型-版本或日期”。每份文档需要明确负责人，负责人对内容的准确性和更新节奏负责；多人协作的文档应约定谁有编辑权、谁只读。文档结构宜用页面树或目录分层组织，避免所有文件堆在同一层级。
任务创建与状态更新
任务创建的最小字段通常包括：任务标题、负责人、截止时间、所属项目或迭代，必要时补充优先级和验收标准。缺少负责人或截止时间的任务，其他成员无法判断进度。状态更新要求明确时机与责任人：由任务负责人推进状态，进入进行中、完成或阻塞时及时更新，阻塞原因写在任务中而不是只在聊天里说明。这样项目看板上的状态才能反映真实进展。
在工具承载层面，ONES Project 可围绕项目计划、工作项和迭代安排协同工作，帮助团队及时了解任务状态、项目进展和待处理事项；ONES Wiki 支持文档关联项目任务，并用页面树组织项目文档与知识信息，页面组可关联项目，使需求与文档互相对应。文档实时同步并记录所有页面版本，支持随时查看与回滚，便于落实文档负责人和版本维护的要求。具体权限粒度与配置方式以实际版本和套餐为准。
通知与权限行为要求：减少打扰、控制可见范围
通知与权限类要求分别处理“打扰谁”和“给谁看”的问题，二者都与前面的沟通、文档行为直接衔接：沟通中产生的提醒需要控制范围，文档和任务的开放程度需要与共享范围一致。
通知对象、频率与免打扰
规范应约定通知的发送对象：只通知与事项直接相关的人，避免全群广播与当前工作无关的消息。频率上，进展类信息按固定节奏汇总，例如每日或每周一次，减少碎片化提醒。团队可约定免打扰时段，例如非工作时间和集中工作时段；紧急事项作为例外，需在通知中标注紧急并说明原因，同时约定可接受的响应时限。通知规则写清楚后，成员才能判断哪些消息需要立即处理。
权限申请、授予与共享边界
权限要求包括申请与授予两个动作：成员因工作需要访问某份文档或某个项目时，向文档负责人或项目管理员提出申请，说明用途和期限；授予方按最小必要原则开放，并定期复核。共享范围需要区分团队内部与外部协作：对外共享的资料应明确可查看的对象和内容范围，涉及敏感信息的文档在对外共享前需经负责人确认。ONES Wiki 支持为多种角色配置不同的读写权限，ONES Project 拥有产品、项目、任务多层级权限，可按组织架构、用户组、项目角色灵活分配，为落实共享范围约定提供承载方式；具体角色与权限项以实际版本和套餐为准。
规范与工具配置、系统集成的区别
使用规范、工具配置和系统集成约束的对象不同，混在一起写会让成员分不清哪些是自己的操作要求。下表按同一口径对照三者的差异。
| 层面 | 约束对象 | 典型内容 | 负责人 |
|---|---|---|---|
| 使用规范 | 成员行为 | 渠道选择、文档存放、任务字段、通知对象、共享范围 | 团队负责人与成员共同遵守 |
| 工具配置 | 系统参数 | 字段设置、状态流转配置、通知开关、角色权限项 | 系统管理员 |
| 系统集成 | 系统间数据流转 | 接口对接、消息推送集成 | 技术或应用管理团队 |
| 旧平台迁移 | 历史数据搬迁 | 数据导出、字段映射、迁移验证 | 迁移项目组 |
接口对接与消息集成属于企业应用与消息集成主题，旧平台迁移属于研发工具替代与迁移主题，本文不展开。使用规范可以引用配置结果，例如“按管理员设定的状态流转更新任务”，但规范本身描述的是成员在既定配置下应当采取的动作。
一个具体例子与常见误解
以下示例为演示情景，用于说明五类行为要求如何在一次跨角色协作中同时落地。
产品经理需要推动一次版本发布，涉及产品、研发、测试三个角色。按规范，沟通行为要求他在项目群发起发布范围讨论，涉及个人排期的协调改用私聊；讨论形成的范围结论写入发布计划文档，并在群内附上文档位置。文档行为要求发布计划由产品经理担任负责人，按“项目名-发布计划-日期”命名，放在项目文档空间的固定目录下。任务行为要求研发和测试负责人各自创建任务，填写负责人、截止时间和验收标准，状态变化时及时更新。通知行为要求范围变更只通知相关任务负责人，日常进展按每日汇总发送，非工作时间的紧急问题标注紧急并说明原因。权限行为要求发布计划对项目成员开放读写，对外部合作方仅开放只读范围，并由产品经理确认后再共享。五类要求各司其职，覆盖了从讨论到交付的完整过程。
常见误解之一是把规范等同于工具功能说明。功能说明描述按钮和菜单能做什么，规范描述成员在什么情况下应当做什么；前者由产品文档承担，后者需要结合团队实际工作方式编写。误解之二是认为规范发布一次即可长期使用。团队角色、项目类型和工具配置都会变化，规范应指定维护人，按固定周期或在重大流程调整后复核，收集成员执行中的问题并修订条目。规范条目写成可判断、可检查的行为，维护时才能发现哪些要求已经失效。
常见问题
团队规模较小，是否也需要把五类行为都写进规范？
五类行为都值得约定，但条目数量可以随团队规模调整。小团队可以先用少量条目覆盖最容易出问题的环节，例如结论写回哪里、任务由谁更新状态、资料开放给谁；随着角色增多和项目类型增加，再补充渠道选择、通知频率和权限复核等细则。判断标准是条目能否被成员直接执行和检查，与团队人数没有固定对应关系。
规范发布后成员不按约定执行，应该怎么处理？
先检查条目本身是否可判断。像“及时沟通”这类表述难以对照执行，可以改成“结论在讨论当天写入对应文档，并在群内附上位置”。其次看工具是否让正确做法更省事，例如文档目录和任务字段是否已经配置好。规范维护人可以定期收集执行中的具体问题，把反复出现的偏差转化为更明确的条目或配置调整，而不是只靠提醒。
通知和权限的约定与工具里的设置是什么关系？
规范描述成员应当怎么做，工具设置提供承载方式。例如规范要求只通知与事项直接相关的人，工具中的通知开关和角色权限项由管理员配置，成员在既定配置下按约定操作。两者需要对齐：如果规范要求对外共享前经负责人确认，权限设置就应让这一确认动作有对应的操作路径。具体配置项以团队实际使用的版本为准。
跨部门或与外部合作方协作时，规范需要额外补充什么？
跨边界协作主要补充共享范围和沟通渠道两方面的约定。共享范围上，明确哪些资料可以对外、以只读还是可编辑方式开放、由谁确认后再共享；沟通渠道上，约定对外沟通使用哪个群或哪个空间，避免内部讨论与对外信息混在一起。涉及敏感信息的资料，在对外共享前由文档负责人确认，这一条应与权限授予动作衔接。
规范应该由谁维护，多久复核一次？
规范通常由团队负责人指定一名维护人，负责收集执行问题、汇总修订建议并组织确认。复核周期可以按团队节奏设定，例如每季度一次，或在角色调整、项目类型变化、工具配置重大调整后触发复核。复核时逐条检查要求是否仍可执行、是否与当前工具配置一致，失效条目及时修改或删除，避免规范与实际工作方式脱节。
