云效

请审查需求是否具备进入研发或接受变更的条件。输入：需求当前版本、上一版或变更说明、设计及接口资料、数据和权限约束、迭代安排、团队已有评审规则。给出可操作的评审问题与责任建议。

评审内容和节点以团队现行规则为准，下面的检查维度用于补齐业务问题，不替代团队的决策流程。

执行步骤：
1. 确认审查对象、版本、材料日期和本次变更范围，对比前后差异。材料不完整时列出实际已读内容，避免以旧版设计稿审查新版需求却不说明。
2. 检查目标、角色、输入、业务规则、状态、失败恢复和验收条件是否齐备。每个问题指出具体条目及会影响的用户操作，避免只有“建议完善”等泛泛意见。
3. 分析变更对历史记录、统计口径、接口兼容、导入导出、权限和跨组织数据的影响。分别列出已证实影响、需查代码或数据才能确定的影响。
4. 检查设计、接口、前后端任务与测试准备是否相互匹配，找出责任空白和依赖顺序。没有人员和工期证据时只写责任角色，不替团队承诺完成日期。
5. 按业务损失与返工范围确定问题优先级，区分必须明确后才能开发的问题、可并行补充的问题和优化建议。优先级定义优先使用团队既有规则。
6. 给出逐项处理建议、补充材料、责任角色和复核条件，并形成进入研发、补充后复核或暂不具备条件的建议。未获得真实评审意见时不能标注任何人已同意。

输出：评审范围与材料、变更摘要、问题表、影响关系、待办清单、评审建议及其条件。问题表含编号、依据位置、具体影响、优先级理由、责任角色、关闭条件。

验收：每条问题可定位和复核；重大规则与权限影响没有被界面细节掩盖；结论基于当前版本；建议与团队真实决策明确区分。

信息边界：只进行材料评审，不自动推进工作项状态、替他人签署意见或发出上线通知；未知事实应保留为问题，不能用行业惯例冒充已确认规则。

参考来源（核验于 2026-09-08）：
- [云效 Projex：需求评审](https://help.aliyun.com/zh/yunxiao/user-guide/requirements-review)
- [使用项目协作创建并完成需求](https://help.aliyun.com/zh/yunxiao/user-guide/start-collaboration-within-a-project)

请将业务需求转成可交付研发的功能说明与工作项。输入：业务需求、已确认范围、现有系统或页面、业务规则及数据字典、项目与迭代约束、参与角色。面向产品、设计、前后端和测试共同阅读。

工作项需写清描述、负责人、优先级、项目和迭代，并关联设计、接口等研发资料；字段与流转规则以团队实际使用的系统为准。

执行步骤：
1. 建立需求编号和简短中文标题，写明业务背景、使用角色、进入条件和最终结果。每条只描述一个可独立验收的业务目标，复合目标先拆分再说明关系。
2. 逐项列出页面或接口的输入字段、来源、类型、必填条件、合法范围、默认值和校验时机。任何默认值须有业务依据；历史数据兼容规则未知时作为缺口保留。
3. 明确核心计算、状态变化、重复提交、并发修改和失败恢复规则，分别写正常路径与异常路径。凡涉及统计，注明时间范围、组织范围、状态过滤和去重口径。
4. 整理角色操作矩阵，分别定义查看、新增、修改、审批、导入和导出权限。说明数据可见范围及权限不足时的用户反馈，不把按钮隐藏当作完整授权实现。
5. 按设计、服务端、前端、数据调整和测试拆分实际工作，建立依赖与交付物。负责人可用已提供的人名或岗位，缺少人员安排则保留待分配，避免编造排期。
6. 将需求编号关联设计稿、接口、规则依据和验收用例入口，写出每项完成条件与变更影响。只建议需要的工作项，不把拆分结果冒充已经在云效创建。

输出：功能说明表、字段规则表、状态与异常分支、角色权限矩阵、研发任务及依赖、验收清单、待补充材料。工作项至少包含标题、范围、责任角色、依赖、交付物、优先级依据。

验收：开发能够识别输入、处理规则和结果；测试能够从每项需求形成用例；没有无来源字段和虚构工期；中文业务名称前后一致。

信息边界：现有代码与需求冲突时同时列出两者，并标明需要业务决策的差异；本任务默认不创建外部工作项或发送协作消息。

参考来源（核验于 2026-09-08）：
- [云效 Projex：新建需求](https://help.aliyun.com/zh/yunxiao/user-guide/new-demand/)
- [使用项目协作创建并完成需求](https://help.aliyun.com/zh/yunxiao/user-guide/start-collaboration-within-a-project)