第3章 项目目标与范围定义

你是不是也见过这种项目——干了大半年，突然有人问"咱们当初要做啥来着？"

别笑，我遇到过。而且不止一次。

目标不清、范围乱飘，是ADMET项目翻车的头号元凶。这章咱们就聊透一件事：如何在项目启动的头两周，把目标和范围钉死。

下面这张图，是我做项目时反复用的框架。先有个全局印象，再往下拆。

3.1 为什么目标定义是项目的第一道坎

说句实话，ADMET项目失败，很少栽在算法上。大多数死在最开始——没人能说清楚到底要达成什么。

我记得有个项目，药化团队说要"预测准确率高一点"，计算团队理解成"把AUC从0.82提到0.83"，两边吵了三个月才发现说的不是同一回事。嗯，这种事儿在业内太常见了。

目标定义不清会引发三个连锁反应：

• 验收扯皮——做完了有人说"这不是我要的"
• 范围膨胀——今天加个属性，明天加个模型，永远做不完
• 资源浪费——一半的建模工作在项目后期被推翻重来

我个人习惯，在项目章程里只写三行：业务目标、技术目标、成功指标。三行不够？那说明还没想透。

3.2 目标定义：把"要什么"讲清楚

目标分两层。上面是业务目标，下面是技术目标。缺一不可。

业务目标面向的是项目资助方和药化团队。它回答：这个ADMET平台能帮公司省多少钱、快多少天。

举个例子：

• "将先导化合物优化阶段的ADMET筛选周期从6周缩短到3周"
• "将临床候选化合物的ADMET相关淘汰率降低30%"

技术目标才是咱们建模团队真正要扛的。它必须可量化、可验证。

我在项目中常用的技术目标模板长这样：

# ADMET 项目目标定义（YAML 示例）
project:
  name: "ADMET Prediction Platform v1.0"
  business_objectives:
    - "Reduce screening cycle by 40% (from 6 weeks to 3.5 weeks)"
    - "Decrease ADMET-related attrition by ≥25% at candidate stage"
  technical_objectives:
    - "AUC ≥ 0.85 for Caco-2, PAMPA, CYP inhibition, AMES, hERG"
    - "Single compound inference latency < 500 ms (GPU mode)"
    - "Model update cycle ≤ 2 weeks when new data arrives"

3.3 范围定义：学会说"不"

目标定了，接下来要画边界。说白了，就是什么做，什么不做。

ADMET项目最容易踩的坑是"顺便把XXX也预测一下吧"。今天加个皮肤渗透性，明天加个血浆蛋白结合率……

我曾经就被这么拖垮过一次。项目做了八个月，原本只做5个ADMET属性，结果扩展到了12个。最后核心模型反而没时间调优，上线效果一塌糊涂。

所以，范围定义必须写清楚"排除项"。建议用表格列出来：

类别	包含（In Scope）	排除（Out of Scope）
ADMET 属性	Caco-2, PAMPA, CYP 抑制, AMES, hERG	皮肤渗透性, 血浆蛋白结合, 组织分布
数据来源	内部筛选数据 + ChEMBL 公开数据	专利数据, 临床前动物数据
模型类型	分类模型 + 回归模型 (RF, XGBoost, GNN)	生成模型, 强化学习, 3D 结构模型
部署方式	REST API + 批量预测服务	移动端, 桌面端离线版本

为什么一定要写"排除项"？因为人对"得到"的贪婪远大于"失去"的恐惧。白纸黑字写下来，才能在需求变更时理直气壮地说"这个当初说好的不做"。

3.4 干系人对齐：让所有人上同一张图

目标和范围定义得再好，如果关键干系人没点头，那就是一张废纸。

我通常会把四类人拉进对齐会：药化负责人、计算化学负责人、项目管理、IT运维。每个人的关注点完全不同：

干系人	核心关注点	对齐策略
药物化学家	预测结果能不能信？反馈够不够快？	拿历史化合物做盲测，展示混淆矩阵
计算化学家	模型可解释性？特征工程是否合理？	展示SHAP值和数据分布报告
项目管理	进度能不能按期？资源够不够？	拆里程碑，每两周一个可演示版本
IT 运维	服务稳定性？资源消耗大不大？	做压测，明确QPS和GPU配额

对齐会开完，当场打印一份目标与范围定义文档，所有人签字。别走电子签，纸质签字是有仪式感的——签了，后面改就得掂量掂量。

3.5 验收标准：用数字说话

目标和范围都定了，最后一步是把"怎么做算完"写清楚。

验收标准要满足SMART原则。我直接给个检查清单：

维度	检查项	ADMET 示例
Specific（具体）	目标是否明确到属性级别？	"Caco-2 预测 AUC ≥ 0.85"
Measurable（可测）	验证数据和方法是否已定？	留出 20% 内部数据做独立测试集
Achievable（可达）	当前数据量和计算资源是否支撑？	已有 2000+ 化合物标注数据
Relevant（相关）	指标是否对齐业务痛点？	缩短先导化合物优化周期
Time-bound（时限）	验收节点是否明确？	第 6 周末交付 v1.0 模型

验收标准写好后，嵌入项目计划的第一周里程碑。先花两天把这件事做扎实，后面所有的建模、测试、部署才有据可依。

3.6 避坑指南：我踩过的三个坑

最后，分享三个我亲身踩过的坑。你能绕开，就算这章没白写。

坑一：把"目标"写成"愿望"

比如"构建业界领先的ADMET平台"。这种话放PPT里没问题，但放进项目章程就是灾难。什么叫"领先"？谁说了算？

坑二：范围定义只写"包含"，不写"排除"

我吃过这个亏。项目做着做着，药化团队说"既然你们能做Caco-2，那LogD顺便也做了吧"。你想想看，数据格式、模型架构全都不一样，这一"顺便"就是两个月。

坑三：对齐会只拉技术负责人，不拉IT运维

等到部署阶段才发现服务器内存不够、GPU配额早被别的项目占满了。这时候再改架构？成本高得离谱。