之前写过一篇文章《编程的精进之法》，这篇文章主要侧重于个人精进之法。然而现在已经不是个人英雄的年代了，我们需要再深想一步，一个团队应该怎么办？

当我们带领一个团队的时候，我们想的总是，如何做好任务分配、平衡团队战斗能力、交付最好的结果。于是做的时候就会下意识的去简单、被动的因材分工，那么随着项目的进展、人员的流动、各种意外的发生，我们在项目后期会感到处处掣肘，于是只能加班以示诚意。

我刚入行的时候，经历的各个项目都是如此，一直觉得这种事情就是天经地义的，直到认识了一个项目经理。该项目经理是个高人，他在项目开始的时候，问清楚每个人擅长的部分，然后让每个人去做自己不擅长的部分，不会？去找擅长的人帮忙。

（图片来自：cargocollective.com/）

比如，张三以前做过用户权限管理，李四以前做过单据管理，王五以前做过工作流。（交代一下例子的上下文，当时那家公司主要就做一个大的领域，不像现在前后端分这么清楚，项目经理有时候还要身兼Tech Lead）他就会说，好，张三去做工作流，王五去做单据管理，李四去做用户权限管理，遇到不会的，谁擅长什么你们都知道了啊，去问。

虽然看起来有点乱来，但是他负责的项目从来没出过问题。后来我加入了ThoughtWorks才知道，这是“把项目成功交付看作能力建设的副产品”口号的一种朴素实现。

很多团队能力不强，团队的领导者就总是在向外寻找方法和帮助。这个行为本身没错，但是做这件事的人往往无法摆正心态，很多人的潜意识是假设团队成员能力不变的，期待在此前提下通过一种魔法般的方法改变团队的绩效，这种思路在真实世界里是走不远的。

在ThoughtWorks，我们认为，软件开发中的一切问题，根本上都是人的能力问题。如何发展每个成员才是问题的关键。如果成员没有进步，始终是治标不治本的。所以我们采用的一切实践，不管是以前曾采用的还是以后会采用的，核心目的都只有一个：发展人的能力。因此才有了那个听起来很耸动的口号：“把项目成功交付当成能力建设副产品”。

如何发展人的能力？讲东西吗？不太靠谱，信息仅靠分享是没用的，我经常把刚讲过一遍的知识，让人复述；把结对时刚写完的代码全删掉让同伴重写一遍，能做到的人不多。记也记不住，做也做不到。

就像我之前在《然而培训并没有什么用》里说的，做练习？没时间，项目太忙了。而且，就算你有时间，我们拿出时间来做练习，你能保证到了跟练习不一样的场景下，团队成员们都能用好吗？把学会的知识在新场景下用好这件事，还是挺看天赋的。

讲东西不靠谱，做练习没时间，那难怪大家不考虑能力建设了。不过，如果我们反过来想，这个问题就变得没那么难办了，既然没有时间做能力建设，那么也许一切活动都可以看作是能力建设。所以那个项目经理的招数虽然看起来比较乱来，却恰恰是这个思路，我在项目开始的时候，不是着急去以最快的速度交付结果，而是通过任务分配，发展团队成员的能力。在一个较长的时期里平均来看，我们就是在以最快的速度交付结果。

（图片来自：cargocollective.com/）

所以，回到我们的主题，团队的精进之道就是把交付过程中的一切活动都看作能力建设，把整个团队构造成促进每个成员成长的生态系统。

说起来好像挺简单，我只要换个角度看就好了，然而想要做到却没有那么简单。这里面差异微妙而关键。

比如以上一篇文章《编程的精进之法》中讲到的方法为例。一个人要划任务、估时间、在做的时候计时、根据实际结果进行反思。我们可以把这个方法做成非常邪恶的、仿佛流水线上工人的强制要求。我不关心你为什么超时，就通过这种方法来控制程序员，要求每个人都严格按照一个死板而僵化的步骤做一些简单重复的机械动作。也可以用这个方法来锻炼一个人的自我认知和发现知识漏洞等能力，促使他以最快的速度成长，等他成长起来马上给他更重要的任务，比如评估技术、评估项目、带新人、做架构等等。这两种结果的差异，背后就是领导者认识的差异、团队成员认识的差异。这其中的不同早在很多年前，atv，就被一些大牛们观察到，作为敏捷宣言里的一句话表达了出来：“个体与交互 胜过 流程和工具”。

（图片来自：）