我心目中的理想测试团队
昨天 @左耳朵耗子 发了篇文章：「开发团队的效率」，对文中绝大部分观点都很认可，但关于团队小而精这点上，我觉得有失偏颇，于是回复了一条： 非常理想化的想法，但不接地气。小而精的全栈式团队，像一个曲线的波峰，看似美好，但不稳定。更喜欢朴实的工程团队，能安然处于谷底，每个人可能都不太牛，但通过各种土办法，能汇聚起来，所向。 由于微博的字数限制，读者容易断章取义。看大家的疯狂回复，只能淡淡一笑了。不过耗子既然约战，我详细写下，侧重于描述我心目中的理想团队。 耗子描绘的小而精，我的感觉是这样的：
每个小红点都是一个不错的全栈式人才。全栈的含义，一是多语言的快速掌握能力，消除技术锁，二是跨模块的业务深入能力，消除模块锁。这非常赞，是很多技术团队梦寐以求的追求。 我关注的是，怎么组建出这样一支团队？耗子全文中并没有给出答案，耗子描述了美好的终局，但并没给出实际可行的路径。能猜到的一种做法是，疯狂招聘牛逼的人才，看不上的都不要。对于现有人员，则严要求、高淘汰。这种做法，对于极少部分团队，是可行的。但对绝大部分团队来说，缺乏实际的可操作性，不接地气。 我更倾向于下面这种团队构成：
小红点是大牛，团队里有，但并不多。小黄点是小牛，正在快速成长为大牛。团队里更多是小绿点，技术基础不错，发展潜力好，但当下只熟悉某一门语言，在具体项目里，也只能为某一两个模块负责。我相信这是绝大部分团队的现状。 在这种现状下，我们回到耗子的主题：开发团队的效率。很明显，耗子的倡导是好的，但直接开搞，团队非死即残，只有很侥幸的机会能存活下来。面对现实，说说我的「土」办法。 第一步是承认现状，认清自己所处的环境。耗子所在的阿里云我不清楚，不多说。我待过的淘宝和支付宝两家公司，这么多年，从来没看到小而精的团队能持久存活。同时还有一点非常重要，无论自己多牛，需认清的一个现状是，大家都不是傻瓜，能在阿里一路带兵打将到带领团队的负责人，十个里面有八个都是不错的，否则阿里不可能做这么大。这么一帮不错的技术负责人里，肯定有不少人想过耗子想做的事情，为什么没去做或没做成？希腊的神谕真的不是鸡汤，认识你自己，无论什么时候都非常非常重要。 认清现状，很多问题会清晰和简单化。在不断的碰壁失败后，会发现一些可行的「土」方法更接地气并且更能实现理想中的目标。比如 对于软件开发中的「锁」，耗子的解决方案是： 一个程序员应该能够掌握多个语言，也能够负责多个模块甚至不同的职责。如果一个程序员觉得多学习一门语言，多掌握一个模块是件很困难的事，那么这个程序员本质上是不合格的。 这个解决方案，淘宝曾经的技术负责人三丰，支付宝 CTO 鲁肃等等牛人，都自上而下以及自下而上推行过，但现阶段来看都尚未成功。我现在的主要工作职责之一，是和鲁肃一起在支付宝推行全栈工程师文化，其实从 2009 年开始有尝试。我们尝试过让前端学 Java，也尝试过让 Java 工程师学前端。但后的解法，并不是发现培训不成功，认定这些工程师本质上是不合格的。即便认定不合格，在当下技术人才稀缺的情况下，你能怎么样呢？耗子给的是要求，并不是解决方案。 分工并不可怕。分工源自社会经济学，分工解决的问题，是效率提升。无论在传统工业车间，还是在互联网技术公司，分工依旧是提高团队效率「土」但有效的方式。分工的背后，是遵循人类社会发展的规律性，是术业有专攻。分工有两个非常关键的点：
