CIO如何强化资讯在团队中流通的方式

标签:沟通

访客:20918  发表于:2012-05-14 14:43:26

 有些程式开发者,即使他对程式语言和技术不那麽全面深入了解、撰写程式也不那麽的快,但是因为他能够适当的让别人知道他遭遇到的问题、请求别人的协助,也懂得确认自己所接收的资讯是否正确、避免因为资讯传达错误而衍生出种种的问题。所以这样子的开发者,反而能够在团队中扮演称职的角色,让开发的工作进展顺利。
  
  相反的,有些技术高强的开发者,如果被赋予一个需要大量沟通的工作,但他本身却不擅长沟通时,就有可能没有办法圆满的把工作完成。由此可见沟通对软体开发的重要性。
  
  需要流通的资讯类型
  
  事实上,沟通这件事除了倚赖团队中每个成员自己的能力及自觉之外,其实为团队设计良好的机制及流程,也可以诱发团队成员间的沟通,做为一个导引和辅助的力量。
  
  即使不同类型的开发专案,在资讯的权限控管上会有不同的考量。不过我觉得对于资讯控管上没有特殊需求的团队而言,「尽可能的让资讯在团队中流通」是很重要的一件事。
  
  这包括了和开发有关的种种资讯,和专案工作排程有关的,像是现在总共有那些工作、每个人分别负责什麽工作、下一个开发的里程碑时限订在何时、这个里程碑抵达时需要完成那些工作等等。
  
  而和程式有关的则像是系统的架构为何、总共有那些主要的类别、每个类别的作用、它们是如何和其他类别进行互动……等等。
  
  也有一些和团队成员有关的,像是某成员可能在几天後要请假,或是某人最近身体或心理状态不好,可能没有办法全力投入在开发之类的。
  
  各种和专案本身、和需求规格、和设计、和程式码、和每个成员有关的资讯,都应该尽可能的在团队中流通,因为让团队中的成员知道愈多的资讯,他们便更有机会做出更好的决策、得到更好的工作结果。
  
  从极限编程看资讯流通的意义
  
  在极限编程(XP)里主张「集体程式码共有(CollectiveCodeOwnership)」的概念。在这个概念下,专案中的每个人都有权力及能力,基于增加功能、修正错误,以及重构的原因,更动系统中的每一行程式码。
  
  而当我们谈到了「能力」,不禁会问到,要怎麽才能够让每个人都有能力来更动系统中的每一行程式码?除了本身技能之外,也得让和每一行程式码对应相关的资讯(像是领域知识或是演算法,甚至是设计细节或特殊考量),都让每个成员知晓,才能够让他真正具备更动程式码的能力。
  
  极限编程里怎麽达到这件事呢?
  
  它是透过搭档编程及系统隐喻等准则,来达到程式码的共有。透过持续更换搭档编程的对象,让不同的成员间得以都有合作的机会,每个人都有机会碰触到每一段程式码。
  
  而在搭档编程的过程中,透过这种特有的合作模式,领域知识、演算方法、设计思维,都可以在成员间流动、传递。我们可以说,极限编程透过开发方法及流程本身的设计,促进了这些资讯在团队中流动。只要这些资讯能够在团队中流动,这些资讯就容易被更多的人所持有。
  
  使沟通顺利进行,让团队成员之间更乐于相互了解
  
  这正是本文的主旨,我们是可以透过机制的建立,来促进各种形式的沟通在开发过程中发生,而不必只是倚赖团队成员自己的能力及自觉。甚至,我们有机会利用这些机制,强化成员沟通的能力与意愿。
  
  以沟通所得到的效益,很容易可以构成一个正向循环。当团队成员发现这麽做可以得到好处,他们就更愿意沟通。一开始是机制的导入,随着大家在这过程中所感受到的好处,就会渐渐形成文化。
  
  就像我知道的一些团队,他们用IRC网路聊天室来做为团队中资讯交换的中心。他们建立IRC的专用频道,每个成员习惯这个频道上,将自己正在做些什麽、打算做些什麽、有什麽想法,对于别人想法的评论或建议、等等的资讯都丢上去。
  
  虽然不见得每个人随时都看着频道的内容,甚至不是每个人都一直待在座位上,但是,因为他们都会挂在该频道上,所以只需要检视频道内的资讯,就可以知道其他人所丢出来的各种资讯──即使这些资讯是在自己的非工作时间被丢出来的。
  
  我相信,这一开始或许只是一两个成员所建立的机制,但是每个人融入这个机制後,享受到好处,也进而形成一个文化。这样的文化很好,也有一个机制来辅助,可以随时、随地都在沟通。因为有更多的资讯在团队中流动,所以其他成员就能接收到愈多的资讯,而这些资讯便可以辅助他们做决策,使得决策的品质更好。
  
  在过去,我们可能很习惯利用定期或不定期会议的方式来做沟通,像是定期的进度会议来审阅每个人的进度、是否遭遇到什麽困难、以及讨论各种问题的解决方案。但是这样子的资讯流通及沟通方式,受限于会议的参加者必须要在同一个时间出现,甚至不利用远距通讯机制的话,还得在同一个地点一起出现,都让资讯流动的速率不够即时,也让沟通的频率显得有点过低。
  
  其实,这些在开发中的活动,都可以设计一些其他的机制来辅助的。像是,你可以利用规范成员撰写版本控制系统上的commitlog的方式,来让成员间彼此了解彼此的工作进展。
  
  怎麽说呢?一般而言,commitlog的的主要目的,是要记录你所commit到版本控制系统上的原始码,究竟是为了达到什麽样的目的,大致上做了那些事情。这样子的记录,有助于当我们要追溯版本控制系统中原始码的每一次变动,找出究竟发生了什麽事情。
  
  例如,我们在现行的原始码版本中,发现了一个重要的程式臭虫,为了找出这个臭虫究竟影响到那些版本,我们就得找出这个臭虫究竟是何时被埋到系统中的。
  
  每一次变动的commitlog,当然可以提供不错的提示及帮助。这有助于我们判断版本间的变化究竟是基于什麽原因、发生了什麽事情、以及可能会产生什麽效应。
  
  不过,除了上述的目的之外,其实,commitlog还有一个很好的好处,就是每个人都可以透过查看其他成员的commitlog,来了解其他成员做了些什麽事情;遇到感兴趣的部份,还可以把和该commitlog有关的原始码部份,都撷取出来阅读。
  
  这是一种有趣的方式,我知道有人会利用有空的时间去查看团队中其他成员的commitlog,看到有兴趣的部份,就会拿出来好好的研究一番。无论对方是不是高手,都可以查看、研究其他成员的程式撰写方式,看他解决特定问题的手法,看他的思维方式是否值得效法,或者是存在破绽。
  
  以上述的描述做为一个例子,commitlog除了原先就具备在版本控制系统上的好处之外,一方面,可以让团队成员间知道彼此的工作进展,二方面也提供一个彼此效法或相互审阅潜在问题的途径。如果,能够在团队中建立这样的机制,让大家开始也这麽做,渐渐形成一个文化,那麽,必然可以强化团队中资讯流通的速度及品质。
  
  我相信,还有很多可以强化资讯在团队中流通的方式,也衷心的建议大家不妨花点时间思考,还可以透过什麽样机制的建立,来达到这个目标。最後也还是再度强调,资讯在团队中的流动,是再怎麽样也不嫌多的。

评论(0)

您可以在评论框内@您的好友一起参与讨论!

<--script type="text/javascript">BAIDU_CLB_fillSlot("927898");