怎么当一个LSP（SPL），然后怎么当一个好的LSP，这是我今天要分享的一些东西，仅仅从我自己的角度讲讲感想，后续有其他需要注意的地方还会继续更新。

当你有几年经验，去面试的时候，面试官99%会问你的一个问题就是“带过项目吗？”。可见带过项目对于SP来说有着举足轻重的作用。

如果你只是项目里的一个组员，写完数据集，输出TFL可能就差不多了，但是LSP要考虑和检查的东西就多的多了，并且对最终交付的成果负责。

1：项目统筹阶段

作为一个LSP，当你拿到一个项目的时候，就得进行各样的准备了，首先查看合同，是不是注册项目（非注册可能是另一套流程）；了解项目需要做什么，比如aCRF;SDTM;SDTM define.xml;SDRG;ADaM ADaM define.xml;ADRG;TFL这些是不是都要。

接着你得熟悉方案，至少要了解这个项目是什么类型的，主要终点、次要终点，试验设计是什么，试验流程是什么，涉及到什么统计方法，这些都是要清楚的最基本的东西。

至于什么时候要开始项目，因为我还没做到特别高的位置，大多数时候还是LM来通知安排，开始项目不一定要等SAP和shell完成，CRF定稿之后，就可以着手开始项目了。（这里有不完善的地方欢迎指正）

然后就是给组员分配工时和任务，如果公司要求预先估计员工在某个项目可能花费多少工时，LSP要有一个大概（也有可能有一个标准，比如规定写完一个aCRF、SDTM domain需要花费多少工时）；给组员分配任务，从我自己的考虑的话，拖沓的人就不会分配给他试验设计和DM,SE,SV这些domain；没有写过某些domain的组员，会考虑每次都分配不一样的数据集给他写，而不是每个项目就让他写某几个domain。

任务安排完毕后，设置好项目环境，也就是我们通常说的的setup（里面包含各种逻辑库、还有项目信息等）,最好开一个kick off meeting，跟组员讲一下任务安排是什么，需要注意什么；timeline是什么。

说到timeline，我觉得项目第一重要的是质量，第二个就是timeline的完成度了，其实换句话说也就是效率。当制定了timeline之后，组员严格按照这个timeline执行（所以LSP在制定timeline的时候，要考虑组员还有没有其他项目，工作强度，有没有请假，甚至一些突发情况）。

如果大家对timeline没有严格的执行意识的话，这个项目没有在规定的时间完成，很有可能就会影响到其他项目的执行，然后多个项目拖延导致冲撞到一起，后果比较麻烦，直接的结果就是导致组员加班，进而影响工作幸福度。

2：SDTM/ADaM review

LSP要不要参与到项目中一起编程，看LSP的工作强度吧，不一定需要你带的项目就一定要你参与编程。但是统筹规划那些一定是要你参与的。在aCRF和SPEC的编写过程中，我觉得最好只有一个人参与，不会你改一下SPEC，我改一下SPEC，然后到后面谁改了什么，什么时候改的都不清楚，这样就会显得很混乱。所以要么LSP直接负责这块，或者指定一个组员，然后你负责review相关内容。

在程序编写完成，输出数据集之后，LSP的一大工作就是review数据集，比如明显的dataissue;相关变量的处理方式是不是不符合IG的定义，很多时候，在组员对某些变量或者筛选条件起分歧的时候，LSP都是最终做出决定的那一个，所以LSP还是需要对相关规则有比较清晰的认识和理解。

在做项目的过程中，数据肯定存在很多dataissue；或者shell格式不正确等等需要和其他部门的人沟通的，这里我建议一切都反馈到LSP这边，不要一个组员这边去找DM，另一个组员也去找DM；一个组员这边去找ST，另一个组员因为另一个问题也去找ST，到后面shell做了哪些改动，数据做了什么处理，你作为LSP什么都不知道，整个项目显得乱七八糟的。所以这些事，组员就统一反馈到LSP这边，再由LSP这边去沟通。

因此我这边有一个给LSP的建议，就是自己准备一个文档，记录做项目过程中有哪些特别大的改动，或者TFL某个section当初有分歧，然后确认了筛选条件是什么，这些都可以记录下来；以及编程中适用于多个数据集的通用处理规则是什么；listing某列没有值是放空还是用横杠代替等等，都可以记录到这个文档中，然后有项目群的话，可以把这个文档发到群里。尤其是做肿瘤项目，一开始完成SDTM到TFL所有的编程，可能隔了很久，突然说有些改动，但是当初为什么这样做完全没有印象，也没有聊天记录，程序里面也没有注释说明，所以这时候这样的一份文档就很重要了。

3：TFL的review

当SAP和shell有个初稿之后，一般就可以开始ADaM和TFL的编程了。开始TFL的编程之前，LSP除了分配任务之外，还需要导入TOC（也就是TFL的标题脚注那些）。

对于输出的RTF，需要进行review，尤其是各组相加不等于总数、或者分页这些明显的情况需要重点注意（其实这应该是编程两侧的责任）。最终交付的时候，需要检查shell上的TFL个数和交付的TFL个数是否一致，顺序是否一致。数据、分页那些就不再赘述了。你也可以将combine之后的文件发到项目群，让组员各自检查对应的TFL是否有问题，这样你也不会那么累。

所以大家在做项目的时候，一开始就认真一点，检查输出（包括数据感觉有问题的都去进行核查），对LSP，大家都好。

4：综合

对于交付的timeline，在通知组员的时候，可以提前几天，因为有些组员确实不够自觉，总是拖延，如果你定的timeline就是交付的那一天，可能那天他才刚写好程序，但是输出那些都没有检查，这种情况下就很容易出篓子。不是最终交付还好，dryrun可能还会给你comments修改一下，final run交出去还是有问题的话那就真的GG了。

对于做项目中需要跟其他部门确认的东西，最好都通过邮件沟通（或者说一定要）。要是项目中出了什么问题，邮件记录就是保护你的最好利器。项目到了某个节点，比如SDTM\ADaM完成；TFL交付；或者需要重新CO的，也可以给你的LM发一封邮件，汇报一下工作进度和状态，不要自己一个人在那埋头做项目，LM也需要清晰地了解每个组员的工作内容和状态，以便继续下一步的工作安排。

今天分享的就这些，其实我说的这些东西你们不一定有感觉，但是只要你自己带过一个项目，就能感受到组员带给你的折磨和刺激了。记得当初自己带的一个项目，组员还没做过很正式的I期项目，然后很多domain都没写过，统计师的shell格式也是不清不楚的，那段岁月折磨了我不知多久，内分泌失调、新冠后加班到11点多，感觉随时要猝死的感觉...

现在看来，当初的那些问题感觉都不是问题啊。

我是老色批，老色批是我