项目资料改到第 8 版时，通常会出现一种非常微妙的气氛。
文件名已经从“最终版”进化成“最终版_真的最终版_请以此版为准_0914”，群里每个人说话都格外客气：“辛苦再微调一下。”翻译过来就是：麻烦把我们前面没想清楚的事情，靠你今晚的 Word 文档想清楚。
这时，写资料的人很容易怀疑人生：是不是我逻辑不行？是不是表达不够专业？是不是标题字号还不够有诚意？
先别急着和字体较劲。
很多新项目的资料反复返工，根本不是文档写得差。文档只是项目里最诚实的那面镜子：谁没想清楚，它就照出谁；哪件事没人拍板，它就把哪件事卡在批注里。你以为大家在改方案，实际上大家在借方案开会。
更准确地说，返工通常有两条根：需求不清，以及 决策未定。前者让团队不知道“到底该做什么”，后者让团队不知道“既然有分歧，到底谁来定”。两件事凑在一起，资料就很容易成为项目的临时垃圾桶：市场的期待、医生的建议、研发的方案、质量的担心、老板的灵感，统统往里塞。
最后，资料越厚，项目越虚。
资料不断修改时，先回到需求和决策本身。
不是市场需求不清，而是“市场”这个词太好用了
立项会上最常听到的一句话是：“市场有需求。”
这句话和“天气不错”“大家都很努力”一样，很难反驳，也很难执行。
市场到底是谁？是医院采购，还是临床使用者？是科室主任，还是每天和设备较劲的一线人员？他们在哪个场景里觉得难受？现在用什么办法凑合？愿意为什么价值付出成本、改变习惯，或者承担切换风险？这些问题没有答案，“市场有需求”就只是一个穿着西装的模糊愿望。
于是资料刚写到产品定位，市场同事会说：“我们要做差异化。”研发同事会问：“差异化到什么程度？”质量同事会追问：“为了这个差异化，要新增哪些风险控制？”到了这里，所有人忽然发现：原来“差异化”没有长度、没有宽度，也没有使用说明。
于是，第一轮改资料开始了。
真正麻烦的不是需求还不够完整——新项目在早期本来就不可能全知全能。麻烦的是，团队把“尚待验证的假设”写成了“已经明确的需求”。
一句更诚实的写法是：我们判断某类用户在某个场景存在某种问题，目前有哪些证据支持，哪些问题还需要进一步听取 VOC。这样写，可能没有“市场巨大、前景广阔”来得热闹，却能让后续讨论有地方落脚。
几位医生说“不错”，不等于临床价值已经成立
临床意见当然重要。问题在于，临床意见有时会被项目团队用得像一句万能咒语：“医生都说好。”
医生说好，究竟是觉得操作更省事、诊断信息更有用、流程更顺，还是觉得这个功能“听起来挺先进”？不同回答，指向的是完全不同的产品需求。
更现实一点说，任何一两位、几位医生的意见，都可能非常专业，也可能非常宝贵；但它们首先是重要线索，而不是自动盖章的产品定义。一个临床场景里，往往不只有“提出意见的人”。使用者、配合者、采购者、维护者，甚至被流程影响却没有发言权的人，都可能改变产品真正的价值判断。
如果临床价值的输入只来自少数熟悉的专家，项目很容易得到一种令人愉快的错觉：需求很清楚，大家也很认可，明天就能开干。
然后，一进入更广泛的场景，问题就冒出来了：原来目标用户在意的不是这个功能；原来工作流根本放不下这个步骤；原来对方觉得“能用”与“值得换掉现有方案”之间，还隔着一整片海。
资料改到第 5 版，团队往往开始互相询问：“当时不是问过医生吗？”
问过，和问全，确实不是一回事。
最危险的需求，往往长得很像技术方案
当市场说不清、临床输入又零散时，项目不会停在那里等答案。项目很忙，它会自己长出一个答案。
这个答案通常由最积极、最懂实现的人提供——技术人员。
这不是说研发爱“自嗨”。恰恰相反，研发在不确定里必须做选择：器件怎么选、算法怎么走、结构怎么取舍、软件如何架构。问题是，当外部需求没有被说清时，技术可行性很容易悄悄升级为产品必要性。
“这个功能我们能做”，慢慢变成“这个功能用户一定需要”；“这个指标做得出来”，慢慢变成“这个指标肯定更有竞争力”；“这个方案很漂亮”，慢慢变成“这个方案必须写进需求”。
这不是某个人的错，而是空白处总会有人填。只不过，技术人员填进去的，往往是一个合理、先进、甚至很优雅的技术答案；而真实、全面的 VOC 需要回答的，是另一个问题：用户是否真的在意，它解决的是否是高频且高痛的问题，以及用户愿意为此付出什么。
如果这两件事没有分开，资料就会出现一种经典场面：研发写得越来越具体，市场和临床反馈却越来越抽象。前者在谈“怎么做”，后者还在问“为什么做”。两边都很努力，只是站在不同楼层喊话。
决策未定，资料就会被迫兼职当裁判
需求不清会让资料不知道往哪儿写；决策未定，则会让资料每次写完都要重新投票。
比如，目标用户到底先抓哪一类？产品先解决核心流程，还是先堆出一串看上去很厉害的功能？成本、上市节奏、性能指标发生冲突时，优先级谁说了算？
这些问题如果没有明确结论，评审时就会变成批注：“建议加强”“是否考虑”“能不能兼顾一下”。每一条都像很温柔，合起来却是一锅不负责的需求火锅。
资料作者最怕的不是意见多，而是意见没有身份。谁是信息提供者，谁是评审者，谁是决策者，谁只是提出风险？如果没有区分，所有意见看起来都像“必须修改”，所有修改又都会在下轮被另一组意见推翻。
于是，版本从 V3 到 V8，项目并没有获得 5 次进化，只获得了 5 次集体回忆。
少开一场“改改改”会，从两张账本开始
想减少无效返工，不必一上来就发明 47 页流程。很多团队先把两张小账本做扎实，已经能省下大量“请再优化一下”。
第一张：需求证据表
它不负责把需求写得漂亮，只负责把需求问得明白。每一项需求至少写清四件事：
谁在什么场景遇到什么问题？不写“用户需要更便捷”，而是写清角色、任务和阻碍。
证据来自哪里？是市场信息、临床观察、访谈、使用反馈，还是尚待验证的假设？
这个问题为什么重要？它影响效率、结果、风险、成本，还是只是“看起来不错”？
如果暂时不做，会怎样？这能帮助团队区分核心需求、机会项和技术小爱好。
它的价值不在于让每个人都满意，而在于让每个人都知道：哪些是已确认的输入，哪些只是值得继续验证的猜测。猜测不可怕，假装它不是猜测才可怕。
需求证据表：把判断、证据和待验证问题分开记录。
第二张：决策账本
每一个会影响资料、方案或资源投入的关键问题，都只记四行：议题是什么、结论是什么、谁来定、依据是什么。
例如：“首期目标用户是否聚焦某类科室？”“当前结论：聚焦；决策人：项目负责人；依据：现有需求证据与资源约束；复核条件：新增 VOC 出现明显相反信号。”
这样做有一点像给项目装了行车记录仪。它不能保证你永远不走错路，但至少能让团队知道，这个弯是谁在什么信息下决定转的。以后需要调整，也可以基于新证据改，而不是靠“我记得当时好像说过”。
决策账本：以后要改，也能知道为什么改。
不是所有修改都该被消灭
这里还要替“修改”说一句公道话。
新证据出现了，真实风险暴露了，法规要求变化了，或者用户反馈推翻了原先假设，资料当然应该改。这样的修改不是返工，是项目终于学到了东西。真正该警惕的，是那些早就在项目里、却一直没人说清、没人记录、没人决断的问题，拖到文件发出去以后才集体爆炸。
所以，下一次再看到“最终版_真的最终版”时，别急着先给文件换个更谦虚的名字。
先问四个问题：这条需求来自真实、足够全面的 VOC 吗？它解决的是谁在什么场景里的什么问题？这件事究竟有没有结论？结论是谁、基于什么作出的？
这四个问题没有答案，资料改到第 18 版也只是排版越来越熟练。答案一旦清楚，文档未必一稿过，但至少不会再替整个项目背锅。