即将离开之际，趁记忆还在，留下一点关于ROC项目的反思和总结。
ROC项目现在进入一个阶段的break，自去年的5.18号提出，到6月4号真正启动，到目前，将近一年的时间。人员从最初的11人，中间FRK淡出，LQL和LXB也相继从事其他事宜，到ROC项目的系统构建时，人员稳定在8人。今年4月份后ZY和ZX毕业，人员降至6人，其中包括即将毕业的我，因此准确的讲是5.5人。经过了SDK构建，MVC移植，到系统的开发和测试，两大模块基本成型，于4.30演示，而后10多天的测试修复，终于推出一个较为稳定的roc2010 release版本，已告天下。
首先给ROC打个分数，我给70分。大部分的不足体现在管理探索、团队效率和最后软件的功能和健壮性3个方面。
管理探索方面：反思启动阶段我理想化的学习项目管理知识，调查各类项目管理平台软件，以及过于体制化的期待秩序的建立，导致自己浪费的大量时间，在真正可以发力的地方没有探索和深化。总结仍然是没有实事求是，过于教条主义，实验室环境必然和正规公司不同，很多东西具有自身的随意性和自由性。因此将本本的东西强加之上，最终是要消逝去的。不过，也许经过了才发现这些问题，管理初学者的一个毛病就是满腔热忱，看到的到处都是共产主义。
团队效率方面：这是我一直很头疼，却逃避去解决的问题。我非常期望形成战斗方队的氛围，譬如一起攻打一个高线，一起防守一波进攻。但事实上，大家时间上较为随意，且在实验室里非常自由，花在项目上的时间并不充裕。加上分配的任务检查周期较长，促使了拖延的发生。管理者在此处的自然反应是如何让成员花更多地花在项目上，效率更高，更快地完成任务。这是一个误区，但是我犯了另一个错误：一开始就制定了不紧不慢的团队节奏，导致了缓慢的挪动速度。
软件方面：需求没有很好的较早的定下来，导致随意修改软件功能，以及补丁式地开发。固然一个探索性的软件，功能不会非常明确的显现，需要逐渐去发掘。但是我们失败的地方是，凭此理由便拒绝深入的思考软件的功能，制定较为详细的说明书。导致后续一系列的问题，我才醒悟一个道理：凡事预则立，不预则废。
ok，现在我们来尝试解决问题。
作为一名管理人员，首先要改掉名字，协调人更能帮助定位。管理者的称谓会使人往家长的角色上靠，导致控制孩子的悲剧的发生--孩子并不是不想学好，但是家长自己急迫，忽略了孩子的感受，一味以为自己是对的，将意愿强加在孩子身上，并自己认为是以爱的名义：这才是世上最大的悲剧。小组成员也想把事情做好，但是你需要的不是把书本上，别人的经验照搬硬套，我们有自己的真实情况和特点。多花时间在研究自己孩子的特点，说起来简单，做起来为什么老是遗忘呢？
实验室里可以做到让大家同时在位置上，并且不在网上瞎逛，不玩游戏，电影……这种氛围能培养自然最好，但现实是同学们太习惯了自由自在的生活方式，很难束缚起来。不过话说回来，真的需要大家一直像公司里一样吗？实验室的特点岂不是没了？只要读好书，你是在教室里读，还是在操场上，或是在厕所里，有什么不同吗？因此，这并不是问题的本质，我们要解决的根本是：如何保质保量的完成任务。至于你是在实验室里，还是在寝室里，在白天，还是在晚上，都是旁枝末节的。逃离误区后，我们要做的是：任务分派的完整性--检查具体时间，检查范围的细致性制定。以及相应的积分制度和惩罚措施。此处比较麻烦的是：检查时间的估计，任务协调和惩罚措施。这是需要协调人去思考和努力的，自身的价值就体现在这个地方。此处也要另外提一点：适当的时候，可以安排团队成员在一起集中奋战，集中开发，集中测试，要的是让成员不忘团队的感觉，人心不散。
至于需求，很明确，建房子前要设计图纸，需求规格说明书必须是要的，如果说需求还不明确，那么把明确的给写出来，或者制定迭代开发的计划，什么时候开发原型，而后重新制定需求等等。先定下来做什么，再动手，这样也方便任务切割和分派，不会朝三暮四，游离不定。
经验教训大致就这三点了，或许还有其他琐碎的小点，但是纲举目张，"君子务本，本生而道立"，抓住这些主要矛盾，看清问题本质，较好地分析和解决问题，从而将实验室里的项目进行到底。
我不知道其他同学从ROC项目中学到了什么，但对于我而言，以上是我在这一年多学到的宝贵经验。因此，感谢geng老师，感谢ROC成员，感谢BVH。希望，或者是奢望有一天我们能看到ROC的子孙运行在游戏或者动漫动画师的电脑上，虽然那时候不知道是ROC的哪个版本，哪个名字。
是以记之。
王鹏 2010-05-16 教11-207