项目管理新趋势：2026年最受欢迎的5大人员工作安排软件对比

2026年挑选人员工作安排软件，最容易踩的坑不是漏看一个功能，而是把三种不同问题当成同一种问题：谁去上哪个班、谁在什么项目上投入多少时间、团队未来几周还有没有空余产能。排班表看起来都能填名字和日期，但如果底层管理对象不同，工具上线后仍可能要靠表格、群聊和人工核对补洞。我的判断是，先定义“安排”的对象和决策周期，再比较软件；否则，功能最多的产品未必最适合。

一、核心结论：先分清班次、项目资源和团队产能

1. 五款软件解决的不是同一个层级的问题

本文比较 PingCode、Asana、monday.com、Float 和 Resource Guru。它们都能在不同程度上帮助团队安排人员，但侧重点并不相同：有的以项目执行为中心，有的适合跨团队任务协同，有的更强调排期与资源利用率，还有的专注于人员和设备的日历式预订。

因此，我不会把它们排成一个脱离场景的“第一名到第五名”。同一款产品在软件研发团队中可能很合适，在门店轮班场景中却可能要补上考勤、工时规则和换班流程。真正有用的对比，是看每款工具在哪种业务问题上省掉了最多的人工判断，又会在哪些地方留下新的管理负担。

2. 快速选择：按“安排的对象”而不是品牌热度筛选

• 排的是项目任务及责任人：优先评估能把需求、任务、协作和进度放在同一工作链路中的项目管理平台。
• 排的是跨项目人员容量：优先测试资源计划、可用时间、冲突提醒和计划变更追踪。
• 排的是门店、工厂或客服班次：优先找具备轮班规则、休息时间、换班审批、考勤衔接和劳动合规配置的排班系统，不要只看项目管理软件的日历。
• 排的是设备、会议室和人员资源：评估资源预订和冲突处理，而不是只比较任务看板。

如果只能记住一个结论，我建议记住这句话：人员安排软件不是“把人放进日历”，而是把需求、能力、可用时间、变更和责任放进同一个可追溯的决策过程。

二、背景和真实场景：排班表背后，往往藏着容量决策

1. 一个安排请求，通常包含四种信息

在实际管理中，一条人员安排并不只是“某人周三有空”。它至少要回答四件事：工作需要什么能力、需要投入多少时间、人员在这个时段是否可用、任务优先级改变时谁来决定重新分配。很多团队只录入姓名和日期，却没有记录估算依据和变更原因，最终得到的是一张看似完整、实际不能用于决策的表。

例如，产品团队要在两周内完成一次发布。表格上可能显示开发人员都已分配，但其中一人还承担线上问题值班，另一人有跨团队评审，测试人员则要并行支持另一个版本。若安排工具只展示“任务已指派”，而不显示实际容量，计划就会把名义上的可用时间误当成真实产能。

这也是我比较工具时会先问的事：软件有没有办法表达“计划”和“现实”的差异？如果只能登记计划，却不能及时反映休假、临时任务、优先级调整及技能限制，它更像数字化日历，而不是资源决策系统。

2. 项目排期与轮班排班，不能用同一套判断标准

项目资源排期通常关注跨周甚至跨月的负载、项目优先级、人员技能匹配、任务依赖和交付风险。班次排班则更关注每天的时段覆盖、连续工作时长、休息间隔、轮班公平、临时请假与替班速度。两者都涉及“人”和“时间”，但约束条件相差很大。

如果一家连锁门店需要确保晚间收银岗位有人值守，那么“这个员工本周项目负荷只有百分之六十”并不能解决问题。反过来，若一家研发组织需要判断下个月是否能承接新项目，单看每个员工每天是否排了班也无法回答团队容量问题。

我把“安排周期”作为第一道筛选条件：小时级、日级安排通常需要更精细的班次规则；周级、月级安排需要容量和项目视图；季度级预测则需要需求管道、技能结构和不确定性分析。周期不匹配，工具再易用也只是把旧问题搬到新界面。

3. 2026年的关键变化不是多一个视图，而是计划更频繁地变化

团队工作方式越来越混合：固定岗位、项目制协作、外部供应商和跨时区成员可能同时存在。安排计划因此不再是月初做一次、月底复盘一次，而是随着客户需求、产品优先级、请假和突发事项持续调整。

在这种环境下，工具价值不应只用“能不能排出来”衡量。我更关注计划变更后的连锁反应：被挪走的人原先负责什么，受影响的交付日期是什么，新的安排是否造成其他人超负荷，相关负责人是否收到通知。这些信息是否可见，决定了管理者是在做计划，还是在不断修补计划。

一些行业研究常把数字化和自动化视作提升生产率的方向，但这类宏观结论不能直接证明某个排班软件能带来多少效率提升。对企业来说，更可靠的基准是上线前后同口径记录：计划更新时间、冲突数量、超负荷人数、变更后的任务延误率，以及经理用于核对的时间。

三、常见误区：看见“工作量视图”不等于拥有资源管理能力

1. 误区一：功能列表越长，越适合大型组织

功能数量与业务适配度不是正相关。组织规模扩大后，最难处理的通常不是“没有某个按钮”，而是不同团队对工作状态、优先级和估算单位理解不一致。若软件允许各团队随意创建字段和流程，却没有管理口径，最后会出现多个版本的“可用容量”，管理者无法横向比较。

因此，我建议大型组织优先看三件事：能否设置清晰的权限边界，能否统一关键字段的含义，能否在不破坏团队自治的前提下汇总跨项目视图。一个较少但稳定的公共数据模型，往往比一套功能繁多、无人负责维护的配置更有价值。

2. 误区二：看起来有日历，就认为能处理冲突

日历能显示重叠，并不等于能解释冲突。比如同一名设计师在两项任务上被安排了每天八小时，系统若没有有效容量上限或超配提示，两个色块可能只是并排展示。使用者仍然需要人工发现：计划里同一个人被重复计算了。

验证冲突管理时，我会故意制造三种情况：让同一个人同时承担两个高优先级任务；把一个休假日插入既定计划；再将某个交付日期提前。观察系统能否标出受影响安排、保留变更记录，并让负责人判断先调整哪项工作。只有“显示冲突”而没有后续处理机制，提醒的价值有限。

3. 误区三：名义利用率越高，团队效率就越高

把人员排到百分之百，看起来像是充分利用资源，实际可能没有给紧急问题、评审、协作和返工留下空间。很多知识工作不能像生产线工时一样无损切分；频繁切换任务还会带来上下文恢复成本。因此，高利用率不一定意味着高产出，也可能只是更脆弱的计划。

我的经验判断是，利用率只能作为诊断信号，不应成为单一绩效目标。管理者还要一起看延期率、返工率、临时插单次数和超负荷持续时间。如果利用率上升，但交付质量下降、计划变更增加，就说明团队可能只是被排得更满，而不是变得更高效。

4. 误区四：把工具里的预测值当成事实

软件可以汇总历史投入、任务估算和日历空档，但预测依赖输入数据。估算习惯不一致、未登记的支持工作、技能差异和临时中断都会让预测偏离现实。工具给出精确到小数点的利用率，也不意味着预测本身足够准确。

在试点期，我会把预测数字标成“计划值”，并保留实际投入或实际完成记录。连续几个周期之后，再分析偏差来自任务估算、工作中断、人员能力匹配还是优先级变化。预测系统的可信度，不是看图表有多精致，而是看偏差能否被解释、被复盘并逐步缩小。

5. 误区五：只让项目经理使用，忽略一线人员的更新成本

资源计划如果只能由管理者维护，人员状态很快会过期；如果要求所有员工每天重复填写多份工时和任务信息，使用者也会绕开系统。设计合理的安排流程，应明确哪些信息由项目经理确认、哪些信息由成员更新、哪些数据可以从已有工作系统同步。

在演示时，不要只让供应商展示管理员视角。让一位普通成员完成更新可用时间、查看本周安排、提出冲突或换班请求，再让管理者处理该请求。这个过程比十分钟的功能讲解，更容易暴露真实使用成本。

四、专业判断逻辑：用一套可验证的标准比较五款工具

1. 先建立适配门槛，再讨论加权得分

很多选型表一上来就给功能打分，结果把不适用的产品也纳入总分。我建议先设“门槛项”：如果核心业务是轮班，就必须通过班次规则、休息间隔、换班审批和考勤接口核验；如果核心业务是跨项目资源规划，就必须能表达可用容量、项目分配和冲突影响；如果核心业务是任务执行，就必须能把责任、状态和交付进展连起来。

门槛不通过的产品，不应靠其他漂亮功能加分补回来。先确认能解决关键问题，再用加权评分比较易用性、集成、安全治理和实施成本。这样的顺序可以避免团队被精致界面吸引，却在上线后发现最关键的规则无法落地。

2. 建议使用六个维度，且每个维度都要定义证据

表中的权重是建议起点，不是行业标准。对于轮班组织，业务规则和合规约束的权重应提高；对于多项目服务团队，容量、项目切换和资源预测应占更大比重。重要的是让权重在试用之前确定，避免团队看完演示后再调整标准去证明自己偏好的产品。

3. 产品逐一看：适合什么，不适合什么

（1）PingCode：适合项目执行与协作链路更重要的组织

PingCode可作为研发及中大型组织项目协同的候选，尤其是100人以上团队需要统一需求、任务、计划和协作信息时。它的判断重点不应只是能否给任务分配负责人，而应看项目计划与执行信息是否能形成可追踪闭环：负责人变更后，团队能不能知道工作状态、相关需求和交付进展。

若企业要做的是跨项目人员容量规划，应在演示中明确验证团队负荷、可用时间和调整后的影响是否满足自己的管理要求。若企业要做的是门店轮班或工厂班次管理，则必须另行核对轮班规则、考勤和换班流程，不能因为它是项目管理平台，就推定它天然覆盖人事排班的完整要求。

（2）Asana：适合任务关系清晰、跨部门协同频繁的团队

Asana可以优先纳入营销项目、产品发布、运营活动和跨部门任务协作的评估。对这类团队而言，重点不是单纯列出谁在忙，而是任务负责人、截止时间、依赖关系和工作量能不能让协作者快速理解。

需要核实的是，团队使用的工作量视图与实际容量是否一致，人员可用时间和估算单位是否符合企业口径。若组织需要精细的技能池管理、长期资源预测或严格的本地人事规则，不能仅凭演示中的视觉化负荷图下结论，应拿具体案例验证配置边界和版本能力。

（3）monday.com：适合流程差异明显、需要灵活配置的团队

monday.com的评估重点可以放在流程自定义、信息视图和自动化是否适合团队现有工作方式。对于不同部门的工作项差异较大、希望快速搭建流程的组织，灵活性可能降低初期适配阻力。

但灵活性会产生治理责任。字段、状态和自动化规则如果由多个团队各自创建，组织可能出现同名字段含义不同、看板规则互相矛盾的情况。选择时应明确谁有权限新建字段，哪些字段是公共标准，配置变更如何测试和回滚，并测算维护这些规则所需的人力。

（4）Float：适合按项目分配人员、需要持续调整计划的服务团队

Float值得重点评估的情境，是咨询、设计、代理服务或数字化交付团队需要把人员分配到多个客户项目，并持续看见可用时间和排期变化。此时，资源日历和人员计划是核心工作面，项目负责人能够较早发现某一技能组未来几周的拥挤程度。

但资源安排不等于任务执行。若团队还需要管理复杂需求、缺陷、审批、文档和研发流程，应验证它与现有项目执行系统如何连接，计划变更是否会同步，以及重复录入是否会抵消资源视图的价值。

（5）Resource Guru：适合资源占用可视化和预订管理

Resource Guru适合纳入人员和其他资源需要集中预订、检查占用情况的场景。比如服务团队除人员外，还要安排设备、工作空间或其他稀缺资源，管理者需要快速确认某一时间段是否可用。

选型时要检查资源类型、冲突处理、休假或不可用时段，以及预订修改后的通知机制。如果企业的难点主要是任务依赖、产品研发过程或跨项目成本核算，需核实其作为资源日历是否足够，还是必须和另一套项目系统配合。

4. 不要把模拟评分误读成产品排名

为了减少主观争论，可以对五款候选工具按前述维度进行试点评分。但评分必须来自同一组用例、同一批使用者和同一套规则。比如先给每款工具相同的团队结构、同样的休假信息和同一个计划变更，再记录完成任务所需时间、遗漏信息和手工补救次数。

我通常建议将评分与证据放在同一张表中：分数旁边写明“因为什么给这个分”，并标记是已验证、产品演示中看到，还是尚待确认。没有证据的分数只是偏好；标记为待确认的能力，也不能提前计入最终结论。

五、案例与数据观察：用一个模拟团队检验工具有没有减少管理摩擦

1. 设定场景：120人研发组织，三类工作同时发生

以下是用于说明评估方法的情景模拟，不是某家企业的真实客户数据，也不是任何产品的效果承诺。设定一家120人的研发组织，分为产品、研发、测试和设计团队，同时维护多个版本，并承接线上支持。管理者每周需要协调跨项目安排，团队成员还要更新任务进展和休假。

试点前，该组织依赖项目表格、日历和群聊。项目经理每周花约4小时合并不同表格，负责人变更后平均需要1个工作日才能完成全部通知和排期更新。每月出现的人员重复分配、休假未同步等安排冲突按12次估算。这里的数字仅用于后续演示如何建立基线，真实企业应以自己的连续记录替换。

2. 先测“安排过程”，而不是急着测“效率提升”

试点初期不要马上把“交付更快”归功于软件，因为周期变化可能来自范围缩小、人员增加、需求减少或管理层优先级改变。更可控的观察对象，是安排信息从提出到确认的耗时、冲突发现时间、计划变更通知是否完整，以及管理者为核对数据投入多少时间。

我会把试点分为三个阶段：第一阶段清理人员、项目、技能和休假等基础数据；第二阶段选一个代表性团队，让其用工具完成真实周计划；第三阶段模拟人员临时不可用或需求提前，记录调整过程。三阶段都要保留人工基准，否则很难分辨是流程变化还是产品界面带来的差异。

3. 示例观察：过程指标可以先于交付指标改善

假设试点六周后，团队核对排期所需时间从每周4小时降至2.5小时，排期冲突从每月12次降至8次，计划变更通知完整率从六成提高到八成。即使这些示意结果成立，也只能说明安排过程可能更顺畅，不能直接得出项目交付速度提高了同样比例。

进一步分析时，要拆解冲突为何减少：是休假信息更完整、跨项目可见性提高，还是团队实际减少了并行项目？如果只是把冲突改成了“未记录的临时工作”，指标改善就是表面现象。因此，试点应同时抽查成员实际工作，确认计划表和现实之间的差距有没有缩小。

4. 建议至少观察六个指标，并设定清楚的口径

• 计划维护耗时：记录管理者每周合并、核对和更新排期的总时间。
• 冲突发现提前量：从安排冲突首次出现到被发现的时间间隔，越早发现越容易调整。
• 计划变更通知完整率：受影响人员和负责人中，按时收到变更信息的人数占比。
• 超负荷持续时间：人员处于超过团队设定容量状态的连续时长，而非只看某一天的峰值。
• 计划偏差率：按同一估算单位比较计划投入和实际投入，解释偏差原因。
• 成员更新负担：每位成员为维护安排数据投入的时间和重复录入次数。

这些指标里，计划维护耗时容易量化，却不一定能代表业务结果；通知完整率和冲突提前量能反映管理透明度，但也可能因团队纪律改善而上升。比较可靠的做法是至少搭配一个过程指标、一个风险指标和一个成员体验指标，避免用单一数字宣告成功。

5. 计算总成本时，把管理维护和数据迁移算进去

软件订阅费用只是总成本的一部分。更完整的核算至少包括：迁移旧排期和人员资料的工时、权限及字段设计、培训、与现有系统的集成、管理员长期维护，以及上线初期工作效率暂时下降的影响。若只看报价单，可能会低估自定义配置和数据清理的支出。

对于100人以上组织，尤其要明确“谁拥有人员可用时间数据”“谁负责统一项目优先级”“谁批准跨团队调配”。工具可以提供视图，却不能替企业做权责设计。若这些责任无人承担，短期内再好的软件也会被旧表格和私聊重新取代。

六、按不同情况行动：从小范围试点到组织级上线

1. 如果你是项目经理，先拿一个真实项目做对照试验

选择一个持续数周、涉及多个角色且有一定变更概率的项目，不要从最简单、最不容易出错的任务开始。用同一份需求、人员配置和休假信息，分别走现有流程和候选工具流程，记录两边完成计划的时间、遗漏问题和调整次数。

重点检查：排期能不能反映任务负责人和交付日期；一名成员跨两个项目时是否能看出容量冲突；临时插入高优先级工作时，相关依赖是否容易找到。试点结束后，邀请实际使用者说明哪些信息重复填了、哪些提醒有用、哪些视图看起来清楚但不影响决策。

2. 如果你是资源经理，先治理“可用容量”的定义

不同团队很容易对百分比产生误解。有人把百分之百理解为每天八小时全部可分配，有人会预留会议、支持和学习时间，还有人按项目工时而不是日历工时估算。上线前应先统一基准：容量按工作日、工时还是比例计算；休假、培训和支持任务是否扣除；超负荷阈值由谁设定。

建议先把关键团队的安排口径写成简短说明，再在工具里配置和验证。若输入标准尚未统一，不要过早比较谁利用率更高。此时图表展示的可能只是不同团队的填报习惯，而不是实际产能差异。

3. 如果你是人力或运营负责人，轮班需求要从规则清单开始

整理班次长度、岗位覆盖、休息间隔、技能要求、节假日安排、临时请假、换班审批和考勤衔接。再挑选一周的真实班表，检查系统能否在不依赖人工补充规则的情况下生成或校验安排。必要时让业务、法务或合规负责人一起确认制度边界。

要特别谨慎处理个人信息和员工可见范围。班次管理可能涉及休假、考勤和人员状态，组织应明确哪些角色能看到哪些数据、变更记录保存多久、离职或调岗后如何处理权限。效率提升不能以过度暴露个人信息为代价。

4. 如果你是信息化负责人，先规划系统边界和数据来源

安排工具可能需要读取员工目录、项目任务、节假日、工时或考勤数据。上线前做一张数据流图，标出每类数据的来源、负责人、同步频率、异常处理方式和权限范围。若两套系统都允许修改同一字段，就必须定义主数据源，避免同步后相互覆盖。

集成评估还应包含失败场景：人员离职后同步失败怎么办、接口延迟时计划视图是否提示数据过期、同名成员如何消歧、权限撤销多久生效。供应商演示成功的一次同步，不等于长期运行可靠，运维责任和异常处理流程同样要写进实施方案。

5. 建议用四周完成第一轮选型验证

1. 第一周：界定问题。确认安排对象、使用人群、计划周期、目前人工耗时和最常见的三类冲突。
2. 第二周：统一样例。准备一份脱敏数据集，包括人员能力、任务、休假、优先级和变更需求。
3. 第三周：并行试用。让候选工具完成相同任务，记录操作步骤、遗漏信息、变更处理时间和成员反馈。
4. 第四周：复盘与决策。按预先确定的权重评分，确认未验证能力、总成本、实施责任和退出条件。

四周是一个可操作的验证节奏，不是所有企业都能完成正式部署的承诺。数据治理复杂、审批链条较长或需要多系统集成的组织，应延长验证时间，先确认风险和接口，再扩大试点范围。

七、不同情况下的取舍：没有万能工具，只有清晰的边界

1. 选择项目管理平台，还是专门资源计划软件

如果团队的主要问题是任务责任不清、状态分散、协作链路断裂，优先选能够承载项目执行的工具。资源计划是重要能力，但不能替代需求、任务、责任和进展管理。此类团队可把 PingCode、Asana 或 monday.com 放入候选，并按现有工作方式和治理需求筛选。

如果任务执行已经有稳定系统，而管理难点集中在跨项目调人、未来容量和资源占用，专门资源计划软件可能更直接。Float或Resource Guru可以按业务样例评估，但要事先确认它们与执行系统之间如何同步、谁维护接口、计划变更能否及时传递。

2. 选择灵活配置，还是选择更强的统一口径

流程变化多、团队自主性强时，灵活配置能缩短适配路径；但如果企业需要集团级汇总、审计和统一指标，配置自由度越高，越需要明确治理边界。团队不能只问“能不能改”，还要问“谁能改、改完谁审核、旧数据如何解释、跨团队字段怎样保持一致”。

我的取舍原则是：对影响跨团队比较、权限、安全和成本核算的字段保持统一；对不影响公共数据模型的团队工作方式保留一定灵活度。这样既避免把所有团队硬塞进同一套细节流程，也能让管理层看到可信的整体数据。

3. 选择自动排程，还是保留人工决策权

自动排程适合规则清晰、输入稳定、重复性高的场景，例如有明确岗位要求、时间约束和人员资格条件的轮班安排。它可以快速给出候选方案，但管理者仍应检查公平性、例外情况和人员偏好，不能将系统结果直接等同于最佳方案。

对于研发、创意、咨询等高度依赖经验判断的工作，自动化更适合做冲突提示、容量预警和方案比较，而不是取代负责人决定优先级。技能匹配、客户关系、知识连续性和风险承受能力等因素，往往无法仅靠历史工时或空闲时间完整表达。

4. 选择单一平台，还是保留专业系统组合

单一平台的优势是入口少、数据链路可能更简单；代价是它未必在每个专业环节都够深。多工具组合可以各司其职，但会带来数据同步、身份权限、重复录入和责任划分成本。决定之前，先算清楚团队每周为跨系统维护投入多少时间，以及信息不同步会造成多大风险。

如果采用组合方案，至少要明确主数据来源、同步频率、异常责任人和退出策略。不要让每个团队各自选择工具，再把“之后再集成”当成默认解决方案。集成不是采购完成后的附属任务，而是方案总成本的一部分。

5. 选择追求高利用率，还是追求计划韧性

人力紧张时，管理者很容易把利用率设成唯一目标，但完全排满会让团队缺少处理异常的空间。计划韧性意味着留出合理缓冲，并知道发生变化时哪些工作可以推迟、哪些人员能替补、哪些任务必须维持连续性。

因此，我更愿意同时看“负荷是否合理”和“突发变化能否承受”。如果短期内必须提高利用率，应明确这是临时措施，设置持续时间和复盘点，并观察加班、延期、返工与离职风险。没有退出条件的高负荷计划，往往会把短期资源缺口变成长期组织问题。

八、最终建议：把试点做成一次管理验证，而不是软件演示

1. 采购之前，先写出一页“安排问题定义”

在联系供应商前，先用一页纸写清楚：你要安排的是班次、项目任务、人员容量还是资源预订；谁提出需求、谁维护计划、谁批准变更；计划周期多长；当前最常见的三类冲突是什么；上线后准备观察哪些指标。

如果这页纸写不出来，说明企业还没有形成稳定的选型标准。此时最有价值的动作不是扩大产品名单，而是访谈实际使用者，观察计划是怎样产生、怎样被修改、又在哪些地方脱离现实。

2. 让供应商处理“出错后的场景”

常规演示通常展示顺畅流程，真正能区分产品的，是计划出错以后怎么恢复。要求演示人员处理一个员工临时请假、一个高优先级任务提前、一个关键岗位无人替补的组合场景，并说明系统保留了哪些记录、通知了哪些人、哪些决定仍需要人工完成。

同时记录每一步需要的权限、配置和额外模块。若某项核心能力必须依赖未包含在当前方案中的版本或集成服务，应把它列入总成本和采购条件，而不是留到上线阶段才发现。

3. 用“持续采用”而非“上线完成”作为成功标准

工具上线只是开始。一个月后还要检查成员是否持续更新、管理者是否仍在维护旁路表格、计划数据是否能用于周会和资源调整。若系统记录很完整，却没有改变决策过程，组织承担了输入成本，却没有获得相应价值。

因此，试点结束后应设置一个复盘周期，持续看计划维护耗时、数据更新率、冲突提前发现情况、计划偏差和用户反馈。指标恶化时，不要立刻归因于产品；先检查规则是否过重、数据源是否失真、角色是否不清，以及团队是否缺少必要培训。

4. 我的最终判断

2026年最值得关注的趋势，不是每个软件都加上自动排程或智能提醒，而是人员安排从静态计划转向可持续校准：需求变化后，组织能够看见影响、比较方案、说明取舍，并让责任人完成后续动作。

如果你的核心工作是研发和跨部门项目协作，可以把PingCode、Asana和monday.com作为不同协作逻辑的候选；如果重心是跨项目资源分配，可深入评估Float和Resource Guru；如果实际需求是轮班，则应把班次规则、考勤衔接和合规要求放在首位，不能被通用项目日历替代。

下一步不是先选“最受欢迎”的软件，而是选一个真实团队、一段真实计划和一个真实变更，要求候选工具现场走完“需求输入，容量核验，人员安排，冲突处理，变更复盘”全过程。谁能在减少人工核对的同时保留决策透明度，谁才更可能适合你的组织。