#import "template.typ": *

#let data=yaml("./data.yaml")
#import "@preview/tablex:0.0.8": tablex, rowspanx, 




#show: doc => conf(

    

  linespacing: 1em,

  outlinedepth: 3,

  blind: false,

  listofimage: true,

  listoftable: true,

  listofcode: true,

  alwaysstartodd: true,

  doc

)
#import "@preview/colorful-boxes:1.3.1": *

= 总结与反思
#v(-3em)
== 管理层面
#v(-3em)

=== 队长
- 仁慈，没有威望，管不住人
- 对比赛了解不够，缺乏经验
- 性格急躁，情商低，不够成熟
- 拖延，效率低


#h(2em) 很多时候对事情的认知和处理和大部分人不一样，做事情总是考虑不够周全。
一些事情总喜欢自己去做，还想把事情都做好，都拖到最后，也处理不好也浪费时间。

技术上对技术组了解不够，可以说完全没有经验和判断能力，充其量算是一个勉强合格的运营，平时负责对接一堆杂事，安排队伍日常，反而没有起到队长对队伍的管理作用。

*解决方案*：如果可以，重新指派队长，其明年还能继续当队长，经验和管理方面一定更加好；着手组建运营组，一些对接上或者其他杂事交给运营组去做，尽可能减轻新队长的工作量，使其能够着手于队伍管理。

#v(-1em)
=== 项管
*没有项管*。

赛季初项管完全没有作用，之后退队后处于空缺，队长虽然也想去承担起项管的角色，但因为能力不足，威望不足，也没有起到很好的效果。不管怎样，效果上来看就是没有项管。

以*英雄*为例。应该有人意识到，这么短的工期，以我们的人力不足以去造一台*能上场*的新英雄#footnote([哪怕他很好使，没有足够的测试，他依然不能够上场，还牵制了英雄组大部分的人力])。还有就是英雄老车*机械*，留给电控的时间很少。虽然不反对追求极致，但这时候本应有人站出来协调进度。

从赛季初虽然指定了项管人选，但根本一点没有起到项管应该负的责任；某些人，总觉得自己做的是对的，其他人但凡压力一点，指出一点都无法接受，之前总是过于替他们着想，导致最后所有人一年的努力差点付诸东流。

*解决方案*：指定新的项管，有一定威望和能力，不留情面，足够公正。

*候选人*：李振旭、石恪
=== 技术组长

*技术组长*没有起到作用。


除视觉组外其他所有技术组长都没有负起责任。硬件组组长李鑫华，因复习考试没去去分区赛，同时管理能力欠佳。机械组长刘虹艺，没有管理能力。

再加上队长也没有足够的*技术能力*、*管理能力*和*比赛经验*去担负起这些组长该有的责任，这直接引发了一系列问题，包括

- 哨兵机械问题，以及祝梓钦的离队
- 英雄电控、硬件方面稳定性问题
- 对大一的人员的管控、处罚力度不够，队伍松散
- 技术组员对比赛经验不够，传承不到位


#h(2em) *解决措施*: 指定新的技术组长，以大二为主，这些人在之前的备赛过程中已经逐渐担负起了技术组长主力的责任。
		- 视觉：郑竣哲 
		- 机械：黄金涛 / ？
		- 硬件：李天宇 / 石恪
		- 电控：李振旭

=== 车组组长
车组组长无过大问题，以现在人力情况，建议维持现状。

== 架构
其实更大的问题是*队伍架构上*的问题。很多人只认为这个比赛只是单纯的技术比赛，只需要技术就可以，自己技术厉害就比其他人强很多。#footnote([其实之前队内是有专门的运营组和宣传组的，但是因为技术组组员的歧视，很明显，我做技术，你不做技术，你就是比不上我。你不做技术，有没有别的事情，这么半天，这点事情都搞不定？])

这种风气一定程度上决定了现在队伍运营职责全部压到队长，导致不能很好地去进行技术上地把控和管理。

=== 职责划分概述

在现有的赛事体系中，带有管理职能的岗位有很多，如：项目管
理、队长、副队长，还有宣传经理、招商经理，研发部门、支持部门、运营、电控、
机械、视觉，对比其他的赛事团队，为什么会形成这种架构？

不妨以一支刚刚参加加3v3的队伍举例，这支队伍由6个人组成，来自同
一个实验室，他们一致决定要参加机甲大师。决定参赛第一步，他们
围着电脑向组委会提交了参赛申请，石头剪刀布决定出了队长和项管
填了上去。报名完成后，他们需要向学校申请场地，六个人路子都很
硬，其中一人心思活络、八面玲珑，被其余五人推举去完成与学校交
涉获取场地的任务，随后的各类与学校、组委会、其他学校队伍交涉
的任务也都由这位同学完成，暂且称这位同学为A。

$" "$ 

这一阶段的队伍成员较少，A也能很好的平衡研发与交涉的任务，并且在日常生活中六个人经常同吃同住，相互之间的信息也基本清楚，
遇到一些如购买车票、购买队服、财务报账的问题，A也能很快的解
决。第一年的比赛很快就结束，6人的成绩还不错，赛后6人决定，
下一年要在学校里招兵买马，参加超级对抗赛，一路打到春茧。（*在人数较少时，管理的作用并不明显，对比赛结果的影响并不显著*） 

$" "$ 



于是进入到第二年，超级对抗赛的任务很重，需要的人员更多、
资金更多，6人明显精力不足，于是决定从实验室拉入一批同学，技
术靠谱的同时也相对更为熟悉。在赛季开始前，他们的队伍扩张到24
人，但是参与比赛还远远不够，他们还需要吸收新鲜血液、更大的场
地、更多的资金。于是众人联系了X老师，在X老师的支持下，众
人收获了更多的资源，同时也被告知，需要承担相应的任务，给钱但
是不能只打RM，还有别的比赛以及领导的各类要求等等。这一阶段，
因为人数增加，众人内部进行划分，分为电控、视觉、机械三个小组
进行，每个小组各推选出一名组长作为队伍的管理者，A由于上一赛
季表现出色，被推选为队长。


$" "$ 

在备赛的过程中，由于超级对抗赛需要提交的文件更多，同时需
要承担老师的各项任务，A逐渐不再进行技术研发，转变为队伍的管
理角色，在磨合的过程中，各组的组长也逐渐承担起一定管理责任，
负责组内进度把控、技术培训等。到赛季后期，由于人数增加后，各
个兵种的发票整理报账任务繁重且单一，众人决定寻找专门的人来负
责财务报销，偶尔也负责和学校进行对接。

$" "$ 

由于技术不成熟以及人员磨合问题，这一赛季的成绩并不理想，众人赛
后复盘是项目进程出了问题，由于缺少一个全局把控的人（项目管理），
所以各组的分工不明确，配合出现差异，最终导致兵种研发出问题。
（这一时期，队长、组长、财务等人组成了队伍的基本运营团队，但
职能并不明确，往往很多事情都需要队长亲自进行，当事情多的处理
不过来时，就需要研发管理二选一，最终舍弃其一） 

$" "$ 

第三年，队伍决定优化体系，将运营部门独立出来。由 A来承担
项目管理的工作，负责日常进度的督促，以及各组的组间协同，*运营
部门负责各类非技术的问题*，如纳新、账号运营、活动策划、周边制
作、财务报销、比赛期间的差旅食宿等等，*作为队伍的支持部门帮助
研发部门解除后顾之忧*，能够全心全意的去备赛。同时选取了新的队
长，与项管一同进行技术管理（这时的组织架构基本接近现在大多数
队伍，基本成熟，宣传运营部门独立，技术研发部门内部进行细分） 
支持部门（宣传、运营、策划、招商等）的出现意味着体系成熟，
保证了研发部门能进一步提高效率。

$" "$ 

善战者无赫赫之功，队伍的正常
运转离不开支持部门的付出，因为总有很多杂活是需要人去做的，例
如文档整理、财务报销、物资管理、差旅管理。作为一个做好了没人
夸（大多数人意识不到，进入队伍的第一天就已经习惯了，例如如今
城市的水、电、网络），做差了会被骂的部门，*如果管理者认识不到
支持部门的付出，不能让队伍认可支持部门，就会出现支持部门逐渐
减员、运营的任务量加重、支持部门减员的恶性循环，最终研发部门
不得不承担运营任务，降低研发效率，最终影响比赛成绩*。

$" "$ 

从第一年到第三年，人员的扩张使得需要进行管理，为了提高效
率，队伍内部的分工更为明确，最终出现了支持部门与研发部门。（从
第一年到第三年的过程，像不像企业的成长路径，从一个草台班子到
分工明确能稳定生产产品进行销售的企业） #footnote([上述内容引自中北斐老板地宣经入门。])

=== 明确职责划分
#import "@preview/tablex:0.0.8": tablex, rowspanx, colspanx
#v(0.5em)



#align(center,[

    #tablex(

  columns: 2,

  align: center + horizon,

  auto-vlines: false,

  header-rows: 2,

  /* --- header --- */
  [*名称*], [*负责人*],

  
  [运营组],  [比赛的支持部门，负责*一切除比赛技术以外的所有内容*，包括但不限于宣传，招商，招新，差旅，活动策划，和老师的对接，日常学校的任务，文档整理，财务报销，物资管理],
  [队长，项管], [负责整个队伍的技术上的管理，调度，资源的分配，进度的把控],
  [技术组长], [协同队长，项管完成技术组内的管理],
  // [车组组长], []


)
])

== 测试层面
#v(-3em)
=== 不够重视
    // 一方面不够重视，一方面场地问题。

对平时的队内赛不重视，没有把平时的队内训练当成正式的比赛，典型的就是步兵自瞄和英雄，步兵的自瞄，如果在家里上的就是自瞄和大符融合后的版本，问题是不是能早点发现，早点解决。#footnote([之后的队内赛如果无法上某些功能，那直接砍了算了，我们不需要一个可能会好用的新功能，我们需要的极致的稳定性，哪怕他不具有极致的性能。
])再比如英雄，英雄的问题更为严重，英雄不管什么时候，总在拖着不肯上队内赛测试问题，一直不停地修改，测试，结果之后的每场队内赛训练英雄都稳定*出现问题*，几乎没有一次，英雄是稳定能打满一场的，最后分区赛英雄这个样子，其实是可以预见的。
#v(1em)
还有*工程*，自定义遥控器，按理从做出来就能知道好不好使，某些人一直拖着不给上，还在拿手调姿态，最后的键鼠操作也是最后几天肝出来的，根本没有留出充足的测试时间，万幸的是最终好用。
=== 安排不合理

*开始时间过晚*

最后只留出一周时间来队内赛，并且一开始还没法有力组织。

*组织能力不行*

没有一套完整的制度和队内赛体系，没法调动所有人，导致最终在场地中干活的总是那么几个人，效率低且累。

*能跑就能队内赛*

完全没有按照能过检录的标准，比如UWB，比如步兵的摩擦轮接Gambal，再比如英雄的底盘一开始完全没有过断电检录。

*解决措施*：

1. 留出足够的时间给队内赛，队内赛前应进行预检录。
   从下周开始就该每周两次，周三周六晚，一次五局。暑假后频率提上来，每周三次，一次五局。比赛前一周每天晚上都要打。（频率安排待定）

2. 按照官方比赛的流程来，准点无法开始叫*官方技术暂停*，调试好的车搬出场外，下电，留一台车用于测试图传接收端能否正常工作。

  - 这件事要找两到三个人专门负责，包括搭服务器、保证赛前机器人链接正常，他们和收拾场地的应该提前一小时入场着手准备。一局比赛七分钟，确保所有设备正常后开始比赛到两场BO3比赛结束时间不要超过两个小时，
3. 三分钟准备阶段可喊“还有几分钟”提高效率。
4. 如弹丸不足，就比赛结束前四分种左右，进场捡子弹45s左右。

5. 队内赛时把任务落实到人，以目前的人力来说可以分成大一大二搭配四组人，把名单发到群里、时间排好，不用管他们是否有课，让他们和别的组去更换时间，能保证每组十人左右出勤率，两周一共四次比赛正好一个轮换，这些人的任务就是赛前收拾场地，赛时录像、捡子弹、负责专门的任务。每次在群里@ 全体 问有没有人来起不到任何作用。

==== 校内赛时间分配

#v(-2em)
=== 场地
*①能用于训练的标准#footnote([之所以要标准是因为全向轮在家里完全不能飞坡，道具训练却有飞的可能；全向轮在场上被卡了一次狗洞，因为家里的和场上的狗洞并不完全一样；])场地*

测试不足的另一个原因是没有合适的，能用于训练的#footnote([能平时用于队内赛训练，而不是单纯测试某项功能，这里特指家里的环形高地和狗洞])*标准*场地。我们的每次训练都好像*超级联盟赛*，完全没有考虑战场的地形，训练的目的好像只是为了测试车自身的稳定性。

看过了华科、工大的实验室，才意识到这个问题，我们需要标准的，能用于训练的场地，哪怕只有半场也是足够的。人家在家里就能训练的战术执行，我们却只能在场上来找到感觉。

目前问过了哈尔滨本地的家具厂，复刻一个完整的环高和梯高的价格在7000块钱左右，个人认为可以接受。
//如果预算有限的话，要是想搞个能打比赛用的半场不推荐，外包做价格必然几万起步，找大一机械来搞质量是一方面，进度也是一方面（就算催的再紧在期末之也前别想着能搞出来）。可以把飞坡落点接上一段“梯高”，这个“梯高”只要一个坡和飞坡落点连接，另一个坡和地面连接就好，上面平台能有四个英雄的大小就够。场地具体细节还是大家一起讨论讨论吧。

*②便于携带的场地道具*

如前哨战，基地，起伏路段，设计之初就应该考虑带到比赛地点测试的需求。
#footnote([如果运输方式打算找货车来拉的话，其实可以不那么便于携带，塞得下就行，甚至可以带的下能量机关和飞坡等。])
//感觉便携没啥用，在家测好了啥都不用带，带个靶车或者前哨站过去就够了。

// #table([1,2,3,4,])
#import "@preview/tablex:0.0.8": tablex, rowspanx, colspanx
#v(0.5em)



#align(center,[

    #tablex(

  columns: 2,

  align: center + horizon,

  auto-vlines: false,

  header-rows: 2,

  /* --- header --- */
  [*名称*], [*负责人*],

  
  [飞坡],  [陈骏熔],
  [起伏路段], [],
  [前哨站], [],
  [梯形高地], [],
  [环形高地], [#h(5em)],


)
])



== 运营

运营组应该独立于技术组，负责一切杂事，包括但不限于物资采购，场地维护，赛事组织，辅助队伍管理等。队长和项管应该负责的是技术上的管理，而不是被这些杂事牵制住绝大部分精力。

管理者必须明白这些看起来对比赛毫无作用的事情对比赛的影响。
// #v(-3em)
=== 物资管理及其混乱
// #v(-3em)
没有物资管理，乱扔的各种工具，散乱的螺丝，导致工具的缺失，效率的低下，比如分区赛时随处可见的地上的水口钳和镊子，明明已经强调了很多遍，还是没有起到效果。

*解决措施*：
// 1. *螺丝盒、货架物资的管理和分类、适当的惩罚措施*
1. *工具分区，责任到人*。物资放在专门的地方如*螺丝盒*、货架上的不同分区，设置专门的人来进行看管，比如xxx负责电池和充电器，xxx负责螺丝和螺丝刀，xxx负责视觉物资等。
//条件允许把被负责的东西都贴上人名。
2. *定期盘点*。 定期对工具进行盘点，核对数量，检查损坏情况，及时补充或维修。

3. *制定合理规则*。如多久没有放回就需要自费赔偿，或者其他惩罚措施，使用场地摄像头进行定时抽查，提高威慑力。
//第三条难以实现
//4.裁判系统，车和裁判系统箱子回来了要让一个人专门去统计一下现在手里各种裁判系统的数量，由他负责裁判系统相关事宜（包括赛季末归还裁判系统）要用裁判系统找他，坏的裁判系统贴上签找他更换。    负责人：



=== 一些物资没人采买
指定专门的人负责物资采买。
= 战术方面
= 问题总结

=== 关于运营的一些杂谈





+  在若干人员中分解任务会引发额外的沟通工作量——培训和相互沟通。
+ 因为我们对自己的估计技术不确定，所以在管理和客户的压力下，我们常常缺乏坚持的勇气。
+ Brook 法则：向进度落后的项目中增加人手，只会使进度更加落后。 
+ 同样有两年经验而且在受到同样的培训的情况下，优秀的专业程序员的工作效率是较差程序员的十倍。
+  一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法——既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。 
+  “因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。”由于对其他人的各种假设，团队成员之间的理解开始出现偏差。 
+ 团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册。
+ 团队组织的目标是为了减少必要的交流和协作量。
+ 为了减少交流，组织结构包括了人力划分（division of labor）和限定职责范围（specialization of function）
+ 项目经理的主要日常工作是沟通，而不是做出决定；文档使各项计划和决策在整个团队范围内得到交流。
+ 程序员不愿意为设计书写文档的原因，不仅仅是由于惰性。更多的是源于设计人员的踌躇——要为自己尝试性的设计决策进行辩解。
+ 缺陷修复总会以（20－50）%的机率引入新的bug
+ 只有懒散和惰性会妨碍高级语言和交互式编程的广泛应用。[如今它们已经在全世界使用。] 
+ 有时必须回退，推翻顶层设计，重新开始。
+ 一天一天的进度落后比起重大灾难，更难以识别、更不容易防范和更加难以弥
+ 里程碑必须是具体的、特定的、可度量的事件，能进行清晰能定义。如果里程碑定义得非常明确，以致于无法自欺欺人时，程序员很少会就里程碑的进展弄虚作假。
+ 慢性进度偏离是士气杀手。[Microsoft 的 <NAME> 说：“如果你错过了一个最终期限（deadline），确保制订下一条deadline。2”] 
