December 02, 2016

我从小组项目中学到了什么

这个学期有两门课进行了小组项目 (team project),分别是通信和 Java 课。迎来了学期的最后两周,小组作业即将收尾,在各种due的沉重压迫下,我竟然突然有了闲情逸致写了这篇文章,此处应该无数黑人脸。

本科的时候,课堂上的小组项目几乎都是水过去的,虽说也当过所谓的大腿,不过更多情况下是报别人大腿。至于课堂之外的团队竞赛类活动,因为我从来对这些活动没有兴趣,也没有参加过什么,就更没有体会过一个小组从头到尾一同做一个项目的挑战和乐趣。所以研究生入学的第一个学期,参加了这两个小组项目中,我觉得还是学到了非常多东西。

这个学期一开始,就启动了通信课的小组项目,项目要求选定一个和通信相关的问题,从学期开始持续到学期结束。由于最好的项目很快被其他小组抢走,最后分到我们的项目是安卓操作系统。不得不说,这是我非常喜欢的选题,我一直想找机会深入研究一下安卓系统,但是我们小组的其他成员对此选题非常不满,一直想着换选题。于是他们去问教授,教授说可以换选题,我们就出现了一个备选的选题——LiFi。LiFi 简单的说就是一种可见光无线通信技术,开灯便可接入互联网。我一开始就觉得 LiFi 不太有前景,我们能找到的资料也少,非常不支持这个题目。

我们小组的选题拉锯战持续了一个星期,8个人中有4个人支持安卓系统,有4个人支持LiFi,双方彼此不能说服对方。但是回顾起来,或许我做的是相当不好的:除了观点上在坚持,我并没有做过多研究,没有提供给小组充足的证据研究安卓系统的可行性,这就导致最后组里一个同学动摇了,于是我们最后的选题定为了LiFi。其实我想,觉得如果当时能够充分收集资料和小组讨论,即使仍然选定了LiFi,也会更好一点。

我们的项目一直做到期中,都没有太大进展,可能是因为不像其他小组,我们没有见客户的推动力,大家也找不到方向,仅是罗列了一切 LiFi 的技术和商业细节。直到期中前后的时候,我们去见了教授,和他进行了一个小时的交谈。教授给我们的建议,是让我们从一个分析员的角度进行分析,比如说,如果你是投资机构,你会给市面上的 LiFi 产品投资吗?教授让我们不要仅仅在报告中罗列事实,而是提出自己的想法,做 Critical Analysis,这不仅仅是从技术的角度去看,还有商业的细节,政策的辅助等等方面,这给了我们之后的研究和报告一个大方向。

一开始的时候,我特别不喜欢小组一起见面讨论,因为一开始大家的讨论的确比较低效,远远不如自己查找资料阅读效率高。不过渐渐地,我发现了小组讨论和小组协同的好处。总体来说,我的组员们还是很给力的,他们中有的人有非常丰富的信息和通信学习背景,可以从技术的角度给予专业的分析,也有组员能够提出很好商业分析想法,并写出细致的分析报告。总之团队一起讨论,相互借鉴取长补短,反而极大补充了一个人知识面的欠缺和思维的局限。另一方面,在交流中,我觉得我的英语水平还是得到了很大的提高,多说一些,进步飞快。虽然我从始至终一直听不懂其中一个印度同学的英语……(不过这个印度同学人真是好,承担了组里好多工作,为人也很友善。)

接着我发现,如果项目没有进展的时候,应该主动去推进它,而不是坐等着别人去推进。我们小组中没有一个明确的 leader 角色,也就是每个人都应该在需要的时候站出来推动项目,总领方向。我们在没有进展的一个周之后,我觉得我们需要推进下去了,于是我付出了一些努力,设定了每周固定的团队讨论时间,并且制定出了报告的大纲,接下来的讨论就顺利了一些。这或许对我也是一个很好的收获,因为我向来不是一个很主动的人,但是这次主动一点,发现还是有效果的。

我也发现在一个团队中,最重要的不是你有多少专业技能,或者你是不是leader,而是每个人找到自己适合的位置,不仅做好自己的事情,而且尝试着去做更多事情。比如我们小组有一个同学,和我一样,我们之前对通信技术几乎一无所知,所以我们在专业角度的贡献可能都差一些。但是每次会议的时候,她都会记录详细的会议笔记,放到 Google Drive 和 WhatApp 上,让大家方便查看本次开会内容和自己本周的任务。她还会每周都会提前为大家定好讨论室。我觉得这就很值得学习,或许这些事情很简单很基础,有些人觉得不值得去做,但是这些事情又有很大做的必要。每个人都有自己的长处,都有自己的不足,在团队中找到自己的角色,尽出自己应有的努力,我觉得就是对团队的贡献。

说到每个人在团队中的位置和职责,我在Java的小组作业中也深有感触。小组项目中,毫无疑问组员很重要。但是什么是靠谱的组员?似乎每个人都很喜欢大神,喜欢找大神抱大腿。这样的问题是,首先大神毕竟是稀缺资源,而他们也往往因为选了更难的课,课业负担更加繁重,另外即使大神人很好,一个人完成了最主要的所有功能,使小组得到了一个满意的分数,团队中的每个人又到底能从这次项目中学到什么东西呢?

Java 的小组项目持续了一个月。开始的时候,我们小组五人的进度过于缓慢,这导致了太多的工作压到了最后。上个周,我们多见了几次,终于有了比较大的进展。我们计划上周日可以写完,这周就可以赶紧写别的作业准备考试。然而,我们周日写了整整一天,一直在学校呆到周一早晨,也没有写完。不过的确实现了大部分功能,于是昨天晚上大家聚在一起的时候,我们信誓旦旦地说最后的功能应该很快实现,可以早点回家睡觉。而结果是,我实现一个功能的时候,报出了非常奇怪的错误,我们两个同学一起查代码,耗费了整个一个晚上也没能解决,而其他的功能因为这里的实现阻碍,无法继续推进。

到晚上 10 点的时候,我们组的大神忙完了其他项目的讨论,开始过来支援,一行一行看我写的代码,一行一行分析,一行一行改,然而似乎依旧没有太大进展。我们debug到凌晨两三点,IDE 到最后已经坏掉了开始随意跳错——我们将所有文档中的日期全部设为固定值,似乎不可能有任何地方调用 Date,但 IDE 仍然报错到系统时间,而接着,IDE 又报错到 comment 的地方。(如果有大神愿意看我们无比糟糕的代码,或许能解决我们纠缠了半天的困惑呢?)

于是,实在找不出哪里的错误,我们决定回滚到之前的版本,将这一天工作归零。我们一边写,一遍痛骂 Apache Derby,这个反人类的数据库,老师为什么不让我们用关系型数据库?不过,开源粉看到这里肯定很不高兴,怎么能这么说 Derby 呢?我只好道歉,其实还是我们自己的问题,我们的代码写的太渣了,太渣的代码拼在一起,就是牵一发而动全身的危害。——大家可能觉得这很奇怪,都上了研究生怎么可能写出这么渣的代码?事实上我隐藏了一小点十分关键的细节,或许都不是我们的错误,但是现在的确不是说出来的时候,只能说它的确发生了。

我承认到后面我很绝望,看到我的组员濒临崩溃,我觉得这一切都是我造成的,如果我能够顺利地将一切实现出来,就不会有这样的问题,或许现在我无比辛苦的组员就可以去睡觉了。我失落地跟我的组员说,都是因为我太渣,拖累了小组进度,我觉得我很抱歉。接下来的事情让我很感动,他们说没有,说我因为之前学的少,或许的确会有不熟悉的地方,但是一直在努力完成任务,这就是很好的队友。充满困意的我顿时困意全无,特别感动,觉得我的队友真的太好了。或许这就是一个小组协作的极佳示范,遇到问题的时候,相互鼓励,相互宽容,而不是相互指责。

这次 Java 作业暴露出我们团队协同极大的问题。我们一开始的分工就极度不清晰,几乎是没有怎么做需求分析直接上来写代码,这简直是致命的。而尽管我对数据库不太了解,却不知为何被分配了重要的数据库。后来发现,我设计的数据库问题不小,给今后埋下了好多坑。另外,我们一开始还在用 Github 协同,后来因为麻烦经常产生冲突,于是抛弃了 Github,改用微信文件传输,导致版本控制极为混乱。今后真的不能够这样了,不过好在,我们终于在刚才写完了,再也不必看到明天早晨的朝阳了,真的感叹良多。

为了防止搭便车现象,我们的每次小组作业都有Peer Review环节,但是由于其比重不得而知,似乎作用也没有很大。以下内容不是针对哪一组,不过似乎也有一些搭便车的事情发生。可能是因为组里人仍旧相对较多,或者我没有太在意一个人做多做少,所以如果有这样的事情,至少我其实是能理解的,然而显然并不是每个人都能忍受这种行为。当其他组员压榨着睡眠,牺牲着身体健康,一起尽心尽力为了共同把项目做好,即使有各种理由,搭便车可能也不能算得上是一个很好的事情。

总结来说,从小组作业中还是能学到很多东西的。我发现在我们学校,同学们尤其是中国学生,最喜欢选一些很硬的技术课程,而对一些相对偏沟通交流的课程置之不理。毕竟技术类的课程学完之后带来的对编程技能的收益很大,对找实习和找工作也有很好的帮助,而其他偏“软”的课程则不是这样。不过我们的course adviser和我们的想法却相反,他建议我们选一些提升综合能力的课程。虽然绝大多数同学都对这样的建议置之不理,但是现在想来也是有道理的,如何和他人沟通协作,共同完成一项工作或任务,与如何写出性能更好的代码一样,都十分值得学习,甚至或许长远来看,前者会更重要一些。

这篇文章暂且写到这里,在剩下的一周半,还有无数多的作业考试和展示,实在不能在写了。最后,感谢我的队友们,尤其是给力的 Java 队友,虽然他们应该是看不到这篇文章,但还是谢谢你们让我学到了很多东西,包容我的技术渣,大家共同努力做完一件事情的感觉还是很棒的。

Share with your friends: Twitter Facebook
comments powered by Disqus