CIO如何强化信息在团队中流通的方式？

  沟通这件事除了倚赖团队中每个成员自己的能力及自觉之外，其实为团队设计良好的机制及流程，也可以诱发团队成员间的沟通，做为一个导引和辅助的力量。

 有些程式开发者，即使他对程式语言和技术不那麽全面深入了解、撰写程式也不那麽的快，但是因为他能够适当的让别人知道他遭遇到的问题、请求别人的协助，也懂得确认自己所接收的资讯是否正确、避免因为资讯传达错误而衍生出种种的问题。所以这样子的开发者，反而能够在团队中扮演称职的角色，让开发的工作进展顺利。相反的，有些技术高强的开发者，如果被赋予一个需要大量沟通的工作，但他本身却不擅长沟通时，就有可能没有办法圆满的把工作完成。由此可见沟通对软体开发的重要性。

  需要流通的信息类型

  事实上，沟通这件事除了倚赖团队中每个成员自己的能力及自觉之外，其实为团队设计良好的机制及流程，也可以诱发团队成员间的沟通，做为一个导引和辅助的力量。

  即使不同类型的开发专案，在资讯的权限控管上会有不同的考量。不过我觉得对于资讯控管上没有特殊需求的团队而言，「尽可能的让资讯在团队中流通」是很重要的一件事。

  这包括了和开发有关的种种资讯，和专案工作排程有关的，像是现在总共有那些工作、每个人分别负责什麽工作、下一个开发的里程碑时限订在何时、这个里程碑抵达时需要完成那些工作等等。而和程式有关的则像是系统的架构为何、总共有那些主要的类别、每个类别的作用、它们是如何和其他类别进行互动……等等。

  也有一些和团队成员有关的，像是某成员可能在几天後要请假，或是某人最近身体或心理状态不好，可能没有办法全力投入在开发之类的。

  各种和专案本身、和需求规格、和设计、和程式码、和每个成员有关的资讯，都应该尽可能的在团队中流通，因为让团队中的成员知道愈多的资讯，他们便更有机会做出更好的决策、得到更好的工作结果。

   从极限编程看信息流通的意义

   在极限编程(XP)里主张「集体程式码共有(CollectiveCodeOwnership)」的概念。在这个概念下，专案中的每个人都有权力及能力，基于增加功能、修正错误，以及重构的原因，更动系统中的每一行程式码。

  而当我们谈到了「能力」，不禁会问到，要怎麽才能够让每个人都有能力来更动系统中的每一行程式码？除了本身技能之外，也得让和每一行程式码对应相关的信息(像是领域知识或是演算法，甚至是设计细节或特殊考量)，都让每个成员知晓，才能够让他真正具备更动程式码的能力。

   极限编程里怎麽达到这件事呢？

  它是透过搭档编程及系统隐喻等准则，来达到程式码的共有。透过持续更换搭档编程的对象，让不同的成员间得以都有合作的机会，每个人都有机会碰触到每一段程式码。

  而在搭档编程的过程中，透过这种特有的合作模式，领域知识、演算方法、设计思维，都可以在成员间流动、传递。我们可以说，极限编程透过开发方法及流程本身的设计，促进了这些信息在团队中流动。只要这些信息能够在团队中流动，这些信息就容易被更多的人所持有。

  使沟通顺利进行，让团队成员之间更乐于相互了解

  这正是本文的主旨，我们是可以透过机制的建立，来促进各种形式的沟通在开发过程中发生，而不必只是倚赖团队成员自己的能力及自觉。甚至，我们有机会利用这些机制，强化成员沟通的能力与意愿。

  以沟通所得到的效益，很容易可以构成一个正向循环。当团队成员发现这麽做可以得到好处，他们就更愿意沟通。一开始是机制的导入，随着大家在这过程中所感受到的好处，就会渐渐形成文化。

  就像我知道的一些团队，他们用IRC网路聊天室来做为团队中信息交换的中心。他们建立IRC的专用频道，每个成员习惯这个频道上，将自己正在做些什麽、打算做些什麽、有什麽想法，对于别人想法的评论或建议、等等的信息都丢上去。

  虽然不见得每个人随时都看着频道的内容，甚至不是每个人都一直待在座位上，但是，因为他们都会挂在该频道上，所以只需要检视频道内的信息，就可以知道其他人所丢出来的各种信息──即使这些信息是在自己的非工作时间被丢出来的。

  我相信，这一开始或许只是一两个成员所建立的机制，但是每个人融入这个机制後，享受到好处，也进而形成一个文化。这样的文化很好，也有一个机制来辅助，可以随时、随地都在沟通。因为有更多的信息在团队中流动，所以其他成员就能接收到愈多的信息，而这些信息便可以辅助他们做决策，使得决策的品质更好。

  在过去，我们可能很习惯利用定期或不定期会议的方式来做沟通，像是定期的进度会议来审阅每个人的进度、是否遭遇到什麽困难、以及讨论各种问题的解决方案。但是这样子的信息流通及沟通方式，受限于会议的参加者必须要在同一个时间出现，甚至不利用远距通讯机制的话，还得在同一个地点一起出现，都让信息流动的速率不够即时，也让沟通的频率显得有点过低。

  其实，这些在开发中的活动，都可以设计一些其他的机制来辅助的。像是，你可以利用规范成员撰写版本控制系统上的commitlog的方式，来让成员间彼此了解彼此的工作进展。

  怎麽说呢？一般而言，commitlog的的主要目的，是要记录你所commit到版本控制系统上的原始码，究竟是为了达到什麽样的目的，大致上做了那些事情。这样子的记录，有助于当我们要追溯版本控制系统中原始码的每一次变动，找出究竟发生了什麽事情。

   例如，我们在现行的原始码版本中，发现了一个重要的程式臭虫，为了找出这个臭虫究竟影响到那些版本，我们就得找出这个臭虫究竟是何时被埋到系统中的。

  每一次变动的commitlog,当然可以提供不错的提示及帮助。这有助于我们判断版本间的变化究竟是基于什麽原因、发生了什麽事情、以及可能会产生什麽效应。

  不过，除了上述的目的之外，其实，commitlog还有一个很好的好处，就是每个人都可以透过查看其他成员的commitlog,来了解其他成员做了些什麽事情;遇到感兴趣的部份，还可以把和该commitlog有关的原始码部份，都撷取出来阅读。

  这是一种有趣的方式，我知道有人会利用有空的时间去查看团队中其他成员的commitlog,看到有兴趣的部份，就会拿出来好好的研究一番。无论对方是不是高手，都可以查看、研究其他成员的程式撰写方式，看他解决特定问题的手法，看他的思维方式是否值得效法，或者是存在破绽。

  以上述的描述做为一个例子，commitlog除了原先就具备在版本控制系统上的好处之外，一方面，可以让团队成员间知道彼此的工作进展，二方面也提供一个彼此效法或相互审阅潜在问题的途径。如果，能够在团队中建立这样的机制，让大家开始也这麽做，渐渐形成一个文化，那麽，必然可以强化团队中信息流通的速度及品质。

   我相信，还有很多可以强化信息在团队中流通的方式，也衷心的建议大家不妨花点时间思考，还可以透过什麽样机制的建立，来达到这个目标。最後也还是再度强调，信息在团队中的流动，是再怎麽样也不嫌多的。