关于作项目经理和架构师的一点点感想

    这是我第二次打着项目经理的名号来完成一个项目了，上一次结束以后，本来有很多感想，但是没有写下来，这次结束以后，必然又有一些感想，不得不写下来了。
    事实上，我这还算不上什么项目经理和架构师，如果你看完下面写的这些，你就会明白我其实想说的是什么。
    第一次是电子商务课的课程设计，任务是实现一个电子商务网站的任何一个功能，老师的要求很低，即使只实现一个用户注册的模块都可以，但是她给了我们3个月的时间，这是很充足的。
    在一开始，我并没有任何想法，我或许可以一个人自己做一个小小的注册模块算了，不用花什么精力，也或许可以和几个非常强的人一起做一个大一点的网站，负责其中的一个部分，这些都比较轻松，我也乐得去做。但是别人来找我一起组队，我也就答应了。当时我们的队实力很不错，编程不错的有好几个，我想，这样就比较轻松了吧。
    由于考虑到这是所有人第一次做项目，而我算稍微有点经验的，于是就自告奋勇去当了个项目经理，我觉得，既然是一个大家都认可的项目经理了，至少应该有比较大的决定权。
    第一次组织开会的时候，我们必须给这个项目做一个定性，我们究竟是只需要为了完成任务让老师高兴就可以了，还是把网站做的非常的完善面向商品化。前者只要有一个软件工程的流程，有UML，有版本控制，声势很大就足以搞定，而后者则必须非常谨慎的考虑市场和技术的完善性。我当时比较倾向于前者。但组内有很强的理想想把它做成一个非常漂亮的网上蛋糕店，并卖给蛋糕店用于网上销售，由此还展开了更强烈的期望把它进行扩展至卖鲜花、卖玩具、卖节日礼物。他们觉得这是一个创举。虽然我知道其实网上这种蛋糕店和鲜花店已经很多了，所以并没有像他们那样兴奋。我认为只要做得好，还是能够卖得出去的。
    于是我许可了大家一起做一个完善的蛋糕店的目标。接下来就是分工，组内共有7个人，并不是每个人都热衷于写程序，因为在考研的复习过程中，想考其他专业的学生又怎么会对这样一个项目有兴趣呢，况且对计算机没兴趣的也不具备很好的编程技术。于是我提出没有参与欲望的人就不用参加进来做事，最后挂一个名就可以了。这样既不会耽误他们自己的复习，也不会由于他们的漫不经心耽误小组的整体进程。组内的理想主义不太同意，认为大家都可以做一点事。那几位不想做事的还是给我解了围，说挂名吧。我觉得如果没有热情来做，又怎么会有很好的效率呢？
    接下来安排了今后的工作安排，因为大家都需要从头开始学jsp，所以首先需要安排一个月的学习期，然后接下来一个半月的集中开发。我定下每个星期开例会，大家互相确定一下学习进度，以便互相督促让那些学得慢的人有点拼劲。
    第一周的例会，都开始学了点，但还有人没有搞到jsp的书。我督促了一下。
    第二周的例会，java的基础差不多都有了，还有两个人没有开始学jsp。我提出布置几个小程序编写让大家巩固一下java的学习效果，有人不愿意做。由于每次例会仅仅是汇报一下各自的学习进度，几句话很快就结束了，有人提出以后不要开例会了，自己学习就可以了。可是你究竟有没有在学习呢？我没有同意。
    第三周例会，他们仍然没有学习，我再次催促了一下，仅剩一周就要开始开发了。
    接下来的时间，仍然只有两个人在孜孜不倦的学习，我开始对项目失望，毕竟当时不是我对项目有着那么大的幻想，当我调整了心态想配合大家大搞一场的时候，理想主义却倦怠。
    我的失望导致了我想放弃，最后做一个老师满意的就行了。于是第四周的例会我没有去召集他们，他们也没有提起要开例会。时间就任由这样过去，玩耍的依然玩耍，我们几个依然自己看着jsp的书。就这样到了5月底，不会jsp的依然从没看过书，交作业的期限越来越近了。他们终于开始有所醒悟，开始担心怎么做。于是我给每个人安排了一些任务，找模版、找蛋糕图片、设计静态页面等。还是完成了。到了交作业前的那个周末，不得不商讨网站怎么做。我又安排了一些流程，但是到了周末，大家仍然有自己的事去忙了，在他们做好的静态页、模版的基础上，我写了一些数据库操作，完成了页面的显示和转换，算是把一个简陋的蛋糕店前台给做了起来。就这样把东西交了出去。好在老师还算满意。
    这一次，我作为项目经理这个角色，在其中确实没有发挥什么作用，没有调动他们的积极性，没有督促好他们完成自己的任务。因为这是在学校，是一个课程的设计，不涉及工资，不涉及利益，任何人想做就做，想玩就玩，没有上下级，没有权利，因此管理这个词，只能用人际处理来代替。一个项目经理，只能用婉转的斡旋，来鼓动大家，而不是安排工作。一个倦怠的小组，靠一个项目经理的调动才能有工作的情绪，那怎么可以呢。
    因此我觉得，这一次，是作为项目经理这个角色彻底的失败。

    在这以后，我比较反感没有激情的团队，比较反感夸夸其谈自己踌躇满志却不行动的人。因此，在其后的一些组队的活动中，ACM和数学建模，对于我没有精力投入的活动，我会明确的告诉有意向要我加入的人我可能不会投入太多，对于我已经投入的活动，则必然会尽力去做，如果不做的话，也应该及早表达自己的放弃的念头。

    事情又到了这次的软件比赛，当初的组队者是4个人，这四个人都将是认真投入的人，我看出来了这一点，因此我参加了。
    在7月的夏令营中，我们四个都确定了彼此的念头，可以说，这一次将会比上次要凝聚的多。
    我又是担任了项目经理的角色。由于我们的是作一个游戏主题，因此大家提出了一些游戏创意，经过4个人斟酌以后，仍然没有结果。从夏令营回来以后，有了一些意外，组员生病在家，只剩下我们两个人。如果是其他的时候，我或许会果断地选择放弃，因为两个人实在是太艰巨了。但是这次不同，因为另外那个人是国荣姐，这个强人，有一个在技术上比我强的人，在学习能力上超强的人，能够给人以极大的信心。于是我们两个开始做这个游戏了，同时，我们也决定做万智牌的游戏。
    由于国荣姐没有玩过万智牌，因此我们两人必定要从最基本的地方开始探讨。于是我开始担任起架构师的职责。这个职责给人以崇高感，在我实际经历的过程中，我觉得我非常幸运，因为我最开始定下的架构一路做过来没有出现太大的问题，只有一些经过细小的考虑后被解决了的问题。
    再加上我们有一个现成的magicX可以进行参考，给我们提供了太大的帮助，比如数据库里的信息，如果让我们自己来设计表结构，也许就不会像他们这样合理和方便。在界面和功能的启示上，我们也获得很多。

    最开始分成的套牌编辑器和网络竞技场两大块就是借鉴MagicX，对于套牌编辑器是由国荣姐来做，主要是一些数据库的操作和图片的显示，当国荣姐把它做好的拿给我看的时候，我发现居然被她做得和MagicX一模一样，真是服了她了。
    网络竞技场最开始时我来做，在界面设计上我参考了MagicX，并考虑到实际需要去掉和加入了几个按钮。整个界面frame我分成了4块，四个Panel——玩家区，手牌控制区，聊天区和牌桌区，手牌和牌桌区需要容纳牌，于是我设计了一个卡牌类和一个牌套类（extends jpanel），卡牌类包含了牌的基本信息，牌套类则封装了卡牌类，用来检测鼠标事件和进行处理、显示。事实证明，在卡牌和牌桌之间加入一层牌套类使我们后来的处理工作变得容易。第二个设计就是消息协议，为了两边保持显示和状态的同步，必须在一方有改变的时候通知另一方作相应的改变。消息机制的实现和消息的格式曾经让我思考了很久，后来受java书上的一个例子启示，决定把聊天的消息和其他消息用同一个通道传送，在接受端解析。
    在编写的过程中我曾经有过一个不妥之处，即把所有的事件处理都写在frame的代码里，造成了文件的臃肿和查询的不便，这还是在和国荣姐的交流中领悟到的。在这之前，我对swing的分级分层的概念还不甚了解，在这之后才明白了各个swing和frame、dialog之间的关系。
    在这十几天的写代码过程中，有了什么重大问题马上和国荣姐讨论，两个人一起思考的效果会比一个人苦想要好，因为国荣姐喜欢追求完美，总想用最好的、最正常的方法来解决问题，而我技术知识不如她多，有些处理过程不知道机制是怎样，但总有些旁门左道的方法来处理问题，因此，一些架构设计上的问题就是这样在纸笔上的讨论中解决的，其中最重要的是牌套与牌的契合问题。最初的时候，我们讨论的是吧比赛用牌存到数据库的一个临时表中，用时查询，在实际做的过程中我发觉得这样并不是太方便，因此我决定把这些牌读到内存中，用卡牌数组存储。由于卡牌被牌套类封装，因此我自然在一张牌的位置发生改变时把卡牌和牌套的指针都改变。但是后来国荣姐告诉我她在处理手牌出牌这种事件的时候，频繁的牌套new和=null操作并不是太方便。于是两个人经过讨论，决定将卡牌放在内存这个想法不变，牌套的地址也不变，仅仅是在卡牌的移动过程中将牌套内的卡牌进行交换和改变。这样就解决了两个人的问题。事后我才想到，因为比赛中出现的牌是一定的，因此卡牌肯定不需要进行变化，这样太难管理，而至于卡牌放在手上还是牌桌上，这就由牌套内的指针的改变来决定，这确实最正常的解决方法。
    由于国荣姐是如此强的一个技术支持，以至于当我被错误郁闷的不行的时候，把代码发给她，她总能很快的指出我的错误所在。有这么一个组员，完成项目的过程就成了一件很愉悦的事情了。
    现在项目已经全部完成了，虽然说我们为了赶时间而牺牲了很多细节的功能，但是毕竟非常令人惊异的完成了它。

    在第一次的项目中，本来不积极的我打起精神后终被又气馁，第二次的项目中，本来觉得很没希望的我虽然在过程中一直并没有极其高昂的积极性，但最终越来越受到鼓舞。我觉得，一个项目，必须要有一个很积极的团队，一个理智的项目经理，才有了最初级的成功条件，然后才是这个团队的技术实力，还有资金等。我们这个团队的技术实力可以说是很强的，并不是最强的我，正好可以因为经验原因来做项目经理和架构师这个职责，我觉得这样的平衡是很好的。但是这样的平衡也要小心技术高强的程序员恃才傲物，完全不理会项目经理的话，在公司的金钱制约中，这当然是很少发生，但是在毫无制约的学校里，这些担忧就很有必要了。