一、過程回顧
寒假至賽前
最開始一個多月假期，因爲自己是編程手，而且是小組內唯一的一個編程手，所以壓力其實是很大的。在假期期間就想這提升一些自己的編程能力，那就想什麼東西實用上手又快？沒得說當然是Python了，於是乎就找到了這裏：嘿嘿嘿。裏邊的課程連着聽了下來，案例也都操作了一遍，感覺學到了一個非常簡單實用的工具，雖然還是很粗淺，但在處理問題時就不會再像以前那樣手足無措了。
原本是二月多在學校進行爲期三天的比賽，但由於疫情的影響返不了校，給小組溝通上會帶來影響。又看了一下二月公佈的賽題，感覺都不是很擅長。綜合考慮之後決定參加三月的比賽，希望那時能夠正常返校。然而到了三月疫情依然嚴峻，返校無望而且已經沒有退路，只好在家開麥進行答題。當然二月的那個賽題我們也沒有浪費，畢竟每一道題都是不可多得的好題，所以儘管決定放棄二月的比賽，我們還是模擬了一下比賽過程。結果團隊之間分歧太大、對模擬不重視導致模擬了一天就結束了，等待三月的比賽。
賽題是在下午接近晚上的時候公佈的，花了兩個小時進行翻譯、讀題、討論，最後決定跳進這次比賽最大的一個坑——C題（一共六道題，選這個題的大概有三分之一！！！）。當時只能在三道題裏進行選擇，討論了一下，有一道題是超出我們能力範圍或者說是對自己非常沒有把握，所以就直接放棄了，還有一道關於社會科學的題，小組都是理科生對此也是很無奈，只好放棄，然後就只剩下了天坑C題，看了一下剛好能用上假期裏學到的知識，就決定選擇C題了，小組成員也沒有反對。於是乎方向就選好了，剩下的就是全力向終點前進了！
考慮到是比賽剛剛開始，所以也就沒想着熬夜，大概討論了下思路，各自找點相關資料，差不多了就洗洗睡了，準備迎接新的一天。
比賽開始至結束
Day 1
經過溝通，我的主要任務還是處理數據及生成圖像，然而由於掌握的不夠熟練，我還需要邊複習邊執行任務。隊友則開始寫問題分析，以及在之前討論的基礎上開始解題。期間我們通過語音通話不斷交流意見，有時也會意見無法統一，僵持一段時間，但最終意見趨向一致。
Day 1 任務進程：完成問題一及問題二的解答。
Day 2
在第一天裏，身爲程序員的我基本沒有什麼貢獻，但通過一天的努力，終於算是把假期裏學的方法給重新撿了起來，基本上完成了問題一、問題二、問題三、問題四所需要的數據及圖像。由於我是實用主義者，所以模型和圖像都比較粗糙（就是邏輯上說得通，可以解釋問題即可，並不是很嚴謹。），這就與隊友有較大的分歧。當時隊友也沒有給出較爲嚴謹可靠的模型，所以也只好使用我給的比較粗糙的模型了。
Day 2 任務進程：完成問題三及問題四的解答，補充了問題一及問題二所需要的數據及圖像。
Day 3
第三天則輕鬆很多，就剩下了摘要、問題五的建議信、論文的檢校和論文的翻譯。主要任務是由小組的論文寫手和文案BOSS來完成，我則獨立地開始論文的檢校，包括對之前應用的模型、數據處理的結果和生成的圖像再檢查和論證一遍。等到論文完成的時候
Day 3 任務進程：完成摘要、問題五的解答及論文翻譯的工作。
比賽結果
在四月末的時候比賽結果出來，看到評選的結果爲S獎，內心沒有太多波瀾，坦然面對。看着學校獲獎比例幾乎是 M:H:S=1:3:6 也挺難受的，畢竟團隊也經歷了很多，最終還是相信付出和回報成正比吧。
二、總結
個人方面
本人雖然是團隊裏邊的編程手，但說實話對於算法的掌握也不是太好，只是能基本保證在用到的時候去學，學完之後能夠拿來解決問題的程度，而且很多時候還是靠着Python第三方庫解決，勉強能算作三流編程手吧。
個人特點就是有點固執己見，符合自己的邏輯之後就堅信自己是對的，這就導致我很難被人說服，當然我的想法大多時候也是對的，不然挫敗感早就把我的自信心消滅掉了。不過在團隊裏有時還需要做出妥協的，這點是最爲難受的。
現在回想在比賽時我能多做點什麼？能多做幾張好看點的圖；能把模型優化一下；能和隊友多討論討論，統一一下意見；能對模型結果多做一下檢驗與評估；能…… 現在爲時晚已，所以在比賽只給的一次機會裏，若不盡自己的全力，那一定會留下或小或大的遺憾。
團隊方面
大致介紹團隊其他成員的情況，隊友A負責建模與寫論文，隊友B負責編輯與校驗。A與我有些相似，都比較自信，但他的思考邏輯性和嚴密性都不太好，有時即便解釋清楚也會固執己見；其次就是對於建模他似乎只在套用的階段，沒能對模型有較好的掌握，這對我們團隊的影響極爲重大，時常會有生搬硬套的情況出現，更有甚者出現模型一列自己編結果；還有就是不懂編程，根本不知道所用模型該如何實現，基本的邏輯流程圖都完成不了，使得我與其的溝通極爲不順暢。B主要負責文案，文案水平相當棒，我現在編輯水平很大程度上受其影響，其此就是態度認真，性格隨和，有幸能遇到這樣的文案大佬。
最後想一下團隊有什麼可以優化的地方。我認爲第一條就是態度要對，不能是爲建模而建模，而是要解決問題用到建模，我們團隊很多時候都是硬生生插入一個模型，既佔有了篇幅，又使得論文結構完整。在不考慮模型是否合適的情況下這樣做並不是建模，也無益於問題的解決，真正的建模應該是理解原有模型，在新的問題上加以改進，使之適合於新的問題並達到解決問題的效果。第二條就我的親身經歷來說，團隊裏邊的建模手要有一定的編程經驗，至少應該能做到將模型的大致流程圖畫出來，當然最好的就是主要編程的懂建模，主要建模的也懂編程，這就完美了，如果能遇見大佬既做建模又做編程，那麼保緊大腿躺好~ 第三點就是溝通，在這樣一個最簡單的多人小組中就能體會到妥協的意義了，你不可能讓別人完全地接受你的想法，而你自己可能也不會完全接受別人的想法，所以有效的溝通就使得團隊更能達成一致組成合力。當然溝通是建立在對隊友的信任的基礎之上的，要在團隊裏邊不斷磨合，逐漸產生互信並可以進行良好的溝通。
結尾
雖然淪爲炮灰，但並沒能挫傷自己的勇氣，不過有過這次經歷也更加清晰地認識到自己的不足及需要改正的地方。希望我的經歷能給各位帶來些許參考意義。