项目正式启动了，因为我们获得了一个导师推荐的题目，这是一个realty system，之所以推荐是因为它和Rational Rose教程中的例子是一样的，因而对于初学者而言有很多可以直接参考的UML模型，事实上，掌握UML是这次课程的重点。然而我们并没有打算做这个题目，因为我们不想依靠太多现成的东西，和更多的组撞车不是一个好主意，更重要的，我们既不能和现有模型太过相似，显然至少不能比它还要差，然而事实是这个模型已经相当完善了，我们没有了发挥的余地。于是在每周例会上，我们决定重新找一个题目。周例会也变成了每周两次，这样做是必要的，因为在开发的前期准备阶段，我们需要很多的时间来达成一些共识作为今后的行动准则，这同样可以营造出良好的讨论氛围和融洽的合作关系，为后面的开发做好铺垫，而这一阶段的文档要求并不高，工作量不大，有足够的时间来讨论。
不知道算不算一个明智的决定，我在题目决定之前就分发了风险组织的任务，因为我相信对于大多数项目而言，大多数的风险是相似的，这种相似包括可能性和影响级别，当然还有风险类别。也许80-20准则是适用的。现在看来这个决定暂时是明智的，因为在这个阶段我们没有太多的事可以做，或者说没有太多需要形成文档的工作。我们需要时刻保持对文档的熟悉，所以安排在这个时候做风险分析是合适的。我给出了一个模版，要求我们每一个人给出至少30条风险，其中至少有10条是和自己的角色相关的（比如测试经理必须给出10条与测试密切相关的风险），这样做一方面可以让各人更加熟悉自己的角色，同时也让各自风险雷同的几率小了很多，我们有更多的机会找到更多的风险。很快地，反馈回来了，这是第一次让我得到满足的反馈，Review Manager负责将这些风险组织起来，去掉雷同的并给出适当的翻译，可能会很奇怪为什么要这样做，我们一再要求所有的文档必须英文化，为什么还要多此一举把它再翻回来呢，因为在这些风险中，很多是来自于一些中文资料，每个人将它们用自己的英语生硬地翻译成英文之后提交了上来，面对那些蹩脚的英文或许翻回中文再阅读比较合适，当然最后还是要重新翻译成英文的。很快地，我们总结出了大约80条风险，去粗取精之后剩下了50条，形成了最终的风险表。不可能也没有必要对所有50条风险都做监督管理计划，我们选择了其中的30条形成各自的RMMM（Risk Mitigation Monitoring and Management，风险缓解、监督和管理计划），每个人负责6条的编写，当然都是和各自的角色密切相关的6条风险，所选择的风险或者发生可能性高同时影响也不低，或者尽管不大可能发生然而一旦发生后果很严重，它们都被列入了风险表并进行管理。同样地，伴随着分发的任务还有一份我制作的RMMM Template，需要说明的是，作为一个学生项目经理，最好能够尽可能多地给出各种文档模版给大家使用，因为我们并不是总有很多现成的模版可以使用，而事实上很多人不是很愿意去寻找模版，所以比起之后再统一格式，一个好的选择就是尽早地分发模版，当然，这要占用项目经理的很多时间。
主题的决定是艰难的，尽管否定了老师的推荐主题，我们仍然没有确定合适的替代者。我的建议是一定要围绕数据库开发，这样的好处是我们可以形成更多地UML图表（主要是类图），这也正是导师的初衷，主动去迎合他不是很好吗。于是，锁定在信息管理领域成为了第一个确定的范围。关于足球转会系统的设想失败了，因为我们的Requirements Manager（也就是那个唯一的女生）对足球不感兴趣，的确，很难想象让这样的角色去做不愿意做的事情，那对项目的损害是灾难性的。另一个提议是学生信息管理系统，或者通俗地讲就是做一个教务处系统，这是被我否决的提议。试想，这样一个系统导师和其他同学太过熟悉了，一旦包含任何的缺陷（这是必然的）很容易就会被发现，对于学生项目这是一个糟糕的主题。最后的选择是酒店管理系统，主要是面向前台的订房系统，这来源于需求经理的强烈兴趣，有时候非原则性的相互妥协是必要的，它可以激发团队的工作热情，更何况这是一个的确很不错的主题，因为它需要一定的专业领域知识，在一个项目中涉及到适当的专业知识可以使得需求范围进一步缩小，需求更加明确，同时可能会有比较多的现有系统来参考。不容忽视的是，并非每个同学和导师都会对这些领域的系统相当熟悉，也就容许了一些缺陷的偷偷存在。
我曾经试图将项目计划中的活动计划分发给每个人去完成，然而几经考虑之后不很合适，因为现在已经有太多的事情要做，为了保持团队的活力（一个重要的原因是我的课比起他们要少得多），我决定独立完成计划，当然这期间每个人仍然有自己的任务要完成，不要让任何一个人闲着，因为这表明对他的不信任和对他能力的低估，每个人都适当忙碌对大家都有益。项目计划也是有现成模版的，感谢Rational SoDA的模版，当然还有我综合各种文献进行的修改，使得文档的结构相当完善，好的结构是进行文档创作的第一步，需要再次强调模版的作用，前人的财富对于初学者总是享用不尽的。在制作项目开发进度的Gantt图（甘特图）时，我采用了Microsoft Project，尽管我不很愿意过多地使用Microsoft的产品（这是因为我是SUN和Java的忠实支持者，而非对Microsoft的技术抱有怀疑），然而最后还是选择了它，因为它太好用了，而且还提供了现成的模版，只需要根据实际情况稍作修改就可以了。尽管已经在计划上花去了太多的时间，然而这是值得的。我在制作Gantt图时耗费了一个下午（这还是在有模版的条件下），然而这一个下午我对项目的整个进程有了把握，明确了什么时候该做什么事，每件事的大概持续时间是多少。我惊奇的发现，风险分析已经和即将花去接近两个星期的时间，以至于我都耻于将这个事实记录在内，要知道，代码开发的计划不过是18天而已。这是个不很合适的比例，事实上两至三天的风险分析就已经足够了，对于学生项目而言可以适当放宽，因为还有其他的作业要完成。庆幸地，我发现代码开发的时间正好包含劳动节假期，这是一个不错的巧合。再次强调计划的重要性，这种重要性只有亲身做过才能体会得到。否则，一个无序的开发管理从一开始就泛滥了。没有完善的计划是项目失败的主要原因之一。
我们观察过几个现有的酒店管理系统，有几个是很不错的，各有特点，我们有了明确的方向和赶超的目标，或许它们就是我们潜在的假想对手。有了参照，我们的需求分析和原型搭建可以容易很多。界面相当重要，然而这不是Java的强项，至少不是AWT和Swing的强项，然而我们并不想贸然使用不熟悉的SWT，新技术的风险超过了获得成功的几率。稳妥和做好业务逻辑应当摆在首位，强大完善的功能同样不容忽视。经验告诉我们导师不会太多在意图形界面的细节，所以不必为了一两个像素的差别花去太多的时间，更多地放在提供足够的功能上，这是相当有分量的筹码。
每个人对我们的系统提供哪些功能有很大的分歧，即使对有几种类型的客户端都争论得不可开交，或许应当需求经理说了算，然而这是一个学生项目，每个人必须对自己开发的系统相当熟悉和满意才会充满热情，不得已的，每个人各自做一份功能计划书，下一次例会进行答辩，这是最民主的方式，也可以让每个人充分熟悉这个系统的功能范围。然后，一切才能继续。下次例会之后，一切都将明朗起来。
