我是这样领导一个学生项目的(1)

类别:软件工程 点击:0 评论:0 推荐:

    没想到在小组成立的第八天才想起来该为这个项目记下点什么,不是开发设计文档,也不是使用手册或者项目进度表,而是为了我自己的一些回忆。这是我领导的第三个软件开发项目,真正意义上的应当是第一个,因为这次是软件工程课程的实践项目,相比而言以前的两个只能算是体验软件开发的一些经历而已。同样的,作为真正意义上的Leader,或者PM(项目经理Project manager),我还是个新手。毕竟,软件工程这门课刚刚开始五个星期,区区十五个学时还不能带给我一些什么,因而我努力阅读了大量的书目去丰富我的知识体系。我希望这个项目能够获得我期待的成功,至少这门课程的结业成绩能够让我满意,仅此而已。当然,如果能积累下宝贵的丰富经验那便是额外的巨大收获。
    过去的一周让我充实,我从未如此大量的阅读书籍,在过去的七天中,我翻阅了近十本软件工程相关的书籍,它们大多是经典的和有效的,大约六本我仔细钻研了每一个细节,剩余的我循着前人的笔迹也汲取了足够的精华(这些书大多来自图书馆,感谢那些喜欢在书上乱涂乱画的前辈,是他们给我勾勒出了重点)。很难说我究竟学到了什么,技术上的也许没有,或者思想上的本就可以形式化为技术,那我的收获是丰富的。让我寄予期望最多的是著名的《人月神话》,这个书名让我的许多朋友误以为是小说的东西(事实上,人月指的是工作量,月指month),的确是那样迷人。如果说这本书与其它的书籍有什么区别,那就是:我阅读一般的两百页的书籍能够大约为其中的六七个闪光点而激动得手舞足蹈,而这本书有超过十次让我兴奋地从公交车上跳了起来(我不鼓励大家在公车上阅读,对视力的影响的确很大,尽管这是节省时间的一个有效的方法)。我要说的是,仅此而已,毕竟这是一本几十年前的书籍,尽管在它二十岁生日的时候再版过(这也正是我所阅读的版本),然而它并非是专为软件工程而设,尽管被软件工程领域的专家们奉为圣书。
    我的这个小组共有五名成员,很多项目经理不愿意将自己记入到成员数目中,一个典型的说法是:我们小组由我以及另外四名成员构成。这会使得项目经理变得孤立,特别是人人都对上司有天生的反感的情况下,这种现象并不仅仅出现在中国。在上一次的OOP(面向对象项目)中,有三个骨干成员保留到了现在的小组,另外两个中的一个是同样出色的一名成员,也是小组中唯一的女生。最后的一个是一个不折不扣的新兵,是一个还不知道OO为何物的初学者(也许这样说有些自大,似乎我们已经清楚什么是真正的OO一样)。他的加入是一个偶然,纯粹是出于哥们儿义气,这也是大多数学生项目会遇到的问题之一,你不得不去面对一些你并不愿意一同合作的搭档。如何将这样的五个人捏合在一起将成为我们的项目成功的关键。在人面前,技术将变得索然无味,记住这样一个事实,项目管理是面向人的。于是我不得不花去相当多的时间帮助他通过Java来入门,这缘于我对Java的热爱以及Java很可能成为我们的开发语言这一事实(请记住,永远不要做无用功,争取让你现在做的每一件事都可以成为将来迭代的一部分)。
    不要以为开会是一个不好的习惯,适当的会议是必要的,甚至是强行要求的,因为它可以让你的项目受益,我们为什么不适当进行会议呢。我的工作就是从第一次会议开始的,一个惊人的举动就是我决定在今后所有的字面文档和口头交流中都使用英文,为此我们进行了尝试,第一个吃螃蟹的人总是弥足珍贵,你的项目中需要有这样一个人,他有足够的能力,并且愿意尝试新鲜事物,不惧怕枪打出头鸟的传统观点。庆幸的,我们有这样一个组员(多使用“我们”而不是“我”,是每个项目经理应当养成的良好习惯)。于是,英文的交流顺利地展开了,尽管大家还有些约束,特别是那个新兵的四级考试还没有通过,着实让我汗颜。然而,轻车熟路之后一切都没有了障碍,单词成为了我们交流使用最多的单位,而不是句子。
    第一次会议是轻松的,不要指望能通过这次会议得到些什么,这是一次互相熟悉的会议,彼此需要互相熟悉习性、说话的习惯、喜欢的零食甚至迟到的时间,对于一个项目经理,掌握这些更为重要,我无意重复实践的重要性,实际情况的反馈往往是制定今后计划和策略的基础,也是最直接的来源,然而不幸的是,没有人可以为你收集这些资料,你需要做的是默默记在心里,然后转为今后的行动依据,一些估算往往由此而来。
    我们确定了文档的重要性,尽管文档驱动被更多的书籍称作软件开发的黑洞,一些专家认为文档仅仅是官僚主义的作风,当然没有人否认适当的文档是绝对必要的。什么样的文档应当生成呢?你需要将今后可能查阅的资料组织成文档,时刻告诫自己文档是面向未来的,而不是面向过去。单纯的流水账似的总结没有意义,附加上从中获得的经验教训才是这类文档的灵魂。
    还有可笑的预算机制,对于学生项目而言,没有明确的所谓客户的概念,没有人会为你的付出买单,所有的开支都是有去无回的,对于许多并不富裕的学生来说任何的开销都倍加重要,请记住,没有一个一天只能吃一顿肉的孩子会为了打印一百页纸而花去四十块钱,他们更宁愿选择手抄。庆幸的,我们的小组成员虽然不能称得上富裕,但至少可以经常在菜盆中发现牛肉的痕迹。我们的预算(budget)机制很简单,也许称之为报销(reimbursement)机制更为合适:每个人先交十块钱给CFO(首席财政管,我们经常为起了这个名字而感到乐趣),也就是当然不让的那个女生,然后项目总结时一并从中报销开支,多退少补。就像许多班级收班费一样,简单的往往是最好的,因为它易于被最多的人接受。会议在轻松的气氛中结束,伴着混沌和锅贴的香味,看来选择食堂作为会议地点是一个不错的决定,因为这里足够嘈杂,不会让大家觉得拘束而不敢说出真实的想法,即使冷场也可以借用咀嚼的声音来打发无聊的时光。一个更现实的原因是,我们找不到其他的地方能同时拥有灯光、场地以及大声说话的权利了,我们没有会议室可用。请记住,这是一个学生项目。
    第二次会议在一周之后举行,也就是昨天(还记得吗,我是在小组成立的第八天记录下的这篇文章)。一周以来,我明确了一个思想:项目经理必须和首席架构师分开,哪怕是四五个人的小型项目。这得感谢《人月神话》以及其他的软件项目管理的书籍(他们大多来自于机械工业出版社的软件开发技术丛书系列)。在以前的两个项目中,我都将项目管理和系统开发以及首席编程和测试融为一身,以至于曾经一个组员反问道:你都做完了还要我们干吗啊?的确,明确的分工是必要的,用人不疑,疑人不用。一个成功的项目经理应当懂得如何将工作交给适当的人去完成,而不是独自去完成所有的事。于是,我决定由另一个人来担任首席架构师的角色而不是我自己,这在我看来是一个破天荒的决定(尽管有些可笑),很多人(特别是学生和一些积极性不高的人)都会认为技术最好的人理应当成为项目经理,这也许也是我成为项目经理的原因,然而事实上要记住的是,项目经理是管理人的,而不是管理技术的,他所要做的仅仅是辅助首席架构师完成协调的工作,技术的事还是交给别人去完成吧。
    我在图书馆花去了五个小时翻阅了几乎所有关于软件工程方面的国外书籍(不是我对国内的书籍作者有偏见,然而确实国外的教材要优秀的多,当然国内不乏鼎鼎有名的作者和同样鼎鼎有名的著作),从需求分析、设计到质量保证、配置管理,还有CMM,等等一切。我选出了九本书籍作为我们项目的主要参考书目。我为我们的小组设计了五个领导人(感到奇怪吗,我们一共只有五个人而已),分别是需求经理、首席架构师、质量保障经理、测试经理以及项目经理,也就是我自己。九本书的一本是所有人都必须阅读的,另外我为其他每个人选择了相关领域的各两本参考书,我认为它们是可获得的、经典的和有效的参考书,这是我五个小时的全部结晶。在每个阶段或者说每个领域,都会以特定的人为中心,其他人接受他的指派完成任务,这样做的好处是利用有限的人员让每个人能够尽可能多的体验到软件项目的所有阶段,请记住,这是一个学生项目,学习是第一位的。为什么要我亲自去选择参考书,因为我的时间比他们富裕,我免修了本学期的三门其他课程,因而我能够有足够的时间去做这些事情,同时,选择书籍的过程也是自我提升的过程,何乐而不为呢。
    终于有人在第二次会议迟到了,直到我们收拾东西准备离场时才出现,后果就是我们已经分完了所有的职位,她没有选择地成为了需求经理。这并不是什么坏差事,然而对于这样的学生项目,没有真正的客户是一个很困难的问题。需求经理需要有强烈的自虐倾向,需要自己扮演客户、最终用户和需求分析师三个角色(如果你还不清楚客户和最终用户的区别,那太糟糕了。客户是出钱的人,用户是实际使用软件的人),这种经历恐怕是绝无仅有的,试想,一个人需要自己不断给自己出难题,然后去解决,太可怕了。那个新兵选择了质量保障经理,因为他认为这是个轻松的职位,不用太多的编写代码,他讨厌程序设计。事实上,我可以想象当他面对一大堆模型的时候他的反应。在软件项目中,如果你认为某一个职位是轻松的,那唯一的原因是你还没有真正理解这个职位的作用。
    会议中我最后强调的是,每个人都应当适时地召开会议,并非只有项目经理才有权召开会议,如果必要,任何人都可以这样做。另外,软件项目不是生活的全部,每个人应当将更多的精力放到生活中去,比如陪伴自己的家人,或者处理其他学业,这仅仅是一个项目,是诸多生活元素中的一部分,仅此而已。
    一周中我最大的工作是完成了项目计划的草案,这得益于我阅读的几本书籍,当然还有Rational SoDA,这是一个很棒的文档自动化工具,它的文档格式成为了我的设计标准,甚至教会了我许多Microsoft Word的使用技巧,比如自动生成目录。这份草案没有任何实质内容,仅仅是标题性的搭建了框架,所有的内容将在一周之内填充,为什么?因为我们还不知道项目的题目,除此以外的一切都会是徒劳。良好的准备是必要的,在组织任何文档之前都应当先建立模版或者框架,接下来的工作才是用内容去填充框架,而不是线性的编写过程。
    也许我还做过许多别的事,然而八天的缘故已经难以一一记录,有一些大概已经在脑海里永远冬眠了,甚至我自己都难以提取形成文字。庆幸的是每个人同样可以获得这些,只要愿意去阅读一些经典的书籍,总能得到。
    现在我能做的就是静静等待项目题目的出现,还有学习RUP,三个月之后项目交工之时我大约能够读完软件项目最经典的一百本书籍,这会是我最大的收获和骄傲。我喜欢从阅读中得到满足。

本文地址:http://com.8s8s.com/it/it32030.htm