Dian团队组长培训活动总结
2007年的1月13日到1月14日,Dian团队第一次举办了针对组长及未来组长人选的培训活动,主要目的是增强未来组长的团队文化素养、提升项目管理能力、重塑项目流程概念、暴露自身各种问题等。应该说,经过这两天的培训活动,未来组长们还是能够从中得到一些经验和教训,特别是总结会上各个组代表的发言,确实都有所得、有所悟。因此,我觉得从形式上来说,这次培训达到了它的效果。
在这里,我主要从组织者的角度出发,重新来审视这次培训的过程,以期望在未来举办类似活动时进一步提升效果。
一、培训内容组织上的经验教训
培训从内容上主要分为三个部分:团队文化培训、Tiny Project和组长必读的学习。其中,Tiny Project演练占据了绝大多数时间,从最开始的流程概述到需求分析,再接着走完一个典型的项目流程全过程,甚至于最终将生成可用的代码并要求现场演示。这个项目虽小,但是绝对是五脏六腑一应俱全。这样安排的主要理由是:希望首先通过文化培训增进未来组长们的团队认同感,然后用这个实际动手的Tiny Project来增进未来组长们的团结协作的精神,最后在实践上升为理论,解读组长必读中所谈到的各种组长必须了解的知识或具备的素质,加深印象。这样的循序渐进的搭配应该起到了应有的作用,起码在解读组长必读时我可以看出来,大家会结合培训中遇到的问题来分析自己的问题,与这个文档中的某些内容产生共鸣。
不过培训内容之间衔接的还是不够好,这一点今后应该尽力避免,这与我们准备太晚有关。在组长培训的前一天,我们还在修改文化培训的PPT,这使得文化培训的内容并没有经过很好的审核和演练。Tiny Project前面的流程讲解与后续的Tiny Project活动PPT是两个独立的文档,之前也并没有互相呼应,所以做Tiny Project的过程中也忘记去回顾流程中规定的输出和活动的内容,没有注意实时的从理论上进行提高。TIny Project中的各种文档本应该提供一个范本进行参考,并应该严格要求文档的规范性,可惜并没有这样做,使得输出的文档风格迥异,不能直接应用于实际。组长必读的解读过程完全是照着Word文档来浏览,并没有进一步提取必读中的必读,恐怕收效会比较有限,实在遗憾。
二、培训时间安排上的经验教训
培训原先的计划安排如下:
- 1月13日活动安排
09:00~09:20:组长培训欢迎词
09:20~10:10:Dian团队文化培训
10:30~11:30:Tiny Project:介绍典型项目流程
14:00~14:45:Tiny Project:需求分析
14:45~15:15:Tiny Project:系统测试用例
15:15~16:00:Tiny Project:输入评审会
16:00~17:30:Tiny Project:设计程序框架
19:00~22:00:Tiny Project:实现程序代码 - 1月14日活动安排
09:00~11:00:Tiny Project:输出评审会
11:00~11:30:Tiny Project:评审点评
14:00~15:00:组长必读
15:15~16:15:活动总结
16:30~17:30:自由讨论
实际过程则有些变化:
- 1月13日活动安排
09:00~09:20:组长培训欢迎词
09:20~10:20:Dian团队文化培训
10:30~11:30:Tiny Project:介绍典型项目流程
14:00~14:55:Tiny Project:需求分析
14:55~15:15:Tiny Project:系统测试用例
15:15~16:20:Tiny Project:输入评审会
16:20~17:30:Tiny Project:设计程序框架
19:00~22:30:Tiny Project:实现程序代码 - 1月14日活动安排
09:00~09:45:Tiny Project:实现程序代码
09:45~11:10:Tiny Project:输出评审会
11:10~11:30:Tiny Project:评审点评
14:00~15:00:组长必读
15:15~17:20:活动总结
在活动安排中变化较大的是“活动总结”这一项,由于总结的时间花的比较就,所以直接就把最后的“自由讨论”给取消了——本来这个自由讨论就比较虚,属于灵活使用的时间。另外,“实现程序代码”则比预计要花的时间多,所有组都没能在第一天的晚上完成编码。不过我并不认为这个程序会花如此多的工作量,毕竟第二天做的是“输出评审”,而非“结题评审”,所以对软件个方面的健壮性、功能的完备性等都没有太多要求,一些无关痛痒的需求就算还没有实现,只要解释得当就可以不做——所有组的同学都没有体会到如何权衡和估计实现各种功能需要占用的时间,也没有主动的去裁减一些优先级较低的需求。
所以总体来说,培训的各项时间估计还比较准确,只要继续更新Tiny Project中具体的Project题目,这样的培训还是可以不断重复举行的——不过参加过的同学再次参加似乎也没有什么意思,所以具体何时再做一次、选择哪些培训人员等,都是值得讨论的问题。
在这样一个过程中,比较令人头疼的是对各个Tiny Project培训时间点的把握。我在操作时时时刻刻都拿着手机,确保时间在可控范围内,但这样做也难免在有些环节上超时,于是我只能将某些内容略过或从某些讲解环节里面挤时间。这一方面需要培训的主持人对Tiny Project十分熟悉,甚至于可以对其进行临场发挥,另一方面需要主持人具有一定魄力,及时终止一些耗时过长的活动,希望未来的主持人能真正在这两方面都做好。
三、典型项目流程简介的经验和教训
这个环节应该是本次培训的特色环节,应该说是其中最能称得上精华的几个点之一。xbull给大家准备的流程简介是他在年终总结中仔细思考得到的宝贵经验,要知道,他是Dian团队里参加项目类型最多的同学,软硬通吃,经历过各种磨难和考验,随着团队分工愈发明确,他这样的人才恐怕是再也难见。
不过遗憾就在于,讲解的过程并没有穿插互动,所以同学们最后印象并不深刻——从最后的回顾活动可以看出,新讲的东西并没有被大家接受的很好。而且,一开始就讲解ISO 9000与CMM4之间的差异似乎不妥,毕竟在听的队员大部分既不知道ISO 9000也不知道CMM4,更不谈如何去对比它们了,这样子的安排或许有点过于拔高。
四、Tiny Project活动过程的经验和教训
Tiny Project培训在整个培训过程中属于最难以操作的部分,不过由于在预备队已经成功举行过三次类似活动,而且对我个人来说,更有上十次类似培训的经历,所以我反而不会觉得很麻烦。整体来说,这个培训从时间把握和内容调配上来看还算正常,并没有出很大的问题。
不过其中最大的问题是:没有和其他的培训内容有机的结合起来。前面说过,没有有机结合的一个重要原因是准备过于仓促,没有预先演练,甚至于有些PPT在培训前一天晚上还在改,很有问题。另外还有一个原因,主要因为我自己过于习惯于已经约定俗成的思路,不想改变,所以这个Tiny Project只是预备队培训的延长版或者完整版而已,并没有很好的切合组长培训这个特殊的目的。具体来说,我本应该在每个阶段流程开始之前回顾这个阶段需要输出的内容和需要进行的活动,不过我没有做;我本应该提示未来的组长们在活动中需要注意的问题,例如组长常会犯的错误、组长的责任等,不过因为我并没有在这方面与其他参加组织培训的同学讨论,所以也没有做;还有,“项目计划”和“进度管理”这两方面的讲解和演练缺失,实在非常遗憾。此外,Tiny Project中固有的一些问题我还是没有真正的解决好,比方说各个环节的评分标准等,这一次依然还是在看感觉酌情给分,尽量平衡每个组的得分,不太好让后来者继承。
对于Tiny Project的模拟项目选题我也有一些担忧。这次做的“D语言代码信息统计工具”实际上与H3 Mini Project中那个“C语言代码信息统计工具”很类似,当然,我设计的需求更为复杂,要求完成的时间却更短。这个题目如何设计才算是好呢?恐怕很难有一个定论。从2005年开始,我培训的题目先是一个“C语言代码分析器”,可以分析C语言的词法、语法等,非常复杂,到后来的统计C语言注释率信息的小工具,非常简单,再到增强版的C语言注释率,有些复杂,最后是这个D语言代码信息统计工具,难度进一步增加。这样的变化,虽说难度有升有降,但选题其实都是一样,并没有太多创新,所以经历过其中任何一次培训的同学,到后来如果再次参加就会有似曾相识的感觉,甚至能提前猜到我的底牌,这样当然就不好了。我们需要不断地在题目上进行一定的创新,通过把选题这个“汤”换掉,来吸引同学不断来吃我们的“药”,达到持续培训的目的,这就最好了。
因此,今后一个很重要的目标就是:多准备几套培训方案,希望能够在达到同样效果的前提下创造出更多更吸引人的形式来。
五、组长必读讲解的经验和教训
组长必读主要是xbull在Dian团队这三年多来的智慧结晶,特别是一些实用的管理经验和案例,令人深省。原先我的想法是从中再提取出“组长必读”的“必读”,用最精要的语言点破其中的精华内容,将好几十页的文档先压缩成几十句话,再通过展开解读来加深理解。不过因为xbull太忙了,所以这个环节并没有采用这种形式,而是直接对着Word文档来解读。
解读的过程中,通过结合讲解Word文档里面附带的例子,应该已经达到基本目的。不过也通过这次解读,发现文档中存在的问题,需要今后继续修订。希望各位未来的组长都去FTP上下载这个文档,然后自行修改,寄给刘老师、xbull或我。
六、其他的经验和教训
在所有活动中,我发现最后两个小时的总结非常有用。总结的最开始是我来组织大家回顾这一天多以来讲解过的所有重点内容,通过回顾,做到前后呼应,加深印象。之后,是各个组的组长和各个组分别选出来的一位组员进行活动总结发言。这个总结发言不同于一般,因为我所要求的是结合组长培训的内容,站在组长的角度来总结这一天多以来的所有经验教训,当然以教训为主。在这里,所有上台来的同学,包括组员,也要站在组长的角度来思考和总结问题,特别是上台的组员,必须指出组长存在的问题,以及如果是自己来做组长会如何改进。通过听大家的总结,我甚至能发现自己的不足,我觉得,大家其实都是从项目中成长起来的,其经历和不足都会有些类似,但如果有机会这样开诚布公的自我批评,真的可以警醒很多人,使得大家不会犯同样的错误。
所以,我发现这个总结活动成了所有活动里面最为精彩的部分,也是最为精化的部分,我也毫不犹豫的砍掉了最后的自由讨论,让同学们有更多时间来自由发挥。
在活动的后勤准备上则有很大的教训。首先是电脑软件的安装和配置上,虽然我们事先调查过所有电脑安装软件的情况,但是的确忘记实际使用一下,保证一切正常。这个巨大的疏忽使培训中发生了好几起软件不能正常使用、甚至于不能联网的重大问题,也直接导致xp.ED小组只能靠U盘来互相拷贝代码和文档,严重影响了他们的发挥。以后做类似的活动,一定需要充分验证每一台电脑的可用性,千万不能再草率行事。
七、总结
组长培训活动整体来说是顺利的,我非常地欣慰,但我更希望这个活动会有第二次,并且能够不断延续下去。
我或许应该花更多时间来写下自己的想法、经验和教训,让这些宝贵的财富随着Dian团队发展而不断变得丰富多彩。

有话想说?请留下评论吧~~如果喜欢我的blog,欢迎订阅~~
评论
还没有任何评论。
留下评论