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

　　第二次会议在一周之后举行，也就是昨天（还记得吗，我是在小组成立的第八天记录下的这篇文章）。一周以来，我明确了一个思想：项目经理必须和首席架构师分开，哪怕是四五个人的小型项目。这得感谢《人月神话》以及其他的软件项目管理的书籍（他们大多来自于机械工业出版社的软件开发技术丛书系列）。在以前的两个项目中，我都将项目管理和系统开发以及首席编程和测试融为一身，以至于曾经一个组员反问道：你都做完了还要我们干吗啊？的确，明确的分工是必要的，用人不疑，疑人不用。一个成功的项目经理应当懂得如何将工作交给适当的人去完成，而不是独自去完成所有的事。于是，我决定由另一个人来担任首席架构师的角色而不是我自己，这在我看来是一个破天荒的决定（尽管有些可笑），很多人（特别是学生和一些积极性不高的人）都会认为技术最好的人理应当成为项目经理，这也许也是我成为项目经理的原因，然而事实上要记住的是，项目经理是管理人的，而不是管理技术的，他所要做的仅仅是辅助首席架构师完成协调的工作，技术的事还是交给别人去完成吧。

　　我在图书馆花去了五个小时翻阅了几乎所有关于软件工程方面的国外书籍（不是我对国内的书籍作者有偏见，然而确实国外的教材要优秀的多，当然国内不乏鼎鼎有名的作者和同样鼎鼎有名的著作），从需求分析、设计到质量保证、配置管理，还有CMM，等等一切。我选出了九本书籍作为我们项目的主要参考书目。我为我们的小组设计了五个领导人（感到奇怪吗，我们一共只有五个人而已），分别是需求经理、首席架构师、质量保障经理、测试经理以及项目经理，也就是我自己。九本书的一本是所有人都必须阅读的，另外我为其他每个人选择了相关领域的各两本参考书，我认为它们是可获得的、经典的和有效的参考书，这是我五个小时的全部结晶。在每个阶段或者说每个领域，都会以特定的人为中心，其他人接受他的指派完成任务，这样做的好处是利用有限的人员让每个人能够尽可能多的体验到软件项目的所有阶段，请记住，这是一个学生项目，学习是第一位的。为什么要我亲自去选择参考书，因为我的时间比他们富裕，我免修了本学期的三门其他课程，因而我能够有足够的时间去做这些事情，同时，选择书籍的过程也是自我提升的过程，何乐而不为呢。

　　终于有人在第二次会议迟到了，直到我们收拾东西准备离场时才出现，后果就是我们已经分完了所有的职位，她没有选择地成为了需求经理。这并不是什么坏差事，然而对于这样的学生项目，没有真正的客户是一个很困难的问题。需求经理需要有强烈的自虐倾向，需要自己扮演客户、最终用户和需求分析师三个角色（如果你还不清楚客户和最终用户的区别，那太糟糕了。客户是出钱的人，用户是实际使用软件的人），这种经历恐怕是绝无仅有的，试想，一个人需要自己不断给自己出难题，然后去解决，太可怕了。那个新兵选择了质量保障经理，因为他认为这是个轻松的职位，不用太多的编写代码，他讨厌程序设计。事实上，我可以想象当他面对一大堆模型的时候他的反应。在软件项目中，如果你认为某一个职位是轻松的，那唯一的原因是你还没有真正理解这个职位的作用。

　　会议中我最后强调的是，每个人都应当适时地召开会议，并非只有项目经理才有权召开会议，如果必要，任何人都可以这样做。另外，软件项目不是生活的全部，每个人应当将更多的精力放到生活中去，比如陪伴自己的家人，或者处理其他学业，这仅仅是一个项目，是诸多生活元素中的一部分，仅此而已。

　　一周中我最大的工作是完成了项目计划的草案，这得益于我阅读的几本书籍，当然还有Rational SoDA，这是一个很棒的文档自动化工具，它的文档格式成为了我的设计标准，甚至教会了我许多Microsoft Word的使用技巧，比如自动生成目录。这份草案没有任何实质内容，仅仅是标题性的搭建了框架，所有的内容将在一周之内填充，为什么？因为我们还不知道项目的题目，除此以外的一切都会是徒劳。良好的准备是必要的，在组织任何文档之前都应当先建立模版或者框架，接下来的工作才是用内容去填充框架，而不是线性的编写过程。

　　也许我还做过许多别的事，然而八天的缘故已经难以一一记录，有一些大概已经在脑海里永远冬眠了，甚至我自己都难以提取形成文字。庆幸的是每个人同样可以获得这些，只要愿意去阅读一些经典的书籍，总能得到。

　　现在我能做的就是静静等待项目题目的出现，还有学习RUP，三个月之后项目交工之时我大约能够读完软件项目最经典的一百本书籍，这会是我最大的收获和骄傲。我喜欢从阅读中得到满足。

　　项目正式启动了，因为我们获得了一个导师推荐的题目，这是一个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，需要说明的是，作为一个学生项目经理，最好能够尽可能多地给出各种文档模版给大家使用，因为我们并不是总有很多现成的模版可以使用，而事实上很多人不是很愿意去寻找模版，所以比起之后再统一格式，一个好的选择就是尽早地分发模版，当然，这要占用项目经理的很多时间。