怎么當一個LSP（SPL）功戚，然后怎么當一個好的LSP僚楞，這是我今天要分享的一些東西勤晚，僅僅從我自己的角度講講感想枉层，后續(xù)有其他需要注意的地方還會繼續(xù)更新。
當你有幾年經(jīng)驗赐写，去面試的時候返干，面試官99%會問你的一個問題就是“帶過項目嗎？”血淌。可見帶過項目對于SP來說有著舉足輕重的作用财剖。
如果你只是項目里的一個組員悠夯，寫完數(shù)據(jù)集，輸出TFL可能就差不多了躺坟，但是LSP要考慮和檢查的東西就多的多了沦补，并且對最終交付的成果負責。
1：項目統(tǒng)籌階段
作為一個LSP咪橙，當你拿到一個項目的時候夕膀，就得進行各樣的準備了，首先查看合同美侦，是不是注冊項目（非注冊可能是另一套流程）产舞；了解項目需要做什么，比如aCRF;SDTM;SDTM define.xml;SDRG;ADaM ADaM define.xml;ADRG;TFL這些是不是都要菠剩。
接著你得熟悉方案易猫，至少要了解這個項目是什么類型的，主要終點具壮、次要終點准颓，試驗設(shè)計是什么，試驗流程是什么棺妓，涉及到什么統(tǒng)計方法攘已，這些都是要清楚的最基本的東西。
至于什么時候要開始項目怜跑，因為我還沒做到特別高的位置样勃，大多數(shù)時候還是LM來通知安排，開始項目不一定要等SAP和shell完成妆艘，CRF定稿之后彤灶，就可以著手開始項目了。（這里有不完善的地方歡迎指正）
然后就是給組員分配工時和任務(wù)批旺，如果公司要求預先估計員工在某個項目可能花費多少工時幌陕，LSP要有一個大概（也有可能有一個標準，比如規(guī)定寫完一個aCRF汽煮、SDTM domain需要花費多少工時）搏熄；給組員分配任務(wù)棚唆，從我自己的考慮的話，拖沓的人就不會分配給他試驗設(shè)計和DM,SE,SV這些domain心例；沒有寫過某些domain的組員宵凌，會考慮每次都分配不一樣的數(shù)據(jù)集給他寫，而不是每個項目就讓他寫某幾個domain止后。
任務(wù)安排完畢后瞎惫，設(shè)置好項目環(huán)境，也就是我們通常說的的setup（里面包含各種邏輯庫译株、還有項目信息等）,最好開一個kick off meeting瓜喇，跟組員講一下任務(wù)安排是什么，需要注意什么歉糜；timeline是什么乘寒。
說到timeline，我覺得項目第一重要的是質(zhì)量匪补，第二個就是timeline的完成度了伞辛，其實換句話說也就是效率。當制定了timeline之后夯缺，組員嚴格按照這個timeline執(zhí)行（所以LSP在制定timeline的時候蚤氏，要考慮組員還有沒有其他項目，工作強度喳逛，有沒有請假瞧捌，甚至一些突發(fā)情況）。
如果大家對timeline沒有嚴格的執(zhí)行意識的話润文，這個項目沒有在規(guī)定的時間完成姐呐，很有可能就會影響到其他項目的執(zhí)行，然后多個項目拖延導致沖撞到一起典蝌，后果比較麻煩曙砂，直接的結(jié)果就是導致組員加班，進而影響工作幸福度骏掀。
2：SDTM/ADaM review
LSP要不要參與到項目中一起編程鸠澈，看LSP的工作強度吧，不一定需要你帶的項目就一定要你參與編程截驮。但是統(tǒng)籌規(guī)劃那些一定是要你參與的笑陈。在aCRF和SPEC的編寫過程中，我覺得最好只有一個人參與葵袭，不會你改一下SPEC涵妥，我改一下SPEC，然后到后面誰改了什么坡锡，什么時候改的都不清楚蓬网，這樣就會顯得很混亂窒所。所以要么LSP直接負責這塊，或者指定一個組員帆锋，然后你負責review相關(guān)內(nèi)容吵取。
在程序編寫完成，輸出數(shù)據(jù)集之后锯厢，LSP的一大工作就是review數(shù)據(jù)集皮官，比如明顯的dataissue;相關(guān)變量的處理方式是不是不符合IG的定義，很多時候实辑，在組員對某些變量或者篩選條件起分歧的時候臣疑，LSP都是最終做出決定的那一個凿试，所以LSP還是需要對相關(guān)規(guī)則有比較清晰的認識和理解向拆。
在做項目的過程中沛申，數(shù)據(jù)肯定存在很多dataissue；或者shell格式不正確等等需要和其他部門的人溝通的婿奔，這里我建議一切都反饋到LSP這邊，不要一個組員這邊去找DM问慎，另一個組員也去找DM萍摊；一個組員這邊去找ST，另一個組員因為另一個問題也去找ST如叼，到后面shell做了哪些改動冰木，數(shù)據(jù)做了什么處理，你作為LSP什么都不知道笼恰，整個項目顯得亂七八糟的踊沸。所以這些事，組員就統(tǒng)一反饋到LSP這邊社证，再由LSP這邊去溝通逼龟。
因此我這邊有一個給LSP的建議，就是自己準備一個文檔追葡，記錄做項目過程中有哪些特別大的改動腺律，或者TFL某個section當初有分歧，然后確認了篩選條件是什么宜肉，這些都可以記錄下來匀钧；以及編程中適用于多個數(shù)據(jù)集的通用處理規(guī)則是什么；listing某列沒有值是放空還是用橫杠代替等等谬返，都可以記錄到這個文檔中之斯，然后有項目群的話，可以把這個文檔發(fā)到群里朱浴。尤其是做腫瘤項目吊圾，一開始完成SDTM到TFL所有的編程达椰，可能隔了很久，突然說有些改動项乒，但是當初為什么這樣做完全沒有印象啰劲，也沒有聊天記錄，程序里面也沒有注釋說明檀何，所以這時候這樣的一份文檔就很重要了蝇裤。
3：TFL的review
當SAP和shell有個初稿之后，一般就可以開始ADaM和TFL的編程了频鉴。開始TFL的編程之前栓辜，LSP除了分配任務(wù)之外，還需要導入TOC（也就是TFL的標題腳注那些）垛孔。
對于輸出的RTF藕甩，需要進行review，尤其是各組相加不等于總數(shù)周荐、或者分頁這些明顯的情況需要重點注意（其實這應該是編程兩側(cè)的責任）狭莱。最終交付的時候，需要檢查shell上的TFL個數(shù)和交付的TFL個數(shù)是否一致概作，順序是否一致腋妙。數(shù)據(jù)、分頁那些就不再贅述了讯榕。你也可以將combine之后的文件發(fā)到項目群骤素，讓組員各自檢查對應的TFL是否有問題，這樣你也不會那么累愚屁。
所以大家在做項目的時候济竹，一開始就認真一點，檢查輸出（包括數(shù)據(jù)感覺有問題的都去進行核查）霎槐，對LSP规辱，大家都好。
4：綜合
對于交付的timeline栽燕，在通知組員的時候罕袋，可以提前幾天，因為有些組員確實不夠自覺碍岔，總是拖延浴讯，如果你定的timeline就是交付的那一天，可能那天他才剛寫好程序蔼啦，但是輸出那些都沒有檢查榆纽，這種情況下就很容易出簍子。不是最終交付還好，dryrun可能還會給你comments修改一下奈籽，final run交出去還是有問題的話那就真的GG了饥侵。
對于做項目中需要跟其他部門確認的東西，最好都通過郵件溝通（或者說一定要）衣屏。要是項目中出了什么問題躏升，郵件記錄就是保護你的最好利器。項目到了某個節(jié)點狼忱，比如SDTM\ADaM完成膨疏；TFL交付；或者需要重新CO的钻弄，也可以給你的LM發(fā)一封郵件佃却，匯報一下工作進度和狀態(tài)，不要自己一個人在那埋頭做項目窘俺，LM也需要清晰地了解每個組員的工作內(nèi)容和狀態(tài)饲帅，以便繼續(xù)下一步的工作安排。
今天分享的就這些瘤泪，其實我說的這些東西你們不一定有感覺洒闸，但是只要你自己帶過一個項目，就能感受到組員帶給你的折磨和刺激了均芽。記得當初自己帶的一個項目，組員還沒做過很正式的I期項目单鹿，然后很多domain都沒寫過掀宋，統(tǒng)計師的shell格式也是不清不楚的，那段歲月折磨了我不知多久仲锄，內(nèi)分泌失調(diào)劲妙、新冠后加班到11點多，感覺隨時要猝死的感覺...
現(xiàn)在看來儒喊，當初的那些問題感覺都不是問題啊镣奋。
我是老色批，老色批是我
