一、过程回顾
寒假至赛前
最开始一个多月假期，因为自己是编程手，而且是小组内唯一的一个编程手，所以压力其实是很大的。在假期期间就想这提升一些自己的编程能力，那就想什么东西实用上手又快？没得说当然是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主要负责文案，文案水平相当棒，我现在编辑水平很大程度上受其影响，其此就是态度认真，性格随和，有幸能遇到这样的文案大佬。
最后想一下团队有什么可以优化的地方。我认为第一条就是态度要对，不能是为建模而建模，而是要解决问题用到建模，我们团队很多时候都是硬生生插入一个模型，既占有了篇幅，又使得论文结构完整。在不考虑模型是否合适的情况下这样做并不是建模，也无益于问题的解决，真正的建模应该是理解原有模型，在新的问题上加以改进，使之适合于新的问题并达到解决问题的效果。第二条就我的亲身经历来说，团队里边的建模手要有一定的编程经验，至少应该能做到将模型的大致流程图画出来，当然最好的就是主要编程的懂建模，主要建模的也懂编程，这就完美了，如果能遇见大佬既做建模又做编程，那么保紧大腿躺好~ 第三点就是沟通，在这样一个最简单的多人小组中就能体会到妥协的意义了，你不可能让别人完全地接受你的想法，而你自己可能也不会完全接受别人的想法，所以有效的沟通就使得团队更能达成一致组成合力。当然沟通是建立在对队友的信任的基础之上的，要在团队里边不断磨合，逐渐产生互信并可以进行良好的沟通。
结尾
虽然沦为炮灰，但并没能挫伤自己的勇气，不过有过这次经历也更加清晰地认识到自己的不足及需要改正的地方。希望我的经历能给各位带来些许参考意义。