我带过的一个 8 人小组，曾经用三周时间打磨出一份 60 页的立项申请，评审会上 25 分钟就被否了。否决理由只有一句话：这份材料没有告诉我，如果批了这笔预算和这 6 个人，明年我会在哪个指标上看到变化。后来我们把同一件事压缩到 12 页重新上会，一次通过。差别不在于写得更少，而在于第二次我们把”申请”当成了资源谈判，而不是文档交付。项目立项如何做好项目申请、项目成员制度怎么设计、操作步骤到底该走几步，本质上都围绕同一个问题：你能不能让决策者在 20 分钟内相信，投给你的每一份资源都有可验证的回报路径。
一、先给结论：立项申请的成败，发生在评审会之前
我做过统计，也参与过评审：一份立项申请被否，80% 的原因在写材料之前就已经注定，只是到评审会上才被暴露出来。所以这一节先把三条结论摆出来，后面的所有方法都是为这三条服务的。
1. 立项申请不是”写文档”，是”谈判资源”
立项申请的交付物看起来是文档，实际交付的是三样东西：预算、人、时间窗口。文档只是这三样的载体。判断一份立项申请好不好，最简单的标准是，评审人看完之后，能不能明确说出”我要给你多少钱、几个人、多久”。
如果看完只记住了”这个项目很重要”，那这份材料其实没有完成它的功能。我见过太多立项书把 70% 的篇幅花在行业趋势和技术架构上，却在”需要几个人、什么职级、投入几个月、什么时候释放”这些真正要拍板的字段上模糊带过。
2. 项目成员制度不是”人员名单”，是”权责与投入合约”
很多人把成员制度理解成一张表：谁担任什么角色。这是通讯录，不是制度。真正的成员制度至少要回答四个问题：这个角色有多少决策权、承诺投入多少人力（FTE）、冲突时谁升级、退出或调岗时怎么交接。
成员制度的本质是一份内部合约：业务方承诺投入多少业务专家，IT 方承诺投入多少开发资源，双方都承诺在什么时间点给出什么输入。没有投入承诺的项目，本质上是在用”抽空干活”的方式推进，必然延期。
3. 通过率来自”可验证假设”，不是”材料完整度”
我对比过 40 多份立项材料的评审结果，发现一个反直觉现象：篇幅越长的材料，一次通过率反而更低。原因很简单，长材料通常意味着作者在回避判断，把能查到的信息都堆上去，把该做的取舍留给评审人做。
评审人最想看到的其实是三句话：现状是什么（有数据）、不做的代价是什么（有量级）、做完之后怎么验证（有指标）。
二、真实场景：为什么”看起来很完整”的立项书反而更危险
我拿一个真实场景来说。某制造企业要做一次质检流程的数字化改造，申请预算 180 万，周期 9 个月，申请借调 6 个人。第一版立项书 58 页，目录涵盖了行业趋势、技术选型对比、架构图、实施计划、培训方案，甚至附了三家供应商的报价单。
评审会上，业务副总问的第一个问题是：”现在质检环节一次漏检导致的返工成本是多少？”没有人答得上来。第二个问题是：”你说借调 6 个人，是哪 6 个？他们现在的活儿谁来干？”也没有明确答案。会议开了 40 分钟，结论是”材料很充分，但先回去把这两个问题补上”。
1. 材料的”完整”，往往掩盖了判断的”空缺”
这是我最常遇到的情况：作者把立项书当成了”信息容器”，而不是”决策工具”。信息越全，评审人越容易在细节里打转，反而把关键判断放过去了。
更麻烦的是，一份 58 页的材料，评审人实际只会精读前 3 页和执行摘要。剩下的部分只有在质疑某个具体数字时才会被翻到。
2. 评审人真正在意的，是”机会成本”而不是”项目价值”
普通项目的价值通常是明显的，不明显的项目根本不会进入立项流程。评审人的真实焦虑是：这笔钱和这 6 个人，如果投给另一个项目，会不会更划算？
所以立项申请里最有含金量的一页，往往是”资源占用与替代方案对比”，而不是”项目价值陈述”。这一页能直接回答机会成本问题。
三、四个高频误区，几乎每个立项申请都会踩
下面这四个误区，我在不同行业、不同规模的组织里反复见到，而且它们往往同时出现。
1. 把立项书当成技术方案书
技术团队写立项材料时，本能反应是证明”我们的方案是对的”。但评审会不是技术评审会，决策者关心的不是方案有多先进，而是这个方案失败的概率有多大、失败之后能不能退回来。
判断标准很简单：如果一份立项书拿掉所有架构图，论证还成立吗？如果不成立，说明论证建立在方案上，而不是建立在业务问题上。
2. 把成员制度写成通讯录
典型写法是列一张表：张三，项目经理，李四，业务负责人，王五，技术负责人。这张表没有任何约束力，因为张三可能同时挂着 4 个项目，李四可能只是”挂名支持”。
没有 FTE 承诺的角色表，等于没有成员制度。我建议每个角色后面至少写清楚：承诺投入比例、投入周期、关键交付物、缺席时的替补人选。
3. 用”战略重要性”替代”决策依据”
“本项目符合公司数字化转型战略”，这句话在评审会上约等于没说。战略是给定的，项目要回答的是在这个战略下，为什么是现在做、为什么是这个范围、为什么是这批人。
4. 只报收益，不报退出条件
我审阅过的大量材料里，主动写”什么情况下应该停止这个项目”的不到 10%。但恰恰是退出条件，能让评审人放心地把资源批给你，因为它说明你已经想过失败，并且设置了止损点。
四、专业判断逻辑：四层论证 + 三道决策门
我自己的立项申请，无论规模大小，都按”四层论证”来组织。这四层的顺序不能调换，因为它对应着评审人从”这事值不值得做”到”能不能做成”再到”谁来做”再到”做不成的代价是什么”的思考顺序。
1. 价值层：现状基线 + 差距 + 目标值
价值层唯一的要求是量化。量化的最低标准是三个数：现状值、目标值、测量口径。比如”质检返工率从 6.2% 降到 3.5%，按月度质检批次统计”就是一个合格的目标；”显著降低返工率”不是。
如果确实拿不到基线数据，就明确写”基线待第 2 周数据采集后确定，采集方式为……”。这比编一个数字要安全得多，因为评审人最反感的就是被编造的数据误导。
2. 可行性层：关键假设 + 验证方式
把项目成立所依赖的假设显式列出来，是提升通过率最有效的单点动作。常见假设包括：业务部门能提供 2 名全职专家、现有系统提供标准接口、日均数据量不超过 50 万条。
每一条假设后面都要跟一个验证方式和验证时间点。假设如果在第 6 周被证伪，项目就要触发重新评审，而不是硬着头皮做完。
3. 资源层：成员制度 + 投入承诺
资源层就是本文标题里的”项目成员制度设计”。它要回答三个问题：需要什么角色、每个角色投入多少、这些人的决策边界在哪。这一层我建议单独成一章，不要塞在实施计划里。
4. 风险与退出层：失败信号 + 止损动作
风险层要写的是”可观测的失败信号”，而不是”风险描述”。比如不写”需求变更风险”，而写”若第 8 周累计需求变更超过原始范围的 30%，则触发范围重新评审”。
5. 三道决策门：让立项不是一次性赌博
我通常会把项目拆成三道门。第一道门在立项时，只批”验证阶段”的资源；第二道门在方案验证通过后，批”建设阶段”的完整资源；第三道门在上线前，批”推广与运维”的持续投入。
五、项目成员制度设计：四个必须写清楚的模块
成员制度设计最容易走过场的部分，恰恰是最影响落地成败的部分。我把它拆成四个模块，每个模块都有明确的交付物。
1. 角色地图：从”职位”转向”职责”
角色地图不要用职位来定义，而要用职责定义。同一个项目里，一个资深工程师可能同时承担”技术方案决策”和”接口对接”两个角色，这是允许的，前提是写清楚。
我常用的角色集合是六个：项目发起人（Sponsor）、项目经理（PM）、业务负责人（Product Owner）、技术负责人（Tech Lead）、关键用户代表（Key User）、质量与合规（QA/Compliance）。
| 角色 | 核心职责 | 决策权边界 | 典型 FTE 投入 |
|---|---|---|---|
| 项目发起人 | 提供资源、清除跨部门障碍、对最终收益负责 | 预算追加、范围重大变更、项目终止 | 0.1 FTE，按需参与 |
| 项目经理 | 计划、协调、风险跟踪、汇报 | 计划调整、任务分配、风险升级 | 0.5-1.0 FTE |
| 业务负责人 | 需求优先级、验收标准、业务规则裁定 | 需求取舍、验收通过与否 | 0.5 FTE，关键阶段 1.0 |
| 技术负责人 | 技术方案、架构决策、技术风险 | 技术选型、技术实现路径 | 0.5-0.8 FTE |
| 关键用户代表 | 提供一线场景、参与测试、推动落地 | 流程细节确认 | 0.2-0.3 FTE |
| 质量与合规 | 合规审查、质量标准、上线把关 | 合规一票否决 | 0.1-0.2 FTE |
2. 投入承诺：用 FTE 把”支持”变成”义务”
“全力支持”是立项材料里最没有价值的一句话。我要求所有成员制度里的投入都必须写成 FTE 和周期，并且由该成员的直线经理确认。
这里有个容易被忽略的细节：要写清楚投入的时间分布，而不仅是总量。一个 0.5 FTE 的业务负责人，如果他的投入集中在第 1-2 周和第 30-36 周，那么中间 28 周项目其实处于”业务失联”状态，这往往是需求返工的根本原因。
3. 决策权与升级路径：把”扯皮”变成”流程”
成员制度必须写清楚三类争议的处理方式：需求优先级争议、技术方案争议、进度与范围争议。每一类都要指定第一裁决人和升级对象。
我的经验是，升级路径最多两级。如果一件事需要升到第三级才能解决，说明成员制度本身设计有问题，而不是团队执行力有问题。
4. 退出与交接：决定项目后半程能否稳住
几乎所有立项材料都不会写退出机制，但现实中人员变动是必然的。我要求每个关键角色都有明确的替补人选，并且替补必须在关键评审会上出现过至少一次。
退出交接的最小清单包括：角色对应的权限移交、未完成交付物的责任人变更、上下文的书面记录、正在进行的争议事项交接。这四项缺一项，交接就会出现信息真空。
六、操作步骤：从想法到立项通过的 8 个动作
下面这 8 步是我实际使用的顺序，按这个顺序走，一份立项申请从想法到上会通常需要 2-4 周，比反复返工要快得多。
- 写一页纸的立项前备忘录。只写四件事：问题是什么、影响谁、不做的后果、粗算的资源量级。这一页不是给别人看的，是给自己判断要不要继续投入的。
- 找 3 个非利益相关方做红队预审。让不了解这个项目的人用 10 分钟挑毛病，他们提出的问题往往就是评审会上的问题。
- 定基线。把现状量化成 3-5 个指标，明确采集口径和采集时间。如果暂时取不到，写明采集计划。
- 画目标状态与差距。目标值要能被基线口径测量，差距要能算出量级（金额、工时、订单数等）。
- 设计最小可交付切片。明确第一阶段的边界，让第一道决策门只需要批很小的资源。
- 拟成员制度。按上一节的四个模块写，重点是 FTE 承诺和决策权边界，并让直线经理确认。
- 做成本-收益-风险三栏表。成本要包含机会成本，风险要包含可观测的失败信号。
- 走评审门并留下决策记录。会后 24 小时内发出决策记录，写明批准的资源、附加条件、下一次评审时间。
很多人会跳过第 1 步和第 2 步，直接开始写正式材料。这两步加起来的时间成本大约 3 小时，但通常能省掉一轮完整返工，也就是一到两周。
立项申请书 12 页骨架（我实际使用的目录）
├── P1 执行摘要：问题 / 目标 / 资源 / 验证方式（半页）
├── P2 现状基线与量化差距
├── P3 目标状态与三档目标值（保守 / 预期 / 激进）
├── P4 关键假设与验证计划（表格）
├── P5 方案概要（不含技术细节，只讲路径与备选）
├── P6 项目成员制度
│ ├── 角色地图与权责边界
│ ├── FTE 投入承诺与时间分布
│ ├── 决策权与升级路径
│ └── 替补与退出交接
├── P7 里程碑与三道决策门
├── P8 成本明细与机会成本对比
├── P9 收益测算（含测算口径与敏感性区间）
├── P10 风险登记册与失败信号
├── P11 退出条件与止损动作
└── P12 附录：数据来源、术语表、历史材料索引
七、把成员制度落到系统里：以中大型组织的项目管理平台为例
立项通过只是开始。我见过太多项目，成员制度在立项材料里写得很漂亮，通过之后就变成了一份归档的 Word 文档，谁也不再打开。真正让制度起作用的方式，是把它固化成系统里的角色、权限、工作流和投入记录。
1. 为什么 100 人以上的组织必须靠系统而不是靠自觉
50 人以下的团队，靠周会和口头约定还能维持；一旦超过 100 人、跨三个以上部门，口头约定必然失效。原因不是大家不守信用，而是信息传递链条太长，没人知道别人承诺过什么。
这类场景下，我一般建议直接在项目管理系统里把成员制度建成可执行配置。以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，在这类组织里，角色权限、需求评审流、跨部门审批这些环节本身就需要系统承载。它支持私有化部署，对有数据不出内网要求的企业可以满足；同时支持从 Jira 平滑迁移，对于原本使用海外工具、现在需要做国产替代的团队，迁移成本相对可控。
2. 把四个制度模块映射成系统配置
角色地图对应成员角色与权限组，FTE 投入对应工时登记与资源视图，决策权对应评审流与审批节点，退出交接对应任务负责人变更与记录留存。
成员制度 → 系统配置 映射示例
角色地图 → 项目角色组：Sponsor / PM / PO / Tech Lead / Key User / QA
权限差异：PO 可改需求优先级，Tech Lead 可改技术状态，Key User 只读+评论
FTE 投入承诺 → 资源视图中的计划工时 vs 实际工时
告警规则：实际工时 / 计划工时 决策权与升级 → 需求评审工作流节点
需求变更 > 30% 范围 → 自动触发 Sponsor 审批节点
退出与交接 → 负责人变更时强制填写交接清单
未填交接清单时，原负责人权限保留 7 天后自动回收
3. 用数据反哺下一次立项
系统化还有一个被低估的价值：它会在项目结束时留下真实的人力和周期数据。下一次做同类项目的立项申请时，这些数据就是最有力的基线，比任何行业报告都更有说服力。
我建议每个项目结项时，都产出三个数字：实际 FTE 投入与计划的偏差、关键里程碑的实际耗时与计划偏差、目标指标的达成率。这三个数字进入组织级的知识库，立项质量会以肉眼可见的速度提升。
八、不同组织规模下的行动建议
同一套方法，在不同的组织规模下重量应该完全不同。把重流程套在小团队上，会直接被压垮；把轻流程放在大组织里，等于没有流程。
| 组织规模 | 立项申请重量 | 成员制度重点 | 审批方式 |
|---|---|---|---|
| 50 人以下 | 1-2 页，写清问题、目标、3 个数字即可 | 只写角色和 FTE 两列，不做权责矩阵 | 一次沟通会拍板，会后留一页纪要 |
| 50-100 人 | 4-6 页，增加假设清单和风险清单 | 增加决策权边界和替补人选 | 双人决策，24 小时内出记录 |
| 100-500 人 | 8-12 页，完整四层论证 + 三道决策门 | 完整四模块，FTE 需直线经理确认 | 评审委员会，季度批预算 |
| 500 人以上 / 集团型 | 12 页以上，增加项目组合视角的重复与冲突排查 | 增加跨法人、跨区域的权责与合规角色 | 分阶段评审，每道门单独批资源 |
1. 研发主导型组织：把技术可行性假设前置
研发型组织最容易犯的错是把技术可行性当默认成立。我建议这类组织在成员制度里单独设一个”技术风险负责人”，其唯一职责是在立项阶段识别技术不确定性并给出验证计划。
2. 交付主导型组织：把客户承诺写进约束条件
交付型项目的立项往往受合同节点约束，那么成员制度要反过来倒推：要满足这个节点，需要多少 FTE 投入，如果投入达不到，需要提前向客户申请范围调整。这一点必须在立项阶段说清楚，不能拖到执行期。
3. 强监管行业：合规角色必须有一票否决权
金融、医疗、能源等行业的立项，合规角色如果只是”参与评审”，形同虚设。我在成员制度里会给合规角色明确的一票否决权，同时配套一个”合规前置咨询”动作，让合规在方案设计阶段就介入，而不是上线前才否决。
九、不同情况下的取舍
做立项和成员制度设计，本质上是不断做取舍。下面三组取舍我认为最关键，也最容易被忽略。
1. 速度 vs 严谨：用决策门而不是用篇幅来平衡
如果你的目标是快速启动，不要通过减少论证来提速，而要通过减少第一道门的资源投入来提速。第一道门只批验证期资源，论证可以浅一点；第二道门必须严谨，因为那时投入的资源已经不可忽视了。
这个取舍的好处是，你既拿到了启动速度，又没有放弃严谨性，只是把严谨性往后推到了信息更充分的时点。
2. 统一模板 vs 场景适配：模板管结构，内容管场景
统一模板的价值在于让评审人形成阅读预期，降低理解成本。但如果模板强制到字段级别，会出现大量”为了填而填”的内容。
我的做法是：模板固定章节结构，但允许章节内部自由裁量。比如”风险”这一章必须存在，但小项目可以只写三条，大项目可以写十五条。
3. 强流程 vs 轻流程：按成员制度的重要性分层
不是所有项目都需要完整的成员制度。判断标准是：这个项目是否依赖跨部门资源。如果是，成员制度必须完整；如果资源全部来自一个团队内部，可以简化为角色和 FTE 两列。
把重流程用错了地方，会让团队把精力花在填表上；把轻流程用错了地方，会在执行期付出成倍的协调成本。
十、常见追问
1. 立项申请一般多少页合适？
我的经验值是 8-12 页，不含附录。核心判断标准不是页数，而是执行摘要能否在一页内讲清楚问题、目标、资源、验证方式。如果一页讲不清，说明论证结构还没理顺，加页数解决不了问题。
2. 业务部门不愿意承诺 FTE 怎么办？
这通常不是意愿问题，而是排期问题。我的处理方法是在成员制度里写明”若业务侧投入低于承诺的 60% 连续两周，项目自动进入暂停状态并重新评审”。把后果写清楚，比反复催人有效得多。
3. 项目已经启动了，成员制度还能补吗？
能，而且越早越好。补的方式建议是找一个具体的冲突场景作为契机，比如因为需求优先级不清导致返工，然后借这个机会把决策权和升级路径定下来。凭空补制度通常推不动。
4. 小项目也要写假设清单吗？
要，但可以只写三条。假设清单真正的价值不是给评审人看，而是让你自己在项目中期有据可依地判断”是不是该调整方向”。
十一、总结与下一步
回到最初的问题：项目立项如何做好项目申请、成员制度怎么设计、操作步骤是什么。我的核心观点是，立项申请的质量不取决于文档写得多完整，而取决于论证结构是否可验证；成员制度的价值不取决于角色写得多清楚，而取决于投入和决策权是否被承诺并被系统强制执行。
这两个判断有个共同的底层逻辑：把模糊的承诺变成可观测的约束。评审人不需要被说服，他们需要的是能验证的证据。
如果你的下一步是启动一个项目立项，我建议按这个顺序做三件事。第一，用 3 小时写出那页立项前备忘录，并找 3 个局外人挑毛病。第二，把成员制度的 FTE 和时间分布表发给每一位直线经理确认，拿到书面回复。第三，把决策权边界和升级路径写成一页纸，在第 1 周的项目启动会上过一遍，让每个人知道争议该找谁。
这三件事做完，你大概率会发现立项申请的其余部分都变得好写了，因为它们终于有了可以被检验的地基。
常见问题解答（FAQ）
1. 项目立项申请书写到什么程度，评审会才不会被质疑「价值说不清」？
我第一次写立项申请时，把背景和技术方案写了六页，结果评审会上领导只问了一句「不做会怎样、做了能省多少钱」，我当场卡住。后来发现身边同事也常踩这个坑：材料很厚，却没有一个能对得上的数字。所以我很想知道，申请书到底写到什么颗粒度才算够。
判断依据是「三问闭环」：为什么现在做、不做会损失什么、做完用什么数字验收。写法上把申请书压成三块：一页价值假设，写清问题现状、影响范围、量化目标；一页方案与边界，写清做什么、明确不做什么；一页资源与风险，写清人力工时、预算、关键依赖和Top3风险及应对。
量化目标必须带口径，例如把「提升效率」换成「月度对账工时从人均12小时降到6小时，基线取自上一个季度的工时填报记录，验收时从系统操作日志取数」。收益测算至少给三种口径：人力折算、收入增量、风险规避，并写明假设条件。经验上，价值部分超过两页却没有一个数字的申请，基本都会在质询环节被按住；
凡是能写清「基线值+目标值+取数来源」的，评审往往只在资源和排期上讨价还价。一句话原则：宁可写「一年省下2个人月」，也不要写「显著提升协同效率」。
2. 项目成员制度怎么设计，才能避免成员「挂名不产出」？
我之前参与的一个项目，立项时拉了11个人进群，看着阵容很齐整，结果真正干活的还是那3个人，其他人只在启动会上出现过一次。后来我在设计成员制度时开始较真：到底谁对哪个交付物负责，投入多少比例，不投入会怎样。
核心是把「成员」从一份人名清单，变成角色、交付物、投入比例三者的矩阵。具体做法：第一，角色只设四类，决策人负责对目标和资源拍板，项目经理负责进度和风险，核心交付人对具体产出负责，协作与评审人对标准把关，每类写清权限边界；第二，每个人对应到具体交付物，而不是对应到项目群；
第三，标注投入比例，比如每周8小时或占其工作量30%，并让直线经理确认，没有确认的投入等于没有；第四，把项目交付指标纳入其当期考核，权重建议不低于10%到15%，低于这个区间基本没有约束力；第五，设置退出机制，连续两个里程碑未交付且未报备，自动转为观察角色或退出，由项目经理发起。
判断依据很简单：如果某个成员说不清自己这个月要交出什么，那他就是挂名。另外成员规模控制在7人上下，超过9人建议拆成子项目，否则沟通成本会吃掉收益。这套结构落到项目管理平台里，就是一张成员与交付物的对应表，谁缺席一目了然。
3. 项目立项从想法到启动会，有没有一套可以直接照做的操作步骤？
我们团队以前立项很随意，谁嗓门大谁先做，做到一半才发现预算不够、人手也没到位。后来我复盘整理了一套流程，从收集机会点到开启动会大概两周能跑完，想知道这套步骤在别的团队能不能直接复用。
可以按五步走，每一步都给时间盒和输出物。第一步机会收集，一周，用统一模板收提案，字段固定为问题描述、影响人群、量化收益、预估投入、不做的后果，避免各写各的。
第二步预筛，一天，由项目管理部门按战略匹配度、收益量级、资源可得性、风险四项各1到5分打分，低于阈值的直接退回并写明理由，不要把所有提案都推到评审会上。第三步评审会，半天，每个提案15分钟陈述加10分钟质询，只回答资源、排期、验收标准三个问题，结论只有三种：通过、有条件通过并写明补什么材料、不通过。
第四步定稿立项，三到五天，明确目标与验收指标、范围边界、里程碑、预算与人力、Top3风险及应对、决策人和项目经理。第五步启动会，一小时，向全体成员讲清目标、各自交付物、沟通节奏和变更流程。判断依据是：如果一份立项材料里找不到验收标准和变更流程这两项，流程就还没走完，别急着开工。
4. 立项通过后成员被抽走、需求又不断加，项目还要不要继续？
我最头疼的就是这个场景：项目批下来两个月，两个核心成员被别的紧急事项抽调走，业务方又塞进来三个新需求，工期一天都不能延。这种情况下到底是硬扛，还是重新走一遍立项流程，我一直想找个不那么靠感觉的判断标准。
先别硬扛，用「重立项触发线」来判断。建议预设三条线：一是核心交付人变动超过三分之一，或关键角色空缺超过两周；二是范围变更累计超过原工作量20%，或新增需求影响到原有里程碑；三是预算或工期偏差超过15%。
任意一条被触发，项目经理须在两个工作日内提交变更申请，重走一次简化评审，只评范围、资源、时间三件事，结论必须是「调范围、调资源、调时间」三选一，不能三项都不动。操作上，变更请求要写明新增了什么、为此放弃什么、对里程碑的影响，由业务方和直线经理共同确认；
同时预留约20%的资源缓冲给临时插入事项，超出缓冲一律走变更流程。判断依据是：所有利益相关方都想要「范围不变、人不加、时间不延」，这在算术上不成立，与其后期集体背锅，不如在触发线上就把取舍摊到桌面上。
文章包含AI辅助创作：项目立项如何做好项目申请？项目成员制度设计与操作步骤，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/283379
读者评论
FTE 承诺那节看着对，但真正难的是让直线经理签字。我们试过一轮，收回来的数字全是“0.2 FTE”这种谁都不用负责的模糊值，到了关键节点人还是被拉走。后来改成写进部门月度排班、固定每周几个半天，反而好使。另外四个模块里退出和调岗交接那段没展开，这块最缺能直接抄的模板。
三道门的思路认可，但十来个人的小团队，门与门之间可能只隔三四周，为走门单独准备一轮材料，评审成本快赶上项目本身。我更想确认的是，验证期指标没达标时组织真会终止吗？多数情况是继续给资源，只是把目标悄悄改小。图里那个 27% 的端到端成功率，是统计口径还是示意数据？
篇幅与质疑错配那张图，我的体感正好相反：评审人嘴上追问收益和资源，真正让他投反对票的常常是“跟另一个项目重复”，而这个在材料里最难自查，因为看不见别人的盘子。退出条件写不出来也不全是意识问题，很多组织一旦把它写进材料，项目停掉就要被追责，所以大家宁愿留白。