发布最佳实践：项目成员发布管理落地方案，常见问题

项目发布前一天，测试负责人发现候选版本里有两个需求没有验收记录，开发负责人则认为它们已经合并；项目经理看到的进度是“开发完成”，运维拿到的却还是上周的部署清单。类似问题往往不是成员不努力，而是发布管理没有把“谁在什么时间交付什么、由谁确认、出现变化后如何处理”说清楚。发布最佳实践的重点，不是多开几次会，而是让项目成员围绕同一份发布基线协作，并为每个关键决策留下可追溯的记录。

一、先讲核心结论：发布管理管的是协作闭环

1. 发布不是一个日期，而是一组可验证的承诺

不少团队把发布管理理解为“确定上线日期、通知相关人员、安排部署”。这只覆盖了发布的末端。真正影响发布成败的，是需求、开发、测试、运维、业务验收等角色能否在同一节奏上完成交接。日期只是承诺的外壳，里面必须有范围、责任人、验收标准、风险和回退安排。

我判断一套发布机制是否有效，通常不先看项目看板有多少状态，而是追问五件事：本次发布包含什么；每项内容由谁负责；什么证据能证明它完成；谁有权批准进入下一阶段；临近发布时发生变化由谁裁决。只要其中一项没有明确答案，团队就容易把“我以为”当成流程。

发布管理的核心产物不是一张排期表，而是一条可追溯的决策链：需求进入发布范围，任务完成并通过验证，版本候选得到批准，发布窗口内按步骤执行，发布后确认业务结果，异常时按预案恢复。

2. 用四个控制点代替“大家盯紧一点”

“大家盯紧一点”不是管理动作，因为它没有定义检查对象、执行人和触发条件。更可执行的做法，是在发布过程中设置四个控制点：范围冻结、候选版本确认、发布准入、上线后验证。每个控制点都对应一个责任角色和一份证据。

• 范围冻结：明确本次要交付和明确不交付的内容，避免需求在测试后期悄悄进入版本。
• 候选版本确认：检查代码、构建包、配置、数据库变更和测试结果是否对应同一个版本。
• 发布准入：由指定负责人依据质量、风险和回退条件作出继续、延期或缩小范围的决定。
• 上线后验证：确认关键业务链路、监控指标和用户反馈，而不是以“部署命令执行成功”作为发布完成。

这四个点的价值在于把模糊协作变成可检验的交付。每个点都不必设计复杂审批；小团队可以通过一次短会和清单完成，大型组织则可能需要权限控制、审计记录和跨团队确认。

3. 发布质量看结果，也看结果是否可解释

发布成功率高，不代表管理一定成熟。如果团队每次都靠少数熟手临场补位，结果可能暂时不错，但过程不可复制。相反，成熟机制不仅能降低故障，还能回答“为什么延期、风险在哪一步暴露、哪些检查最有效”。

建议至少同时观察结果指标与过程指标。结果指标包括按期发布率、发布后故障率、回滚率；过程指标包括范围变更次数、准入材料完整率、阻塞问题平均处理时长。只盯结果容易把运气当能力，只盯过程又会把填表当产出。

二、背景和真实场景：为什么成员管理总在发布前失灵

1. 项目成员参与的是同一发布，承担的却是不同责任

一个版本通常涉及产品、研发、测试、设计、运维、安全、业务验收等角色。它们的工作并非简单串行：需求澄清可能与技术方案并行，测试准备依赖接口稳定，运维评估又需要部署结构和容量信息。管理者如果只把所有人放进同一群聊，成员之间看似信息相通，实际上各自依据的版本、口径和时间点可能并不一致。

我见过一种典型的错位：项目计划显示某功能已完成，开发人员指的是代码合并；测试人员理解为测试通过；业务方认为是可以面向用户开放。三个“完成”指向三种状态，最后只能在发布窗口里补做定义。问题并不在状态名称本身，而在于状态没有明确的退出条件。

因此，发布管理首先要把角色责任拆开。负责人不等于执行人，审批人也不等于所有问题的最终解决者。每项交付物都应至少写清：谁产出、谁验证、谁作出决策、谁需要被通知。

2. 高频变化会让计划失去可信度

需求变化本身并不可怕，危险的是变化没有经过影响评估就直接进入迭代。一个看起来只有半天工作量的改动，可能影响接口兼容、测试范围、文档、数据迁移和业务培训。发布计划如果只记录开发工时，就会低估这些隐性成本。

对每次范围变化，我建议至少追问四个问题：它解决什么用户问题；影响哪些任务和角色；会不会改变测试与回退策略；如果不纳入本次发布，最迟何时再处理。判断结果要落在接受、延期、替换或拒绝其中一种，而不能只留下“评估中”。

3. 规模扩大后，口头同步的边际成本急剧上升

十人以内的团队，负责人可能通过日常沟通掌握大部分变化；当项目成员增加到多个职能组、多个地域或多个并行项目时，靠记忆和即时消息同步就会出现信息滞后。尤其是关键成员同时参与多个版本时，单个项目的排期变动会传导到其他团队。

中大型企业或成员超过百人的组织，需要更重视统一视图、角色权限、变更留痕和跨项目依赖。比如使用 PingCode 这类项目管理平台时，重点不应是把所有团队都塞进同一套流程，而应先统一项目、需求、任务、缺陷与版本之间的关联，再按团队实际情况配置流程。工具能提供共享记录，但不能替管理者决定风险容忍度。

4. 发布窗口越紧，越要提前处理不确定性

团队常把最后几天当作“冲刺阶段”，实际上，越接近发布窗口，发现问题的处理成本越高。早期发现缺少验收标准，可以补充说明；发布前发现同一接口有多个不兼容改动，可能需要重新测试甚至延期。真正的效率不是压缩所有检查，而是把不确定性尽可能前移。

一个实用的管理判断是：如果成员在发布前两三天才第一次看到最终范围，团队管理的不是发布，而是在赌各环节恰好没有遗漏。对关键版本，范围确认应早于测试冲刺；对高风险变更，技术评估与回退方案应早于上线审批。

三、常见误区：看似做了管理，实际没有控制风险

1. 把发布管理等同于发布日期管理

只维护一张“版本号，上线日期”表，无法说明版本是否具备上线条件。日期能帮助协调资源，却不能证明需求已验收、缺陷已处理、运维方案已准备。若计划表上只有日期和负责人，管理者很难在问题出现时判断究竟是内容、质量还是资源导致延期。

修正方式不是增加更多日期字段，而是围绕日期补充交付证据。每个关键事项要有完成标准；每个风险要有处置人和截止时间；每次范围调整要有明确结论。

2. 用“开发完成”替代可验证的完成定义

“开发完成”可能意味着代码写完，也可能意味着代码合并、构建成功、单测通过或环境部署完成。若不同角色使用同一个状态却理解不同，项目看板会制造虚假的确定感。

建议给状态配套退出条件。例如，开发完成可以要求代码合并、关联需求、自动化检查通过；测试完成可以要求约定范围内用例执行完毕、阻断级缺陷关闭、遗留风险获批准。团队不必追求复杂流程，但必须让状态可解释。

3. 临近发布才集中做风险盘点

发布前检查会发现风险，却不一定还有时间处理风险。如果依赖项、数据迁移和权限审批直到上线前才被提起，团队很可能只能在延期和冒险之间二选一。

风险盘点要分阶段做：计划阶段识别依赖与外部审批；开发阶段检查变更影响；测试阶段验证关键业务链路和回退方式；上线前只确认风险是否仍在可接受范围内。上线前检查不是风险管理的起点，而是最后一道闸门。

4. 把所有变更都当成紧急事项

当每个需求方都能绕过既定流程，把自己的需求标成紧急，紧急机制就失去意义。真正的紧急变更需要说明损失、时限、受影响范围以及不处理的后果，并由有权限的人作出取舍。

我倾向于把紧急变更分为两类：修复正在造成的重大业务或安全影响；利用窗口处理已经评估过、延期会产生明确高成本的内容。一般体验优化、临时想法和缺少证据的“领导要求”都不应自动获得插队资格。

5. 认为工具配置越细，管理越成熟

复杂的状态、审批和必填字段可能让流程显得严谨，却也可能让成员为了通过系统而填写无用信息。若字段没有对应决策，审批没有明确风险责任，流程只会增加等待。

判断字段是否值得保留，可以问：谁会使用它；在什么决策中使用；缺失时会造成什么风险。如果答不上来，就不要把它设为强制项。工具配置应服务于控制点，而非用配置数量证明管理水平。

6. 发布成功就关闭项目，不做复盘

部署成功只证明技术动作完成，不代表用户价值实现。业务链路可能在真实流量下失败，关键指标可能没有改善，支持团队也可能收到大量重复问题。没有发布后观察，团队就无法区分产品缺陷、培训不足、监控缺口和预期偏差。

发布后复盘要聚焦可改变的机制，而不是追究谁“没盯住”。例如，若回滚演练耗时超出窗口，问题可能是预案未验证；若缺陷集中在某类接口，可能是契约测试不足。复盘结论应转成下一次发布的具体控制措施。

四、专业判断逻辑：从发布范围到上线确认的落地方案

1. 先建立发布基线，再开始追踪成员进度

发布基线是本次版本的共同参照，至少包含版本目标、范围清单、计划窗口、交付责任人、验收条件、依赖项和已知风险。没有基线，进度就无法判断：今天的完成率可能以昨天的范围为分母，延期也可能是需求不断变化造成的。

基线不等于锁死需求。它的作用是区分“原计划内容”和“后来变化”，让影响有迹可循。基线确认后，任何新增或替换都应留下提出人、理由、影响评估、决定人和结论时间。

2. 为每项发布内容定义责任与证据

项目成员管理最容易出现责任重叠或责任空白。建议对关键交付物使用轻量责任矩阵：执行者负责产出，验证者负责检查，决策者负责接受风险，知会对象需要及时获知变化。一个人可以兼任多个角色，但每个责任必须有人承担。

这张表不是要求每个小团队都增加正式岗位。它的用途是逼团队回答：缺少某项证据时由谁补，证据不一致时由谁裁决。责任矩阵最好围绕高风险交付物建立，不要把所有琐碎任务都纳入审批链。

3. 用阶段门管理节奏，不用会议替代判断

阶段门是一个明确的决策时点，不必等于一场长会。管理者可以异步查看清单，只有存在争议的事项才召开短会。每个阶段门都要有进入条件、检查内容和退出决策。

1. 计划确认：范围、依赖、窗口、关键成员和验收标准已明确；未确定事项有负责人和截止时间。
2. 开发检查：关键接口、环境、数据和外部依赖已验证；范围变化完成影响评估。
3. 候选版本检查：构建编号固定，测试结果与该构建对应，阻断问题已有处理结论。
4. 发布准入：业务风险、运维准备、监控和回退条件均可接受；决定继续、延期或缩小范围。
5. 上线验证：关键链路通过，监控处于预期范围，业务代表确认是否需要扩大、暂停或回退。

阶段门不能只记录“通过”。应当保留通过依据、附条件通过的条件，以及延期后的复查时间。这样团队才能复盘判断质量，而非只知道最后是谁点了批准。

4. 把发布准入做成风险判断，而不是打勾比赛

清单是防遗漏工具，不是自动批准机器。即使所有必填项都完成，也可能存在无法消除的业务风险；反过来，个别低风险材料暂缺，也未必值得阻断整个发布。关键是明确风险级别、影响范围、发现概率和恢复能力。

我建议至少区分三种结论：可以发布；满足指定补救条件后发布；不应发布。对第三种结论，必须写清触发原因及重新评估时间。对第二种结论，要指定补救责任人，并在发布窗口前验证条件是否满足。

5. 让异常升级路径事先存在

项目里常见的延误不是问题本身，而是问题没人敢升级。成员可能担心暴露风险被视作能力不足，于是等到自己解决不了才报告，留给团队的调整空间已经很小。

建立升级机制时，明确什么情况必须升级：关键依赖超过约定时间未响应；阻断级缺陷影响窗口；核心成员无法到位；测试环境不稳定；回退路径未经验证。升级的目的不是追责，而是让有决策权的人及时选择调整范围、补充资源或延期。

6. 通过统一记录减少多渠道信息冲突

聊天工具适合快速讨论，不适合长期充当唯一发布档案。重要决定如果只存在于某条消息里，成员加入、人员轮换或跨团队协作时，很难知道哪条信息仍有效。发布记录应链接到需求、任务、缺陷、构建和决策，而不是把全部上下文复制成几份表格。

在 PingCode 等项目管理平台中，可根据组织成熟度把需求、迭代、缺陷和版本关联起来，并为关键节点配置负责人、状态和审计记录。对于中大型团队，权限和跨项目依赖尤其重要；对于规模较小的团队，先建立统一版本清单和变更记录通常比全面铺开复杂流程更有效。

五、案例与数据观察：一个版本如何从混乱转向可控

1. 案例边界与样本说明

下面使用一个情景模拟案例说明落地方法。案例设定为一支由产品、研发、测试、运维和业务代表组成的企业软件团队，约 30 名项目参与者，每三周发布一次功能版本。数字用于展示管理逻辑，不是某家企业的真实绩效，也不应当被当作行业基准。

这类案例最值得关注的不是“上线率提升了多少”，而是团队如何识别数据背后的问题。若范围不断变化，单纯提高按期率可能只是减少了测试时间；若故障下降但发布前人工投入翻倍，也未必是可持续改善。

2. 初始问题：项目状态很多，发布判断仍然靠问人

模拟团队初期有四类反复出现的问题：一是需求状态由各组自行解释；二是测试结果没有稳定关联构建编号；三是紧急需求在测试后期进入版本；四是回退流程文档存在，但没有明确责任人演练。项目经理每天追问进度，仍无法快速回答哪些内容真正具备上线条件。

我们把问题拆成三组观察：信息是否一致、风险是否提前显现、决策是否能在窗口前完成。这样做比给团队贴上“执行力不足”的标签更有帮助，因为每一组都能对应具体改进动作。

3. 调整动作：先收窄控制范围，再补足关键证据

• 冻结版本范围，并约定新增需求必须提供影响评估，不能仅凭口头承诺进入候选版本。
• 将“开发完成”和“测试完成”改为带退出条件的状态，测试结果必须关联候选构建。
• 为阻断级缺陷、业务验收、部署验证和回退方案指定明确责任人。
• 把发布前长会拆成异步检查表与短时决策会，会议只处理未解决的风险和取舍。
• 上线后设置观察窗口，记录关键业务链路、告警和用户支持反馈，并复盘偏差。

这里的关键不是流程变多，而是控制点更少、更清楚。团队先对高风险事项建立闭环，再根据复盘结果决定是否扩大到低风险任务，避免一开始就要求所有工作使用同样重的审批方式。

4. 观察结果：过程指标比单个成功率更能说明变化

以下仍是情景模拟数据，用于展示复盘时可以怎样对照。假设连续观察八个发布批次，团队在措施实施后，范围变更更早被记录，候选版本关联更完整，回退演练也从“文档存在”变为“责任人实际执行”。在真实项目中，必须统一统计口径，并区分发布规模和风险级别。

这组数据不能证明流程改善必然带来相同幅度的结果。它更适合用来说明一个判断：若按期率提升，同时紧急修复占比下降、晚期变更减少、演练覆盖增加，改善的解释更可信；若只有按期率上升，就应该检查是否压缩了验证时间或降低了发布门槛。

5. 如何避免把案例数字误当成团队目标

建议团队先收集两到三个周期的基线，再设定阶段性改进目标。若历史数据缺失，第一步应是统一定义，而不是追求漂亮数字。例如，“故障率”究竟按版本数、变更项数还是用户影响事件计算；“按期发布”是否把缩小范围后按时上线也算成功，都要先说清。

数据还需要有分层视角。低风险文案调整与涉及数据结构变更的版本，不应简单放在同一组比较；新团队与成熟团队、内部系统与面向用户的系统，也可能有不同的容忍区间。指标的用途是帮助决策，不是用一个数字给成员排名。

六、不同情况下的行动建议：按团队规模和风险选做法

1. 小团队、低风险、发布频率高

小团队不宜照搬大型组织的审批链。可以使用一页式发布清单，覆盖范围、负责人、测试结果、部署步骤、回退条件和上线验证人。清单由项目负责人维护，成员只更新自己负责的事项，避免重复报表。

当版本主要是低风险迭代时，可采用轻量准入：发布负责人检查关键事项，只有阻断问题和重大变更才升级讨论。若每次发布都花大量时间填表，团队应删减无法影响决策的字段。

2. 多团队协作、依赖复杂或成员超过百人

这类组织的主要风险通常不是单个任务没做，而是接口、依赖和信息权限出现断点。应建立跨团队的版本视图，明确哪些团队是交付方、哪些团队提供依赖、依赖确认的最晚时间，以及依赖失败时谁负责协调。

使用项目管理平台时，优先打通项目、需求、任务、缺陷、版本之间的关系；设置可审计的变更流程，并让不同层级看到适合自己的视图。中大型企业可用 PingCode 这类平台承载协作数据，但落地前应先梳理对象和责任，不宜先配置大量字段再要求团队适应。

3. 监管、金融、安全或高可用要求较高的项目

高风险项目需要更强的证据链。范围批准、测试结论、权限变更、部署操作、审批意见和回退演练都应可追溯。关键决策尽量由职责分离的角色完成，避免同一人既实施高风险变更，又独立批准该变更。

这种情况下，发布节奏可能要为审查、演练和外部依赖留出缓冲。不要用“流程太慢”一概否定控制要求；应逐项识别真正降低风险的检查，并移除重复、无实际决策价值的审批。

4. 业务窗口固定、错过窗口代价高

若业务窗口只有每月一次或与外部活动绑定，计划必须更早锁定关键依赖。可以设置明确的范围冻结日期和最后变更时点，并预留缩小范围的备选方案。所有成员都要知道：窗口临近时，新增内容不是默认加入，而是需要证明收益足以覆盖额外风险。

窗口稀缺不代表必须硬上。若核心链路未验证、回退条件不清或关键岗位无人值守，延期可能比带病上线的预期损失低。决策应依据业务影响和恢复能力，而不是只看已经投入了多少成本。

5. 远程协作、跨时区或关键成员经常缺席

此时应减少对实时会议的依赖。发布信息采用异步更新，统一记录最新结论、决策时间和待回应事项；对有时限的审批明确响应期限，超时后的升级对象也要提前约定。

关键岗位最好配置备份责任人，尤其是发布批准、环境操作和业务验收。如果只有一个人掌握某项操作步骤，成员管理就形成单点故障。备份人不必每次都执行，但应能够找到资料、理解边界并在必要时接替。

七、不同情况下的取舍：效率、控制与灵活性如何平衡

1. 统一流程与团队自治之间的取舍

全组织完全统一，便于审计和跨团队协作，但可能不适合风险差异很大的项目；完全自治能贴近团队实际，却会造成状态、指标和交接方式各不相同。更稳妥的做法是统一最小公共规则，再允许团队在规则之上增加控制。

最小公共规则通常包括范围变更记录、责任明确、版本可追溯、风险准入和上线后验证。团队可以自行选择会议形式、任务拆分方式和低风险事项的检查频率，但不应取消关键证据和异常升级机制。

2. 固定发布日期与质量门槛之间的取舍

固定日期有利于市场、客户和运营协调；质量门槛则保护用户和系统稳定性。两者冲突时，不要把问题变成“谁更重视业务”。先区分版本中哪些内容关键，是否可以缩小范围、灰度发布、关闭功能开关或分批交付。

如果核心风险无法隔离，延期可能是正确选择；如果风险只影响非关键功能，减少发布范围可能比整体延期更合理。每种选择都应把业务收益、潜在损失和恢复方案摆在一起说明。

3. 自动化控制与人工判断之间的取舍

自动化适合重复、规则稳定、可机器验证的检查，例如构建校验、测试执行、依赖扫描和部署记录。人工判断更适合评估用户影响、未覆盖风险、业务窗口和例外批准。把所有判断自动化会掩盖上下文，把所有检查留给人工又容易造成遗漏。

可按风险分层：低风险、规则明确的事项尽量自动通过；中风险事项由负责人确认例外；高风险事项要求独立复核和明确批准。自动化能减少机械工作，但不能替代对风险承担者的清晰定义。

4. 统一指标与局部差异之间的取舍

统一指标便于组织层面比较，但如果统计口径不一致，横向排名会误导决策。按期率较低可能是团队执行问题，也可能是需求持续变化、外部依赖较多或主动拒绝高风险发布的结果。

组织层面可以统一定义指标，却应同时保留解释字段，如发布规模、风险等级、范围变化和延期原因。指标用于发现需要深入调查的信号，不适合直接作为个人绩效结论。

5. 详细流程与成员负担之间的取舍

流程的价值要看它减少了多少错误、等待和重复确认，而不是看它写得有多完整。每增加一个审批节点，都应问该节点解决什么风险、需要多久、是否与其他检查重复。对低风险任务，过多审批的机会成本可能高于收益。

如果成员普遍绕过流程，不要先增加惩罚。先确认流程是否过重、入口是否难找、审批人是否及时响应、记录是否需要重复填写。成熟机制既有约束，也给成员一条容易遵循的正确路径。

八、常见问题：项目成员发布管理的实操答疑

1. 谁应该对发布结果负责

发布结果通常由多个角色共同影响，但必须有一位发布负责人协调准入与执行。该负责人不一定亲自完成所有工作，也不应替代技术、质量或业务责任人作专业判断。技术负责人对技术风险负责，测试负责人对验证结论负责，业务负责人对业务接受度负责，发布负责人确保决策链完整。

2. 发布负责人可以和开发负责人是同一个人吗

小团队可以兼任，但要评估利益冲突和风险级别。低风险、可快速回退的版本，兼任可能是务实选择；高风险或监管要求强的发布，应尽量让实施与批准职责分离，并安排独立验证。关键不是职位名称，而是是否有人能对实施结论提出有效质疑。

3. 测试中发现非阻断缺陷，应该延期吗

不能只看“非阻断”标签。应评估影响用户、发生概率、影响范围、临时规避方法和修复后的回归风险。若缺陷影响核心业务或数据正确性，即使数量只有一个也可能阻断；若影响边缘场景且可监控、可回退，则可能允许带风险发布，但必须有明确批准和补救计划。

4. 发布前还有需求变更，怎么决定是否纳入

让提出方说明用户价值和不纳入的损失，再由相关负责人评估开发、测试、部署、培训和回退影响。若变更无法在剩余时间内完成完整验证，默认不进入当前版本。确属紧急事项时，考虑替换已有低优先级内容，而不是在原范围上无限叠加。

5. 怎样处理成员临时离岗或关键任务无人接手

为关键角色准备备份人和交接材料，发布计划中标记单点依赖。成员变动后，先确认任务状态、未解决风险、访问权限和下一步动作，再更新责任人。不要只把任务名字改成新成员，就认为交接已经完成。

6. 项目管理平台是否能自动保证发布质量

不能。平台可以统一记录、关联工作项、配置提醒和保留变更历史，降低信息分散造成的遗漏；但它无法判断验收标准是否合理，也无法替组织决定可接受风险。工具能让问题更可见，能否采取行动仍取决于责任、权限和决策机制。

7. 没有历史数据，应该从哪些指标开始

先从少量且口径明确的指标开始：按期发布率、发布后紧急修复占比、发布前晚期变更次数、准入材料完整率和回退演练覆盖率。连续记录数个周期后，再判断哪些指标能预测风险，哪些只是增加填报负担。

8. 如何判断发布流程是不是太复杂

看成员完成一次发布所花的协调时间、审批等待时间和重复录入次数，也看流程是否实际拦截过高风险问题。如果流程耗时增加，却没有减少遗漏、返工或故障，应检查冗余节点。若流程很轻但问题总在上线后暴露，则可能缺少有效验证，而不只是成员执行不到位。

9. 多个项目共用同一批成员，应该如何安排发布

建立跨项目的关键人员负载与依赖视图，尤其关注发布负责人、测试、运维和领域专家。排期不能只看每个项目单独是否可行，还要检查多个发布窗口是否冲突、关键成员是否被重复占用。必要时错开高风险窗口，或者明确优先级与资源调度人。

九、结语：让每个成员知道自己承诺了什么

发布管理最容易被误解成流程管理，实际要管理的是承诺、证据和风险。团队不需要为了显得专业而增加层层审批，也不能把希望寄托在成员“多留意”。一套有效机制应让成员知道范围为何确定、自己的交付如何验收、问题何时升级，以及谁有权作出取舍。

我建议下一步不要先采购工具或重画整套流程。选一个近期发布版本，回看最后两周发生的变更、阻塞、缺陷和临时协调，把最常见的三个失控点找出来；随后为每个失控点指定责任人、检查证据和升级时限，再运行两个发布周期。若数据改善且成员负担可接受，再把做法固化到团队流程或项目管理平台中。

真正成熟的发布机制，不是保证永不延期，而是让团队更早知道什么可能延期、为什么延期，以及此刻最稳妥的选择是什么。