正在阅读：经验之谈:我是这样领导一个学生项目的经验之谈:我是这样领导一个学生项目的

　　主题的决定是艰难的，尽管否定了老师的推荐主题，我们仍然没有确定合适的替代者。我的建议是一定要围绕数据库开发，这样的好处是我们可以形成更多地UML图表（主要是类图），这也正是导师的初衷，主动去迎合他不是很好吗。于是，锁定在信息管理领域成为了第一个确定的范围。关于足球转会系统的设想失败了，因为我们的Requirements Manager（也就是那个唯一的女生）对足球不感兴趣，的确，很难想象让这样的角色去做不愿意做的事情，那对项目的损害是灾难性的。另一个提议是学生信息管理系统，或者通俗地讲就是做一个教务处系统，这是被我否决的提议。试想，这样一个系统导师和其他同学太过熟悉了，一旦包含任何的缺陷（这是必然的）很容易就会被发现，对于学生项目这是一个糟糕的主题。最后的选择是酒店管理系统，主要是面向前台的订房系统，这来源于需求经理的强烈兴趣，有时候非原则性的相互妥协是必要的，它可以激发团队的工作热情，更何况这是一个的确很不错的主题，因为它需要一定的专业领域知识，在一个项目中涉及到适当的专业知识可以使得需求范围进一步缩小，需求更加明确，同时可能会有比较多的现有系统来参考。不容忽视的是，并非每个同学和导师都会对这些领域的系统相当熟悉，也就容许了一些缺陷的偷偷存在。

　　我曾经试图将项目计划中的活动计划分发给每个人去完成，然而几经考虑之后不很合适，因为现在已经有太多的事情要做，为了保持团队的活力（一个重要的原因是我的课比起他们要少得多），我决定独立完成计划，当然这期间每个人仍然有自己的任务要完成，不要让任何一个人闲着，因为这表明对他的不信任和对他能力的低估，每个人都适当忙碌对大家都有益。项目计划也是有现成模版的，感谢Rational SoDA的模版，当然还有我综合各种文献进行的修改，使得文档的结构相当完善，好的结构是进行文档创作的第一步，需要再次强调模版的作用，前人的财富对于初学者总是享用不尽的。在制作项目开发进度的Gantt图（甘特图）时，我采用了Microsoft Project，尽管我不很愿意过多地使用Microsoft的产品（这是因为我是SUN和Java的忠实支持者，而非对Microsoft的技术抱有怀疑），然而最后还是选择了它，因为它太好用了，而且还提供了现成的模版，只需要根据实际情况稍作修改就可以了。尽管已经在计划上花去了太多的时间，然而这是值得的。我在制作Gantt图时耗费了一个下午（这还是在有模版的条件下），然而这一个下午我对项目的整个进程有了把握，明确了什么时候该做什么事，每件事的大概持续时间是多少。我惊奇的发现，风险分析已经和即将花去接近两个星期的时间，以至于我都耻于将这个事实记录在内，要知道，代码开发的计划不过是18天而已。这是个不很合适的比例，事实上两至三天的风险分析就已经足够了，对于学生项目而言可以适当放宽，因为还有其他的作业要完成。庆幸地，我发现代码开发的时间正好包含劳动节假期，这是一个不错的巧合。再次强调计划的重要性，这种重要性只有亲身做过才能体会得到。否则，一个无序的开发管理从一开始就泛滥了。没有完善的计划是项目失败的主要原因之一。

　　我们观察过几个现有的酒店管理系统，有几个是很不错的，各有特点，我们有了明确的方向和赶超的目标，或许它们就是我们潜在的假想对手。有了参照，我们的需求分析和原型搭建可以容易很多。界面相当重要，然而这不是Java的强项，至少不是AWT和Swing的强项，然而我们并不想贸然使用不熟悉的SWT，新技术的风险超过了获得成功的几率。稳妥和做好业务逻辑应当摆在首位，强大完善的功能同样不容忽视。经验告诉我们导师不会太多在意图形界面的细节，所以不必为了一两个像素的差别花去太多的时间，更多地放在提供足够的功能上，这是相当有分量的筹码。

　　每个人对我们的系统提供哪些功能有很大的分歧，即使对有几种类型的客户端都争论得不可开交，或许应当需求经理说了算，然而这是一个学生项目，每个人必须对自己开发的系统相当熟悉和满意才会充满热情，不得已的，每个人各自做一份功能计划书，下一次例会进行答辩，这是最民主的方式，也可以让每个人充分熟悉这个系统的功能范围。然后，一切才能继续。下次例会之后，一切都将明朗起来。

　　这是艰难的一周。一切都遭遇极大的阻力，新鲜感过去之后，后遗症出现了。有人出现了厌战情绪，有人时间紧张分不开身，混乱，成为了这一周的代名词。我有着不可推卸的责任。

　　我们首先试着确定项目的范围，或者说产品的范围，然而诸多的分歧让这个过程几乎停滞。我没有安排所有人很好的做调研，也没有安排所有人认真地去试用几个现有的系统，每个人都揣着自己的想法来到一起，这样也就罢了，更可怕的是很多人根本没有想法就来到了这里，于是对其他人的意见所能做的只有反驳。看来为了造成不必要的争执和尽快达到共识，事前一定要做好充足的准备。我曾经一度以为这个阶段我没有太多的事要过问，因为这是属于需求分析的阶段，我所要做的仅仅是组织开开会而已，现在看来这是完全错误的。这个阶段是最需要沟通和组织的阶段。一方面这是项目开始不久的阶段，大家的凝聚力还没有到可以脱离组织约束就能成事的阶段，另一方面这个阶段特别需要沟通，因为需求分析是后面所有活动的基础。我们的测试经理的一句话让我很有感悟：如果需求分析我不参加怎么知道我该测试什么东西呀。的确，这个阶段如果任何一个人对任何一个环节有任何的不清晰，哪怕是一丁点的模糊，累计到后面很可能带来的是整个项目的崩溃。

　　我安排了两个人去独立的完成use-case，然而不幸的是他们参考了同一个系统，做出了几乎一样的use-case，这让我始料未及，于是两个人的努力变得没有任何意义，我的初衷是对他们俩的use-case做一个并，现在不可能了。在分配任务前一定要交代清楚，不仅仅是做什么和大概怎么做，还有做的意义都要解释得很明白才行，这样会减少很多无用功。在我们尝试确定具体的功能性需求时，分歧接踵而至。我们对太多的事情不能达成一致，我们做的是酒店管理系统，可我们中的一部分人根本没有住过酒店，另一些人住得较多所以意见和反响很大，我们难以达成一致。更重要的是下周还有考试，这大概是学生项目最头疼的问题，兼顾学业。我们的进度一拖再拖，幸好一次停课的机会让我们重新坐到了一起。是进度表拯救了我，拯救了我们。我展示了进度表，上面清晰地反映出我们已经落后预定进度三天了，要知道项目仅仅开始半个多月。大家有了清醒的认识，不再苛刻追求功能的完美实现，我们砍掉了大部分的次要功能，将他们作为增量的形式发布，尽管谁都清楚这个增量版本等于是天方夜谭罢了。在不至于牺牲太多质量的前提下，我们达成了一致，功能少了很多，然而我们取得了空前的统一，对功能的需求相当清晰了，甚至一些初步实现方案也有了端倪。一切似乎又步入了正轨。对于学生项目，能够完成才是最重要的，重要的是体会这个开发的过程，产品功能是否强大已经显得不重要了。每个人完成任务的能力我也有所了解，这为我以后任务的分配提供了依据。每个人的能力也能从开始的几个任务中得到体现，事实上，这种体现暴露得越早越好。