这是敏捷开发与中医理论系列的第一篇。。
最近一个世交的中医朋友到梁冬的正安药坊上班,也去实地参观了一下。因为之前的一些经历和最近的几天的交流,一点点悟到一些中医理论与软件研发管理的共同之处,写在这里成一系列。这里的很多内容来自于与这位朋友沟通所得,并与之前更早听《冬吴相对论》的思考成果。
内容将涉及中国文化与研发管理方法,团队的自组织管理,师徒制度/技能教育等内容。
千年古籍
这位朋友很精湛的一个解释是:为何西医教材每年都在变化,而中医却经常使用《黄帝内经》、《伤寒杂病论》这些千年古籍?到底是什么导致教材千年不变但依然有效?
原来西医基于对外界变化的认知,比如发现了细菌,就有了抗生素;发现了病毒,就有了疫苗;发明了人工心脏,就可以做植入心脏。西医的研究对象是外界。
而中医则聚焦于人本身,就是人的经络,阴阳,五行等,听起来很玄乎,实际上是对人体免疫系统工作原理的一种“近似的”甚至可以称为“错误”的但确是自洽的解释。由于2000年来人体并没有发生明显的进化,因此中医的理论也没有明显的变化。(这位朋友并不认为不变化是完全正确的,但也认为“研究人本身”从思想上说是正确的)
不过,这个和研发管理关系何在?
文化及社会对生产关系的影响
世界上的“资本主义”分为3个流派,一个是英美注重自由竞争、重公司轻员工的央格鲁萨克逊资本主义,一个是北欧注重福利、重员工轻公司的莱茵资本主义,一个则是我们的近邻日本注重“仁”与大家庭观念的儒教资本主义。
欧美资本主义发展迅速,很大程度上得益于“新教伦理”,即基督教中关于工作即修行的信念。这一信念在产生了诸如“为何极其富有的企业主仍然努力工作”“为何盖茨会捐献几乎全部家产”“为何50%的美国前100富翁会响应盖茨的捐献50%的号召”“为何西方罕见富二代”“为何巴菲特从刚起步到拥有百亿美元一直开一辆旧车(注意他不是成名后买辆旧车装简朴)”。因此注重世俗享乐的西/葡/意等国纷纷衰落,而新教国家将资本主义发扬光大。
但日本很奇特,其文化中也有工作即修行的概念(如果大家看过《入殓师》),但产生的资本主义形态却截然不同,比如“终身雇佣制”“年工序列”等等,与西方资本主义相差很大。
但是简单的理解可以解释其产生过程:日本人有1000多年的儒教历史,而日本企业至今只有100多年的资本主义历史,因此当两者相遇,作为新生生产关系的客体“资本主义”,就必须要受到存在已久的主体“人(及其社会)”的影响而发生变形。
研发管理建设中存在的问题
但是在研发管理中却经常忽视这种现象,一个公司可能上个月还在用CMMI管理,下个月就决定改为敏捷开发。而且,CMMI是原汁原味的CMMI(因为要做认证),敏捷开发是原汁原味的敏捷开发(因为不想做成“Scrum But”)。可是被管理的主体——人呢?他们并没有在这短短的两个月里边发生什么实质性的变化,一个本来连每天的计划变更都要审批还要被PPQA严格审计的受控团队,转眼变成一个居然可以自己估算和领取任务的自组织团队,不可不谓一个相当疯狂的举动。
敏捷中本来有以人为本的概念,但个人感觉并非是指选择管理方法要以人为本,而是指任何管理方法,都应该以发挥个体的能力为最主要的目标。这个目标很好也很实际,但和本文讨论的以人为本不是一个概念。
本文中的以人为本的概念是:“无论使用哪种研发管理方法,都要以被管理的人为本,进行相应的调整,才能发挥个体的能力。”
比如中国人文化上内敛含蓄,比较不容易“对估算结果进行挑战”,那么就利用估算扑克中的匿名性,引发估算讨论(老外比中国人用扑克反而多,因为国内对此方法多不了解);又比如中国人文化上有“人之患在好为人师”的说法,因此就应该指定师傅徒弟,来取代自发的互助行动(估算中的和每日立会中的);再如中国人文化多内敛,不愿意干涉别人的代码也不愿意被干涉,就适合使用松结对编程建立有限的以师傅帮助徒弟为目的的“干涉”(不解对不好,天天结对也不好);载入中国文化人多喜欢被动指令,就可以保留项目经理的指派制度;等等。
开始变革
不知道日本18XX年有没有报纸,但是显然并没有一场社会运动来讨论资本主义如何适应日本文化,等出现结果了,然后大家才能开工办厂。相反地,工厂一个一个建立起来,人们在日常的活动中不断问题驱动地持续改进、精益求精地消除浪费(是所谓“精益生产”),最终形成了其特有的生产方式,甚至超越了欧美原来的生产方式。
现在中国也处于大国崛起的状态,本人并不提倡真的上升到国学/儒学/佛学的高度来看研发管理甚至敏捷开发,这很不现实。但是笔者提倡在日常工作中,适时地发现那些与群体性格(可以算是文化的缩影)相悖的实践,并加以变革。
变革不能是生硬的,而是要遵循适当的步骤。操作层面的步骤可以大致归纳如下:
1. 理解“相悖”的原因。
这个原因不能马虎地找到一个就算,而是要真切到你感觉“如果是我,我也会……的”的程度。
比如如果团队成员都很反对别人看自己的代码,就要找真正原因。一个人对公司代码的最大权利,也不过是在注释里边签上自己的名字(其实,在编译的时候就给忽略了别指望发布后还能找到),有什么可保密的呢?仔细思考可能我们才发现:“原来公司是考核大家的编程质量的,而这些代码里边隐藏这很多测不出来但一看就知道是坏代码的东西”,如果一个人看了我的代码说:“这些代码真烂”而项目经理果然过来看了以后说:“的确如此,你别编新功能了(这会影响我的生产率绩效),先把代码重构一下吧”然后他转身离去……如果是我,我也会反对别人看我的代码的。
2. 理解这一实践的必要性和前后生态
既然连自己都不想做的事情,是不是不做算了?不行。在敏捷开发生态系统系列之二中曾经提到,为了能让团队“跨职能”/“共同估算”/“共同跟进”,看别人的代码肯定是难免的,那怎么办?
3. 在平衡文化和生态系统中解决问题
如果一个人看了我的代码,而我也不会被考核为差,反而这个人还会帮助我改好代码(甚至提前预防写出烂代码),岂不美哉?估计没有人会拒绝这种看代码。
可是谁这么大公无私呢?只有一个能从中得利的人才会如此——比如我的师傅。他能力强经验多,管理着一群小组,而小组的生产力都算在他的头上,因此他的工资也比我多,但是为了让我能干更多活,他得帮助我,其中一种方法就是看代码——这就是我们在敏捷开发松结对编程系列中提到的代码审查。
所以师傅会帮助改好代码;因为“改好”代码太费时间,他还会选择前关键点来提前防止代码变坏;又因为每次都来指导很麻烦,他会尝试指导徒弟在工作中学习,提高水平。
师徒制度其实是中国文化由来已久的一种生产关系,我刚分配到研究所的时候就被指派了一位师傅。在多数企业中都被忽略了,另外一些企业则西化为mentor制度(还是师徒制度)。在“古法教学”一文中,还有详述额外的问题,比如“饿死师傅”。
读者可以试着用三部曲分析这个问题:在无人认领任务的团队中,如何“指派”任务,而又不破坏自组织团队?
如果您愿意,可以在回复中作答,我也会说一说我对这件事情的认识。
转载于:https://blog.51cto.com/cheny/1100193