如许领导师长教师项目.doc

这样领导学生项目 我是这样领导一个学生项目的(1) 没想到在小组成立的第八天才想起来该为这个项目记下点什么，不是开发设计文档，也不是使用手册或者项目进度表，而是为了我自己的一些回忆。这是我领导的第三个软件开发项目，真正意义上的应当是第一个，因为这次是软件工程课程的实践项目，相比而言以前的两个只能算是体验软件开发的一些经历而已。同样的，作为真正意义上的Leader，或者PM（项目经理Project manager），我还是个新手。毕竟，软件工程这门课刚刚开始五个星期，区区十五个学时还不能带给我一些什么，因而我努力阅读了大量的书目去丰富我的知识体系。我希望这个项目能够获得我期待的成功，至少这门课程的结业成绩能够让我满意，仅此而已。当然，如果能积累下宝贵的丰富经验那便是额外的巨大收获。 过去的一周让我充实，我从未如此大量的阅读书籍，在过去的七天中，我翻阅了近十本软件工程相关的书籍，它们大多是经典的和有效的，大约六本我仔细钻研了每一个细节，剩余的我循着前人的笔迹也汲取了足够的精华（这些书大多来自图书馆，感谢那些喜欢在书上乱涂乱画的前辈，是他们给我勾勒出了重点）。很难说我究竟学到了什么，技术上的也许没有，或者思想上的本就可以形式化为技术，那我的收获是丰富的。让我寄予期望最多的是著名的《人月神话》，这个书名让我的许多朋友误以为是小说的东西（事实上，人月指的是工作量，月指month），的确是那样迷人。如果说这本书与其它的书籍有什么区别，那就是：我阅读一般的两百页的书籍能够大约为其中的六七个闪光点而激动得手舞足蹈，而这本书有超过十次让我兴奋地从公交车上跳了起来（我不鼓励大家在公车上阅读，对视力的影响的确很大，尽管这是节省时间的一个有效的方法）。我要说的是，仅此而已，毕竟这是一本几十年前的书籍，尽管在它二十岁生日的时候再版过（这也正是我所阅读的版本），然而它并非是专为软件工程而设，尽管被软件工程领域的专家们奉为圣书。 我的这个小组共有五名成员，很多项目经理不愿意将自己记入到成员数目中，一个典型的说法是：我们小组由我以及另外四名成员构成。这会使得项目经理变得孤立，特别是人人都对上司有天生的反感的情况下，这种现象并不仅仅出现在中国。在上一次的OOP（面向对象项目）中，有三个骨干成员保留到了现在的小组，另外两个中的一个是同样出色的一名成员，也是小组中唯一的女生。最后的一个是一个不折不扣的新兵，是一个还不知道OO为何物的初学者（也许这样说有些自大，似乎我们已经清楚什么是真正的OO一样）。他的加入是一个偶然，纯粹是出于哥们儿义气，这也是大多数学生项目会遇到的问题之一，你不得不去面对一些你并不愿意一同合作的搭档。如何将这样的五个人捏合在一起将成为我们的项目成功的关键。在人面前，技术将变得索然无味，记住这样一个事实，项目管理是面向人的。于是我不得不花去相当多的时间帮助他通过Java来入门，这缘于我对Java的热爱以及Java很可能成为我们的开发语言这一事实（请记住，永远不要做无用功，争取让你现在做的每一件事都可以成为将来迭代的一部分）。 不要以为开会是一个不好的习惯，适当的会议是必要的，甚至是强行要求的，因为它可以让你的项目受益，我们为什么不适当进行会议呢。我的工作就是从第一次会议开始的，一个惊人的举动就是我决定在今后所有的字面文档和口头交流中都使用英文，为此我们进行了尝试，第一个吃螃蟹的人总是弥足珍贵，你的项目中需要有这样一个人，他有足够的能力，并且愿意尝试新鲜事物，不惧怕枪打出头鸟的传统观点。庆幸的，我们有这样一个组员（多使用“我们”而不是“我”，是每个项目经理应当养成的良好习惯）。于是，英文的交流顺利地展开了，尽管大家还有些约束，特别是那个新兵的四级考试还没有通过，着实让我汗颜。然而，轻车熟路之后一切都没有了障碍，单词成为了我们交流使用最多的单位，而不是句子。 第一次会议是轻松的，不要指望能通过这次会议得到些什么，这是一次互相熟悉的会议，彼此需要互相熟悉习性、说话的习惯、喜欢的零食甚至迟到的时间，对于一个项目经理，掌握这些更为重要，我无意重复实践的重要性，实际情况的反馈往往是制定今后计划和策略的基础，也是最直接的来源，然而不幸的是，没有人可以为你收集这些资料，你需要做的是默默记在心里，然后转为今后的行动依据，一些估算往往由此而来。 我们确定了文档的重要性，尽管文档驱动被更多的书籍称作软件开发的黑洞，一些专家认为文档仅仅是官僚主义的作风，当然没有人否认适当的文档是绝对必要的。什么样的文档应当生成呢？你需要将今后可能查阅的资料组织成文档，时刻告诫自己文档是面向未来的，而不是面向过去。单纯的流水账似的总结没有意义，附加上从中获得的经验教训才是这类文档的灵魂。 还有可笑的预算机制，对于学生项目而言，没