三，团队协作和软件
　　从一个游戏来看团队协作
　　我以前曾经玩过一个游戏，相信也有很多同行也玩过，游戏很简单.在一个空房子里，摆满很多凳子，然后由一个人被蒙上眼睛，由另一个人在旁边指挥，什么地方应该转弯，什么地方应该往前走，后到达目的地，再一次，摘掉眼罩，由他自己决定.两次的速度相关是非常大的，结果也是显而易见的. 所以细节的实现更应该去相信员工自己，让员工自己来解决，而不是事无巨细的管理.
　　从版本管理软件的发展来看团队协作
　　大家在工作中肯定有用过很多版本管理软件，比如有名的有: vss，svn，git每一个都有各自鲜明的特点.
　　Vss: 它有这样比较明显的特点，整个过程基于锁定和解锁，如果你想修改某个文件，需要先锁定签出，然后修改完后再提交，提交结束后便解锁.这时如果有其它人需要修改这些文件，需要等别人提交后才能解锁，签出，然后修改完成后再提交.他对版本的管理是依赖于同时只有一个人使用一个文件，当然你可以选择vss支持的另一种更开发的模式，但是这个已经放弃了vss本身的优点，利用版本管理软件来建立起一个有序的开发的流程.以消除文件编辑的冲突. 同时带来的负作用是大家往往一半时间在等待其它人提交释放锁，而且在修改完成后，时刻要记得去提交.签出时也小心翼翼.
　　Svn:从vss过渡到svn，是一个自我解放的过程.每个人可以自由奔放的修改然后提交，如果提交的文件里没有别人修改的文件，只管提交，如果有，更新下再提交.在实际工作中，因为大家实现的是不同的模块，90%左右的冲突都由svn本身的合并功能解决了.只有极少部分需要手动合并，这要归功于svn的强大的合并功能还有忽略文件的配置等.它把可能的冲突转给的团队线下自身来解决，事实上，人的可调控性远远好于软件的强制性，很快采用这个版本管理软件的团队，制定出了一套协作的方案，使每个人的工作独立，相互没有影响，当然也同时促进了团队的架构水平和管理水平.
　　Git:从vss过渡到git，则是一种更大的自我释放，它的历史版本管理，不再完全依整服务器，文件提交也不再完全依赖网络，他可以仅仅只是先提交到本地，在本地积累到一定程度后，再一起提交到服务器.可以说一个本地副本在提交到服务器前是一个svn，一个分支，你可以自由的回滚，可以终提交你的决定.更多的工作交由线下自身来解决.
　　他们也呈现出了一种从封闭到开放，从软件限制转到人为管理转化的过程.很可喜的是每一次转化都极大的提高了生产率.也同时提高了团队的管理水平.
　　再回顾企业管理，总监下有经理，经理有部门，部门有组长，组长有成员.一级一级管控.如果有个办公室需要买一本书，可能需要给组长申请，组长再提交部门审批.一级一级.从想买到实际买到可能已经过了一周了.一周后，可能这本书没必要买了.当然在大的企业管理里，这样没什么问题. 但是我想如果把这种层级关系放开，由扁平化的组织结构来管理，再制定一定的机制让人员自我管理.这个效率会高很多.当然可能也会非常混乱.
　　对于小的团队来说，如果所有成员扁平化，每个成员都是团队里重要的一员，每个人都有权力做所有的事情.我想这一定会是一个更高效的团队.我举几个例子:
　　1，如果团队成员因为有病不能来，但是项目又要求他这方面的工作完成，我可以直接拿过来他的任务然后完成它.
　　2，如果我有一个模块开发完成，我可以直接拖到测试员，测试员直接接手测试.
　　3，测试员完成测试，反应出一些问题，可以直接递回我做修改.
　　我想权力越大，操作会越谨慎，我们不应该总是把大家绑得死死的.大家有了灵活性，反而不会去做一些实际上会逾越自己权力的事情.只在必要时去做.这个必要性，线下大家讨论制定出一个协议，然后执行即可.好像我们制造了一把斧头，但是我们不规定别人如何去使用他，线下我可以帮他们推荐一种比较好的挥斧方式，但是如果他喜欢，他也可以用别的方式来挥斧达到更好的效果.
　　还想说点什么
　　如果你是一个程序员，你是不是很想分享你的一个惊天的发现，可能是一个js的游戏开发框架，可能是你写的一个无比牛比的demo，有可能是你找出一个许久没有解决的程序的bug.也许是你花了两天时间终配置起来的nodejs成套的开发环境.你是不想希望得到别人的关注，领导的关注，希望有一些成感.那么你肯定也希望有一个能写点什么的地方.所以也希望有一个知识库，可以展现自己.