最新资讯

在创业过程中，研发管理是很重要的内容。但是国内创业公司的研发管理却长期处于一种比较混乱的状态。国内创业公司的研发管理到底出了什么问题？“什么时候采访我？”在GitCafe北京分部的开幕活动上，显峰半开玩笑半认真地问我。认识显峰的时间不算短，总在各种技术大会与小会上频繁碰面。过去一年多，他的工作状态算不上“稳定”，这不，刚离开高大上的互联网金融，投身APM的伟大事业。真要采访，得先选出一个可行的话题切入角度，他引用《人件》里提到的“高科技幻觉”，从传统工程的角度谈了谈对IT研发管理的看法，于是采访主题顺利地定了下来。

这通吐槽显然憋了很久，不乏“这个行业充满了骗子与强盗”的激烈言辞。我有点被惊到，常看他以典型的东北式幽默与人调侃，并不知道他原来如此严肃。在北五环外的东升科技园，我们从下午两点半，一直聊到天黑，期间换了3个场地。末了，他叹到：“为什么好好做技术这么难！”

显峰无需借此博眼球、搏出位，公开发表这些话给他带来的潜在风险远大过收益，观点犀利自然会赢得一些赞同，也难免招致对号入座的无端恨意。在乌合之众汇聚成的网络空间，谩骂而非理性的讨论是更为常见的交流方式。虽然在文字上做了些处理，我仍然对其可能带来的争议无比担心。发给他确认，几乎没做大的修改，仅回了个：“整体很流畅，但细节上的文字还不够平滑。”看，真是个对品质要求很高的人。

这些细节暴露了他的始终如一，也让我更加理解显峰的选择，不安定的背后，自有他严格的价值坚守。如果有机会，显峰希望去教小孩写程序，热爱学习的人是真诚的，他喜欢和这样的人在一起。

技术人攻略：你从什么时候起开始对对研发管理感兴趣？

我是学工程出身，本科就读于哈工大航天工程与力学系，研究生是悉尼大学的航天专业，期间受到了严格的工程训练。传统航空业的研发和制造体系非常完整，拿造飞机举例，悉尼大学的本科生就完全可以组装出可供销售的飞机，因为整个生产过程非常严格，任何一个扳手都有编号，有详细的记录和流程，不可能搞错任何东西。

虽然专业选择了航天，我对编程却非常热爱。从小学就开始写程序，那时候家里没有电脑，每次上机需要走40分钟山路。研究生期间，独立完成了完整的有限元分析软件，算是我在科学计算领域的一次实践。

回国之后，我加入的第一家公司Antiy，很重视底层技术，产品做得非常成功，但研发管理做得并不好。我在那期间学了很多软件研发历史，但在研发体系建设上，还是留下了许多遗憾。随后加入做互联网广告监测的创业公司AdMaster，当时公司正在筹建，人员来源多种多样，研发管理问题比较突出。我的职位是专职敏捷教练，配合技术负责人做团队建设，开始更深入地思考研发管理。

刚进入IT这一行时我很难理解，为何在传统工程和制造领域很平常的事情，在IT领域却是需要商量和悬而未决的。可靠性在航天等领域早已解决得很好，为何软件行业却一直解决不了产品质量问题。后来看了不少管理的书，发现IT研发管理的许多思想都是从建筑业、制造业借鉴而来，例如快速迭代、精益管理等概念。

结合工作实践，我逐渐发现了研发管理问题的症结所在。研发能力是工作的综合体现，内功水平是关键，任督二脉打通了，练什么都很快，至于到底用哪个套路，是很轻松的一件事。举个例子，大家通常说要做“敏捷转型”，认为自己是从传统软件研发转型成敏捷，关于二者的争论也显得像是泾渭分明的两派，但实际上不是。难道传统软件就不做配置管理吗？难道敏捷就不做测试吗？这两派理论有八成是一样的，即便在软件工程教科书里，也同样有关于质量控制、配置管理、迭代等理论，如果很好地去执行，同样可以达到不错的效果。

为什么敏捷转型失败的案例很多，因为企业并不具备相应的内功，只想寻求解药，以为敏捷能有所帮助。实际上如果不打好基础，结果还是一样。具备这种内功的人，玩传统软件也会很好。航天、制造、金融行业并不过分强调敏捷，当然敏捷里的好东西，他们也能非常快地去借鉴。《精益软件开发艺术》这本书的作者来自波音公司，他们将其在制造上的经验应用于研发，对软件的驾驭能力相当高。

强调时髦的概念，对研发帮助并不大。比如知道了TDD测试驱动开发，对团队帮助有多大呢？TDD想执行好，要求对测试理论有深入理解，但大部分国内开发团队不仅不具备很高的测试水平，连测试是什么，如何测都不知道。这种情况下去推广TDD是没有意义的。

技术人攻略：根据你的观察，国内研发管理有哪些常见问题？

我观察到国内研发管理主要的问题有几个：第一是过于强调个性，缺乏共同价值观；第二是内功差，不重视软件质量；第三是很多从业人员眼界狭窄，拿无知当个性；第四是对技术缺乏敬畏之心；第五是整体气氛浮躁，擅长炒作概念而非脚踏实地做事。

IT这一行太推崇个性，过于强调创新，强调极客，而对于共同价值的坚守非常少。传统工程领域里，大家都遵照明确的规范和标准做事。软件行业的国家标准很落后，大家也都不执行，几乎每个公司都会自定义一套方法和流程，大家各说各话。个性的东西太多，达成共识的东西太少，导致软件行业的人很难树立共同价值观，以及清晰的研发过程。

我做软件咨询的时候发现，不少合作多年的团队，都未能在基本价值观上达成一致。例如自家产品到底能解决客户哪些问题，10个人能给出8个答案。我认为研发管理首先要解决的问题，是形成一个团队，这就要求大家必须有足够多共性。想要塑造有战斗力的团队，需要模仿军队管理，大家穿一样的衣服，迈一样的步子，用同样的方式使用工具，减少不必要的浪费和沟通。

建立共性的关键之一，是要对代码质量树立共同的认可规范。好代码必须干净、可维护、可测试性好、适宜阅读。如果在大规模项目之前没有就此达成统一，大家冲上去的时候，再说如何配合、包抄，只会被打得一败涂地。

关键之二，是要做好版本控制。版本控制是研发的基石，开发人员每天都要用，而即便很多资深程序员，对版本控制的使用方式依然很落后。版本控制最基本的要求是可回滚，但国内大部分公司做不到这一点。《精益软件开发艺术》这本书第0条就讲：代码必须在版本控制工具里。离开这个基础，其它的改善都是无用功。我原来一直在推Git，本质原因还是我们的内功特别落后，你看Github有多流行，就知道国外做得有多好。

技术人攻略：国内研发管理内功不足，除了版本控制，还体现在哪些方面？

除了版本控制外，调程序和测试的情况也不乐观。国内程序员调试程序大部分全凭拍脑袋，不能以程序的方式思考问题，不仅不具备调高难度算法的能力，也没有清晰思路去解决问题，更不会使用工具。

在互联网领域，测试的重要性远远被低估。合格的测试开发工程师应该既懂测试，又懂开发，还要能教育其它开发工程师。这种人在现实情况下很难找到，根据我面试的经验，能把最基本的单元测试要点说清楚的人都不多。

做互联网金融这段时间，我接触过国内很多第三方支付，都在测试上做得一塌糊涂。举个例子，开放平台让商家接入之前，需要提供一个虚拟测试环境。Paypal的正规做法，是给每个商家建立一个沙盒。而国内大部分厂商的做法，是让所有商家共用一个测试账号，往里面打一分钱。这一看就根本不懂测试理论，沙盒测试是标志性的东西，如果你到某个医院，发现那里没有显微镜，那就一定说明这个医院不具备做某些类型化验的能力。

电信、金融、制造业等传统软件开发领域，对软件质量重视程度很高。互联网领域最不重视软件质量，普遍采用的灰度测试，虽然能解决体验、交互流程上的问题，但并不能解决质量和正确性问题。测试能力是很基本的内功，做灰度可以，但不能对测试一窍不通还无所谓。这好比你有10发子弹，因为时间、资源所限，只能打1发。但如果你只有1发子弹，你就打，不要说别的不好，因为你根本不知道完整的方式该是怎样，只能灰度。

国内的创业者天天看TechCrunch，知道美国的市场、机会、商业模式，唯独别人的研发流程不了解，所以只会抄袭一些表面的东西。媒体总是报道Facebook一夜成名，但很少有人知道，在这家公司刚开始壮大时，就从Mozilla挖了一位非常资深的专家去负责工程。这些经验丰富的人是团队的定心丸，前进路上有多少坑，他们早就踩过了。研发有本质的客观规律，不能因为你年轻，你创新，就逾越这些规律。

技术人攻略：你提到的从业人员眼界狭窄，表现在什么地方？

从业人员不怎么看书，是这个行业普遍存在的问题，最多看点讲程序开发的书，所以有文化的程序员特别少。作为完整的人来讲，基础文化结构的缺失，导致大部分程序员看问题很偏激，没有常识，不知道历史，还总拿无知当个性。

例如做技术选型时，看好某门技术，就要用到项目里，这其实是非常幼稚的行为。技术选型一定要考虑团队的驾驭能力，考虑能不能持续招到懂这门技术的人，以及最重要合作伙伴用了哪些技术，你选的这门技术能不能同他们高效沟通等非技术因素。

研发管理90%的问题，30年前在美国已经出现过，好好看看经典书，90%的问题能解决得挺好。不要总觉得自己是世界上第一个遇到这个问题的人，差不多你都快成为世界上最后一个遇到这样愚蠢问题的人了。干了多年研发管理的人，都没读过研发管理经典的书，是很可笑的事。

我经常说，想去研究软件考古学。软件的历史比较年轻，可考证的东西又比较多，能研究出相对清晰的历史、来源、派系，帮助我们了解行业的发展过程。《人月神话》这本软件工程经典书，就是讲软件开发的历史，程序员知道历史后，会更有兴趣去思考整体的行业脉络。

上大学时，我们会从各种空难事故中，学习飞机设计失败的教训，例如某个部位为什么要这么设计，是从哪一次空难开始改进的。航空工业能发展成现在这样，不是由几个小屁孩拍脑袋做成。在大体理论框架没有突破的前提下，许多改进都是基于已有经验，对细节的精益求精。任何行业都需要积累，研发管理也类似，我们需要对行业历史有所了解，要传承，而不是完全去创新。计算机行业理论框架突破并不多，并且能得图灵奖的理论，跟大部分撅着屁股干活的人没啥关系，所以还是老老实实把这些经典理论继承了，对你的帮助更大。

至于为什么要读那么多其它方面的书，除了能提高人文素养，还能帮你解决自身的问题。国外软件业大师，在思考自己行业问题时，常常能旁征博引其它行业的案例，例如引用一本护士学的书、一本机车修理的书，或一本建筑电气的书。各学科反复交叉会带来启发性思考，可能你这个行业的难题，在其它行业就不是事儿，帮助你开拓新思路。

技术人攻略：对技术缺乏敬畏又如何理解？

国内一些程序员懒、没有开阔的视野，对于技术缺乏敬畏之心，觉得自己什么都懂，不需要特别谦虚去学技术，一幅老子写代码天下最牛逼的样子。问他行业里有没有偶像，回答没有，问他知道业界谁做过什么东西，回答不了解。这种人是行业祸害，拉低了行业平均水准。

开发人员能不能成长，只要看有没有追求就可以。面试时我通常会问几个问题，例如最近学了什么？通过什么途径去学习？看哪几本书？都是谁写的？他还写过什么书？关注什么开源项目？谁写的？他还做过什么项目？这几个问题如果能很清晰回答出来，说明面试的这个人是有追求的，起码有吹牛的追求。如果一个程序员连吹牛的追求都没有，是很失败的。

那这群人为什么如此骄奢淫逸？因为拿钱太轻松了。互联网公司程序员离资本非常近，光今年上市的公司就大概有20家，行业发展得实在太好。国内互联网已经快15年没有寒冬了，包括2008年金融危机时，企业融资可能受点影响，但程序员的薪水一路水涨船高。除了干IT，有几个刚毕业的人能拿到上万工资呢？金融行业能拿到，但不需要IT这么多人。

美国每7、8年，就会经历一次经济周期，而国内这一代程序员没有经历过寒冬，所以不珍惜自己的工作，不知道自己真正的价值在哪里。出来混终究是要还的，大量发行货币必然导致通货膨胀，只是时间早晚问题。从经济学角度讲，市场有了泡沫，需要经历一次大萧条，把泡沫挤压干净，才能变成更健康的环境。经纬合伙人已经写信，让大家做好过冬准备，如果资本持续注血，繁荣的假象就会持续得更长，如果市场找钱很困难，那大批互联网公司就会死掉，释放出大量人员，工资水平马上就会下来。

研发工作非常辛苦，需要踏实态度和长期努力，通过日复一日的艰辛劳动才会有所收获。国内浮躁氛围很难培养出好的工程师。但换个角度，工程师价格高了，对真正有乐趣从事这一行的人来说，还是好事。

从趋势上看，技术学习也正在发生变化，在校学生如果心态够开放，通过参与开源社区快速获取经验，在学校里就能练就很好的内功。这群人一旦成为一个小气候，可以直接和毕业5年左右的人竞争。尤其是当经济形势不好的时候，那些得过且过的人会很危险，终究有一天，他们会拿起书本去学习，知道自己根本不值那个价。

技术人攻略：这种行业普遍存在的浮躁心态，带来了哪些不利影响？

我们生活在一个非常功利、信仰缺失的时代，人们只想快速获取财富，很难有正确的价值坚持。用博弈论解释，这种浮躁走向了囚徒困境，类似日本、德国这种成熟社会，大家做事都不浮躁，整个社会能达到比较高的均衡。而在一个浮躁社会，没按规矩的人走得更快，于是那些按规矩做事的人就吃亏了。这种浮躁其实把大家都害了，把行业也害了。

IT现在和钱离得比较近，所以病得挺重，整个行业里充满了骗子与强盗。大家努力的方向不是提升自己，而是只要能获得钱的事情都会去做。任何时代都有骗子，但一个国度里大部分人都是骗子，是不正常的，还是应该实实在在创造一点价值。

热衷于炒作概念，是行业浮躁的表现之一。前几天参加一个研讨会，讨论了半天，才发现这群人不是在玩大数据，而是玩“数据”。因为以前根本没有数据，决策主要靠拍脑袋，现在有数据了，就觉得自己与时代划上了等号，想裹着这个外衣去挣钱，真是无知者无畏啊。好多人觉得有Hadoop集群了，上了硬件了，从政府那里拿到钱就牛逼了。可对数据没有理解，不知道怎么用Hadoop发挥价值，有钱也没有用。云计算也类似，被地方政府当成了房地产来搞，涌进许多根本不懂这个行业的人。

这种浮躁会导致软件研发竞争优势下降，我们在圈子里有讨论，如果做高端基础软件，硅谷研发成本会比国内更低，能雇佣更高素质的人才，有更好的配合，以及更确定的产出。国内拿到钱的互联网公司，将来可能都会去北美建立研发中心。贵不贵是一说，还有值不值的问题，为什么中国建研发中心不值，这是一个很耐人寻味的问题。

互联网行业看上去门槛低一些，创业相对容易，但总要设置一些门槛给竞争对手，所以还是要有自己的积累。我以前曾喷过阿里这样的公司，觉得他们做的东西不够专业，但后来我改变了观点，他们能坚持这么长时间，能把云计算推到这样的高度，就算走了一些弯路，也是值得敬佩的。这些实实在在的创业者，才是业界的良心。

技术人攻略：根据你做敏捷咨询的经验，实施技术团队过程改进的最大困难在什么地方？

最大的困难在于建立起团队成员对你的信任。许多敏捷实施失败的原因，就是因为程序员不信你，特别是团队资深的人不信你，基本一定会失败。从事敏捷咨询行业的人，许多并不是技术背景，他可以讲一大堆方法论，但程序却写得乱七八糟。所以想做好技术团队的过程改进，至少你得是个懂技术的人，首先要向团队展示出自己的技术能力，才有机会去解决困扰他们的问题。

管理大师德鲁克曾说过：“你度量什么，就能改善什么”。在具体过程改进实施中，我喜欢从细节着眼，寻找一些善于实施，又能见到效益的改善。比如我经常会用到一个方法：度量程序员的时间花在了什么地方。如果大家都是靠猜测，管理不好也不奇怪。

我曾经装过一个软件，记录自己使用电脑的行为，例如统计每天用了多少时间上微博、聊QQ、写邮件，还是写代码。真正把时间记录下来之后，才发现实际结果和自己的感觉大相径庭。社交要消耗大量时间，非常影响工作效率，所以后来我把IM都关掉，集中处理工作。

一个管理良好的团队也是一样，想要改善需，就必须要有动力。作为管理者，你必须刺激团队成员身上的动力，给他们一面镜子，照出来他们背后的魔鬼，这样才会有改善的基石，这也是建立信任的其中一步。大部分程序员都很尊重事实，当他发现每天5个小时都花在聊天上，自己就会想办法去改善。逐渐实行这样能见到效益的改善，就会获得团队信任。

好多找我做咨询的人，容易关注一些表面现象，比如敏捷实施的各种方法。在我看来，表面的东西只占20%，真正想做好过程改进，必须花很多时间做基础工作。比如上面提到的对团队工作时间的测量，对你的改善目标，提供了强有力的数据支撑，是非常基础的改进工作。敏捷是一个方法论，在团队内功真正得到提升之前，那些方法没有任何用处，而且高深莫测的方法，会让大家感觉到不确定，容易对此起反抗。

实际工作中，许多咨询顾问不会花精力，去做看上去没有科技含量、很琐碎、不为人知的事情。就像刚刚谈到的大数据行业现状，大家在会上讨论着大数据的建模、分析、如何出漂亮报表，但80%的脏活累活，是要把数据有效地进行搜集和整理，它是简单的体力活，但做不好的话，根本没有后面这些故事。过程改进也类似，绝大部分工作就是普通工作，没有太多技术含量，也没什么值得可说的，但必须把这些基础打好，才会有后面的故事。

国外谈论敏捷的，都是有20多年工作经验的人，敏捷宣言发起者，都是业界大牛。而平时工作中，我常接触到一些许多没什么工程经验的人在实施敏捷，并且在各种业界大会上，沾沾自喜地分享他们的经验，所以我后来也很少参加敏捷的这些会了。我怀着一颗敬畏的心，去读大师的作品，思考我工作中的不足。我感觉自己做的工作都很普通，都是大师们说过的，很普通的那些事情，值得分享的不太多，失败倒是有很多。

技术人攻略：你从什么时候成为技术圈的交际花？你工作跨的圈子很多，是否会影响知识的积累？

我也不知道从什么时候开始成为交际花，大概是2011年初，我翻译了《MongoDB权威指南》那本书之后，参加了很多技术交流活动。在这些活动上，遇到了不少志同道合、真正热爱技术的人，让我感觉很踏实，于是就更愿意参加社区活动。

客观地说，许多活动的内容和组织都还有很大的提升空间。大家感觉日本的技术做得应该不怎么好，但我最近看了一本日本的技术刊物，发现他们的技术讨论很深入，国内罕有。我之所以会去各个技术会议当出品人和主持人，是因为不想作为批评者旁观，而是主动推动这些事情的发展，促成技术交流的气氛。

离开上一家公司之后，许多做互联网金融的公司都给我打电话。我会问他们一个问题：技术能给你们公司带来什么？在我看来，大部分互联网金融公司处在初期阶段，还远远没到拼技术的时候。他们拼的都还是业务，业务做得好，技术外包一个，都能撑过去。

现在加入的这家公司做APM应用性能监控，提供的是纯技术产品。我个人更希望在一家不浮躁，纯粹以技术为价值导向的公司工作。云计算快速发展，已经到了踏踏实实给大家创造价值的阶段，我希望通过公司提供的SaaS，让大家用得更舒服、更省钱。

我一直很喜欢跨领域学习，对很多东西都有好奇心。大学本来是航天工程力学系的，却因为研究工业自动化系统，获得了电气工程学院的Rockwell奖学金。尝试新东西在我看来不是障碍，而是乐趣。

工作以后，在不同圈子认识了不同的人，在互联网金融圈认识的人，如果一直待在广告圈，是无论如何也遇不上的。在各个圈子有朋友之后，可以做一些融合的事，比如想知道金融里面安全怎么做，就会有很多安全圈的朋友给我出主意。当然，在不同圈子太多，单一的业务上说不上特别精通，但我个人积累的重心一直放在技术上，一直在认真研究和探讨自己感兴趣的东西，从来没有放弃过对积累的追求。