“什么时候可以完成上线签字确认？什么时候可以发起验收？要有目标，不能过一周算一周。请项目组重新梳理计划和任务安排，下周内部做一次汇报。”
这是领导在我提交周报后给出的回复。
看到这段话时，我的第一反应并不是豁然开朗，而是委屈。
过去半年，我几乎一个人在完善这套放疗信息管理系统。需求要分析，功能要设计，问题要排查，代码要修改，现场要沟通，用户提出的新想法也需要继续评估。系统每天都在变化，问题也确实在一个个被处理。
从个人产出来看，我并不认为自己在偷懒。
甚至恰恰相反，我一直觉得自己已经足够努力。
但冷静下来以后，我不得不承认：领导的问题虽然让我不舒服，却准确地指出了一个我长期没有正视的问题。
我完成了很多事情，却没有真正把项目带向“完成”。
一、我为什么一直认为项目在推进
在很长一段时间里，我判断项目进展的方式非常直接：
今天解决了几个问题；
这周完成了几个功能；
用户提出的需求有没有响应；
系统是不是比上周更完整；
遗留问题是不是在不断减少。
按照这套标准，项目当然一直在推进。
因为我每天都很忙，也几乎每天都有具体产出。
一个页面做完了，一个接口接通了，一个流程跑通了，一个异常场景补上了，一项用户反馈处理了。每完成一件事情，我都会觉得项目又向前走了一步。
但后来我才意识到，我在不知不觉中，把几件完全不同的事情混在了一起：
个人很忙，不等于关键路径正在推进。
功能越来越多，不等于上线条件越来越成熟。
问题不断被关闭，不等于项目范围正在收敛。
系统变得更完整，不等于项目已经可以验收。我一直在用“工作量”衡量“项目进展”，用“功能产出”代替“交付结果”。
这两者看起来很接近，实际上不是一回事。
工作量描述的是我做了多少事情。
项目进展描述的是，距离既定目标还有多远。
如果目标本身不清晰，或者没有被拆解成可以验证的里程碑，那么做得越多，反而越容易产生一种错觉：
只要我继续解决问题，项目早晚会自然完成。
但项目通常不会自然完成。
项目需要被主动收口。
二、一个人扛项目时，努力为什么会变成失控的助推器
“越努力，项目反而越容易失控”，听起来有些反常识。
努力本身当然没有错。
真正的问题在于，当一个人同时承担多个角色，又缺少明确边界时，努力会优先流向那些最容易被看见、最容易获得即时反馈的事情，而不是决定项目能否完成的事情。
1. 人会本能地优先处理“可以立刻解决”的问题
一个明确的页面问题、一个可以复现的程序错误、一个字段展示异常，通常都有清晰的处理路径。
它们会给人一种很直接的反馈：
发现问题，分析原因，修改代码，验证结果，关闭事项。
这种工作是确定的，也是令人安心的。
相比之下，真正影响项目能否上线的问题，往往没有这么清晰：
业务口径还没有最终确认；
医院侧负责人没有完成签字；
第三方厂商的接口时间无法确定；
上线范围仍然在变化；
验收标准没有达成一致；
测试责任和上线责任没有完全明确；
某些历史数据该不该迁移，还没有人作出决定。
这些事情很难通过“再努力几个小时”解决。
它们需要沟通、协调、决策，需要其他角色参与，也可能需要领导介入。
当项目只有一个主要执行者时，很容易出现一种情况：
难以推动的问题被暂时放在一边，能够自己处理的问题则不断被捡起来。
于是每天都非常忙，任务列表也在不断减少，但真正的阻塞项没有移动。
局部一直在优化，整体却没有形成突破。
2. 对系统质量负责，逐渐变成了无限扩张范围
我一直希望把系统做好。
这原本没有问题。
医疗软件本身就需要慎重，放疗信息系统又涉及复杂流程、角色权限、数据准确性和临床使用习惯。很多问题如果早期不处理，后续确实可能带来更高的修改成本。
但“把系统做好”有一个很危险的地方：
如果没有明确边界，“做好”就永远没有终点。
一个页面可以再优化一次。
一个交互可以再顺手一点。
一个异常场景可以再补充一层保护。
一个暂时不影响使用的问题，也可以为了完整性提前解决。
很多决定单独看都是合理的。
问题在于，当这些“合理的小优化”不断叠加，项目范围就会悄悄发生变化。
原本的目标可能只是让核心流程跑通，后来变成所有流程都要完整；原本只是完成上线准备，后来又希望顺便解决历史遗留问题；原本是满足当前使用，后来开始提前考虑未来可能出现的需求。
我没有正式宣布项目范围扩大了。
但我每天的选择，实际上一直在扩大范围。
3. 一个人承担多个角色，内部就很难形成制衡
在这个项目中，我承担的并不只是一个单一角色。
很多时候，我既要理解现场需求，又要判断产品方案；既要推进开发，又要验证结果；既要关注系统质量，又要对项目进度负责。
这种模式最大的风险，不只是工作量大，而是缺少制衡。
当提出方案的人、执行方案的人、判断方案是否足够好的人，都是同一个人时，就很少有人持续追问：
这个功能是不是本次上线必须完成的？
这个问题究竟是不是上线阻断项？
现在继续优化它，是否会影响更重要的里程碑？
这个决定是不是应该由业务负责人确认？
这个风险为什么一直由执行者自己承担？
如果暂时不做，会产生什么实际后果？
很多时候，我会默认：
既然我已经看见这个问题，那我就应该把它处理掉。
但看见问题，不代表必须在当前阶段解决问题。
能够解决问题，也不代表应该由自己解决所有问题。
一个人扛项目时，最容易模糊的不是技术边界，而是责任边界。
4. 计划慢慢退化成了待办事项清单
我也有计划，也有周报，也会记录问题和任务。
但现在回头看，那些内容更像一份不断更新的待办事项清单，而不是真正意义上的项目计划。
待办清单回答的是：
还有哪些事情没有做？
项目计划应该回答的是：
项目要在什么时候达到什么状态？
哪些任务决定这个目标能否实现？
当前差距是什么？
谁需要在什么时间之前作出什么决定？
如果某个条件无法满足，项目要如何降级或调整？
当计划只有任务，没有目标日期、依赖关系、责任人和完成标准时，它只能证明大家在工作，却不能证明项目会按时结束。
这也是为什么领导会说：
不能过一周算一周。
从我的视角看，每一周都有实际产出。
但从管理视角看，如果每周都只汇报“做了什么”，却无法回答“离上线还有多远”，那么项目确实是在过一周算一周。
三、人员不足是事实，但它不是全部答案
这个项目资源不足，也是客观事实。
当一个人同时承担大量工作时，产能一定存在上限。项目管理并不是魔法，不可能通过一张更漂亮的计划表，凭空补足缺少的人力。
所以我并不认同一种过度简单的说法：
项目延期，全部都是因为项目管理做得不好。
很多延期，本质上就是资源、范围和时间之间无法同时满足。
但是，资源不足也不能自动解释所有问题。
后来我逐渐意识到，作为承担项目推进责任的人，我需要做的并不是用个人加班，把所有资源缺口悄悄吞掉。
真正需要做的是：
把当前资源能完成的范围说清楚；
把无法按时完成的事项提前暴露；
把关键依赖转换成明确的责任和时间要求；
把需要取舍的问题提交给有权决策的人；
让项目相关方理解，不增加资源、不缩小范围，就必须接受时间变化。
以前遇到资源缺口时，我更习惯先自己多做一点。
多分析一点，多写一点，多测试一点，多承担一点。
短期来看，这种方式能够维持项目继续向前。
但长期来看，它会掩盖真实问题。
因为当一个人持续用额外投入填补资源缺口时，外部看到的不是“项目资源不足”，而是“项目似乎还能继续推进”。
直到个人投入无法继续覆盖缺口，所有积累的问题才会同时暴露出来。
所以，项目管理的价值并不是让一个人变得更能扛。
而是让那些不应该由一个人承担的问题，被及时看见，被讨论，被决策。
四、我后来才重新理解“项目完成”意味着什么
过去，我对“完成”的理解更接近：
系统功能基本完善，用户提出的问题得到处理，整体使用体验达到一个比较满意的状态。
这个定义听起来没有问题，但它缺少可验证的边界。
“基本完善”到底是什么程度？
“问题得到处理”是否包括所有优化项？
“用户满意”由谁确认？
什么情况下，即使还有遗留问题，也可以进入上线和验收？
如果这些问题没有答案，“完成”就只是一个主观感受。
后来我开始重新定义项目完成：
项目完成，不是所有事情都做完，而是在明确范围内，系统满足上线条件，关键角色完成确认，已知风险具备处置方案，并能够进入签字和验收流程。
对于一套信息管理系统来说，真正的完成至少应该包括：
核心业务流程已经跑通；
上线阻断问题已经关闭；
非阻断问题有明确的后续计划；
关键用户完成测试和确认；
权限、日志、数据和异常处理经过验证；
上线时间、参与人员和责任分工已经明确；
数据备份、回滚和应急方案已经准备；
上线后的观察期和问题响应机制已经确定；
签字材料和验收条件已经具备。
在这个定义下，项目不需要等到“再也找不到问题”才算完成。
因为任何长期使用的软件，都不可能在上线前解决未来的所有问题。
真正需要做到的，是把问题分成三类：
必须在上线前解决的问题；
可以通过临时方案控制的问题；
可以进入后续版本持续优化的问题。如果不能区分这三类问题，所有问题都会看起来同样重要，项目也就永远无法收口。
五、我真正做错的，不是努力，而是没有为努力建立边界
这次复盘以后，我并没有得出“以后不要那么认真”或者“系统差不多能用就行”这样的结论。
医疗软件需要认真，复杂项目也确实需要投入。
我真正需要修正的是：
努力必须服务于一个明确目标，并且受到边界约束。
至少需要建立四种边界。
范围边界
本次上线到底包含哪些内容？
哪些需求不进入当前版本？
新增需求通过什么机制评估，而不是提出以后就自动进入开发范围？
质量边界
达到什么条件可以上线？
哪些问题属于安全、数据和核心流程问题，必须解决？
哪些属于体验优化，可以在风险可控的情况下后续处理？
角色边界
哪些事情可以由FDE自行判断？
哪些业务口径必须由医院确认？
哪些产品取舍必须由产品负责人决定？
哪些资源冲突需要管理者介入？
时间边界
某个问题最多研究到什么时候？
某项依赖最晚何时必须得到答复？
到达什么日期后，如果条件仍未满足，就必须调整范围或计划？
没有这些边界，努力就很容易变成无止境的投入。
边界并不是降低质量。
边界是让有限的资源，优先流向最重要的结果。
六、如果重新开始，我会怎么做
如果现在让我重新推进这个项目，我不会先从一张巨大的功能清单开始。
我会先从最终结果倒推。
1. 先定义“这次上线”究竟是什么
在项目开始或重新梳理时，首先明确：
上线对象是谁；
覆盖哪些业务流程；
本次不包含什么；
怎样判断上线成功；
谁负责最终确认；
达到什么条件可以签字；
什么时间可以发起验收。
如果终点没有定义，所有计划都只是暂时安排。
2. 把任务按照与上线目标的关系分级
我会把事项划分为：
P0：不解决就不能上线
P1：应当解决，但存在可控替代方案
P2：优化项，进入后续版本
这里的优先级，不是判断一件事情有没有价值。
而是判断它与当前交付目标之间的关系。
很多有价值的功能，并不一定要在这一次上线前完成。
3. 把“未知”和“等待”当成正式任务管理
过去的计划更容易记录开发事项，却容易忽略：
待业务确认；
待医院决策；
待第三方反馈；
待环境准备；
待用户测试；
待管理层协调。
但这些事项往往比开发任务更能决定项目时间。
所以它们不能只是写在备注里。
每一个外部依赖都应该有：
责任人；
发起时间；
期望完成时间；
最晚决策时间；
超期后的影响；
必要时的升级路径。
4. 用里程碑管理项目，而不是用任务数量证明进展
项目计划应该围绕一组明确状态展开：
需求范围确认
→ 上线阻断项开发完成
→ 内部测试完成
→ 医院用户测试完成
→ 上线准备评审
→ 正式上线
→ 运行观察
→ 签字确认
→ 发起验收每个里程碑都需要有明确的进入条件和完成条件。
这样周报讨论的重点就不再是“本周完成了多少事项”，而是：
当前处于哪个里程碑？
离下一个里程碑还差什么？
哪个问题正在阻塞？
需要谁作出决定？
5. 主动接受“受控的不完美”
项目上线不是软件生命的终点，而是进入真实使用阶段的开始。
只要核心流程安全、数据可靠、风险可控，就应该允许一部分非关键问题进入后续版本。
追求完美本身并不可怕。
可怕的是，在没有明确定义“什么必须完美”的情况下，对所有细节投入同样的精力。
6. 让周报表达承诺、差距和风险
以后再写周报，我希望它不仅记录完成事项，还能够清楚回答：
当前目标是什么；
本周计划达到什么状态；
实际达到什么状态；
产生了什么偏差；
偏差会影响哪个里程碑；
当前需要什么资源或决策；
按照现状，预计何时可以上线、签字和验收。
周报不是工作流水账。
它应该是项目相关方共同判断形势的工具。
七、我对FDE这个角色，也有了新的理解
以前我更容易把FDE理解成一个解决问题的人。
现场有问题，就去分析。
需求不清楚，就去澄清。
产品方案不完整，就去补充。
开发资源不足，就自己承担一部分。
项目缺少推进，就继续往前顶。
这种角色确实能够解决很多现实问题，也可能是FDE存在的重要价值。
但现在我开始意识到，FDE的价值不应该只是“哪里缺人就补到哪里”。
一个成熟的FDE，不仅要能够处理具体问题，还要识别：
当前真正影响结果的矛盾是什么；
哪些问题应该自己解决；
哪些问题需要推动他人解决；
哪些问题必须升级为管理决策；
哪些需求值得做；
哪些需求此时不应该做；
什么时候应该继续深入；
什么时候应该停止优化，推动项目进入下一阶段。
能够解决问题很重要。
能够判断什么问题现在最值得解决，同样重要。
能够承担责任很重要。
能够让责任回到正确的人身上，也同样重要。
八、写在最后：我为什么开始记录这些事情
这次经历并没有让我否定努力的意义。
它只是让我开始重新理解，努力究竟应该放在哪里。
过去，我更关注的是把手上的事情做好。
现在，我开始要求自己同时回答另外几个问题：
项目的目标是什么？
当前的边界在哪里？
真正的关键路径是什么？
哪些事情不应该由我独自承担？
什么时候应该停止继续优化？
怎样才能让项目真正进入下一个阶段？
我开始写这个博客，也不是因为我已经找到了这些问题的标准答案。
恰恰相反，是因为我发现，很多真正有价值的经验，往往不会被正式记录下来。
周报记录我完成了什么。
需求文档记录系统应该做成什么。
测试报告记录哪些功能通过了验证。
验收材料记录项目最终交付了什么。
但很少有地方会记录：
一个错误判断最初是如何形成的；
我为什么在当时认为自己是对的；
现场又是如何一点点推翻这个判断的；
最后，我对同一件事情产生了怎样不同的理解。
所以，我想把这些过程留下来。
这里不会是一份成功经验合集，也不会试图给出所有问题的标准答案。
它更像是一名FDE在真实项目现场留下的认知修正记录。
有些结论以后可能还会被我自己推翻。
但至少在今天，我终于开始明白：
一个人扛项目时，真正需要警惕的，不是不够努力，而是努力没有目标、没有边界，也没有把项目带向可以被确认的完成。