Post by "xaep", 10-17-2007, 10:37
-----------------------------------------------------
十一前夕,公司组织大家进行了拓展训练,一个连的兵力分成七队,经过一天的艰苦训练,历经各种科目,最后在大家的共同努力下,全体队员在一半的规定时间内,顺利成功的翻越了毕业墙,登上了胜利的彼岸。我们获得了成功,每一个成员得到了毕业证,印证了我们每位都是勇往直前团结一致高效有力团队的一员。
然而回想整个过程,不免留下一些反思。我所在的小队共经历了5个科目:分别是木屐行走、信任背摔、盲人方阵、梯形钢丝及最后的毕业墙。加上别的小队参与的高空以及钻蛛网等科目,个人认为,所有科目中最具技术性,最能体现团队协作、过程控制、操作执行、协调配合的非盲人方阵莫属。而在所有参与科目中我队唯一没有成功的也正是这个盲人方阵。而作为从事软件开发这种尚称为高科技的工种来讲,这些体现出的团队素质得因素直接影响到项目的成败与否。可我们却... 不得不让我们有所反思。
以下为整个过程的简介,以此可以分析我队在科目执行中所存在的问题。
科目道具:
方形开阔场地,绳子一条,眼罩每个队员一个
科目规则:
1.在规定时间内将绳子围成一个正方形
2.所有队员均匀分布在四个边上
3.讨论方案20分钟,执行时间20分钟
4.执行期间所有队员戴眼罩,并不准说话
5.开始执行时有一名队员那绳子,其他队员打乱站立
(注:事后听其他队讲,规则中并没有规定必须所有队员参与,所以只要两个人拿着绳子围城方形就行了。这一点属于另个层面的问题,被归结为对需求的定义分析不准确,造成不必要难度而无法完成。对此问题现已无从考证,我队有30人,曾与教练确认过,得到结论为两边7人两边8人可以。就本人而言如果从这点字眼儿上考虑,就失去了科目的意义。这里我们就暂且把它当作对团队能力的挑战,而不是小儿科的脑筋急转弯)
下面是我队执行科目的大致过程(注,此科目为两个小队合作完成,共30人,此处为简单考虑,以28人计)
当教练讲解完要求后开始讨论,我队很快拿出一套基本方案:
开始执行后所有队员集中抓住绳子并站成一个排直线,再由第八个人开始与第七人站成直角,其他人与第八人站成一排直线,一次执行,在三次直角之后就可以首尾相连,形成一个正方形。
此后不断有队员提出各种问题,怎样站成直线?两个人怎样才能站成直角?如何知道是第八个人?大家是先找绳子还是先排队?大约七八分钟过去了,此时有队员提出了第二套方案:
预先订好四个人,当开始后,那绳子的队员先将绳子对折成四段,然后拍手让其他三人集中,每人拿绳子一角,通过摸索绳子角度,顺时针调整绳子角度为90度。四人都完成后,再拍手让大家集中,以绳子为基准最终站在四边上。
又有很多的问题提出,靠摸绳子的角度可以准确的得到一个正方形吗?其他队员集中时如何知道应该在哪一边上?如何能使四边均匀分配人数?又是七八分钟过去了,依然没有定论。此时又有队员提出了第三套方案:
鉴于前两套方案都存在一些问题,第三套是前两套的综合,预先订好八个人,当开始后,那绳子的队员先将绳子对折成四段,然后拍手让其他七人集中,通过站队转直角形成四方形后,有四个人负责拿住绳子角-伺角,另外四个人负责四条边-伺边,发信号让其他队员集中后,由伺边人员分别把适当的人数抓到边上。
没有太多的问题了,因为教练告诉我们20分钟就要到了,匆匆定了八个核心队员,给大家简单的讲解了一下约定的信号,一声哨响,正式开始。
冷风瑟瑟,摸索着找到了周围的两个比较近的队友,拉在一起便于同时集中。聆听几个核心队员窸窸窣窣的动静,突然有一种感觉,当视觉不再工作之后,其他感官变得灵敏起来了。不知道是应为寒冷还是紧张,旁边队员的手臂不停地颤抖着...“啪啪啪”掌声响起来了,大家一起向着声音的方向挪动。突然被一只手抓住,强行拉到一名队友的右边,很快又有一个队员被安排在我的右边,似乎站成了一队,似乎有了些眉目。可是猛然感觉到一个问题,为什么我没有拿到绳子呢?!只有等待了,其他队员的移动和拉扯的声音还在持续着,时间一分一秒的过去了。等待让人更加感到寒冷,终于听到了教练的命令:“大家原地不动,拿掉眼罩”。终于可以见到光明了,然而也确定我们失败了,因为我始终没有拿到绳子。眼前的景象证明了这一切,大家三五成群的站在一起,哪里有什么正方形。因为蒙着眼睛,整个的执行过程没有看到,不过事后回想一下整个的过程,还是有很多的地方值得反思。
也许大家觉得这只是一个小游戏,怎么能和软件开发这样复杂的工作相比。可能这正是我们轻视其中的风险,而失败的根本原因。好树才能结好果,正确的方法才能成功。那么为什么会失败?有什么可以措施可以让我们完成这项科目呢?
就科目本身而言,它是有一定的难度的,我们不能否认它是存在一些技术风险,正确的操作方法是保证顺利执行的基础。我们可以直观的感觉到,失败的主因是因为我们没有找到正确的方法。然而如果我们换一种角度,如果没有不能说话或是不戴眼罩的话,以上的任意一种方法都可以轻松的完成要求。从这点上来看,我们不难发现,操作方法本身并不是关键,而是如何建立起一套简洁有效的沟通管道才是问题的关键。然而由于主要的自然沟通方式都被禁止,从新定义全套沟通平台显然是时间所不允许的,那么所需要的就是在规定时间内,把操作方法中可能遇到需要交流与沟通的关键点加以重新定义,已达到对过程的可控。当然好的操作方法可以简化对于沟通管道的定义,也是决定性的因素之一。常听到“细节决定成败”这样一句话,在这里就可以得到体现了。这一点在软件开发的过程中有着清晰对应,那就是 spec。商业软件产品包含很复杂的定义和逻辑,还有大量的信息和数据,在长达数月乃至数年的过程中,单靠自然语言的交流将会成为团队各个成员之间对于产品定义沟通的瓶颈。就等同于我们蒙上了眼睛,闭上了嘴巴。这个时候建立一套对于产品功能定义的统一标准,就成为开发过程顺利执行的基础。这点在很多项目流程理论中都强调的很多了。另外在项目的过程中遇到不可预知的问题是很正常的,如何通过及时有效的沟通将问题解决,也是体现团队能力的标志之一。
就执行过程而言,在20分钟的讨论中,没能制定出一套可行的方案,仓促开始,是致使失败的主要原因之一。这里体现出两方面的原因,一是未能把握问题的关键,不能及时迅速的制定出主方向,从而没有时间进行制定细节情况的对应措施。二是无组织结构,职责不明确,有民主没有集中,造成效率降低。这说明在整个过程中,没有采取合理的流程和方式。项目管理中存在着相同的道理,需要有角色的定义,明确的分工,相互协作。在我们所做的项目中也常常遇到类似情况,对于功能设计方案各方想法不一,长时间的讨论不能统一认识,造成进度延误。在做结构设计时,开发人员和架构师之间对结构设计思想,反反复复的讨论不能达成共识,以致在开发过程中不能贯彻执行。另外在开发过程中,项目管理者关注一些次要问题,而将影响项目的主要问题忽略,使得项目失控。这些都是在开发过程中经常遇到的问题。另外在团队组建时没有明确分工定义角色,造成职责不明,相互干涉,重复管理或管理盲区。或为成本考虑一人身兼数职,致使决策时原则把握不清,偏离正确方向,做出一些偏激的决定。这些都是软件项目管理中的一些影响最终结果的风险因素。
麻雀虽小五脏俱全,短短一小时的科目,从需求分析,方案设计,实施操作到完成任务,有功能需求,有时间要求,需要协作配合,体现出了开发的整个过程。以小见大,从最终的结果可以影射出一些我们平时工作中可能忽略的问题。在一直提倡专业的现在,可以说我们没有用专业的方式在做这样的一个科目。那么在实际的工作中是否也有同样的问题呢。作为新兴的IT行业,尚无法像传统行业那样用标准化流程和严格的标准来控制项目,仍需要我们每成员发挥出超出角色要求的能力,让我们的工作更专业,让我们的团队更专业,让我们每个人更专业。我们的毕业标准不应只是需要有力量和激情就可以翻过的高墙,而更应该是通过构思巧妙、默契配合,让我们迅速标准的围成正方形。
Reply by "J2.NETe", 10-18-2007, 8:49
-----------------------------------------------------
自己回去也想了想方案,认为迭代方法比较好:
个体-》手拉手成大圈-》大圈找等份点-》成方
一共四个迭代,任务完成,化繁为简~~
Reply by "WilliamLuo", 10-20-2007, 20:30
-----------------------------------------------------
盲人方阵失败的教训,确实值得深思!
我当时最大的感触是:有主意的人太多了,谁都想按照自己的想法做,实际上自己对自己的想法都没有太大的把握。听到别人的想法时,好像有一种“先否决再说”的感觉,而不是首先想到时间有限,抓紧时间对别人的方法进行完善。20分钟都无法对一件小事定下方案,确实很能体现沟通效率的低下。
另一个感触是,我们这么一支队伍确实比较缺乏纪律性。集合慢慢腾腾,站队歪歪倒倒。也挺像我们工作中的有些环节有令不行、有禁不止。
还有一个感触是:这种拓展训练确实对培养积极向上的态度和观念有帮助。有几个项目,刚开始觉得简直不可能,想想办法还真是实现了。
Reply by "robinshen", 10-26-2007, 17:57
-----------------------------------------------------
文章写得很深刻,几乎把项目中的各个方面都考虑到了,个人认为最重要的是两点:
1)一个团队要有一个能做决策,知道怎么去做决策的人,七嘴八舌永远都是失败的最大因素;
2)时间有限,不能没有头绪,要先确定项目实施中的几个关键点,逐一讨论解决。
最后问一个问题,楼主分析了这么多失败的因素,有没有人找到了最佳的解决方案的?
不能光说为什么失败,还要说怎么样才能成功不是,谁能给出一个能够成功的实施方案来?
Reply by "xaep", 10-27-2007, 10:01
-----------------------------------------------------
的确如此,集思广益,谁能拿出巧妙地方案来,社区是不是也可以个一个奖品:)
Reply by "WilliamLuo", 10-27-2007, 10:56
-----------------------------------------------------
奖品不是问题,不过我觉得这个训练科目的成败已经不重要了。如果大家都能看到这个失败所反映出的问题,训练的目的应该就算已经达到了。
这个事情让我联想起我们的软件项目,经常有一些小的技术方案选择,其实每个方案都是利弊参半、各有长短,我们的人却经常争论的不亦乐乎,有时候感觉仅仅是为了面子,就是不愿意接受别人的方案。如果每个人都能怀着“成就他人”的想法,问题本来可以变得很简单。
扯远了,回到训练科目本身。我记得最初有几个意见,一个说是先大家扯成一条直线,然后弯成方形,另一个说先鼓一个圆形,再让一个人推成方形,好像都有可行性。
如果对这个事情本身感兴趣的同事多,下个月可以法一个特别奖。(省的楼上的骂我)
Reply by "riyas", 11-02-2007, 12:16
-----------------------------------------------------
看了楼主的文章,很是佩服,也想参与讨论一下,所以在这里简单写写我对于这个的一些想法。
科目道具:
方形开阔场地,绳子一条,眼罩每个队员一个
参与人员:假定为16人
科目规则:
1.在规定时间内将绳子围成一个正方形
2.所有队员均匀分布在四个边上
3.讨论方案20分钟,执行时间20分钟
4.执行期间所有队员戴眼罩,并不准说话
5.开始执行时有一名队员那绳子,其他队员打乱站立
很多队伍失败的原因就在于混乱和无序。在眼睛被蒙住的情况下,失去了视觉判断,所有人的第一感觉都是茫然,并且严重失去方向感。所以,建议在开始的时候,由拿绳子的人来主导时间顺序。他先选择不动,让大家熟悉蒙眼的感觉,1-3分钟左右,当视觉引导逐渐被忽略的时候,开始行动。
方案:
一. 寻找所有队员
由拿绳子的人先凭借拍手声寻找到第2名队员,并在该名队员手中写阿拉伯数字2(重要步骤之编号,1号之能给2号编号,2号只能给3号编号,以下顺次编号),然后第2名队员拿着绳子,向任意方向迈出2步,将绳子绷直.1号队员不动,2号队员以1号为圆心,2步为半径,寻找队员成功后编号为3.此时3号队员继续2号之动作,2号不动,以3号掌声为准,开始顺时针旋转,配合3号.3号开始向2号的反方向移动2步(反方向由2号帮3号确定)
重点:编号后,被编号之人在行动时需要击掌示意行动开始,被编号4,8,12,16的队员需要击掌3下,让所有队员清楚知道队员寻找的进度.所有人行进方向一致,顺时针或者逆时针.
二.整理方阵
在第4次击掌3次后,16名队员全部找到.此时,由1号队员击掌5次,所有人拉着绳子向1号队员方向贴近(重要步骤之左手拿着绳子,这样方便等下把所有队员围在绳圈内),16号队员和1号队员通过拍手声逐渐靠近,并将绳子系成一个完整绳圈,大家紧紧贴在一起.此时需要刚刚拍手的4,8,12,16号4个队员,按从大到小的顺序,将1234 5678 9101112 13141516每4个人紧紧靠在一起.行成4边型的4条边.并且依靠身体的感觉,面朝面挤成小四边型.
三.扩大方阵
还是由4.8.12.16这四名队员为主导,4号队员拍手1下,属于4号的一条边后撤2步,完成后拍手1下,其次是8号,拍手2下,整体后撤2步,完成后拍手2下,12号,拍手3下,整体后撤2步,完成后拍手3下,16号拍手4下,整体后撤2步.完成后拍手4下。再轮到4号选手.依次顺序重复进行。这样,将绳子慢慢拉紧.(至于是不是一定会是第4组走完把绳子拉紧不是关键的, 因为在讨论方案的时候,没法描述在蒙眼状态下怎样去衡量绳子拉紧的程度).最后应该成为一个八边型。
绳子拉紧站好后,由1号队员拍手2下,由编号1。5。9。13的队员集体左转,同时向前2步。完成后,由1号队员拍手2下。此时4号队员拍手3下,再由4。8。12。16这4名队员集体右转,向前2步,结束后,4号队员拍手3下。然后依次按照此顺序想前1步走,直到1和16,4和5,8和9,12和13这8个人重合。
此时,绳子已经被大概拉成正方形。此方法大概利用规则间隙,一对一为下一位队员单独编号,建立了一套沟通方式。每个人编号后,就项目而言,是开始任务分配,形成了明确角色定义和分工,并且确定了8个主要责任人。整理方阵的时候,分成了4个部分,相当于建立4个模块,模块完成后,进行整体拼装。当4边在最小距离形成正方形的时候,大概就是编码结束阶段,扩大方阵的时候,相当于整体调试测验。
这个方案是随便想了一下,手动用paint简单模拟,大概可行。不过本身就是粗糙之作,其中肯定会有很多明显的纰漏之处,请大家发现后讨伐之际少扔几块砖头,不胜感激。 |
|