为项目配备人员，同时不隐藏资源冲突
面向跨项目人员配置的项目资源管理
为每个项目安排具备合适技能和工时的人员，同时保留这些人员在其他项目中已经承担的承诺。
登录后查看示例应用，再安装包含示例数据的版本，测试记录和审核路径。
软件应具备的能力
项目资源管理会把项目需求与共享人员、技能、可用性、人力安排审批、资源分配和交付反馈连接起来。它与项目管理互为补充：项目工具负责推进工作，资源管理层负责判断哪些容量可以可靠地承诺给多个项目。
- 明确区分实名需求与占位需求
- 审批前即可看见跨项目冲突
- 用实际投入更新后续估算
项目人员配置决策
将工作包转化为依据充分的申请
仅仅写“分配 Liam”不足以让审批人作出判断。
描述工作包
说明成果、日期、所需技能、职级、工作量、优先级和项目负责人。
查找共享资源供给
综合所有现有分配、休假和受保护工作，检查人员或角色的可用性。
提出资源分配方案
记录申请的工时和日期，以及匹配度与时间安排的理由。
批准、退回或拒绝
在人员安排变成隐性承诺前解决冲突。
比较计划与实际情况
利用交付反馈改进下一次项目估算和人员配置方式。
规划精度
确定性不足时先用占位角色，不要过早指定具体人员
规划对象应当随着承诺逐步明确而成熟。
| 阶段 | 应规划到的层级 | 应避免 |
|---|---|---|
| 早期销售机会 | 角色、技能、大致工时、日期范围、概率 | 为尚不确定的工作提前锁定真实人员 |
| 已批准项目 | 工作包、所需职级、工时、日期、优先级 | 只给出项目级人数，却没有时间信息 |
| 人员配置审核 | 实名候选人、匹配度、冲突、被挪动的工作 | 把可用性当作唯一的选人规则 |
| 交付执行中 | 已确认分配、健康度、变更、实际反馈 | 实际情况变化后仍不调整原始估算 |
冲突处理
让项目负责人和资源负责人都能看清取舍
示例不会悄悄覆盖发生冲突的人员安排。
日期冲突
对比两项承诺，再决定是否移动、拆分或替换新增分配。
技能瓶颈
将稀缺专业能力留给真正影响成果的工作，并另行规划交叉培训。
优先级变更
记录被挪动的是哪项承诺，以及谁批准了这项变更。
估算偏差
利用实际投入和交付状态修正剩余需求，而不只是记录加班。
实用问题
承诺人员前需要解决的项目人员配置问题
区分项目执行与跨项目人员配置，再定义占位需求如何转化为已批准的实名分配。
软件能自动为每个项目选出最合适的人吗？
不会。它会呈现容量、技能、日期、工作负荷和冲突等依据，供人员作出决策。规模较大时，自动优化可能很有价值，但前提是先明确约束条件、优先级并具备专业能力。当运营规则和审批路径需要由业务团队自行设计时，Jodoo 更具优势。 即使系统可以提供建议，跨项目优先级和交付后果仍需要明确的人员负责。
项目人员配置只需比较申请工时吗？
工时是实用的统一尺度，但仅凭工时还不够。示例会把技能、职级、时区、可用性、日期、优先级和交付状态与工时放在一起，避免把“数学上有空”的人误认为真正合适的人选。 项目阶段、所需技能、开始时间范围、受保护工作和交接成本都会影响可靠的判断。
项目团队可以自行调整人员申请流程吗？
经过培训的 Jodoo 管理员无需重建传统应用，就能添加字段、选项、视图、流转规则和仪表板。变更仍需明确负责人、完成测试并做好沟通，尤其是涉及审批、访问权限或报表指标时。 随着交付模式变化，经过培训的管理员可以调整角色选项、审批步骤、冲突字段和项目组合视图。
它会取代项目管理软件吗？
不会。项目管理用于管理范围、里程碑、任务、依赖关系、问题和交付；这套应用用于决策和管控跨项目共享容量。关联项目或工作包标识后，两套系统便能互相打开对应背景信息。
尚未确定具体人员时，可以先规划人员需求吗？
可以。在预测阶段保留基于角色或技能的需求，最终分配前再要求提交实名申请。这样既能避免虚假的精确度，也能提前暴露未来的容量缺口。
查看流程如何运行
查看已填充数据的资源规划应用
打开记录和决策视图，再根据团队规划工作的方式调整字段、角色和规则。