打造高效的技术团队，我会关注的7个点

　　1：使用分布式的版本管理系统
　　如果你觉得不需要使用版本管理系统，那我们沟通会有代沟，如果你是cvs、svn的粉丝，或者由于某种原因没有使用过分布式版本管理系统，比如git，那强烈建议你去看一下“whygitisbetterthanx”。
　　2：一键式发布
　　这里发布的目标位置，既可以是开发机，做本地测试；也可以是测试机，为QA准备好捉虫游戏的森林；还可以是生产环境（或者beta环境），供用户直接访问。
　　如深度xp一键恢复系统一样，一键式发布需要自动完成很多工作：代码自动化测试（开发阶段），打包压缩，编译（测试阶段），数据同步（外网）。也许还有很多工作要加入进来，但核心是是否能通过一个脚本的执行就全部完成所有流程，这点至关重要。如果中间多出几个环境，那将来一定会引入发布的灾难。
　　3：TDDBDD请对你自己写的代码负责
　　不要为了TDDBDD而TDDBDD，只要能及时获得自己写的代码运行情况的反馈就行，也无需一次把testcase都覆盖全。对于没有任何单元测试的代码，将来想引入单位测试，将举步维艰！如果，你认为测试完全是QA的事情，那你就花大笔的钱去招聘一个规模庞大的QA集团吧，期望他们能让你偷懒。
　　4：使用靠谱的bug记录工具
　　人脑的潜力虽然无限，但大脑皮层只会对进入缓存区的数据做高效的反应。记忆再好的开发，也可能被各种牛魔鬼怪折磨的忘记了昨日的痛（曾经产生的bug）。所以，从团队第一次提测，就应该使用靠谱的bug记录工作。所谓好记性不如烂笔头就是这个道理。
　　那一个靠谱的bug记录工具应该要记录这些数据：
　　bug复现的整个操作流程
　　产品需求中的正常情况
　　出现bug后，变成为什么情况
　　谁将负责修复这个bug
　　bug最后修复没有
　　至于怎么修复的bug，是重新设计还是漏提交了代码，我觉得无关紧要。如果一个bug修复的经验值得分享，可以单独做一次团队的技术分享，而这往往是由于对现有产品的（技术或者其他的）信息获取不够导致的。
　　5：尽快修复bug
　　我的开发经验告诉我，一个bug越晚修复，被修复的可能性越小，将来产生危害的可能性越大。试想，你刚提测或者发布的代码，出现的bug，往往你能最快得到解决它需求的时间，而时间在项目管理上是非常重要的。反之，如果积累了很多bug，且有一定时间了，那修复它就需要对所有相关的系统进行了解，这将花费大量你可以用来度假，娱乐的美好时光。所以，从团队一开始就贯彻这点，可以释放成员修复bug的压力。
　　6：给团队成员一个安静的环境
　　最近很多同学告诉我，白天基本上没有什么效率，总是受到各种骚扰。我们做一个假设：假如A同学进入最佳状态需要30分钟，那么如果他比较惨，在30分钟间隔内，他总是被打断，那么他一天都无法最高效的工作。又或者同学Bgoogle查询一个技术问，花费2分钟可以解决，但问同学A只要20秒钟（好吧，同学A表达很清晰）。这样同学B节省了100秒钟，而同学A至少损失了30分钟。
　　从这个假设，我们不难发现，如果能避免团队成员受到外来信息的骚扰，他就有可能更加高效的工作，从而写出更好的产品。而常识告诉我们，人不可能一直高效的工作，所以，我们应该利用好无法集中精力的时间去进行一些沟通。但分出这个界限显然十分困难，所以我觉得不妨这样：规定每天的安静时间段，在这个时间段，其他人都不能来打扰这位同学，而在非安静时间段，可以随意访问，从而让这位同学形成一个新的生物钟（人体的自我调节能力是非常强悍的）。
　　7：给员工最好的工具
　　做同样一件事情，如果使用工具A，消耗的时间为5分钟，而使用工具B，消耗的时间为1分钟，那我一定给员工提供B工具，即使B工具的价格是A工具的5倍。因为，假如人在连续高效工作中的抵抗干扰时间为1分钟，那么意味着B工具能保证高效工作的时间连续，而A将可能分散了用户精力，导致需要更多的时间才进入最佳状态。事实上，之所以要更好的cpu，更大的内存，更好的编译器，更好的编辑器，多显示器，都是让程序员尽快能回到核心业务上来，而在等待上花费更少的时间。
　　同时，别忘了，一把好的椅子也是维持更长高效工作时间的保证，所以，别吝啬，给员工更好的椅子吧，他们会感到你的温怀。