青云QingCloud黄允松：最高效的研发管理就是没有管理

摘要：对于底层技术创新而言，没有管理是最好的管理，小规模作战，快速试错，迅速转变方向，迭代周期一定要短。

钛媒体注：钛媒体、商业价值联合主办的第五届“MIIC移动互联网创新大会”如期举行。2015 MIIC大会主题是：新生代，万物生，以“新生”为豪；天地变，邀“新生”为宴。连续举办五届的MIIC在过去五年中见证了中国互联网业的高速成长和天翻地覆的变化，今年登上MIIC舞台分享的互联网大咖、新生代领袖都有谁？他们怎样成为中国未来商业最大的变数与变量？

NB的人才为什么做不出伟大的产品？信息部做出来的东西为什么往往遭遇一种困境，这不是别人要的，或是产品出来大家看看就好，就不买了吧？青云QingCloud CEO黄允松认为，这都是产品管理结构出了问题。传统软件工程管理体系对于差别的管理和产品的预设压根儿都是错误的，所以黄允松做了一些研发管理上的改变。

黄允松的核心观点包括：

所有要求增加人手的请求都应该被拒绝。人多会有分歧和讨论，会浪费时间。研发过程需要快速出错和快速校正，从而形成快速迭代。

不应该有团队领导者，每个人都应该是管理者，管理是一种责任，而不是一种角色。

no schedule！产品研发不应该排出日程表，项目延迟交付也没关系，出问题也没关系，研发管理要看全局，不要太关注细节。

勇敢的去尝试不一样的东西，总能做到最好。

以下为黄允松演讲全文，经钛媒体编辑：

如果各位有关注过云计算IaaS层或者PaaS偏技术领域的项目、技术、框架或者服务、公司的话，大家多多少少对青云有些印象，最大印象应该是产品做的如此之好，如此漂亮，或者性能怎么那么高。大家会对我们如何进行研发这个事情有些兴趣，所以，才有了“高效研发管理”这么一个话题。我自己一直写代码，今天也跟大家分享一下写代码的感知。

管理架构的意义几乎为零

“管理”这个词是为什么而生的？我们组建一个研发团队，做一个管理机构到底是为什么？是为了出来更好的产品？还是真的想有一个管理架构？这个事情想明白的话，你会发现管理架构的意义几乎为零。我在前东家供职的时候，我团队跟其他所有团队运行模式都不一样。我原来所在的公司非常大，几十万人，一级部门可能高达几千人，又有二级部门、三级部门，每个部门独立运行。这些人都是聪明能干的人，受过良好教育，毕业于赫赫有名的顶尖的和研究机构，但为什么给客户的东西表现却一般般？我在前一家单位供职时间非常长，后来建设自己团队时候就思考所谓的管理是怎样的。

后来，我自己有一些机会可以跟市场上的客户直接沟通，这种沟通并不是做销售工作，更多的还是偏产品、偏技术层面的沟通，我得到一些很强的感受，就是我们辛辛苦苦做出来的东西并不是别人需要的。我非常努力，做出来一个东西，我还欢欣鼓舞，客户最后却不要，到底哪里出了问题？写代码的人出问题了吗？肯定不是。是产品、管理、结构出了问题。

在我这个领域，我发现所谓差别的管理和产品的预先设计都是错误的，为什么会是错误的呢？因为一直是闭门造车，没有人知道出来的东西到底是怎样的形态。后来，我尝试做一些改变，包括创建青云项目。

研发团队不应该有leader

我尝试做的第一个改变是什么呢？首先，不允许人多，不管美国公司，还是中国公司，一般需要差不多50-100人的团队设计和开发出一个独立功能或产品的话，在我的团队里，只允许1-2人做，青云线上看得见、摸得着的东西已经突破20个了，背后更多后端的功能尤其是看不见的功能，总数加起来肯定突破50，而且都是很大的单体功能，但整个研发团队迄今为止不超过30人，所有人都是一样的角色，只有一个角色。

我是怎么评判这件事情的？这么多重大功能要做，人数要控制到这么少，各位可能觉得有点不可思议。实际上，尝试出错，这是非常关键的。任何一个产品，如果带一个庞大的团队，那就需要设立一个很重要的角色，这时候把满腔希望放谁身上？当他挂掉的时候，损失不是一个人，是一百人乘以一年，我们称之为一百人/年，你们花了多少钱？你们失去了多少机会？在我看来，应该尽量选择快速出错，人数一定要少，人数多了之后就会形成讨论，讨论就没完没了，沟通成本会非常高。

举个例子，比如做关系数据库，在云端运行，实际上是非常接近于所谓的PaaS层的东西，在我看来不是PaaS，PaaS更多带有行业属性才对，依然是IaaS延伸，扩张的过程。我会让一个人做，他来自于豆瓣，以前有很好的数据库经验，在整个过程中，我不能接受任何需要增加人手的请求，为什么呢？因为我要看到他出错，一般说来，不会让我失望，肯定会出错，每个人都会有这个过程，我们可以迅速矫正我们方案，漂亮东西一定是快速迭代，快速迭代的法宝一定是速度一定要快，核心点是相信你的工程师，他就是最杰出的产品设计者。我认为“管理”这个词在底层技术领域是很虚的，整个团队是点对点的结构。

一个团队不应该超过4个人

第二个体会，当你初步得到验证之后，你应该如何看待迅速的长大？刚才我也讲到了，其实我要做的功能，每个功能复杂度非常高，我做纯底层技术，我需要快速迭代，这是互联网时代，不能等待。今天晚上想好要改，明天早上就应该上测试线。当我验证一个概念的时候，比如称之为α，这时候需要快速长大，这个团队不能再是一个人，一般会变成两个人或者三个人，但一般不允许超过四个人。因为到四个人的时候，讨论变的无章法，你要走A路径，我可以同意你，因为可以做的通，但是，如果我说不太同意你的看法，可以走B路径，是不是可以呢？实际上也可以，问题不太大，如果这个时候有个人说想走C路径，方程式永远都有多个解法。

我们要的是快速的结果、可靠的结果，这个时候人数不能太多，但我从一个人增长到三个人的时候，团队的增长是300%，还不够猛吗？但是，当你是100个人的时候，增长300%就是300人，对于公司来说是不可承担的，到了第二个阶段，我们团队里每一项作品出来的时候我都会去看，如果满足了我的期待，我认为这个东西是可以加大投资的，主要为了快速的出东西。

研发不应该有日程表

第三个小体验，欢迎大家参加我们这个月月底的用户大会。我们的方案失败了四次，做的过程中，我们发现有很多设计最初是想错的，最早的计划是花大约6个月时间做出第一个版本，然后发送给我们的用户，第二个版本给受邀用户，后来再推迟，我应该生气？No，绝对不能生气，我们在做底层技术创新，不要生气，因为没有人做过，因为我们走的那条路是别人没有走过的。

我们一定不要认为任何事情都可以排出日程表，没有日程表是不是意味着你的项目会出现重大的交付延时等问题呢？对，出现就出现，有一百个功能，一两个出了问题，问题很大吗？难道你自己做工程的时候从来不犯错误吗？我们要看到的是全局，不要太关注细节，这个很关键，要看到整个团队的收益是不是好的，不用太纠结一些东西的推迟。

很多人在网络上非常关心青云环北京城400GB骨干网什么时候出来，8月份应该差不多，其实出点问题也没啥，大不了用别的方案对付一下，只要不影响客户的应用就好了，要看开一点。

Try to different，尝试做不一样的东西

所谓的不一样，不是为了不一样而不一样，不知道大家有没有见过我们的Web操作控制台，青云的东西非常易用，超级漂亮，平滑，不管是颜色、布局，还是操作的动作、手势等等，非常符合你的想象。在青云操作平台上，几分钟能够学会并且搞定所有事情，如果懂技术，你会做的非常非常快。

我们最早为什么要尝试一些不一样的东西呢？如果大家了解过我的背景，应该知道做青云是我做云计算的第四个项目，原来做过很多，每次做的时候，除了后端东西，可能有前端东西，就是Web操作台，每次都会请超级懂技术的前端工程师做前端，因为我做IaaS和PaaS的，如果找不懂前端的工程师做就很悲催，我找的人必须懂前端开发，最或懂一点设计，而且一定懂IT技术，以前做的时候每次都这么做，但是，非常抱歉，我做出来跟美国做出来的一个水平，为什么呢？看不到差异性，一点不友好，IT行业难道真的注定这么复杂、这么丑陋和这么的不方便吗？于是，我就想不一样，青云整个前端就是一位姑娘，不少人见过她，她懂技术吗？不懂，我说的是底层技术，她懂艺术，有很好的设计感，基本是文科生，但是你要给她足够强大的机会去尝试。

我们原来四个人在很便宜的平房里做设计的时候，她做第一个版本的设计，做的过程中很有意思，基本会逐个问你觉得这样好不好、觉得这样可以吗？说实在话，我真的不知道好不好，因为我不懂艺术，我是理科生，我就是条件反射觉得不太好，一般说来，有一半的时候我会讲这个地方不太好，但会有一个“但是”，她会迅速的学习，我相信她离开办公室之后也一定打开百度百科看CPU、交换机、路由器等等，她一定会搜索思科公司出的拓扑图的小图标，他尝试理解IT民工常常挂嘴边那些词是什么意思。

总结一点，对于底层技术创新而言，没有管理就是最好的管理，小规模作战、快速试错、迅速转变方向、迭代周期一定要短。（ITValue记者周应根据黄允松在MIIC2015上的演讲整理）

http://www.tmtpost.com/1040109.html