本文简介：提问回顾与个人总结博客中，@HansBug 提出了一条评论，指出了我没有将话说明白的错误，我对此进行了回复。由于回复太长，阅读体验不佳，故放进此博客中。
当然，在这里也要祝下一届有一群更加负责任的助教团队，如果作为助教还是搞不明白自己应该把什么放在重点、把什么“助”教给学生，把自己的先验概率藏起来的话，那可能还是比较适合搞技术，和助教可能有一定的区别，希望软工课程组能够认识到这一点。
这段话的逻辑就很离谱了，不说先验的经验，难不成反而背道而驰才是好的？如果你们将助教们定义为先入为主，那么你们的绝对坚持且不容任何反对的姿态又是什么呢？助教应该做的就是将经验进行传递，而结果如何需要你们来证明，更况且助教们从未有过暴力干涉的行为，不知道你这样的指控从何而来。
我是这么理解的：作为软工助教，软工方面的经验当然可以先验，并且非常需要先验；但判断一个产品能否做得符合要求，恐怕需要对于软工这门课做一个较为准确的定位。如果您认为，这门课的定位就是做出来一个能在市场上正常存活的、真实有效的产品，那我无话可说；如果，我说如果，这门课的目标是让我们对软工有一个较为清楚的认识，并了解流程、进行实践的话，我的建议是，不对一个产品能否做好进行先验的判断。
还有，请部分老师和助教站在我们团队当时的背景角度考虑，选题已经选好并商议好，需求博客已经基本写完，士气高涨已经开始动手；同时，较为容易得到助教认可的航概题库已经被黄金点排名较前的队伍选满。您们对于一个项目可能会从头开始就失败的顾虑我们可以理解，但在这样的一个时间点去 push 我们换题，甚至说“继续做可以，但需要直接扣除你们需求分析博客分数”，这真的合适吗。
@小树o3o @潜行的蚂蚁 @Mokoghost 三位甚至不知道这件事情，因为我们并不想扰动军心，刚刚一鼓作气，怎可能在没有其他选择的情况下打退堂鼓？
但最后，我们三个 PM 顶着无数压力，仍然让这个团队正常地、坚持着做下去了，最终做出的作品无论是从实用性、功能性还是软工质量各方面都怎么说还较为令人满意吧。无论是 Alpha 评审还是 Beta 评审，某些人是否需要扪心自问自己是不是带着一个“这软件做不好”的先验概率，拿着这个软件和市场上卷了几十年的单词软件市场比较看事？别的团队我就不多说什么了，至少本团队，通过一次团队项目，无论是在软工流程方面，还是在技术栈、项目管理、宣传制作等各个方面，都有了很明显的提升，而且完成了一个相较于 6 人和四周的工程量较大且完成度较高的合作软件工程项目，无论是前端的 UI 界面的美观程度、用户体验，还是后端的词库数据、算法设计，都是较为完备且敢于展示的，我认为这是一个达到了目的的实践。
说出这话，也是憋了一个学期，没忍住说出的。其实老师助教们从最开始的博客，阅读博客、案例分析，到结对的出题改指导书、解决 issue、分析问题、压下学生暴动（x），再到团队项目的需求分析、跟组查进度、查看代码提出意见、答辩评审，其中存在着各种各样的抑或学生抑或团队的问题，整个过程下投入的心思和精力，我们都看在眼里。毕竟本身就是一门学分和投入极其不统一、很难平衡的课程，而且还在改革尝试中，无论是学生还是助教老师都不容易，这里真的非常感谢助教老师的付出。但同时，课程组在自己付出如此多的同时，同样是否也应当设身处地的为我们着想，站在我们的角度看看我们有什么路可以走？
尤其是昂神，一个学期付出最多（至少我是这么觉得的），从最开始的交流沟通，到结对项目的指挥控制，再到团队项目的深度评测、代码查看与指导、issues 与 mr 的使用指导、再到项目展示的分析总结，每一部分都让我们收获颇丰。但是金无足赤，评审时仍然保留着自己对于项目在最初时期的先验评价，以至于从评分表中一眼就能看出您是哪位助教。没有其他的意思，但如果能够在项目评估方面，做到更加客观公正，那么无论是软工，还是其他任何组织行动时，都会有更强的说服力和更高的群众支持力度。
说一点关于评分标准的改进吧。由于我们组需求分析被喷不行，但我们坚持认为我们行，因此“将军令状加入进评审标准中”，产生了今天的 Beta 评分标准。然而在这个评分标准下，仍然摆脱不了主观臆测：改之前，主观判断一个项目需求行不行；改之后，主观判断一个项目的军令状合不合理，这不是一回事吗（摊手）。这里贴一下 Beta 评审中预定目标的合理性：
预订目标合理性（10 分，并决定完成度权重）
预定目标完全合理，具备足够的挑战性，令人期待——10分，系数1.0
预订目标基本合理，符合北航大三学生应有的水准——8-9分，系数1.0
预订目标勉强合理，给人比较保守的感觉——6-7分，系数0.8
预订目标不合理，但仍有基本的标杆在——3-5分，系数0.6
预订目标很荒唐，完全不重视也不想认真对待——0-2分，系数0.2
其中，助教 6 十分看好“删库跑路对不队”，给了 9 的高分评价；同时十分不看好“美滋滋甜兮兮队”，给了 6 分，认为一个受众较少的项目也不应当有这么少的日活。不多做评价，可能确实是保守了一些，但是保不保守通常仅仅对于一个数字进行了判断，然而对产品具体在干什么进行一个更加客观准确的估量和分析才是更为关键和重要的。
昂神在我们队伍的深度评测博客中专门指出了我们所实现的需求为较为小众的需求，在这种情况下，我们的日活完全不是一个保守的估计，而是实打实的、通过对于本校学生问卷填写时间和位置分布、对于我们的宣传力度的估计，基于大部分背单词软件用户转化率而做出的一个非常合理的估计；而且如果这个背单词软件做的不够好，没有太大的应用性，一下子就被市场上各种背单词 APP 压下去了，哪里有人会使用我们的软件，因此也非常有挑战性。
恰恰相反，按照今年的这个标准，如果我们选择一个如航概题库这种受众巨大、工程没那么复杂的软件，队伍里六个人四个 OO 助教，我们可能能在起跑线就已经赢了，而且赢太多了。
其实我嘴巴上没说，其实我心里面知道，我已经赢了，而且赢他太多了。——吴强
那我们何苦不选呢？黄金点游戏玩了第五名，没有资格选择，那看来软工能评多少分就看黄金点游戏玩得好不好喽？开个玩笑。其实最初没做黄金点游戏时，我们也把这个可能排除在外了，原因很简单，就是没有挑战性（TO 删库跑路对不队和是兄弟就来摸鱼队所有成员：真的没有任何贬低题库产品的意思，两支队伍做出来的确实都很有应用价值，放过我，只是说句直话）。我们想做的是一个既实用有效、又能够有挑战价值的产品去做，我最初想做的其实是迭代开下来的 visual pytorch，但由于技术栈可能需要比较久的学习，这时老田站出来提出了 A4 纸背单词这个提议。最初我也觉得，背单词市面上东西太多，但当讨论起来的时候，我惊奇的发现这个背单词的方式正是我之前曾经用过的，但因为每次查词都要翻字典太耗时间而放弃的一种方式，顿感项目有趣，而且在问及身边众多人的时候，都认为这个 idea 比较好，我就觉得这个需求可能是 OK 的，那既有创新性挑战性又有价值的活谁不干呢？于是就有了我们的《近取 Key》。
但课程组的处理方式是：我认为你需求不 OK，所以你技术再怎么牛逼也不行。我不认为这是没有问题的。这导致了所有北航相关的、学生相关的作品有一个先天的需求优势，软工从做项目变成了做选题。
软工这门课，评价与给分真的是令人头痛的一件事，能说出现在的评价标准不那么好，但又难以给出完美的解决方式。我对于需求的合理性分析有一个想法，不知道合不合理：对于自选题目，我认为可以以“学生作品”的角度进行评价，尤其是不要拿邹老师这样的业界大牛来评价我们的需求是否合理，站在十层楼上是看不清地上的蚂蚁的，比如可以以队伍为组织形式进行有理有据的互评，在此基础上课程组再进行进一步的评价，这样可能会更加清晰准确一些。从这个角度来看，今年的评分标准改革，将一个个虚无缥缈的博客评分转为了实打实的项目的工程质量评价，非常的合理准确；但同时也可以加大力度对于项目质量提早进行教学性质的指点，如密码的安全问题、https 是否要使用、debug 模式是否要关、以及服务器的连接方式（如昂神答辩时指出的不能使用 root）、issue 的实践上的使用方式（这个感谢昂神在我们团队博客下面进行的许多次指导）等等。另外，能不能改成四学分或者六学分
今年改革了很多东西，无论是结对，还是团队的需求课程组审核、转出人员方式、以及项目的评分标准，有功有过，功远远大于过。在此只是对于改革的过进行了一些分析，如有冒犯，请多包涵。