SAS程序師:如何開辟晉升項目leader之路?

發布時間:2018-09-21 文章來源:SAS程序師:如何開辟晉升項目leader之路?

引言:在藥廠或CRO企業,很多有經驗的SAS Programmer經過幾年的磨礪之后,逐漸走上了項目leader的道路,但是做好項目leader和做一名優秀的項目成員是有很大的區別的,好的項目leader一定是從優秀的項目成員成長起來的,但是好的項目成員卻不一定都能做好項目leader。那么SAS Prorammer需要掌握哪些技能,才能成長為項目leader?如果你是一名項目leader,如何在項目中更好的扮演leader的角色呢?

01

項目leader應該具備的基本條件

1. 一名合格的項目leader首先應該掌握如下知識,比如:

◆SAS 模塊:

SAS/BASE

SAS/SQL

SAS/GRAPH

SAS/MACROS

SAS/ACCESS

SAS/ODS

SAS/STAT

SAS ENTERPRISE GUIDE等。

◆基本的統計知識:

基本的統計學知識:

熟悉基本的統計學描述及檢驗原理,尤其是對以下16個基本統計過程的熟練掌握

1. Wilcoxon Rank Sum Test:

2. Exact Wilcoxon Rank Sum Test

3. Kruskal-Wallist test

4. ANOVA

5. ANCOVA

6. TTEST

7. Kolmogorov-Smirnov Test

8. Chi-Square Test

9. Fisher’s Exact Test

10. Paired T-Test

11. Wilcoxon Signed Rank Sum Test

12. Pearson Correlation:

13. Spearman Correlation

14. Survival Test

15. Mixed Model without random effect

16. Mixed Model with random effect

◆CDISC:

熟悉SDTM(v3.1.2, v3.1.3, v3.2)

ADaM(v1.0, v1.1)

Review Guide,Define(v1.0,v2.0)等。

◆其他:

如ISS/ISE

eCTD and FDA Guidelines

Good understanding of Good Clinical Practice (GCP)等。

2. 較為豐富的項目經驗

Involved in Phase I,Phase II,Phase III of clinical trials

3. 有一定溝通協調和領導能力

對內溝通能力主要分為:

a. 上下(上司與下屬之間)

b. 左右(同級別同事之間)

對外溝通能力

4. 有比較強的抗壓能力

5. 較強的英文讀寫能力

02

項目leader的職責(responsibilities),由于每家公司情況不同,項目leader職責也有所差異,在此列舉僅供參考:

1. 協助統計師develop mockup;

2. 負責內部溝通和對外郵件的溝通;

3. Create the mapping spec;

4. 負責組建項目組,同時開通項目組成員權限;

5. 制定項目Timeline;

6. 召開項目啟動會、項目例會、項目總結會等;

7. 負責提交結果的審閱,確保提交質量和把控Timeline;

8. 確保項目符合部門SOP/IG操作規范,符合客戶要求的其他標準,如CDISC;

9. 對主副程序的不良工作習慣或項目錯誤操作進行及時地糾正;

10. 提升自己所領導的項目團隊。

03

項目leader在管理項目過程中

常見問題匯總

下面我們列舉一下實際情況中遇到的問題的例子和不同風格的leader的做法作為對比,大家可以根據你們的經驗覺得更接受哪種。原則上來說推薦以標(P)的為高標準做法。

1. 如何把控項目的Timeline?

◆Leader A: 雖然沒有內部Timeline,但是覺得項目組成員水平還可以,放手讓大家去干也是可以完成的;只需要在項目提交前compare pass,通過Review即可。

◆Leader B: 制定完成內部的Timeline后,發現實際執行下去項目成員實際完成工作量和Timeline相距甚遠,但也無計可施,只能項目成員進行溝通后,溝通后項目成員說應該能完成,剩下的就只是等待和祈求一切順利了。

◆Leader C: 明確外部的Timeline之后,制定詳細的內部Timeline, 嚴格按照Timelime去執行,定期召集項目組成員Review項目進度和項目疑難點,實時了解項目實際執行情況,比如說是否存在項目沖突,是否需要及時地調整策略、協調資源或是給予成員所需的幫助。

2. 如何解決項目中成員有多個項目沖突的問題?

◆Leader A: 項目成員沒有給我講,我以為沒有沖突或者項目成員可以自己應付過來,我只要保證我的項目能交出去就可以了,其他項目怎么樣我管不了。

◆Leader B: 已經通過資源日歷表或者和同項目成員溝通得知,該項目成員在關鍵節點可能會出現項目沖突嚴重的情況,估計會影響項目提交的Timeline,及時報告該情況給上級PM,請求協助解決。

3. 若多個項目沖突需要更換項目成員,如何做好項目工作交接?

◆Leader A: 讓新成員進入項目討論組后,只需要開通好權限就可以開始干活了,相信項目組成員是有這個實力的!

◆Leader B: 開通好新成員項目的權限,對其進行一些項目上的培訓(如觀看項目啟動會培訓視頻,熟悉Protocol, SAP, Spec等),預留出必要的時間組織新舊成員進行程序上的交接和講解,同時也要做好文檔記錄,熟悉需要接手的程序存在哪些漏洞,應提前處理修復好潛在的bug。

4. 如何更好的解答項目成員疑問?

◆Leader A: 嗯/好/對/給值xx/結果是xx/處理成xx。

◆Leader B: 帶著why to do的思路去回答,用事實證據說話,讓項目成員明白來龍去脈,如:

baseline的衍生規則你可以看一下SAP xxxx;

ADaM IG第xx頁有講到這種類型的處理,你可以去看看相關文檔了解一下;

以前客戶有過郵件溝通,你可以借鑒一下;

可以參考一下‘FDA guideline <Study Data Technical Conformance Guide.pdf>’的第xx頁。

5.  如何處理好緊急需求?(例如當天來的Request需要當天提交的情況)

◆Leader A: 通知項目組成員有緊急需求,簡單開會過完需求后讓各個項目成員自己去寫程序,如果大家發現任何問題就告訴leader, 到時再進行討論和處理,如果實在寫不完就組織加班。

◆Leader B: 將大的任務WBS分解成多個小任務,制定以小時為單位的Timeline,嚴格按照Timeline去執行,以減少加班的風險。

a. 告知項目組成員有緊急需求,讓大家提前熟悉郵件的內容,同時leader會利用這段時間,結合需求和實際的數據,提前整理好問題以及可能會出現的程序困境;

b. 抓緊時間召開項目討論會議(如若涉及到宏的修改等,討論需加入宏開發小組成員),了解所有的項目成員是否有其他疑問和補充,內部應該統一意見,整理出需要內部解決的問題和外部需確認的問題,在最短時間內將外部問題郵件發給客戶。

6.  發現項目主程序或者副程序效率不高,當天只完成了很少一部分工作,項目推不動怎么辦?

◆Leader A:今天寫不完就算了,明天再看看,反正Timeline也是制定得比較寬裕的,說不定明天就覺悟了,可以很快補上來。

◆Leader B: 當天及時同該項目成員進行溝通,對癥下藥:

a. 發現有多個項目沖突嚴重,后面也有可能發生沖突時,需及時報告上級PM,以解決人員沖突問題;

b. 若項目成員對項目理解存在困難,則對該成員進行一對一的項目講解和培訓;

c. 如果項目成員有實現某需求時存在技術上的困難,如果是跨區域的,項目leader不太方便溝通,可以請求區域主管協助解決,如果區域主管也解決不了,可以向工具開發小組成員尋求幫助;

d. 若無其他特殊原因,只是成員比較懶散,不愿意干活的情況,應及時報告區域主管,協助處理解決問題。


7. 如何保證lead的項目符合部門SOP/IG流程規范?

◆Leader A: 我保證最后提交的結果是正確的就可以了,客戶也沒有提comments,流程上的規范也沒有仔細去研究,上級不管我也不用花精力在上面。

◆Leader B: 嚴格按照流程來走,如召開項目啟動會,用Batch run, issue log記錄comments,檢查主副程序有無Hard-coding,如果有就需要進行相應的記錄歸檔,每次提交都要檢查主副程序log是否clear,做好Tracker,QA等,并在該過程中發現的不合理地方及時反饋給上級,提出改進計劃。 

8. 項目成員對某問題固執已見,與項目leader達不成一致怎么辦?

◆Leader A: 花了好幾個小時與成員溝通,感覺還是說服不了ta, 好像覺得ta說得也有些道理,要不我妥協一下,聽ta的算了。

◆Leader B:

a. 如果項目成員的意見確實是錯的,找確切證據去說服ta;

b. 如果感覺兩種意見確實都有道理,可以先咨詢下項目統計師或上級PM的意見;

c. 如果實在得不到確切的答案,只能由Leader先確定一種方案,然后發郵件問客戶,盡量避免花太長時間在上面,影響整體項目進度。 

04

 給項目Leader的建議和意見

1、做之前先寫好計劃

有些人認為,花時間寫計劃還不如花時間寫代碼。困難的部分不是寫計劃,困難的部分是做這個計劃——整個計劃包含思考,溝通,權衡,交流,提問以及傾聽。所用來分析解決問題需要花費的時間,都會節約在以后項目可能帶來的意外上。

2、把大任務分解成小任務( Work Breakdown Structure )

分解成小任務是縮小了里程碑,把大任務分解成多個小任務,也能幫助你更加精確地估計它們,暴露出在其他情況下你可能沒有想到的工作活動,并且保證能更加精確的分段監控和跟蹤。

3、考慮意外緩沖

事情并不一定會像計劃那樣準確地進行,所以在做項目Timeline的時候,應該在提交節點之前考慮部分意外的緩沖,以預防無法預料的情況。如果Timeline是無法更改的,應該盡量把任務提前做,前重后輕,以便留出更多的緩沖時間。

4、強強聯合不一定是正結果

a. 大神和大神組隊,每一個人都覺得自身經驗很豐富,在分工不明確的前提下,都想去實現了自身的功能,這就容易使項目產生偏差。

b. 沒有一個合理的人去指導、分配工作,很容易導致項目組的其他成員無所事事,只有到了緊要關頭才開始自己的工作。

c. 所謂的強強聯合,其中必須的是有一個能站出來總領工作的人。

5、眾謀而獨斷

a. 項目是需要人來帶領的,定期了解、聽取項目成員的想法都有助于及時地識別風險。

b. 在項目實施的過程中,各個項目成員或多或少都會有些別的想法,在與你討論的時候要把控好時間,且最好不要超過30分鐘,來回的拉扯只會讓問題變得越來越復雜。

c. 在對方沒有更好、更成熟的方案拿出來前,如果無法裁定,有兩種解決方法: 一是上報請領導定奪,二是按照原定計劃執行。

6、善于傾聽并敢于承認錯誤

作為項目leader,在做出各種決定以后,要清楚明白,決定不可能是100%正確的,事后如果證明是自己犯錯,千萬不能因為維護自己的面子而極力掩蓋錯誤,那只會讓你更愚蠢,反而應該和項目成員坦誠相待,敢于承認錯誤,勇于承擔責任。


上一篇:沒有了 下一篇:沒有了