段念谈团队：直觉要比写在纸上的规章制度更重要

个人简介 段念，现任豆瓣网工程副总裁。 80年代开始接触编程（BASIC），可惜没有得到父母的支持。尽管大学所学不是计算机专业，但在个人兴趣的支持下进入软件行业，先后在华为、新太等通信企业任职，后加入Google中国。在软件开发、测试、软件团队管理等多个领域都有所涉及，近期关注的重点是团队建设，工程师文化推进。对于能够提升团队生产率和个人技能的方法感兴趣。

感谢马国耀对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至[email protected]。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。

   

1. Dennis老师你好，在各种技术会议上，你都是最受欢迎的讲师，但是在这里还是请您重新介绍一下自己好吗？

段念:好吧，其实我不知道最受欢迎这个是怎么统计出来的，我在好几家风格不同的公司里面工作过，从毕业之后，其实我第一份工作——现在说起来大家都知道那家公司，就是在华为。每次当我提到我第一份工作在华为的时候，下面的听众他们会有一些很奇怪的反映。当然我在97-99年在华为的时候，华为这家公司，对我来讲，还是蛮幸运在刚毕业的时候，就有机会去一个处于很快发展的通讯行业的企业。从华为离开之后，在通讯行业换了大概1、2家公司，从07年开始就进入到互联网的行业。也非常的幸运，进入互联网的第一家公司就是在谷歌中国。所以在谷歌待了4年之后，对于互联网行业有了一些自己的看法，而且也愿意去寻找一个相对而言，相比谷歌而言，更加能有机会的这样一些环境。所以从谷歌离开之后，我选择都是那么一些不是那么大的，没有那么足够大的这些互联网的企业，希望在里面能够用自己的方式去改变一些东西。目前我是在豆瓣，负责豆瓣主要的工程团队，再加上新产品的一部分的内容。

   

2. 那么对于多数人而言，团队文化是一个蛮抽象的概念，您感觉它是由哪些部分构成呢？

段念:团队文化的确是一个蛮抽象的概念。我觉得说，你可以从各种不同的角度去描述团队文化是什么。但是很难去说，你有一个具体的一定的切分的方式把它切成哪几块。我个人更倾向于把团队文化看成是一个系统性的或者说是一个在复杂系统里面的一个没有办法把它分解成一个一个小的模块的这样一个体系。也就是说，我会认为团队文化中间的各个部分都是相互交织的，如果一定要我来说它有哪几个部分，我可能会说，就像我经常说的一个比喻一样，一个种子要生长，它需要空气，需要阳光，需要水，需要土壤。我感觉在一个团队里面来讲，土壤就指这个团队本身它的基础，或者说组成团队这些人。这些人就决定了这个团队能到什么样的高度，接下来是这个对团队本身所需要的空气，空气在我看来就是无处不在——但是你感觉不到，但是又无处不在。在我看来它很像团队里面的惯例，约束，以及团队本身所形成的规范和规则。

   

3. 一些做事情的习惯？

段念:做事情的方式，对！做事情的方式，我尽量避免用制度这个词，因为我发现在一个团队里面来讲，很重要的是在规则之外一些所谓的惯例。也就是说，当我在决定周边事情或者是不用这样方式做事情的时候，很多时候并不是依赖于制度，而是依赖大家认为我们应该用什么方式做这个事情。当然，制度在这里，它一定是一个原因，只是在我自己的观察中，我感觉很多团队都有自己的惯例或者是我们用得通俗一点——潜规则就是了。

其次，除了空气之外，还有像水和阳光这些，这些就是一个团队里面你需要刻意去打造的。包括怎么样去建立一个激励员工的机制和体系，包括怎么样能够从上到下，包括从下到上的去建立良好的沟通渠道等等这些方面的内容。所以在我看来，你要说团队文化，我很难用抽象的词把它变成可以贴在墙上的词或者是什么之类的东西，我觉得看起来它更像是一个系统性的，整个团队在长期的磨合过程中间，包括一些外部的，有意识引导的过程中所形成的一种独特的，让这个团队可以去保持前进的这样一种风格。

   

4. 那你能分享一个或两个让你感触最深的团队，你刚才所说，比如说一些潜规则或者做事情的习惯是什么样的吗？

段念:在我自己的经历里面，还有蛮多这样例子的。我举两个例子，一个就是，这个可能是不那么正面的例子。一是在我02年加入了一家通讯公司里面，这家公司也是一个在国内比较大的一家通讯行业的公司，主要是做通讯集成类的内容，在当时也是比较火的公司。这家公司里面有很有意思的事情，就是它的整个团队推动事情没有办法依赖规则和摆在明面上的方式，很多时候都是要靠私人的关系和你私人的影响力去推动这些事情。作为一个在团队中间，一直成长的这个人你肯定不会觉得有什么不正常，你会觉得这件事情非常的好。但是作为一个团队外的人来讲，你进来的时候你就会意识到这里有很大的一个阻力，就任何事情你首先需要建立你的关系，才有可能做事。有可能某种情况下就是先做人，再做事一个完整的表述。但是对我来讲，我相信对于不愿意用这种风格去做事的人来说，这会变成一个巨大的阻碍和障碍。

   

5. 一个排斥这种多样性？

段念:对，他会很排斥，虽然说在明面上有制度，这件事情应该用什么样的方式来进行，但是实际来讲，按照制度去走的话，他是没有办法去走通的，你只能依靠私人关系来作为制度的一个基础，所以这件事情就变得，我认为一旦形成这么强的一个所谓关系的文化，你实际上在整个组织里就很难形成一个有效的执行力，那这种有效的执行力，往往只是体现在个人的身上，所以这不算是一个特别好的例子。

如果你要说到一个相对比较好的例子，我就说，那可能可以以像谷歌这样的公司为例。我在谷歌的时候加入这些团队，当时在好几个团队里面工作过，这几个团队，虽然风格都不是完全一致，但是都非常类似。这种类似性就体现在：第一，没有明确的边界，也就是说工程师也好，设计、UX的人也好，或者是上面经理也好，你会发现这些角色之间，他们并不会设置非常强的边界，这件事情一定是我的，那件事情是你的，这个方式反而能带来团队极大效能的提升，每个人都会找到在团队中间当时最需要做的事情，并且主动跳进去来做，没有人会说这个事情是你的，不是我的，所以你出了问题我不用管它。

那么另一方面来讲，大家对于每件事情的结果是有一个非常强的期望和期待的，也就是说每个人都会认识得到结果是自己这件事情最终的价值所在。所以在我看起来，当然这些东西，我相信，不可能写在某一个特定的规则里面，既不可能写在员工守则里面，也不可能写在公司制度里面，更不可能贴在墙上。但是这就是这个团队在很长的时间里面所形成的一个做事的惯例，这种惯例就使得这种公司可以始终以小团队的方式往前前进，我感觉这就是挺有意思的一个团队文化的例子。

   

6. 听起来很有趣，就类似说帮我做事情的时候，我下意识已经觉得是我应该这样做事情，这个时候就不再考虑什么规章制度，而是说本来就是这是我们做事情的方法？

段念:是，我会觉得说，做事情的时候大部分的人依赖的是直觉，我不相信每个人做事情的时候，先把规章制度拿出来看一眼，应该怎么做。这种直觉体现出来，就是你长期做事的方式和周围人的做事方式就直接影响到你。这个东西，不管是哪个公司里概莫能外，所以我会觉得说团队的文化为什么重要，或者是团队文化为什么在这点上来讲重要，就是我会看到很多公司，或者是很多团队，会把制度的建设，会把规则的建设，当成是团队文化的一个重要的组成部分。但是写在纸面上的规则和真正操纵的规则很可能是不一样的，我会感觉后者比前者更重要。

   

7. 没错。我很好奇，好的团队文化一定能催生出成功的产品吗？你是怎么样判断团队文化的好坏呢？

段念:这是个好问题。所以团队文化的好坏本身来说的话，我可以从两个角度来说，第一个是从个人的感觉来讲，比如说我在一个团队内，我是不是觉得这个团队是让我喜欢的，我们大家一起在做事情的一个团队，比如说从我的判断标准上来讲，这是一个很私人的判断的标准。但是离开华为，其实就是出于这样一个私人标准判断上的事情，所以选择离开。因为华为是一个很优秀的公司，只是它的团队氛围不适合我而已，这是一个私人的团队。但是从另一个角度判断，就可以说，你站在一个，这个团队它拥有利用这样的方式，能不能达成一个好的结果，我感觉这就要取决于它的团队文化和它做的事情之间是否匹配。所以从这个角度来谈论团队文化好坏的时候，我觉得可能不一定有绝对的标准。也就是说，我可以举一个极端的例子，就比如说互联网的公司，大家都会去信奉，或者大家都愿意相信说一个优秀的人或者一个优秀的工程师，可以在生产力上可以几十倍于一个平庸的工程师，都可以相信说我们保持一定的浑沌状态仍然可以生产出一个优秀的产品，但是我想这样的理念是显然没有办法用在制造企业上的。所以从这点上来说的话，一个团队文化本身，它是不是好？从这个角度上来讲，应该是和你想要做的事情以及你要达到结果这件事情相关的。

   

8. 我很好奇是什么样的文化氛围，催生了CODE这样的产品和开源项目呢？

段念:豆瓣内的CODE确实是一个蛮奇葩类的项目，我也听到过很多人对这个事情的描述，就既然已经有了GitHub了，为什么还要做CODE，其实这样的言论也不只是在外部，在内部也有。豆瓣实际上最早的时候，的确是用GitHub在做自己的一些代码的管理，code review等等之类的事情。最早豆瓣并没有想要去做一个code，而且这个事情是由工程师完全自发的一件事情的。最早的时候，我们最原始的想法就是觉得我们用了GitHub，然后发现GitHub里面code review一个process非常好用，因为它解决了我们一个很大的问题。以前豆瓣一直是把code review当成是一个最佳实践，但是在很长的时间里面，这个最佳实践都进行得不是很好，原因就是它的成本太高。每个团队做code review的时候，要么是一堆人坐在这里来review，要么就是团队小的时候，有3、4个人，每天用固定的时间，大家围着这个电脑看一看，讨论一下。但是不管是哪种方式，都很难坚持很长时间，因为成本实在太高。而且面对面的讨论和争论，有时候会演变成针对人这样一个讨论，就变得不太好了。

所以后面大家就发现说，Git中间的这样一个PR的交互方式，或者pull request的方式，使得大家可以不用面对面，而且可以确保说我一个人的code，可以被更多的人review，甚至是不在团队内的人的review，而且这个review过程中间讨论更充分，都有记录。就感觉这个方式真的是太赞了，那我们就做一个这样的东西吧。当时的CODE就是一个很简单的，实际上就一个功能，就是做PR这件事情。后面把它做上来之后，工程师就会觉得这个还挺好用的？要不我们干脆就给它多加点功能吧，后面就加来加去，加来加去，就变得越来越像GitHub了。

   

9. 这个不是某一个人命令，而是大家自愿的去贡献自己的功能？

段念:我记得去年的时候，我们大概看了一下CODE贡献者的名单，基本上在CODE贡献者名单里面，一共大概有60到80开发工程师的贡献，也就是说，当然大部分的开发工程师他的贡献量并不大，可能就是几十行，或者是一、两百行代码这样的状况。但是你会看到基本上会有很多和很大比例的参与度，也就是说这样的一个工具是工程师真正在用，并且愿意把它变得更好。当然另一方面也就是CODE的项目，不是公司内部一个有产品经理的项目，但是可能正因为如此，所以工程师有机会和意愿去把这个项目变得更适合自己的需要，而且工程师在这个过程中，也可以感觉到自己有更大的控制力。

   

10. 也就是相当于他实际的用户直接参与到这个产品的制造过程当中？

段念:是，这是一个蛮有意思的事情，我自己做一个给自己用的东西，如果觉得说CODE，正是因为这点的原因，所以在豆瓣内来讲，它会变成一个非常例外的，就完全不需要产品就能够被建立起来的一个项目。

   

11. 我这里有一个鸡生蛋，还是蛋生鸡的问题，是先有了好的团队文化，自然而然团队的效率就会提高；还是说，我们专注于这种提高工作生产率，团队文化自然而然就会好起来？

段念:我觉得可能这两者，如果让我来说，可能这两者之间的相互促进的关系，可能会更强一些，就好像这个可以和培养一个员工来做一个类比，我们说培养员工的过程中，你不可能先教会他所有的东西，然后他的效率就高了；也不可能是说你不关心他会什么，只是强调效率高，他会的东西就多了。这两者看起来应该是一个互相间促进的问题，那我们会说，我们希望一个员工变得越来越好，我们的方式首先就是先确定他在具体做的事情上，处于什么样的状况，是有能力还是无能力。如果他有能力，那么我们用什么方式，来让他做得更好；如果他无能力，我们怎么样来去建立他的能力，然后让他做这件事情。所以我感觉在团队上面来讲，和这件事情有很大的类比性。既不是说团队本身有了一个好的文化，就什么东西都解决了；也不是说团队本身只要去追求效率，就自然会有这样一个好的文化。这方面都可以举出很多反例来，比如说单从效率上来讲，那么要效率高，简单，加班就好了。但是一个团队，天天用加班作为效率提升的手段，你会不会认为它是一个好的文化吗？

   

12. 加班真能提升效率吗？

段念:效率有多个层面。从加班的角度上来讲，如果你把效率定义在我产出代码的行数上来讲，加班一定可以搞定这个事情。但是如果你把效率定义在说，我最终产出的结果，是不是给公司真正带来价值上来讲，那加班就不一定能搞这件事情，就看你效率怎么定义了。所以在这块来说，我感觉这是一个很容易想到的反例。所以从我的角度上来讲，我会觉得说团队文化和效率这件事情是什么关系呢？首先你要有一个明确的目标作为团队文化本身的一个推进的一个方向跟方式。那这个目标可能是我整个团队效率的提升，有可能是我整个团队达到某种状态会更匹配我现在业务的需求，也有可能是其他的目标。在这个目标下面来讲的话，你让整个团队朝这个方向去前进，给它设立一些约束，让团队尽可能自己去建立规则，变得越来越成熟，我觉得这就是在我看起来一个互相促进的过程，而团队变得越成熟，它的效能和效率就会越高，你就可以为它设立一个新的目标。在这个过程中间，作为管理者来讲，你可能需要小心的去呵护这个团队，自己生长出来这样一些特性，不要轻易做规划的事情，就觉得我认为这个团队应该是什么样的，我就按照我的方式给它砍，我觉得这种方式通常可能不见得会奏效，尤其是当你的团队都是具有高度的自觉性和自愿做事情的意愿的时候，这种方式可能是很难奏效。

   

13. 管理者提供的是服务，而不是命令是吗？

段念:从手段上来讲，我同意你的说法，但是我想强调更多的是说，管理者不要把自己当成是一个规则的制定者，你不要把它当成说，我认为它最终应该长成一棵什么样的树，你看它现在长得高一点，所以想把它剪掉；你看它现在长得方向歪了一点，所以你想把它扶正。但是我觉得，可能是作为管理者来讲的话，你可能在它的团队自己磨合和往前走的过程中，你需要有一定的容忍度，去容忍到它自己去寻找自己的方向，只不过你需要有一个明确的约束给它，我的团队的共同目标到底是什么，哪些是我可以容忍的，哪些是我不能容忍的，在这之外，我感觉你给它自由，让它去成长，有可能它会长得比你想象得更好。

   

14. 您刚才提到了培养一个新员工，在豆瓣是如何培养新员工的呢？

段念:老实说，豆瓣来讲在培养新人方面，从制度上来讲，我们还真是蛮简单的。因为豆瓣本身在新员工进入的速度上来讲，也不算是频率太高，尤其是工程师这边来讲，我们进人的频率也不算太高。一般来说，我们有几个机制去培养新员工，一个叫“新兵训练营”。“新兵训练营”这样的机制就是，当有大批的新员工进来的时候，我们可能会用一些密集的技能的培养，这种方式使他短期之内具有可以在组织里工作的能力，一般一个典型“新兵训练营”的方式，上午是安排课程，下午自己去做练习。每周，每个新兵会有一个mentor，每周这个mentor会和新兵训练营这边一起来碰一下头，看看这个新员工在新兵训练营中的表现，是不是有一些什么样的问题，针对每个特定的个人，是否需要调整一些具体的手段，包括有人可能是不适合他现在分配的事情，那我们可能给他换一个事情，这是有可能的。在新兵训练营之外，如果不是大批量人进来的时候，我们通常不一定有这种标准的面向他们的课程了，有可能更多的是通过mentor的方式，就每个新员工会有一个指定的导师，由导师去负责他的工作和负责他的成长，这个过程中的责任可能主要是放在导师的身上。

   

15. 他们的职责分别是什么？

段念:豆瓣开发和测试的工程师，首先从数量上来讲，大概是10比1这样的一个比例吧。第二，从职责上来讲的话，测试工程师我们给他定义的职责其实主要是在提升质量和生产率两个方向。这里是很有意思的一个点，就是说豆瓣测试的团队，从来不把发现尽可能多的缺陷当成是自己一个主要的工作目标。大部分时候，这个团队做的事情是围绕着我怎么样能够开发团队，可以更有效的去解决问题，也就是说怎么更有效的让我开发的产品发生尽可能少的问题，围绕着这个点去进行的。所以他们会做很多，看起来跟测试这件事情没有关系的事情。比如整个团队持续集成这样一个体系的维护，包括整个移动应用的打包，一键分发的机制，还包括我在移动应用中间报bug这样一些模块等等，还包括去研究一些具体的技术怎么能够帮助开发工程师更好了去做他的接口测试。像这些内容来讲，通常在测试团队里，做得会比纯粹的通过手工的方式，或者是脚本的方式，去在UI层面发现缺陷做得会更多一些。

   

16. 豆瓣有区别开发与测试工程师吗？

段念:有。

   

17. 带来的价值也更加的大？

段念:至少我是这样觉得。我会觉得豆瓣如果采用的是传统的让他们铺进来去做UI层发现缺陷事情的话，我感觉现在的测试团队在增加3倍，4倍，5倍，我感觉都不一定能搞定现在的问题。当然你也可以从那个角度来讲，那些豆瓣网站上有没有bug呢？当然有，有的，这个毫无疑问。但是你如果要这样说的话，这是不是测试团队本身的责任呢？我感觉这样很难做这样的界定。我见到在国内有一种不好的趋势和趋向，比如说一旦某个网站出现了问题，或者是某个产品出现了问题，大家会说，你看你们的测试太不专业了。可是你要知道，一个产品出现了问题，为什么是测试太不专业呢？这是一个很有意思的问题，是一个很有趣的逻辑。

   

18. <b>段念:</b>至少我是这样觉得。我会觉得豆瓣如果采用的是传统的让他们铺进来去做UI层发现缺陷事情的话，我感觉现在的测试团队在增加3倍，4倍，5倍，我感觉都不一定能搞定现在的问题。当然你也可以从那个角度来讲，那些豆瓣网站上有没有bug呢？当然有，有的，这个毫无疑问。但是你如果要这样说的话，这是不是测试团队本身的责任呢？我感觉这样很难做这样的界定。我见到在国内有一种不好的趋势和趋向，比如说一旦某个网站出现了问题，或者是某个产品出现了问题，大家会说，你看你们的测试太不专业了。可是你要知道，一个产品出现了问题，为什么是测试太不专业呢？这是一个很有意思的问题，是一个很有趣的逻辑。

段念:我本人并不喜欢加班，我也不认为说一个公司应该长期把加班当成自己值得骄傲的一部分。当然每个公司的情况各不相同，所以我也很难说到好和坏的区分，只是个人的偏好而已。豆瓣这块来说，我们不鼓励加班，但是这并不意味着豆瓣没有加班。实际上现在我这边一个新产品的团队，实际上在上周和上上周，分别有2天，我看他们就会加班到很晚。但是在这个过程中间，大家面向的是一个目标。

   

19. 大家是自愿的加班还是什么？

段念:大家面向是一个共同的目标，因为在两次加班的时候，都是因为在接下来的周末，就是在周五的时候，我们需要面向全部的人员做一个新产品的展示，那他们自己会有一个压力，他们很希望在这个时间点上，把自己的东西放进去，让公司其他人可以看到这样一个产品在这个方面的进展和进度，拿到一些反馈的信息，所以他们做了一个加班的决定。从这点上来说的话，我会觉得说，这种加班在豆瓣内来讲，肯定是会有的，但是的确发生的频率不是很高就是了。其次就是，你刚才问的问题是，怎么评价是吗？

   

20. 如何激励员工？

段念:这个问题太大了。从激励的角度上来讲，你要说豆瓣怎么激励员工，从我的激励原则上来讲，大概会有几个基本的原则。第一个，我会认为激励这件事情，当然所有的国内的数据上面都会讲激励最好是内在的，激励你的内在的内因，不要用外因来做激励。但是在这件事情上来说，我可能对它有一个不太一样的解读，我更愿意用“魔鬼经济学”里面的观点来去说这件事情，那就是说，每个人激励因素至少从三个方面来看：一个方面是纯经济型的，那你给他钱这样的概念；第二个是道德上的，我因为这件事情我认为它在道德上是正确的，所以我去做；第三个是social上的，因为大家都在这么做，而且大家都认为这么做是对的，所以我应该这么做。在我看起来，金钱类这样一个激励，虽然是最直接的，但是它往往不是最有效的，所以它最大的一个问题是你的金钱激励往往会改变了，金钱激励往往会改变了你这个激励本身的或者说行为本身的驱动力，这点在迈克尔 J. 桑德尔的《金钱不能买到什么》里面也阐述得非常清楚。

所以从这点上来说，我对激励有两点想法：第一个就是，我对现在的工程师团队来说，我会感觉大部分的工程师，你说他不喜欢钱这个是不可能的。但是对工程师来讲，他的确是有比钱重要的东西，那就是说我在整个团队中间被认可的程度，我做的事情被其他人认可的程度，我在多大程度上可以骄傲的宣称我是一个足够优秀的工程师，我在多大的程度上有机会可能成为优秀的工程师。我觉得这些应该是说，对于有可能成为优秀工程师的人来讲，应该是一个非常，可以说激励团队的一点。所以我们尝试在团队的环境里面，去把这些因素放进来。当然在具体的措施来讲，我们使过很多不同的方法，不是所有的方法都一定有效，但是从原则上来讲，我会尽量的把工程师自己的骄傲感或者是自豪感，或者是成为更好工程师的动力来作为激励大家的因素。

当然话说回来，我并不是完全反对金钱的激励，只是说我认为在一件事情来讲，直接的经济激励，往往会变成一个动机改变的原因，我更倾向于说，我们在一个相对较长的时间段里面来考察工程师的表现，及时的激励更多的趋向于用非金钱的激励，而把金钱的激励放在一段时间之后，对他工作进行评价的过程中间去考虑。

   

21. 最后一个问题是，豆瓣在评价工程师方面有什么倾向性？

段念:倾向性肯定是有的。从我的角度上来讲我觉得工程师，或者我对工程师的认知和认为，我不认为一个好的工程师，就是埋头，整天在写代码的，就叫一个好工程师。我会觉得说，工程师是一群解决问题的人，他们不是一群只能写代码的人。所以从这点上来说，我更倾向于工程师对于事情的结果，投入更多的关注。所以我们在工程师评价的倾向性来讲，我们会非常看中工程师的产出，而产出的定义主要来自于两个方面：一个是你做的事情，在你所在的产品和业务上带来什么样的结果；第二个，你做的事情在工程师团队内的效能提升上来讲带来了什么结果。所以，如果说得直接一点，你写了5千行代码，这不算产出，你的5千行代码达成了什么样的目的，这才是产出。所以从这点上来说，我们的倾向性第一个还是蛮明确的，就是面向产出。

第二个倾向性，我们认为工程师本身来讲，他用工程师的方式来做事情。当然同一件事情你有很多方式来做。比如我要做一件事情，我可以通过延长我自己的工作时间，我不停的把自己放到一个需要不断的加班的环境里面去，把这些工作达成；我也可以选择用一种聪明的方式达成这种事情。那很显然，我们会很强调，在评价体系来讲，我们会宣传后者，我们鼓励聪明的做事情，不鼓励你用笨办法做事情。当然，有时候笨办法是免不了了。

第三个倾向性，可能就是对工程师他自己开放程度和他自己团队内的开放和愿意分享的程度，在这方面来讲，我们会去鼓励和奖励这些愿意跨界，愿意去帮助其他的人，愿意去帮助其他团队去解决问题的人。在我看来，我心目中最理想的一个工程师的团队，很可能就是一个充满活力的，非常有创造力的，愿意去解决问题的，而且愿意去在整个工程师团队去分享和建立，把这个工程师团队变成一个让他自己觉得可以骄傲地方的一个团队。在我看起来，当然我不确定说，我们现在的环境已经是达到这样了，但是这至少是一个可以去想象的目标。