排期排完我就知道,这版本到上线那天根本做不完——一个 AI 医疗产品的破局复盘

0 评论 137 浏览 0 收藏 15 分钟

AI医疗产品的合规红线与资源边界如何平衡?本文通过一个诊后纪要生成器的实战案例,深度拆解当范围、进度、资源三条边同时锁死时的突围策略。从法务合规的硬约束到AI准确率的软瓶颈,作者揭示了如何用『降级阶梯』实现有计划的战略收缩,以及为什么『会认输』比硬撑更能挽救项目。

立项那一周,我被两堵墙夹在中间。

一堵是法务的。

我做的是一个 AI 诊后纪要生成器,给陪诊师和健康管理师用。患者看完病,那一堆乱七八糟的素材——化验单照片、医生口头叮嘱的录音、陪诊师手机里记的几行字,一次性丢进去,AI 整理成一份结构清楚的纪要。

这东西我拆成两层:分析层和建议层。分析层负责把来源材料里已有的信息抽出来、归类、标好出处,这层我们做出来了,跑通了。我真正想做的是建议层,AI 不光整理,还能像个健康助手那样给患者出建议:复诊注意什么、饮食怎么调、这个指标高了意味着什么。我一直觉得,这才是产品的灵魂。

法务一句话把我摁住了:AI 生成健康建议,不合规。我试着争辩,可两个理由都把我堵死了。一个是资质:给患者出健康建议本质上是医疗行为,得有执业医师资格证,模型再聪明也没这张证。另一个更要命,是担责。患者照着 AI 做,万一出事,谁负责?产品经理?算法?还是公司?这条责任链是断的,找不到那个能签字的人。

我脑子宕机了。是啊——谁来负这个责任呢?

争来争去,我还是得认:建议层,这个我最想做的东西,得砍。

第二堵墙是排期。

把建议层砍掉之后,剩下能做的功能按优先级排了一遍,结合组里所有人的时间和当下的资源,我算出一个让人心里发凉的数:就算每个需求都用最理想的方式实现,到上线那天,也做不完。

不是“差不多能赶上”,是“再顺也赶不上”。而这些是 P0、P1,不做产品根本没法用。

两堵墙,撞在同一周。这篇就讲,我怎么从这个“必死局”里把项目捞回来。先撂结论:我没加班,也没加人。说出来甚至有点怂——我提前想好了,这仗万一打不赢,该按什么顺序认输。

先搞清楚,你到底被什么困住了

人一慌就爱瞎使劲。我强迫自己先停下来,回到那张最老的图,项目管理的铁三角:范围、进度、成本三条边,拉动任何一条,另外两条就得跟着动,否则牺牲的是正中间的质量。又要马儿跑又要马儿不吃草,这图里不存在。

我一开始还犯过个常见错:把“风险”当成铁三角的第四条腿。后来才想明白,风险不是一条边。范围、进度、成本是你主动权衡的约束;风险是从外面威胁这三者的不确定性,比如需求变更、人跑了、技术踩坑。它不在腿上,在整个结构外面。(现在 PMBOK 把三重约束扩成了六大约束,多了质量、资源、风险,但思想一样:一堆互相竞争的约束,牵一发动全身。)

把我的项目往图上一套,卡在哪一目了然:范围被法务钉死,进度被上线日钉死,资源就 5 个人、还都 50% 投入、满打满算 2.5 个人。三条边,全锁死。

这事我前前后后想了挺久,才算想明白一件事,也是这篇我最想分享的:当范围、进度、资源同时锁死,项目在数学上就是不成立的。这种局面下,“再努力一点就能做到”是幻觉。你只剩两个结局,要么有意识地松掉一个约束,要么不知不觉牺牲质量、或者到点砸掉交付日。

产品经理最该干的,不是默默扛着硬上。你得把这个“不可能”摆上台面,逼出一个有意识的取舍。

而我能在排期阶段就算出来,其实是好事。最怕的是上线那天才发现做不完。

那么多需求都标 P0,到底听谁的

回头看,法务那一刀虽疼,却帮我把范围想透了。被砍前我脑子里的范围是贪心的、模糊的;被砍后边界反而清晰:建议层是越界,移到 V2;分析层只搬运来源里已有的信息、一个字不新增,是安全区。于是 V1 收缩成一个“内部辅助工具”,AI 出待审核稿,人工复核,不直接交付患者。

这就是一次范围的“再切分”:不硬扛着全做,主动松掉范围这条边。但怎么切有讲究,我想明白两件事。

  1. P0 的判据是“必要性”,不是“价值高”。 每个人都爱把需求标成 P0,老板想要的、ROI 高的全是 P0,结果 P0 疯狂膨胀,等于没排。真正的门槛是一句话:不做它,产品是不是就不可用?或者它是不是合规、安全、依赖上的硬前提?过了才是 P0。高价值但不影响“能不能用”的,归 P1。
  2. 一个 P0 还能再拆成“核心”和“增强”。 我的纪要有 9 大模块,一开始我觉得 9 个都缺一不可。但按“不做就不可用”去卡:诊断、用药、复诊加上来源出处是真核心;“把术语翻成大白话”严格讲是锦上添花。

这里有个特实用的概念,叫 happy path:一切正常、不出错时,功能从头跑到尾那条最顺的主路径。功能真正费工的地方,常常不是 happy path,而是外面那圈“出错了怎么办”。所以赶期有个很狠的打法:第一版只做 happy path,先让“一切正常时能用”落地,异常兜底、边界、打磨全往后挪。

能用,先于好用。

判断一块该留核心还是后置,我常问三句:去掉它,主流程还能不能端到端跑通?能不能先用人工兜底?它是“能用”还是“好用”?

最典型的是音频输入。医生口头叮嘱要走语音转写,这条线技术上最不确定(识别医学术语容易错),合规风险也最大(原始录音带着隐私上云)。但它有个天然兜底:陪诊师本来就在现场听录音,大不了人工听一遍打出来。所以音频自动转写,对我来说就是个能随时降级、又不太伤可用性的功能。

唯一不能拆、不能降的,是那条红线:不编造、不新增来源外内容、AI 标识必须留、关键医疗字段标红了非医生不能跳过。这是合规的地板,砍什么都不能砍它。

AI 产品,该用瀑布还是敏捷

范围理清,下个问题是节奏。我第一反应是瀑布:想清楚再一口气做完,听着稳。但瀑布在 AI 产品这儿,有个致命的水土不服。

瀑布假设需求能前期想清、效果能前期设计出来。传统软件确实如此,一个功能能不能实现基本是确定的,无非工作量大小。AI 不一样:AI 功能“能不能达到可用效果”本身就是未知数。我的纪要准确率能不能到 75%?口头建议抽得准不准?这些都是试出来的,不是设计出来的。你不真训一遍、调一遍、测一遍,没人敢拍胸脯。

所以 AI 产品天然该敏捷,该小步快跑。

但纯敏捷也有坑。我把所有工作分成了两类。

研究型:准确率能不能达标、语音转写选哪家、置信度算法怎么调,连“能不能成”都不知道。这类千万别塞进承诺式排期,你没法承诺“第三版准确率一定到 90%”。它该用时间盒,给两周,到点开个 go/no-go,行就继续,不行就换方案。

工程型:任务卡、上传、标红交互、PDF、权限、归档。这些活儿心里有谱、有明确验收标准,就是标准的敏捷开发,正常估点、正常排期。

很多 AI 团队的痛苦,就来自把研究当工程排:逼算法工程师承诺一个研究突破在第几周完成,然后看着它一延再延。我让两条轨并行:工程轨先搭一个能插拔模型的骨架,研究轨在骨架上反复试模型、调 prompt,两条轨在几个 go/no-go 闸门上同步。这套叫双轨敏捷,但名字不重要,重要的是分清楚:哪些事能承诺,哪些只能给个时间盒去试。

给自己准备一张“认输的顺序”

终于到那一周我真正做的、也最值钱的一件事。

面对一个数学上做不完的项目,多数人的本能是想办法做到:加班,加人,打鸡血。我偏偏反着来——提前想好,万一到点真做不完,该按什么顺序,有计划地认输。我管它叫“降级阶梯”。

为什么需要它?我把关键路径捋了一遍,真正决定生死的是 AI 准确率这条研究型的线,而它特别脆:调优窗口只有三周左右,还加不了人(调 prompt 没法五个人并行);给模型打分的评测集本身也在关键路径上,还得占医生时间标注;2.5 个人的投入,少谁半天产能就掉一块,全程没缓冲。准确率达不达标,到节点才见分晓,而我几乎没有回旋的余地。

那与其到时候手忙脚乱地乱砍,不如现在就排好该砍的顺序,从最不疼的砍起,红线压在最底下,一格都不能碰:

你看这张表会发现个规律:前面好几档,本质上是同一件事,收范围,把准确率喂饱。

这是 AI 产品和传统软件最不一样的地方。传统软件想达标,是加功能、修 bug;AI 产品想让准确率达标,很多时候反而是做减法。模型在全部 9 个模块、全部科室上只能做到 70%,你把范围缩到 4 个模块、3 个科室、两种输入,它就能干到 80%。你没把准确率整体调低,只是把摊子收小,让它在小范围里够得着。

还有个细节:砍之前先诊断。别一刀切,先看是哪个模块、哪个科室、哪种素材在拖均值,再精准砍那几片。评测集本来就分了维度,正好告诉我从哪下刀。

但整张表里最重要的一句是:这张降级阶梯,得在立项前就和老板、法务一起敲定。不是等节点真出事了再现场恐慌谈判,而是提前把“如果到 X 时准确率只有 Y、就执行第几档”白纸黑字定下来。到点了,执行一个早就商量好的预案,而不是现场制造一个措手不及的意外。

(同一个逻辑,那一周我还顺手做了三件事:给排期硬加了一段时间缓冲,把最不确定的语音和 OCR 验证提到最前面,把评测集和医生标注单拎成一条有预算的轨。都是为了让风险早点见光,留好退路。)

写在最后

现在回看法务那一刀,说实话,我从一开始的不服,慢慢变成了感谢。它砍掉的是我最想做的建议层,却逼我在最早就把两件事想清楚了:这个产品的边界在哪,出了事责任算谁的。一个连“谁来担责”都没想明白的 AI 医疗产品,就算硬做出来,也是个定时炸弹。

这趟下来我最想说的就一句:面对一个做不完的项目,会“有顺序地认输”,比硬撑着更值钱。把“到点上一个收窄版”变成立项第一周就拍好的预案,别让它成了上线前一周的事故。

最后留个问题给你:你有没有遇到过那种排期排完、心里咯噔一下就知道做不完的项目?后来你是怎么破的,砍范围、推期,还是硬扛过去了?评论区聊聊。

本文由 @Niney 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!