迭代任务最佳实践：管理层迭代管理流程优化，常见问题

迭代任务最佳实践：管理层迭代管理流程优化，常见问题

迭代计划看起来排得很满，到了评审会却发现关键功能没完成；管理层要求“提高交付速度”，团队于是把更多任务塞进迭代，结果延期、返工和跨团队等待一起增加。这类问题通常不是团队不够努力，而是管理层把迭代当成任务清单来管，却没有管理目标、容量、依赖和变更。我的核心判断是：迭代管理的重点不是让每个人更忙，而是让组织更早发现承诺不成立，并在代价变大之前作出取舍。

一、先讲核心结论：管理迭代，不是替团队排任务

1. 管理层要管边界、风险和决策，不要代替团队估时

迭代计划会需要管理层参与，但参与不等于逐项指挥。管理层应明确本周期最重要的业务结果、不可妥协的质量与合规要求、跨部门资源约束，以及出现冲突时由谁决策。团队则根据工作量、技术不确定性和历史交付能力，提出可执行的承诺。

如果管理者直接指定“本迭代必须完成二十项任务”，团队很容易把会议上的接受误当成可行性验证。真正有效的管理动作，是追问这些任务是否共同服务于一个目标、是否有未解除的前置依赖、是否留有测试与发布时间，以及任务延期时能够削减什么范围。

2. 迭代目标优先于任务数量

任务完成数容易统计，却可能与用户价值脱节。一个迭代关闭了三十张任务卡，不代表用户真的得到改进；反过来，一个迭代只交付少量关键能力，也可能显著降低客户流失、运营成本或安全风险。管理层更应关注目标是否达成、结果是否可验证，以及偏差原因是否能转化为下一轮决策。

我建议每个迭代只设一个主要目标，必要时加一至两个次要目标。目标应能用业务或用户结果描述，例如“让新客户可独立完成首次配置”，而不是“完成配置模块开发”。后者描述的是活动，不是成果。

3. 迭代承诺必须包含容量、风险和变更规则

可执行的迭代计划不只是任务列表，还应说明团队有效容量、关键依赖、验证方式和变更边界。若人员要承担值班、客户支持、例行维护或其他项目工作，这些都应从可用容量中扣除，不能一边把全部工时排满，一边把临时工作当作意外。

以下数字是用于管理讨论的情景模拟，不是行业平均值：一个八人团队的两周迭代，名义上有八十人日；扣除假期、会议、值班和持续维护后，可用于计划工作的容量可能只有五十六人日。若再按团队过去数个迭代的交付情况保留约两成人日缓冲，可承诺的计划量大约是四十五人日。管理者若仍按八十人日排满，风险不是“团队效率低”，而是计划口径错误。

二、背景和真实场景：计划失真的根源常在迭代开始之前

1. 需求进入迭代时，业务价值和验收条件还没说清

常见场景是，业务方在迭代计划会上提出“顺便加一个导出功能”，研发当场给出大致估时，测试却尚未知道导出范围、权限规则和异常处理要求。团队似乎已经接下任务，实际接下的只是一个名称。等到开发完成，业务方补充筛选条件、数据脱敏和历史记录要求，原来的估算自然失效。

管理层不必替产品人员写需求，但要推动需求达到进入迭代的最低质量门槛：谁遇到什么问题、预期改善什么、如何验收、依赖谁、哪些情况明确不做。需求不完整时，合理的决策是先安排澄清或技术验证，而不是用一个乐观估时假装不确定性已经消失。

2. 跨团队依赖经常被记录，却没有被真正管理

任务卡上写着“等待数据团队接口”，不等于依赖已经解决。管理上需要知道接口由谁负责、何时提供、验收标准是什么、延迟后谁有权调整范围。若一个团队的关键路径取决于另一个团队，却没有共同确认时间和责任人，计划就只是把风险写在系统里，没有降低风险。

我会把依赖分成三类：已经承诺且有明确日期的依赖；仍在协调、需要管理者推动的依赖；存在替代方案或可以并行工作的依赖。三类依赖的处置不同。第一类进入排期，第二类需要升级决策，第三类则应记录触发条件和备选路径。

3. 管理层看到“延期”，未必看到延期的形成过程

月底才暴露延期，通常说明组织只盯最终状态，没有观察过程信号。比如任务连续多天处于“进行中”，代码已完成但测试环境不可用，或者多个关键任务都卡在同一位专家评审。这些信号在迭代中段已经出现，若直到评审会才汇报，管理层能做的往往只剩催进度或压缩测试。

更有效的做法是设置轻量的风险检查点。检查点不是增加汇报仪式，而是确认：目标是否仍可达、阻塞是否有人负责、剩余工作是否仍符合容量、质量风险是否被低估。每次检查都应导向一个行动，例如拆分范围、调配资源、解决依赖或明确接受风险。

4. 大规模组织需要共享事实，而不是更多状态会议

在百人以上的组织里，单个团队的迭代信息会影响产品、研发、测试、运维、安全、交付和客户支持。若每个部门各自维护表格，管理层常会看到多个版本的“真实状态”：一个系统显示任务已完成，另一个表格显示仍在验收，会议纪要又记录着等待发布窗口。

此时工具的价值不在于把所有人变成填表员，而在于让需求、任务、缺陷、版本、依赖和决策尽量沿着同一条链路追踪。采用 PingCode 等项目管理平台时，可以评估其是否适合中大型组织的流程与权限要求；如有数据治理和内网部署要求，还应单独验证私有化部署方案、迁移范围、权限映射和历史数据校验。平台功能不能替代管理机制，但可以减少状态分散带来的对账成本。

三、常见误区：看起来更严格，实际更容易失控

1. 把迭代完成率当成团队绩效排名

完成率可以作为诊断信号，但不适合脱离背景直接用于个人或团队排名。团队若因完成率受罚，常见反应包括把任务拆得更小、把未完成工作移出迭代、降低验收标准，或不再接纳探索性工作。仪表盘可能变得漂亮，实际交付质量却更差。

我更关注完成率背后的偏差结构：是需求变更造成、估算偏差造成、外部依赖造成，还是缺陷返工造成？若一个团队连续多个周期承诺过量，问题可能在容量规划和管理压力；若少数任务反复被依赖阻塞，问题则更可能在跨团队治理。相同的完成率，不应触发相同的管理措施。

2. 认为任务拆得越细，计划就越准确

适度拆分能暴露工作内容和验证步骤，但过细拆分会增加维护成本，并制造虚假的确定感。如果一张任务卡被拆成许多十分钟级子任务，团队每周花大量时间更新状态，却未必更早发现关键风险。拆分的判断标准不是卡片数量，而是工作是否可独立验收、是否能在短周期内反馈、是否需要不同责任人或不同依赖。

我通常建议先拆风险最高或最难验证的部分，而不是平均切碎所有工作。例如，接口性能不确定，就先安排可验证的压测或原型；第三方授权流程不明，就先做端到端验证。把未知变成证据，往往比把未知写成更多任务更有价值。

3. 把中途变更一律视为破坏纪律

迭代需要稳定，但稳定不是拒绝事实。安全漏洞、法规要求、生产故障和关键客户影响，都可能要求立即调整。真正需要防止的是没有比较成本的“顺手加需求”：新任务进入后，没人说明要移出什么、延期什么，团队便被迫在原有承诺之外继续加码。

建议为变更设简单规则：说明变更原因、影响范围、紧急程度、决策人，以及对应的范围置换。紧急问题可以打破计划，但需要记录被牺牲的目标或质量余量。管理透明度并不会让变更消失，却能让组织承担变更的真实成本。

4. 以会议数量体现管理力度

每日站会、计划会、评审会和复盘会都可能有用，但会议数量增加不代表管理质量提升。若站会只是逐人念任务状态，管理者听完仍不知道阻塞由谁解决；若评审只演示功能而不确认目标是否达成，组织得到的只是展示，不是反馈。

每个会议都应对应一个不同的问题：计划会确定可承诺范围；日常同步暴露阻塞；评审验证成果与用户反馈；复盘识别系统性改进。无法说明会议产出是什么，就应考虑缩短、合并或取消。

5. 用速度指标跨团队比较

不同团队的估算尺度、工作类型、技术债务和依赖结构可能完全不同。把一个团队的速度数字拿去和另一个团队比较，容易诱导估算膨胀，也会让团队回避高不确定性任务。速度更适合团队内部观察趋势，不能直接解释商业价值或人员效率。

管理层可以比较更接近组织结果的指标，例如从需求准备到上线的周期、阻塞等待时间、生产缺陷趋势、目标达成情况和变更比例。但指标仍要连同业务背景解释：周期缩短可能来自自动化，也可能来自减少测试；缺陷下降可能是质量改善，也可能是缺陷记录变少。

四、专业判断逻辑：把计划问题转化为可决策的问题

1. 先判断目标清晰度，再讨论工作量

工作量估算并不能补救目标模糊。若团队不知道要解决谁的什么问题，估出来的只是对模糊范围的猜测。管理层应先要求目标具备可验证结果，再讨论优先级和容量。无法定义成功条件的工作，可以先以探索任务进入计划，但要设时间上限和继续投入的决策条件。

例如，“研究新搜索方案”不应无限延伸。可以约定用三天完成数据采样、建立基线和验证两个技术路径，随后提交是否继续的建议。管理者买到的是一项带决策产出的探索，而不是一个没有结束条件的任务。

2. 再判断容量是否可信，而非只看名义人数

有效容量至少要区分人员投入、可连续工作时间、必要协作和非计划工作。团队有十个人，不等于每个人都能全职投入本迭代；成员同时承担招聘、支持和架构评审时，名义工时会明显高于实际可用工时。

可以用过去数个周期作为校准材料，但不要机械沿用历史均值。若本周期有系统升级、集中休假或新成员加入，过去容量不代表当前容量。更稳妥的方式是让团队说明容量变化，并由管理层确认是否接受计划相应变小。

3. 把承诺分为确定项、风险项和探索项

所有任务都写成同一种“承诺”，会让不确定性被隐藏。确定项是范围和验收清楚、依赖可控的工作；风险项是目标清楚但存在技术或外部不确定性；探索项则是需要通过试验获得信息的工作。三类任务在计划会上应有不同的讨论方式和缓冲策略。

风险项不能仅靠提高估时处理。还要问：风险会在哪个节点显现？是否能提前验证？失败后是否有替代方案？如果风险需要其他团队配合，管理层是否能推动对方作出明确承诺？

4. 依赖管理要包含责任人、日期和失效方案

每个关键依赖至少应有依赖提供方、接收方、所需交付物、最晚日期和验收方式。若延期会影响目标，就需要定义应急方案：先交付降级能力、切换数据源、延后非关键范围，还是暂停相关任务。没有替代方案的依赖应在计划会上被明确标记为高风险，而不是藏在备注里。

跨团队依赖无法只靠项目成员互相催促解决。若优先级冲突需要组织级协调，应指定有权作出取舍的负责人。管理层真正的作用，是缩短决策等待，不是增加一轮状态汇报。

5. 用领先信号管理过程，用滞后结果复盘

迭代结束后的交付结果是滞后信号。过程中的阻塞时长、任务滞留、评审等待、变更频率和返工趋势，则能帮助团队更早判断计划是否偏离。领先信号不能单独证明失败，但可触发检查和对话。

例如，任务在“进行中”停留超过团队约定的时间，不应自动认定个人表现有问题。管理者可以先检查任务是否过大、评审资源是否不足、测试环境是否不可用，以及外部决策是否迟迟没有答复。先找系统约束，再谈个体责任，通常更容易得到真实信息。

五、案例与数据观察：从“多接任务”转向“可兑现目标”

1. 一个百人以上组织的迭代管理情景

以下是为说明管理方法构造的匿名化情景，不代表某家企业的真实经营数据。某企业有多个产品与交付团队，团队各自使用不同表格和看板。管理层每两周询问一次“完成率”，业务部门则在迭代中持续提出新需求。到迭代末，团队普遍称任务完成了大半，但版本发布日期仍频繁变化。

进一步梳理后，问题并非单一团队执行不力：同一需求在产品、研发和测试系统中使用不同名称；跨团队依赖没有统一负责人；计划时没有扣除支持工作；评审关注功能演示，却没有检查验收标准；临时插单没有明确替换范围。管理者看到的是延期结果，真正的原因分散在流程输入和组织协作中。

2. 先统一目标和状态口径，再追求工具整合

改进时不应第一步就要求所有团队更换流程或迁移全部历史数据。更稳妥的顺序是先统一迭代目标、需求准备条件、状态定义、依赖责任和变更记录，再选择能够支持这些规则的平台。否则只是把原本分散的混乱搬到一个新界面里。

在工具评估阶段，我会重点检查几项实际能力：能否把目标关联到需求、任务和版本；能否按角色配置权限；是否支持跨团队依赖和变更留痕；报表能否呈现等待与返工，而不只是关闭数量；是否满足企业部署、数据安全和审计要求。对于计划从旧系统迁移的组织，还要验证字段映射、附件与评论迁移、历史链接、用户权限和抽样核对机制。PingCode可作为中大型组织评估候选之一；具体是否适用，应以实际流程演示、数据迁移验证和安全评审为准，不能仅凭产品介绍作结论。

3. 用小范围试点验证流程，不先做全组织大改造

建议选两个具有代表性的团队试点：一个依赖较少、节奏相对稳定；另一个跨团队协作较多、需求变化较频繁。试点周期可覆盖三至四轮迭代，足以观察规则是否真实可用，又不会让尚未验证的流程一次性影响整个组织。

每轮只改变少数关键做法，例如先统一目标模板和变更规则，再改容量校准和阻塞处理。若同时更换工具、角色、会议、指标和审批制度，试点结果就难以归因。试点的产出不是“大家觉得不错”，而是流程执行记录、关键指标变化、团队反馈和未解决问题。

4. 建议观察的数据及其解释边界

下面的数字是试点建议基准与情景模拟，用于展示应如何设置观察口径，不是任何企业的实测成绩。正式试点应先采集自己的基线，再判断变化是否值得推广。数据必须有明确定义，例如“阻塞时间”从任务标记受阻到解除计算，不能将不同团队的口径直接混在一起。

这组指标必须联合解释。计划外工作下降，如果同时导致紧急生产问题无人处理，就不是改善；返工率下降，如果团队只是把缺陷留到后续，也不能称为质量提升。管理者应看趋势、看工作类型、看用户结果，并抽查数据来源是否一致。

5. 把结果归因到机制，而不是给团队贴标签

若试点后目标达成率上升，应进一步确认原因：是需求更清楚、容量估得更准、依赖等待缩短，还是目标变得过于保守？若计划外工作减少，也要核对业务响应是否受影响。只有了解改变发生在哪个机制，组织才知道推广时要保留什么、调整什么。

复盘应至少包括一次定量核对和一次任务样本追踪。定量核对看趋势；样本追踪则选取少量任务，从需求提出一路检查到验收，识别状态记录、等待与返工是如何形成的。数据告诉我们“哪里变了”，样本帮助解释“为什么变了”。

六、迭代管理流程优化：从准备到复盘形成闭环

1. 迭代开始前：建立进入条件和优先级规则

每个候选需求在进入计划前，至少说明业务目标、范围边界、验收条件、优先级理由、依赖和风险。若信息不全，可以进入待澄清队列，而不是为了填满迭代提前承诺。管理层要保证优先级冲突有明确裁决人，避免多个部门都把自己的工作称为最高优先级。

优先级不应只按提出部门的级别决定。可以共同考虑用户影响、业务价值、风险降低、时效性、依赖关系和机会成本。重要的是让排序依据可见，必要时说明为什么某项工作暂缓，而不是让团队通过隐性加班满足互相矛盾的要求。

2. 计划会上：先确认目标，再让团队确定范围

计划会议可以按以下顺序进行，避免从任务逐条估时开始后才发现目标冲突：

1. 回顾上周期目标和未完成事项，区分遗留工作与新工作。
2. 确认本周期一个主要目标及其验收证据。
3. 检查成员可用容量、支持工作、休假和其他已知投入。
4. 由团队评估候选工作，标记确定项、风险项和探索项。
5. 逐项核对依赖、责任人、最晚日期和替代方案。
6. 为新增工作明确范围置换规则和决策人。
7. 记录承诺、未纳入事项及其原因，避免会后口径不一致。

会议结束时，管理层应能回答三个问题：团队本周期要实现什么结果；有哪些因素可能阻碍结果；如果条件变化，谁能决定牺牲哪部分范围。若这三个问题没有答案，任务估算再精细也不足以构成可靠计划。

3. 迭代进行中：限制并行工作，优先解除阻塞

多个任务同时进入“进行中”，会增加切换成本，也可能使团队表面忙碌、实际完成很少。团队可依据自身特点设置在制工作上限：先完成或解除阻塞，再启动下一项。管理层不必规定所有团队使用同一个数字，但应要求团队解释上限如何与人员分工、任务大小和支持工作相匹配。

管理者处理阻塞时，重点是消除团队无法自行解决的障碍，而不是每天追问剩余百分比。可以推动外部团队确认接口、协调评审资源、批准必要环境权限，或及时决定是否降低范围。阻塞如果反复出现，也要安排跨周期的系统性改进，而非每轮都靠临时协调。

4. 迭代评审：看可验证结果，不只看演示效果

评审前应确定谁是结果的使用者或验收代表，以及要验证哪些行为和标准。演示可以证明功能存在，却不能自动证明用户能完成目标。可结合现场操作、数据核验、客户反馈、性能测量或运营结果，确认交付是否达到预期。

若目标没有达成，复盘时要区分“做了但未产生预期结果”和“工作没有完成”。前者可能涉及产品假设，需要调整方案；后者可能涉及范围、容量或执行约束。两者都重要，但解决路径不同。

5. 迭代复盘：只承诺少量可验证的流程改进

复盘不是寻找责任人，也不是收集一页“加强沟通”的口号。每轮最好选一至两个最有影响的系统问题，写明问题证据、改进动作、负责人、验证时间和预期变化。例如，把“依赖总是延迟”改为“所有跨团队接口在计划会前确认交付日期；若未确认，相关工作不作为确定承诺”，这样才能在下一周期检验。

管理层应为改进动作提供资源和授权。如果复盘要求解决一个跨部门问题，却没有负责人能够协调优先级，那么团队记录得再完整，也不会改变系统。

七、不同情况下的行动建议：先识别问题类型，再选管理动作

1. 延期频繁，但团队报告一直很乐观

先检查需求进入条件、估算依据和变更记录，不要立即要求团队加快开发。抽查最近几轮未完成任务，判断是范围在过程中扩大、测试时间被压缩，还是任务拆分不足导致风险后置。若延误集中在同一类工作，应优先修流程或技术约束；若不同原因混杂，先建立一致的分类口径。

2. 需求变化多，业务又不能接受响应变慢

把工作分成计划内交付和应急响应两种通道。对高变化业务，可预留一部分容量处理突发事项，并设定触发规则；新工作进入时，明确替换的原计划范围。对不紧急的新需求，则放入候选池参与下一次优先级排序。这样既不把计划绝对化，也不让所有工作都以紧急名义挤进迭代。

3. 团队长期满负荷，仍然交付不稳定

检查在制工作数量、共享专家负担、会议和支持投入，以及等待外部决策的时间。满负荷不等于高产出，过多并行会拉长每项工作的完成时间。可以先减少并行、缩短反馈路径，再看吞吐与质量是否改善。若容量确实不足，管理层需要在缩小范围、延长时间、增加资源或接受风险之间作明确取舍。

4. 管理信息分散，组织规模持续扩大

先定义统一状态、层级关系和责任边界，再讨论平台整合。若不同团队对“已完成”“待验收”“已发布”的定义不一致，跨团队报表会产生误导。可以从一个产品线或一个跨团队项目开始试点，确认数据字段、权限和流程，再逐步推广。

对于考虑某项目管理平台的组织，建议以场景验收而非功能清单评估：现场模拟一个需求从立项、拆解、依赖处理、测试到发布的全过程；测试不同角色的权限；抽查历史数据迁移结果；验证部署方式、安全审计和备份恢复方案。若涉及旧系统迁移，应先做小批次迁移和差异核对，再安排正式切换。不要把“支持迁移”理解为迁移风险已经消失。

5. 试点表现好，但其他团队担心流程不适用

不要把试点模板原样强推给所有团队。稳定产品团队、平台团队、客户交付团队和探索性研发团队，工作形态不同，可能需要不同的计划周期、容量缓冲和验收方式。可统一组织级原则，例如目标透明、变更有记录、依赖有责任人；同时允许团队在执行细节上保留差异。

八、不同情况下的取舍：效率、控制和灵活性不能同时无限最大化

1. 承诺范围与发布日期冲突时，优先保护什么

若发布日期固定，通常应优先保护关键用户价值和不可妥协的质量、安全要求，缩减低优先级范围。若范围受合同或法规约束、发布日期可调整，则应重新评估时间与资源。把范围、时间、质量都设为不可变，再要求团队“想办法”，本质上是把决策成本转嫁给执行者。

2. 流程标准化与团队自治如何平衡

组织需要标准化的是共享信息和决策接口，不一定是所有团队的工作细节。跨团队依赖、状态定义、风险升级和目标验收最好有一致规则；任务粒度、估算方式和日常协作节奏可以由团队按工作类型调整。标准化太少，管理层无法协调；标准化过度，团队会把精力花在适配流程而非解决问题。

3. 透明度与考核压力如何平衡

状态透明有助于及早求助，但若每一次报告风险都会直接带来惩罚，团队就会延迟暴露问题。管理层可以区分主动报告与隐瞒风险：及时提出计划偏差并给出方案，应被视为良好管理行为；重复出现却不分析原因、没有调整动作，则需要进一步追问。这样既保留责任，也不鼓励报喜不报忧。

4. 工具统一与团队特殊需求如何平衡

统一平台有助于减少信息断层、权限管理和跨团队汇总成本，但迁移和流程适配也有成本。若现有工具已经支持关键链路，盲目替换可能造成历史数据断裂和团队学习负担；若信息无法关联、数据维护重复、权限或部署条件不满足，则整合可能具有长期价值。决策时应比较总成本，包括许可与部署、迁移、培训、流程调整、运维和退出成本，而不是只看采购价格。

取舍应当留下记录，尤其是被延后或移出的工作。记录不是为了追责，而是为了让管理层知道一次决策如何影响客户、版本和其他团队，并避免同一项工作在下次计划时被当成从未发生过。

九、常见问题：管理层最容易问错的几个问题

1. 迭代计划必须百分之百完成吗？

不应把百分之百完成设为所有团队、所有周期的硬指标。若目标持续未达，应查明计划质量、需求稳定性、依赖和容量；若团队每轮都轻松完成，也要确认是不是目标过于保守或重要工作被排除。完成率是信号，不是管理目的。

2. 迭代中能不能增加任务？

可以，但要说明原因、影响和替换项。生产故障、安全风险和明确的关键业务事件，可能值得打破原计划；一般需求则应进入候选池。没有范围置换的新增任务，会让团队承担无上限承诺，也会让迭代数据失去解释价值。

3. 管理层应该参加每一次计划会吗？

管理层应参与目标、优先级、资源冲突和重大风险决策，不必参加每个团队的全部估算讨论。对于多个团队共用资源或目标冲突的组织，可以参加计划前的组合优先级协调，再让团队自主确定实现方案。管理层参与的价值在于缩短决策时间，而不是成为新的审批瓶颈。

4. 没有历史数据时，如何估算容量？

先从可用人日和已知职责开始，明确扣除休假、值班、维护、支持和固定会议，再安排有限范围的工作。第一轮把计划当作基线采样，不要假设估算精确。经过数个周期后，再结合交付、阻塞和返工记录校准。数据少时，范围应更保守，而不是更自信。

5. 迭代是否适合所有类型的工作？

不一定。需求变化较快、需要频繁反馈的产品工作，通常适合用固定节奏管理；生产运维、客户响应和探索性研究可能需要不同的工作流或容量机制。组织可以共用目标、风险和决策原则，但不必要求每类工作都套用同一套任务周期。

十、总结：最好的迭代管理，是更早暴露不可行的承诺

管理层优化迭代流程，最值得改变的不是看板颜色、会议时长或任务拆分格式，而是组织如何面对不确定性。目标不清时先澄清，容量不足时承认约束，依赖未确认时升级决策，计划中途变化时公开替换范围，结果不理想时追踪机制而非只追责个人。

迭代管理成熟与否，不在于每个周期都没有偏差，而在于偏差能否尽早出现、能否由有权的人作出取舍、能否在下一周期验证改进。把“按时完成多少任务”改成“是否交付了可验证的目标、为何偏离、组织从中改变了什么”，才是从任务管理走向管理层迭代治理的关键一步。

下一步可以先选一个团队，用三至四个迭代建立基线：统一目标与验收定义，记录计划外工作和阻塞，明确依赖责任人及变更规则。试点结束后，结合数据和任务样本复盘，再决定哪些机制值得推广、哪些需要按团队类型调整。这样比一开始推行全组织大改造，更容易看清真正有效的改进。