最近交付项目，又有一些心得想分享给大家，其实也是一些吐槽。

在正式写之前，不得不提这一两年里让我很头痛的一个项目，这是一个一期肿瘤项目，申办方还是国内大厂，但是参与项目的组员，去年还是正规CDISC项目没做一两个的小fresh，刚好由我来带领。

那时候的我，刚好也是连肿瘤项目都没写过的大fresh，疗效table也没写过一个，反正没写过的东西多了去了(所以我说为什么去年是我成长最大的一年)。

最后就是一群fresh去做一个肿瘤项目，然后申办方还有各种要求的。那时候的我一边模仿以前公司senior做过的项目，一边理解学习；另一边学习完还要分享给我的组员，比如说ADTTE怎么写，那时候的我也是第一次写，但是最终还是完成了，同时在教其他同事的过程中更加加深了自己的理解。

虽然说学到了很多东西，但是说这个项目做的“一坨屎”真的不过分（没有针对同事，就是客观地评价这个项目）,如果你看到了输出的TFL样式，真的能昏倒在地，而且我为这个项目付出了太多，替同事擦了太多的屁股。

最明显的就是listing的输出，一开始的header乱七八糟，七扭八扭，分页也不注意，总之就是数据集QC上了就是，输出关我屁事。那时候的我review,半夜11点还在帮他们改输出....

还有一个就是图，横纵坐标明显长度不够，图中的线都超了也没注意到，不只一次交付的时候发现这样的问题，而且在做完多个其他项目的时候，还是会犯这样的错。

总之，说起这个项目，一肚子的苦水和心酸，也是因为做这个项目，让我胖了10斤，内分泌失调，压力大，睡不着觉...各种各样的小毛病，这是我在以前的工作中没有遇到过的。

所以，有以下感想：

一：“不要相信你的同事”

这个并不是字面上的意思，而是说      比如你的同事跟你说数据集QC PASS了，作为leader，你最好自己再去检查一遍。很多次，我选择相信我的同事，但是实际做项目过程中，我还是选择相信我自己，因为说不定什么时候你瞄一眼就发现了很明显的错，而这就是他们所说的pass之后的东西。

当然首先作为leader你自己要有那个comman sense，知道同事可能会犯哪些错，而这都是通过不断总结经验得来的，如果你自己都不知道可能会有哪个风险，看了也是白看。比如上面那些review的东西。

还有一个就是锁库后的数据，你看table输出还是一大段“未编码”的东西，这时候你就得有那个comman sense了，这个怎么可能，DM没编码吗？按理说锁库后不应该啊，去检查数据，发现从SDTM开始同事就没把那边编码信息做到数据集里面！！！而这就是我最近遇到的。

如果你觉得未编码很正常，还输出了，然后也没意识到问题，那你这不是找对方医学骂吗。

还有一个就是比如listing里面输出的一些"其他"的字段，但是其他后面的东西却没有了，去查看RAW,SDTM,ADaM都有值啊，结果一看listing程序，同时没加上其他描述的那个变量......

这些都是你们以后可能碰见的或者说已经遇见的问题，真的不管做过多少个项目，同事还是有可能犯这样的错。所以我说为什么“不能相信同事”,当然我说的这些问题，可能只有自己当过LSP的人才能懂,其他人可能就看个乐呵。

二：和统计师合作的问题。

一般整个编程统计部门，ST和SP合作的过程中，ST  SAP都快完稿并且确认完了，然后突然说现在要有一个编程的LSP，这时候你可能忙着其他项目，没有时间去管这个新项目的进度。

然后你有一天突然想起来，问了一嘴统计师这个项目的timeline，接着统计师告诉你跟申办方确认了几周之后要交dryrun的结果?????这时候你一脸问号脸，自己什么都不知道，就要dryrun了，自己连这个项目的合同还没看过，aCRF还没开始写...

首先统计师犯了错，早就该通知编程部门安排LSP负责这个项目，而不是数据都快锁库了才通知。

第二编程同事接到了通知，一定要第一时间跟统计师进行沟通，了解这个项目的进度，SAP和shell到什么程度了，有没有什么timeline啥的。

其实在方案定稿之后，编程就要和ST一起参与到CRF的审阅中，其实这时候就不存在上面那种紧急的情况了，这时候编程要做的就是经常跟DM和ST沟通，确认受试者的入组进度，sap和shell的进度，以便提前安排这个项目的任务。

我说的这些都是我自己亲身遇到的，给大家提个醒.