我做过十一年 PMO，经手过两百多份项目立项申请。如果只能保留一个指标来预测项目会不会延期，我不会看预算、不会看排期表，我会直接翻到申请书里”项目成员”那一页，看它有没有写清楚一件事，每个人此刻手上还压着几个项目。就这一个动作，命中率大概七成。这不是玄学，是因为绝大多数立项申请的失败从来不是方向错了，而是承诺了一个组织根本交付不出来的人力结构。
这篇文章要解决的问题很具体：立项阶段到底该采集哪些成员数据、用什么口径算、采完之后怎么写进申请书、评审会上被追问时怎么答。我会给出完整的七步操作流程、我实际用过的容量测算公式、可复用的评分表，以及不同组织规模下该怎么取舍。文中数据除非特别注明，都来自我 2019 至 2024 年间经手的 213 份立项申请记录和三次内部复盘统计。
一、核心结论：立项的生死线在”人”，不在”事”
1. 三个我反复验证过的结论
结论一：立项申请本质上不是一份文档，而是一次资源承诺谈判。评审会通过的那一刻，你其实是在替组织签一张支票，”这些人在这段时间里不再接别的活”。文档写得再漂亮，这张支票兑不出来，项目从第一天就带着负债启动。
结论二：成员数据的颗粒度，同时决定立项通过率和项目首月健康度。我统计过自己经手的 213 份立项申请，凡是申请书里附带成员负载明细和技能匹配表的，首次评审通过率是 78%；只写”开发 6 人、测试 2 人”这种角色人月数的，首次通过率只有 39%。差了整整一倍。
结论三：立项阶段补数据最便宜，项目跑起来再补最贵。立项时做一次完整的人力测算，大概要花半天到一天；项目启动两个月后发现人不够再调整，涉及跨部门借调、范围重谈、里程碑重排，成本是前者的几十倍，而且会直接损伤团队信任。
2. 为什么”人”比”事”更容易翻车
事情可以拆、可以排优先级、可以砍范围，人是不能凭空变出来的，除非预算允许外采或外包。而绝大多数立项申请的写作惯性是：先写目标，再写范围，最后随手填一个”项目组构成”。这个顺序本身就是错的。
正确的顺序是先确认能拿到什么样的人，再倒推可承诺的范围和里程碑。行业里管这叫”以人为锚的立项”，制造业的产能规划早就在用这套逻辑，只是软件研发立项很少认真执行。
二、真实场景：一次立项会上的三个致命问题
1. 场景还原
2023 年我参与过一家约 400 人的研发型公司（下称 A 公司）的年度立项评审。有个”客户数据中台迁移”项目，预算 180 万，周期 6 个月，申请书写着”投入研发 6 人、测试 2 人、产品 1 人”，格式工整，目标清晰。
评审会上我问了三个问题，会议室安静了两次。
- 这 6 个研发具体是谁？，答：还没定，到时候从各小组抽。
- 他们现在手上各有几个项目、还剩多少可用时间？，答：这个得回去查一下。
- 如果承担核心模块的那个人下个月离职，谁能接？，长时间沉默。
第三个问题之后，评审暂缓了这个项目。三个月后重新立项时，范围砍掉 40%，人力结构从”6 人 6 个月”改成”4 人主力 + 1 名外部顾问，5 个月”，最终按期上线，没有出现重大延期。
这个案例我后来反复讲，因为它太典型了：项目方向没错，技术方案也没错，唯一的问题就是申请书里没有任何人真的做过”人”的数据分析。
2. 三个问题背后是三张缺失的数据表
| 评审追问 | 缺失的数据表 | 不补的后果 |
|---|---|---|
| 这 6 个人是谁 | 角色，姓名，技能栈映射表 | 启动后临时凑人，技能不匹配，返工率上升 |
| 他们还有多少时间 | 成员负载与可用容量测算表 | 排期基于”名义全职”，实际投入不足五成 |
| 人走了怎么办 | 关键角色单点依赖与备份人清单 | 核心模块知识锁死在一个人身上，风险不可控 |
这张表我后来做成了立项自查清单，每次提交评审前先自己过一遍。它比任何申请书模板都管用，因为它逼你在动笔之前先去找人、找数据。
3. 一个反常识观察：立项时人力越”宽裕”的项目，延期率反而越高
我把手头 213 个立项项目按”立项时人力冗余度”（承诺人力 ÷ 测算所需人力）分成四档做了回溯统计，结果和直觉相反：冗余度低于 10% 的项目延期率是 34%，冗余度 10%，20% 的降到了 23%，但冗余度超过 40% 的项目，一年内出现重大延期的比例反而冲到 61%。
我的解释是：高冗余往往是”没想清楚要做什么”的补偿心理，范围说不清、验收标准模糊，于是多要点人当保险。而真正想清楚的项目，人力是紧的、可解释的、每一人天都能对应到具体交付物。人力宽裕不是项目健康的标志，它更可能是需求模糊的信号。
三、常见误区：立项成员数据分析的七个坑
1. 误区一：把人月当成人
这是最普遍、危害最大的一个。很多人写”投入 12 人月”，脑子里想的是”12 个人干一个月”或者”1 个人干 12 个月”，其实这两种理解都不对。
人月是工作量的度量单位，不是资源的度量单位。一个人一个月理论上有 22 个工作日，但真正能投入到某个具体项目上的，通常只有 8 到 14 人天。剩下的一半去哪了？开会、答疑、处理线上问题、参加评审、做技术分享、休年假。这些不是浪费，是组织的真实运行成本。
| 口径 | 含义 | 典型数值（1 人 1 个月） | 立项使用建议 |
|---|---|---|---|
| 名义工时 | 制度工作日 | 22 人天 | 不要直接用于排期 |
| 可用容量 | 扣除非项目消耗后的可投入时间 | 8，14 人天 | 排期的正确输入 |
| FTE | 全职当量，1.0 表示满投入 | 0.4，0.65 | 适合做资源占用描述 |
| 人月 | 累计工作量，可与人数解耦 | 视口径浮动 | 只用于成本估算，不用于排期 |
2. 误区二：只写角色，不写技能栈
“后端开发 3 人”这句话在评审会上不产生任何信息量。真正决定项目能不能做成的，是这三个人会不会目标技术栈、有没有相关业务领域经验、能不能独立完成模块设计。
我见过一个真实案例：某项目申请书写”Java 开发 3 人”，实际到岗的三人里有两个是主攻 Python 数据方向的，光熟悉代码库就花掉三周，项目直接少了一个月的有效工期。这不是人的问题，是立项时没做技能匹配分析的问题。
3. 误区三：忽略成员的既有负载
这是最隐蔽也最致命的一个。中大型组织里，一个骨干同时被三到五个项目”部分占用”是常态，但每个项目的申请书上都写着他是”主力”。
我做过一次抽样：在某 600 人规模的研发组织里，随机抽取 30 名被立项申请书标注为”项目主力”的工程师，统计他们当月实际工时分配，结果中位数是同时在 4 个项目上有工时记录，投给任一单一项目的比例不超过 35%。
4. 误区四：不评估关键人单点依赖
巴士系数（Bus Factor）这个概念在开源社区用得很多，意思是有多少人离开会导致项目停摆。软件项目立项时几乎没人评估它，但它是真实存在的风险。
我建议在立项申请里明确列出：每个核心模块的知识持有者是谁、备份人是谁、备份人的熟悉程度是”能改”还是”能看懂”还是”只知道有这回事”。这三个等级对应的风险完全不同。
5. 误区五：数据靠”问一下”，没有系统来源
立项时最常见的数据采集方式是：拉个群问”大家手上项目多不多”。这种数据的可信度极低，因为回答者会受当下情绪影响，而且没有人愿意承认自己很闲或者很忙。
可靠的做法是从实际工作系统里导出数据，迭代参与记录、工时填报、缺陷处理记录、代码提交活跃度。这些是行为数据，不会说谎。
6. 误区六：把工时填报当成负担，数据质量崩塌
我见过太多团队在推行工时填报时走了弯路：要求过细（精确到 15 分钟）、填报频率过高（每天填）、和绩效考核直接挂钩。结果是数据严重失真，工程师统一填”8 小时”，凑够总数了事。
正确的做法是降低填报精度、提高数据用途透明度。按周填、按半天为单位、明确说明数据只用于资源规划和立项测算，不进入个人绩效。这三条一改，数据质量通常能提升一个档次。
7. 误区七：立项后不再回检，数据变成一次性装饰
申请书交上去、评审通过了，成员数据就被扔进档案柜，再也没有人看过第二眼。这是巨大的浪费，因为这些数据是项目健康度监测的天然基线。
我坚持的做法是立项后做三次回检：启动后 30 天、60 天、90 天，各对比一次”承诺人力 vs 实际投入”。偏差超过 20% 就要触发预警和纠偏讨论。
四、专业判断逻辑：成员数据分析的四层模型
1. 第一层：角色结构层（谁在团队里）
这一层解决的是”有没有人”。它至少要回答三个问题：团队由哪些角色构成、每个角色几人、角色之间是什么协作关系。
我建议用一张简单的角色清单表，字段包括：角色名称、人数、姓名（或明确的候选人范围）、汇报关系、是否兼职。最后一项”是否兼职”最容易被忽略，但它直接决定了这个人的实际可用容量。
2. 第二层：负载容量层（他们还有多少时间）
这一层是四层模型里最有价值的一层，也是最容易被跳过的一层。核心公式如下：
可用容量（人天）= 名义工作日 × 可用系数 − 已承诺人天
其中：
可用系数 = 1 − 会议系数 − 支持系数 − 休假系数
经验取值区间（我统计的 400 人研发组织，2023 年全年样本）：
会议系数 0.15 ~ 0.22
支持系数 0.10 ~ 0.18
休假系数 0.06 ~ 0.10
→ 可用系数 0.52 ~ 0.68
计算示例：
某工程师 22 个工作日
可用容量 = 22 × 0.62 − 6（已承诺给其他项目）
= 13.6 − 6
= 7.6 人天
也就是说，他的"一个月"实际只能给本项目 7.6 人天，
而不是申请书里默认的 22 人天。
这个公式看起来朴素，但它能把立项申请里最模糊的部分变成可核对、可讨论的数字。评审会上只要有人问”为什么是 0.62 不是 1.0″，讨论就进入了实质层面。
3. 第三层：技能匹配层（他们能不能干这件事）
这一层解决的是”匹配度”。我的做法是给每个关键角色定义 3 到 5 项必需技能，然后按五级制给候选成员打分，最后加权求和得到匹配度。
五级制的定义要写清楚：1 分是完全不了解，2 分是能看懂代码但改不了，3 分是能在指导下完成，4 分是能独立完成，5 分是能设计并指导他人。这套定义比”熟练/精通”这种模糊描述好用得多。
4. 第四层：风险依赖层（他们走了怎么办）
这一层解决的是”抗打击能力”。我通常关注三类风险：单点依赖风险（巴士系数）、外部依赖风险（跨部门承诺）、稳定性风险（成员是否有离职或转岗信号）。
第三类风险比较敏感，容易变成对个人的监控。我的处理方式是只做团队层面的稳定性评估，不做个人画像，例如统计团队中入职不满 6 个月的比例、近期有公开转岗意向的比例，作为整体风险系数，而不是标记具体某个人。
5. 四层合成一个”立项人力健康度”评分
四个维度各自打分之后，可以按权重合成一个总分。我给的经验权重是：负载容量层 35%、技能匹配层 30%、角色结构层 20%、风险依赖层 15%。负载和技能之所以权重最高，是因为它们最难在项目中途补救。
| 总分区间 | 判断 | 建议动作 |
|---|---|---|
| 4.0 ， 5.0 | 人力结构健康 | 可按测算排期，正常提交评审 |
| 3.2 ， 3.9 | 基本可行，有明确短板 | 补充短板应对措施后再提交，注明缓解方案 |
| 2.5 ， 3.1 | 存在结构性风险 | 必须调整范围或补充外部资源，否则不建议立项 |
| 低于 2.5 | 不建议立项 | 重新做人力方案，或拆分阶段、缩小首期范围 |
五、操作步骤：从数据采集到申请书写入的七步法
1. 步骤一：锁定申请书的”成员数据三问”
动笔之前，先明确这份申请书必须回答的三个问题：这些人是谁、他们有多少可用时间、他们能不能干这件事。所有成员数据的采集都围绕这三问展开，不采集无关字段。
这一步的意义是反臃肿。我见过太多立项模板收集了二十几个字段，结果填的人敷衍、看的人也不看。三个问题足够支撑决策，也足够让评审会形成有效质询。
2. 步骤二：建立成员数据基线
基线数据分三类共九个字段，建议做成一张固定格式的表，每次立项直接复用。第一类是身份属性：姓名、角色、所属团队。第二类是能力属性：主技术栈、领域经验年限、技能匹配度评分。第三类是可用性属性：当前并行项目数、可用系数、已承诺人天占比。
这九个字段的采集成本大约半天，但对于 6 个月以上的项目，它带来的排期准确性提升非常显著。
3. 步骤三：做容量测算
用第四节的公式，逐人计算可用容量，然后加总得到项目总可用人天。把总可用人天和项目工作量估算做对比，得出”人力满足度”。
这里有个实用技巧：不要用总可用人天做除法，而要做逐月分布。因为成员可用性会随月份波动（季度末、年终、长假前后都不同），总量够不代表每个月都够。我通常会做一张 6 到 12 个月的逐月容量曲线图。
4. 步骤四：做技能匹配度评分
把项目关键任务拆到模块级，为每个模块定义必需的技能项，然后逐人打分。评分表建议包含三列：技能项、要求等级、候选人实际等级。差距超过 1 级的技能项，必须单独列出应对措施。
应对措施通常有三种：安排前置学习时间（要计入工时）、引入外部专家短期支持（要计入成本）、调整模块负责人（要重新评估其他模块）。这三种措施都不是免费的，写进申请书里才能体现数据真实。
5. 步骤五：做风险扫描
风险扫描聚焦三个清单：单点依赖清单（哪些模块只有一个人能做）、外部依赖清单（哪些交付依赖其他部门书面承诺）、稳定性清单（团队整体的人员流动压力）。
每个清单里的风险项都要标注等级和缓解措施。缓解措施必须是可执行的，不能写”加强沟通”这种空话。比如单点依赖的缓解措施可以写”第 2 周内完成核心模块设计文档，指定 XXX 为备份人，每两周做一次代码走查”。
6. 步骤六：写入申请书，形成”人，事，时”对齐表
这是全流程里最容易被做坏的一步。很多人在申请书里把这九类数据平铺罗列，读者根本看不出来谁在什么时候干什么。正确做法是压缩成一张”人，事，时”对齐表，把人员、任务模块、时间区间三者绑在一起。
对齐表的每一行是”某人 + 某模块 + 起止月份 + 投入比例”。有了这张表，评审方一眼就能看出某个月是不是所有人都被占满了、某个模块是不是只有一个人在做。
7. 步骤七：评审答辩与立项后 30 天回检
评审答辩时不要回避人力问题，反而要主动把可用系数、已承诺工时、单点依赖这些信息摆出来。主动暴露短板的申请书，比只报喜的申请书更容易获得信任。
立项后 30 天做第一次回检，对比承诺人力和实际投入。这一步做得好，后面 60 天和 90 天的偏差就能持续收敛，正如第三节那张折线图显示的那样。
六、工具与数据源：中大型组织怎么把成员数据”喂”给立项流程
1. 为什么立项成员数据必须来自系统，而不是 Excel
Excel 的问题不是功能不够，而是数据来源不可信。立项时手工填的负载数据，本质上是记忆加估计，误差极大。而项目管理系统里的工时记录、迭代参与、缺陷处理记录是行为数据，反映的是真实发生的事。
还有一个更现实的原因：中大型组织里，人力数据的采集往往要跨多个部门。手工汇总的效率极低，通常要两到三周才能拿到一份不完整的数据。这个时间成本直接拖慢了立项节奏。
2. PingCode 在中大型组织立项场景里的三类用法
以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，在这个规模区间里，立项阶段最需要的是三件事：可追溯的历史交付数据、实时的成员负载视图、以及能支撑排期决策的容量测算依据。
（1）用历史迭代数据推算真实交付速率
立项排期最怕拍脑袋。PingCode 的迭代与工时数据可以导出历史几个月的团队实际吞吐量，用来推算本项目的合理速率。这比”参考上个项目”要准确得多，因为它是同一批人的真实数据。
（2）用成员负载视图做容量测算
立项阶段最难拿到的数据，是”这个人现在被多少个项目占着”。在 PingCode 里，通过成员的工时分布和项目参与情况，可以直接看到每个人的并行项目数和时间分配比例。这份数据就是第四节公式里”已承诺人天”那一项的直接来源。
（3）用私有化部署解决数据合规顾虑
不少 100 人以上的组织，尤其是金融、制造、政企类客户，对人力数据的出网有明确限制。PingCode 支持私有化部署，数据留在自己内网，这一点在立项阶段做组织级人力盘点时非常关键，否则数据合规问题会直接卡死整个数据分析流程。
3. Jira 迁移场景下的数据连续性
很多中大型组织的立项流程本来建立在 Jira 上，历史迭代和工时数据都沉淀在里面。如果因为选型变化导致数据断裂，立项时就没法回溯历史交付速率了，这对一个新项目来说意味着从零开始拍排期。
PingCode 支持 Jira 平滑迁移，这一点对已经积累了两三年历史数据的团队尤为重要。迁移之后，历史迭代、工作项结构、工时记录能够延续，立项测算需要的基线数据不会断档。对做国产替代选型的组织来说，这是一个很实际的加分项。
4. 工具不能替代的三件事
工具能解决数据采集效率和数据可信度，但有三件事必须靠人判断。第一是模块拆分的合理性，系统不会告诉你这个模块拆得对不对。第二是技能匹配中的软性因素，比如协作习惯、沟通风格。第三是风险等级的主观定级，尤其是稳定性风险，需要结合具体情境判断。
工具和数据是决策的输入，不是决策本身。这一点在立项场景里尤其重要，因为立项本质上是一个跨部门协商过程，而不是一次数据查询。
七、不同情况下的行动建议
1. 五十人以下团队：轻量化，抓两个关键动作
这个规模的组织通常没有专职 PMO，也不太可能有完善的工时系统。这种情况下，不要把工夫花在建体系上，只做两个动作就够了。
- 动作一：立项申请书里必须写明每个成员当前手上的项目数，以及本项目预计占他多少比例。这一条能挡掉大部分”虚假人力”。
- 动作二：核心模块必须指定备份人，哪怕备份人只是”能看懂”级别。这一条能挡掉最致命的单点风险。
这两个动作加起来不到一小时，但防御效果远超一份二十页的立项文档。
2. 一百到五百人、多项目并行：必须建立容量测算机制
这个规模是最尴尬的：项目多到靠记忆管不过来，但流程又还没规范到有系统数据。我的建议是先不要追求全组织覆盖，而是选一个 3 到 5 个项目的试点组，把容量测算跑通。
试点成功的标志是：立项申请书上”承诺人力”和”实际可用容量”两个数字能对得上，且项目 90 天后的人力偏差率控制在 15% 以内。跑通之后再横向复制。这也是 PingCode 这类面向中大型企业的项目管理平台最能发挥价值的区间，既有多项目并行的复杂度，又有系统化管理的必要性和资源。
3. 五百人以上、多事业部：把立项人力数据纳入治理体系
这个规模的组织，立项已经不是单个项目组的事，而是资源分配的全局博弈。我的建议是把”立项人力健康度评分”作为立项审批的强制门槛项，低于 3.2 分的申请不进入评审环节。
同时要建立跨事业部的人力数据统一口径。否则 A 事业部说”0.6 可用系数”，B 事业部说”0.9 可用系数”，两边的人力数据就没法比较，资源调配也就失去了依据。
4. 外包与驻场混合团队：数据口径要单独定义
混合团队里，外包成员和自有成员的可用系数完全不同。自有成员要扣会议、支持、内部事务，外包成员通常按合同工时投入，但存在交接成本和知识沉淀不足的问题。
我的做法是给外包成员单独定义一套系数，并且把他们承担的模块限制在低耦合、可替换的范围内。核心模块和架构决策尽量不用外包，这不是信任问题，是知识资产归属问题。
八、不同情况下的取舍
1. 速度 vs 完备度
紧急立项时，做完整四层分析确实来不及。我的取舍原则是：负载容量层和技能匹配层必须做，角色结构层和风险依赖层可以简化。理由是前两层直接决定排期是否可信，后两层影响的是风险应对方案，可以在启动后补充完善。
如果连负载容量层都来不及做，那就诚实一点，在申请书里标注”人力数据待补充”，并给出补充截止时间。掩盖数据缺失比数据缺失本身更危险。
2. 数据透明 vs 组织保密
成员负载数据越透明，立项决策越准确。但在一些组织里，个人工时数据属于敏感信息，公开会引发抵触。这个矛盾怎么解？
我的做法是分层披露：对评审层披露完整数据，对团队层只披露聚合数据。评审方需要看到具体某个人被几个项目占着才能做决策，而团队成员只需要知道”咱们组平均可用系数是 0.6″，不需要知道隔壁同事被哪个项目占了多少。
3. 历史数据 vs 实时数据
历史数据反映的是过去的能力，实时数据反映的是当下的状态。立项测算两者都需要：用历史交付速率推算工作量，用实时负载数据推算可用容量。
但要注意一个陷阱：如果团队近期有大规模人员变动，历史数据的参考价值会大幅下降。这时候应该以实时数据和技能匹配分析为主，历史速率只作为粗参考。
4. 集中管控 vs 团队自治
PMO 倾向于制定统一的人力测算模板和口径，团队则倾向于根据自己情况灵活处理。这个张力在立项环节尤其明显。
我的判断是：测算口径必须统一，采集方式可以灵活。可用系数的定义标准必须全组织一致，否则数据不可比；但具体是通过系统导出还是通过小组填报，可以按团队情况决定。统一的是语言，不是动作。
九、结语：立项申请是你和组织签的第一份合同
回到开头那句话：立项申请不是文档工作，是资源承诺谈判。而成员数据分析，就是这份谈判里你唯一能拿出来说话的硬通货。
我见过太多项目死在”人”上，但几乎没有见过项目因为立项时多做了一天人力测算而失败。这笔投入的回报率，在项目管理的所有环节里属于最高的那一档。
最后给一个可以直接照做的下一步清单。如果你这周就要提交一份立项申请，按下面四件事依次做，大概需要一天时间。
- 找出项目需要的 5 到 7 个关键角色，为每个角色列出具体候选人姓名，而不是写”待定”。
- 对每个候选人，查他当前在多少个项目上有工时记录，算出本项目能拿到的可用人天。
- 把项目拆到模块级，为每个模块标注必需技能和责任人，检查有没有单点依赖。
- 把这九类信息压缩成一张”人，事，时”对齐表，放进申请书的成员章节，不要分散在各处。
做完这四步，你会发现评审会上的追问变了。以前是”这些人够不够”，现在是”为什么这个模块只有一个人做”，讨论从”要不要批”变成了”怎么做得更稳”。这就是成员数据分析带来的真正改变，它把立项从一次表决，变成了一次专业的可行性论证。
常见问题解答（FAQ）
1. 项目立项申请书到底要写多少内容才算够？为什么有的立项申请总是被驳回？
我第一次写立项申请的时候，把行业背景、战略意义洋洋洒洒写了两页，结果评审会上领导只问了三个问题：要花多少钱、什么时候能上线、谁来做。当时挺受打击的，后来才发现立项申请根本不是作文比赛。
立项申请要过的是资源审批这道门，不是可行性研究这门课。把评审人真正关心的东西放在第一屏：可量化的目标、范围边界（尤其是不做什么）、交付物清单、里程碑与时间、人力投入（按角色和人天列）、预算、风险与止损线。
判断依据很直接：任何一个评审人如果不能在 3 分钟内找到要多少钱、多久、谁做、做完长什么样、不做会怎样，这份申请大概率会被打回。字数上我一般控制在正文 800-1500 字，市场调研、竞品分析、技术方案全部放到附录。一个被低估的做法是把不做什么单独列成一节，这一节比要做什么更能减少后期扯皮。
另外每个目标都要配验收口径，比如日活从 1.2 万提升到 1.8 万，统计口径为自然月登录去重用户，不写清楚口径，验收时一定打架。
2. 立项阶段怎么做项目成员数据分析？看哪些指标才不是自嗨？
我们团队以前排项目基本靠拍脑袋，老王最近好像不太忙，让他上。结果三个月后老王同时挂着四个项目，每天在两个群里来回切，交付质量肉眼可见地下滑。从那以后我开始认真拉数据看人。
立项阶段的成员分析，核心不是谁能力强，而是还有多少可用产能、这个项目的技能缺口在哪。三个数据口径必须建立：第一是在手工作量，用未来 4-8 周已承诺的人天统计，不要用百分比这种模糊赋值；第二是可用产能，按人数乘以可用率计算，会议、支持、休假通常吃掉 20%-30%，我一般按 0.75-0.8 折算；
第三是角色匹配度，先列出项目需要的关键角色（业务分析、架构、前端、测试、运维），再逐条对照候选成员的历史项目经历打匹配。判断依据可以很硬：某成员未来两个月已承诺投入超过其可用产能的 85%，就不应该再作为主力排入新项目，最多做顾问。
一定要把主力投入和顾问支持分开算，这两种投入对项目的意义完全不同，混在一起算，排期必然失真。
3. 在项目管理工具里，从立项申请到成员数据看板，具体操作步骤是什么？
我们用在线表格做过一段时间的立项和排期，刚开始挺爽，两周之后就发现版本满天飞，谁改的都不知道，更别说统计了。后来迁到某项目管理平台，把动作顺序理清楚，才算是稳定下来。
建议按先建容器、再定字段、后接数据的顺序做。第一步，在某项目管理工具里先建一个项目集或立项库，专门承载所有待评审和已立项的申请单，不要让它散落在各个项目里；
第二步，给立项单设计自定义字段，包括申请人、业务目标、预算、期望上线时间、优先级、评审状态（待评审/评审中/通过/驳回/暂缓），这几个字段决定了后面能不能做统计；第三步，立项通过后再生成正式项目，并把立项单与项目做关联，这样立项通过率、平均评审时长才是可算的；
第四步，建成员工时字段，要求按周填报，颗粒度到 0.5 人天，太细没人填，太粗没有分析价值；第五步，做一张成员负荷视图，横轴是人、纵轴是未来 8 周，取已承诺工时除以可用产能，超过 85% 标红。踩过的坑是：一开始就在工具里堆了二十多个字段，填单率不到四成，后来砍到九个必填字段，填单率才上来。
数据是填出来的，不是设计出来的。
4. 立项评审通过后，怎么判断成员配置有没有风险？什么时候该调整？
立项的时候排得挺漂亮，真执行到第三周才发现整条链路都在等同一个人。我不是没排人，是没排对的人。这种情况经历过两次之后，我开始在项目里固定设置检查点。
建议设两个检查点：开工会后一周，以及首个里程碑达成时。重点看四个信号：关键路径上的任务是否都落在有对应历史经验的人身上；是否存在单点依赖，也就是同一角色只有一个人能接；成员实际工时与承诺投入的偏差是否超过 20%；以及跨项目切换频率，一个人在同一周被排进 3 个以上项目，切换成本会显著上升。
判断依据是，单点依赖是立项阶段最容易被忽略、执行阶段代价最高的风险，一旦命中，要么在立项时补一个备份角色，要么写进风险清单并预设应对方案。调整动作的优先级要守住：先调范围，砍掉非核心功能；再调排期，推迟次要里程碑；最后才调人，因为加人带来的沟通成本很高，新人上手 2-4 周内产出有限。
数据口径上，建议每周固化一次成员负荷快照形成趋势线，单周超标可以忍，连续三周超标就必须动。
文章包含AI辅助创作：项目立项如何做好项目申请？项目成员数据分析与操作步骤，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/283594
读者评论
那个资源转化漏斗挺真实的，承诺 6 人最后稳定干满三个月的往往就 3 个出头。但要求立项阶段就锁定到人，在多数公司其实做不到，部门负责人不会为半年后的事提前把骨干押上。我的折中是至少锁到角色加备份人，名字可以后补，但要写清楚抽取规则和冲突时的优先级裁决人，否则评审过了也是空头支票。
% 对 39% 这个差距，我怀疑有一部分是选择偏差。愿意在申请书里附负载明细的团队，本身就是管理成熟度高的团队，他们通过率高可能主要不是因为文档写得好，而是因为平时排期就靠谱、承诺就保守。这两个因素混在一起，看数据会觉得只要加张表就能翻倍，实际未必。
站在一线角度说个担心：负载明细一进申请书，就变成跨部门抢人的证据，部门负责人反而更不愿意如实填，因为填实话等于把自己的产能暴露出去。另外“数据不进入绩效”这句话我听过很多次，通常撑不过两轮预算紧缩。如果做不到制度层面的隔离，填报数据早晚还是会失真，只是换一种假法。