这是敏捷开发与中医理论系列的第一篇。。

最近一个世交的中医朋友到梁冬的正安药坊上班，也去实地参观了一下。因为之前的一些经历和最近的几天的交流，一点点悟到一些中医理论与软件研发管理的共同之处，写在这里成一系列。这里的很多内容来自于与这位朋友沟通所得，并与之前更早听《冬吴相对论》的思考成果。

内容将涉及中国文化与研发管理方法，团队的自组织管理，师徒制度/技能教育等内容。

千年古籍

这位朋友很精湛的一个解释是：为何西医教材每年都在变化，而中医却经常使用《黄帝内经》、《伤寒杂病论》这些千年古籍？到底是什么导致教材千年不变但依然有效？

原来西医基于对外界变化的认知，比如发现了细菌，就有了抗生素；发现了病毒，就有了疫苗；发明了人工心脏，就可以做植入心脏。西医的研究对象是外界。

而中医则聚焦于人本身，就是人的经络，阴阳，五行等，听起来很玄乎，实际上是对人体免疫系统工作原理的一种“近似的”甚至可以称为“错误”的但确是自洽的解释。由于2000年来人体并没有发生明显的进化，因此中医的理论也没有明显的变化。（这位朋友并不认为不变化是完全正确的，但也认为“研究人本身”从思想上说是正确的）

不过，这个和研发管理关系何在？

文化及社会对生产关系的影响

世界上的“资本主义”分为3个流派，一个是英美注重自由竞争、重公司轻员工的央格鲁萨克逊资本主义，一个是北欧注重福利、重员工轻公司的莱茵资本主义，一个则是我们的近邻日本注重“仁”与大家庭观念的儒教资本主义。

欧美资本主义发展迅速，很大程度上得益于“新教伦理”，即基督教中关于工作即修行的信念。这一信念在产生了诸如“为何极其富有的企业主仍然努力工作”“为何盖茨会捐献几乎全部家产”“为何50%的美国前100富翁会响应盖茨的捐献50%的号召”“为何西方罕见富二代”“为何巴菲特从刚起步到拥有百亿美元一直开一辆旧车（注意他不是成名后买辆旧车装简朴）”。因此注重世俗享乐的西/葡/意等国纷纷衰落，而新教国家将资本主义发扬光大。

但日本很奇特，其文化中也有工作即修行的概念（如果大家看过《入殓师》），但产生的资本主义形态却截然不同，比如“终身雇佣制”“年工序列”等等，与西方资本主义相差很大。

但是简单的理解可以解释其产生过程：日本人有1000多年的儒教历史，而日本企业至今只有100多年的资本主义历史，因此当两者相遇，作为新生生产关系的客体“资本主义”，就必须要受到存在已久的主体“人（及其社会）”的影响而发生变形。

研发管理建设中存在的问题

但是在研发管理中却经常忽视这种现象，一个公司可能上个月还在用CMMI管理，下个月就决定改为敏捷开发。而且，CMMI是原汁原味的CMMI（因为要做认证），敏捷开发是原汁原味的敏捷开发（因为不想做成“Scrum But”）。可是被管理的主体——人呢？他们并没有在这短短的两个月里边发生什么实质性的变化，一个本来连每天的计划变更都要审批还要被PPQA严格审计的受控团队，转眼变成一个居然可以自己估算和领取任务的自组织团队，不可不谓一个相当疯狂的举动。

敏捷中本来有以人为本的概念，但个人感觉并非是指选择管理方法要以人为本，而是指任何管理方法，都应该以发挥个体的能力为最主要的目标。这个目标很好也很实际，但和本文讨论的以人为本不是一个概念。

本文中的以人为本的概念是：“无论使用哪种研发管理方法，都要以被管理的人为本，进行相应的调整，才能发挥个体的能力。”

比如中国人文化上内敛含蓄，比较不容易“对估算结果进行挑战”，那么就利用估算扑克中的匿名性，引发估算讨论（老外比中国人用扑克反而多，因为国内对此方法多不了解）；又比如中国人文化上有“人之患在好为人师”的说法，因此就应该指定师傅徒弟，来取代自发的互助行动（估算中的和每日立会中的）；再如中国人文化多内敛，不愿意干涉别人的代码也不愿意被干涉，就适合使用松结对编程建立有限的以师傅帮助徒弟为目的的“干涉”（不解对不好，天天结对也不好）；载入中国文化人多喜欢被动指令，就可以保留项目经理的指派制度；等等。

开始变革

不知道日本18XX年有没有报纸，但是显然并没有一场社会运动来讨论资本主义如何适应日本文化，等出现结果了，然后大家才能开工办厂。相反地，工厂一个一个建立起来，人们在日常的活动中不断问题驱动地持续改进、精益求精地消除浪费（是所谓“精益生产”），最终形成了其特有的生产方式，甚至超越了欧美原来的生产方式。

现在中国也处于大国崛起的状态，本人并不提倡真的上升到国学/儒学/佛学的高度来看研发管理甚至敏捷开发，这很不现实。但是笔者提倡在日常工作中，适时地发现那些与群体性格（可以算是文化的缩影）相悖的实践，并加以变革。

变革不能是生硬的，而是要遵循适当的步骤。操作层面的步骤可以大致归纳如下：

1. 理解“相悖”的原因。

这个原因不能马虎地找到一个就算，而是要真切到你感觉“如果是我，我也会……的”的程度。

比如如果团队成员都很反对别人看自己的代码，就要找真正原因。一个人对公司代码的最大权利，也不过是在注释里边签上自己的名字（其实，在编译的时候就给忽略了别指望发布后还能找到），有什么可保密的呢？仔细思考可能我们才发现：“原来公司是考核大家的编程质量的，而这些代码里边隐藏这很多测不出来但一看就知道是坏代码的东西”，如果一个人看了我的代码说：“这些代码真烂”而项目经理果然过来看了以后说：“的确如此，你别编新功能了（这会影响我的生产率绩效），先把代码重构一下吧”然后他转身离去……如果是我，我也会反对别人看我的代码的。

2. 理解这一实践的必要性和前后生态

既然连自己都不想做的事情，是不是不做算了？不行。在敏捷开发生态系统系列之二中曾经提到，为了能让团队“跨职能”/“共同估算”/“共同跟进”，看别人的代码肯定是难免的，那怎么办？

3. 在平衡文化和生态系统中解决问题

如果一个人看了我的代码，而我也不会被考核为差，反而这个人还会帮助我改好代码（甚至提前预防写出烂代码），岂不美哉？估计没有人会拒绝这种看代码。

可是谁这么大公无私呢？只有一个能从中得利的人才会如此——比如我的师傅。他能力强经验多，管理着一群小组，而小组的生产力都算在他的头上，因此他的工资也比我多，但是为了让我能干更多活，他得帮助我，其中一种方法就是看代码——这就是我们在敏捷开发松结对编程系列中提到的代码审查。

所以师傅会帮助改好代码；因为“改好”代码太费时间，他还会选择前关键点来提前防止代码变坏；又因为每次都来指导很麻烦，他会尝试指导徒弟在工作中学习，提高水平。

师徒制度其实是中国文化由来已久的一种生产关系，我刚分配到研究所的时候就被指派了一位师傅。在多数企业中都被忽略了，另外一些企业则西化为mentor制度（还是师徒制度）。在“古法教学”一文中，还有详述额外的问题，比如“饿死师傅”。

读者可以试着用三部曲分析这个问题：在无人认领任务的团队中，如何“指派”任务，而又不破坏自组织团队？

如果您愿意，可以在回复中作答，我也会说一说我对这件事情的认识。