2011年，网景创始人、著名风险投资人马克·安德森(Marc Andreessen)写道，“Software is eating the world”(软件正吞噬整个世界)，用以表达各行各业都被软件所瓦解，之后再重构，未来所有的公司都是软件公司。
事实证明，马克·安德森的预判远比大部分人想象的还要长远。
今天，全球市值最高的几家公司尽数为软件公司，不同领域的巨头内部有着相同的软件工程师群体。这么一群高智商、高薪酬的人聚在一起，是脑力的风暴还是角力的漩涡，是在冥思苦想还是在浑水摸鱼，很大程度上决定了一家公司的生产力。
不仅如此，随着数字化升级的深入，越来越多的企业组建起自己的软件开发团队，以满足自身在业务上的定制以及业务发展需求。因为系统复杂性的提高，软件团队的规模也变得越来越大，管理难度也随之呈指数增加状态。如何有效管理创新开发团队，也成了很多传统企业的一个隐形痛点。
而对于管理超大规模开发团队的经验和教训，阿里云智能总裁、达摩院院长张建锋(花名行癫)可能是最有资格回答的人之一，当年他带着12个人三个月完成天猫商城项目开发就是经典的案例。本期《云栖战略参考》(以下简称《参考》)就和行癫仔细探讨了这个问题。
01
管理超大规模研发的秘籍
《参考》：很多客户其实非常好奇阿里巴巴管理超大规模研发团队的经验和教训，阿里巴巴有怎样的最佳实践?
行癫：这是个很好的问题，但是我想先说说我对最佳实践的看法。
首先，阿里巴巴未必有最佳实践，因为业务的成功会掩盖很多真相。就像当年谷歌说有很多创新，是因为员工可以有20%的时间考虑“与工作无关的东西”。这就有可能弄错了因果关系，谷歌并不是因为这个原因成功的，而是因为谷歌成功才可以这么做。
所以这里面有个挑战是要知道哪些是真正可以复制的最佳实践，哪些只是因为业务成功之后总结成的“最佳实践”。结果很容易看到，但真正找到“因”是很难的一件事情。
我们可以通过这本内刊和读者一起来寻找最佳实践，和大家分享、碰撞一下。
我没办法告诉银行家，他应该怎么做“一二三步”，因为我没有办过银行，但如果这个银行家有足够的领悟能力，他会从阿里巴巴的最佳实践、阿里云的客户的最佳实践中取得一些借鉴，获得启发，然后提出他自己的问题。
我们只能说我们在这个行业里面做了什么，或者自己不见得成功，但是提倡的理念是成功的，能够引领未来的。比如说以后的办公是数字化的，像钉钉这样的平台；比如以后软件的开发是碎片化的。这些我觉得是趋势，未必见得在我们这里成功，可能在我们的客户里实现成功，比如太平洋保险，用了钉钉之后，把很多系统就自己开发上去了。
《云栖战略参考》就是把这个行业里的先行者的探索、实践，呈现出来。但是“核”永远不可能靠别人告诉你——如果我能告诉你，那意味着我能做你的业务。
《参考》：关于创新的研发管理最大的挑战是什么?
行癫：你觉得研发人员不好管理，是因为你不知道应该做什么。最基本的“管理”，就是告诉下属应该做什么，而程序开发是项目化、组织化程度最高的一个活动。
所有项目第一个动作都是立项，第二个动作是所有项目都要被准确的评估，到底要花多少时间进行开发，比如我当年做天猫商城，在规定时间内要把天猫商城上线。评估很重要，比如一个系统登录use case(用户用例)，通常有经验的程序员写这个use case，三天可以写完。我们尽可能把所有的use case都给列出来，如果列不出来，说明这个需求没弄明白，需求没有弄明白就去做，肯定是很难收敛的，做到最后就会发现做的不对。
所以第一步就是把所有的use case都要列出来，列不出来的话，就不要开始后续的工序，就要弄明白这个软件到底有哪些功能。列完之后就在后面标注三天、五天、六天、七天，所有加起来就是总共花的工时。比如可能要花1000个工时，就需要思考，1000个人做一天，还是100个人做10天，还是10个人做100天?这肯定不一样的，但绝不可能1000个人做一天就做完了。必要的周期还是要有的，这个周期有经验的管理者会有自己的判断。
我们根据必需的时间，把人员核算好，就开始做。精髓是，需求必须明确！
我们才能够按部就班列出来，然后得到一个工时数，确定所有的资源投入，之后就是标准化的系统管理：什么时候应该研发介入，什么时候应该测试介入，什么时候应该提交测试，提交测试的提交标准是什么——这都是非常标准的流程，只是很多软件开发团队没有严格去遵循。
比如，听别人说很多软件公司不做测试了，自己也不要测试了，开发工程师来测试就可以了，但实际上有些测试很重要，甚至需要有一半人做测试。原则很简单：如何让总体研发时间最短、成本最低。但一个项目应该是测试多，还是应该是开发多？不同的项目不一样，管理者自己决定。但必须保证总体的时间最短，投入的资源最少。
《参考》：阿里有没有自己的软件开发方法论?
行癫：方法论可以探讨，但是方法论需要固化成为工具。你必须要有一整套工具来支撑方法论落地，怎么管理需求、怎么提交代码等等，我们内部有Aone。
但Aone是很重的，比较适合于大型项目的开发，小公司可能不需要这么重的工具，可以去做裁剪，我觉得各自有各自的做法，认同你的方法论就会采用你的工具，不认同你的方法论人家也不会采用你的工具。
很多公司没有方法论，只关心工具——这是两个层面，都需要关注。阿里现在的方法论，所采用的工具是我们自研的Aone。其实我个人是反对所有的公司都自研工具的，因为我觉得方法论一定是有普适性的。不是说在阿里这个方法论奏效，换个公司就不行了，没法复制。
我现在要求工具一定要开源，开源之后所有的工程师才会来使用，甚至会反过来优化你的方法论。
原来我们中国的软件开发，基本上工具决定了你的方法，有些工具很重很重，互联网公司肯定不能用，因为互联网强大之处在于反复迭代，容错性很高，关键流程不出错，其他东西有点瑕疵无所谓。但是站在其他行业的软件开发维度来看，软件分发出去之后修复成本很高，需要在分发前反复测试。
《参考》：对业务的理解是需要经验积累的，在摸不清需求的那段日子是怎么过来的?
行癫：没有use case的时候，往往项目是很小的时候，是业务推着你在走，那时候是不管白猫黑猫，抓住老鼠就是好猫。
我2004年加入阿里，阿里那时候没几个人，没有人关心你用什么工具，你只要实现目标就可以。那时候很难说效率高，很难说是最佳解决方案，但一定是找到一个比较合适的解决方案。技术要追求合适性，不要追求先进性。
《参考》：研发管理和业务规模强相关，阿里何时开始重视这件事?
行癫：2004-2006年时业务跑的比较快，所以技术只要能够满足业务发展就可以。最近几年，特别是人工智能、大数据涌现之后，其实很多业务已经不是简单的业务方能够想明白了，比如程序化交易或者广告竞价、商品推荐，业务方可能想的是一句话的事情，但研发可能是很复杂的事情，在这些系统里面工程师会占更大的主导地位。
《参考》：“双11”这种大项目，阿里是怎么管理的，是一个什么样的流程?
行癫：关键就是模块化，我们每天模拟“双11”的情况，模拟最坏情况下，怎么做降级处理的操作。
当然研发一个模拟系统，这是另一个重要的工作了。如何定义问题，大的项目里需求的定义变得非常重要。需求定义是最关键的！
乔布斯有句话叫做“消费者并不知道自己需要什么，直到我们拿出自己的产品，他们就发现，这是我要的东西”，软件工程里这个提需求的人也很重要。
我认为很多的产品不好，是因为需求是没有想明白。有时所谓的“提需求”，并不是在提需求，而是在讨论，因为他自己也不知道这是不是个需求。
当年开发天猫商城的挑战非常大，大家讨论了很久，包括有没有购物车功能，需不需要选择尺码。要知道原来淘宝是没有尺码的，如果你要买鞋的话，必须用旺旺跟卖家沟通。我们认为天猫是不需要旺旺沟通的，那我们就开始做SKU，让消费者自己可以选，你买下来直接付款就可以了，也不需要支付担保。
这些问题都反复讨论了很久，那时候我带了12个人，做了三个月就全部做完了。前提是，我们确保需求是非常明确的，我们有足够的管理能力，就能实现快速开发。
我们也提倡开发工程师来写PRD(产品需求文档)，产品经理写的可能比较简略一点，开发工程师会把文档写的特别详细。写的过程中需要画流程图，这就强迫他去弄明白需求。想明白之后，开发会非常快。
02
揭秘阿里巴巴的研发团队
《参考》：阿里现在有多少开发人员？层级分布情况大概是什么样子的？
行癫：具体人数我也不知道，大概五六万人，中间层P7/P8最多。
《参考》：阿里内部的程序员职级体系是什么样子的？不同的岗位描述是什么样的?
行癫：阿里把工程师分为不同层级，做研究的在达摩院，还有做基础工具、基础平台的，阿里云的工程师开发业务产品，阿里巴巴电商系的工程师也有开发电商技术的。但都遵循四个标准：稳定是底线，稳定压倒一切；第二是效率；第三是成本，效率高还要考虑成本；第四要有创新，创新技术能够反向推动业务，比如人脸识别技术可以简化登录。
淘宝、天猫的技术研发不是产品研发，产品是淘宝、天猫。这个看似很简单：把技术能力变成产品，把产品变成市场。但是你有很强的能力，不见得就有很好的市场。
但我们很多工程师有个误区，觉得我有能力，什么都能干，这个肯定是有问题的。你能不能让技术能力变成产品？产品能不能有市场？都是未知。
《参考》：管理体系是什么时候开始建立的?
行癫：阿里的研发管理体系，一开始也没有什么体系，跟所有工作一样的，都是在争吵中度过的。
一个经典的问题就是工程师到底应该属于哪个部门？现在很多工程师都不属于业务部门，而是个资源部门，那么哪个需求优先做，就是个很现实的问题。但正因为你是个资源部门，你有这个权力，就需要你有判断力，去平衡很多东西。
阿里现在的业务工程师占70%左右，业务的工程师那很简单，业务赢了你就成功，业务如果做不好，那你的评价肯定不会高。
工程师的工作是不能精准量化的，最终看贡献，包括你的技术能力、你对这个组织的贡献。技术体系的晋升是个相对性的事情，无法追求绝对公平。
追求绝对公平的有两个体系，一个是行政体系，第二个是技术委员会，技术委员会不会特别考虑业务的问题，而是从纯技术角度评价员工的能力水平。
我倒觉得技术委员会是阿里相对超脱的一个组织，就是工程师自治的组织，它是从技术品牌对外的影响力来思考，比如如何吸引更好的员工来加入。
我觉得技术人员从来都不是一个商业部门的核心问题，业务部门最大的挑战永远都是业务在市场上有没有竞争力，而这种竞争力绝大多数都不是技术决定的。抖音也好，快手也好，都不是因为技术跟别人不一样才成功的。云，是一个特例，技术本身即产品，它的市场是由客户的业务需求决定的。
《参考》：在阿里，是怎么定义架构师?
行癫：我原来也做架构师，架构师的变迁史很复杂，架构师原来就是技术水平最好且最了解业务的那个人，才是架构师。这个人往往后来都会成立架构组或者架构部，架构部一成立就脱离了业务，他会去搞自己的架构。
所以阿里也是在来来回回调整，架构师在部门里面-独立出来-又融合，一直在循环。但是我觉得架构师越来越难培养，因为业务系统越来越复杂，懂得整个系统的人可能后来就不在公司了。
所以后来，我们提出一个要求，就是把系统模块化，所有人能处理问题的边界都是有限的，阿里有很多系统，每个人来负责一个系统，系统里一个主要的人就是架构师，他必须把自己的系统全部做好。
再到后来项目多了起来，一个项目里面有项目经理、架构师、产品经理、程序员，但在业务系统里面那个人不叫架构师了，一般是系统分析师。架构师是偏纯技术的，系统分析师比较偏复杂的业务系统分割，梳理好系统之间的关系。
技术架构师现在的地位被削弱，因为太多的东西都标准化了，没有必要从技术的角度想一个新方案出来，但业务架构师因为复杂业务系统越来越多，比如银行是典型的复杂业务系统，他们需要的就是好的业务架构师。
业务架构师的培养周期很长。技术架构师从A公司到B公司，是能够很快去接手的，业务架构师需要很多年的积累。他一定是技术出身的，因为业务的知识相对容易积累，技术的知识业务人员是积累不起来的。
《参考》：如何看待精英程序员和普通程序员的差别？阿里内部倾向于哪一类？
行癫：比如我们一个部门有10个人，10个人都是P8，这个部门的水平就是P8，10个人里面有一个P10，这个部门的整体水平就是P10。
技术是靠一些特别牛的人把整个水平提上去的，但没有那个人的话，整个团队水平就比较低，因为你永远达不到那个水平，但只要有一个人的水平非常好，整个部门都会到较高的水平。
《参考》：阿里的老程序员都在干什么?
行癫：阿里的老程序员有两种，这个没有贵贱之分。因为哪个公司都需要非常熟练的人，他不见得有特别牛的技术，一个公司里面百分之八九十的工作就是把业务能够快速的变成一个系统，然后去迭代试错。
可能有百分之十、二十的工作才是需要去想怎么把整个系统的水准提到非常高的水平，然后把关键的系统写出来，关键系统永远是只占不到10%。所以我觉得两种人都重要，某种程度上，一批很熟练的人更重要，特别是新的业务需要快速推出的时候。
《参考》：CTO这个岗位是如何定义的?
行癫：在我的逻辑里，CTO其实是站在集团的业务角度来管理技术的角色。他首先要理解业务，第二他要保证业务可以快速实现，这是CTO要干的事情。
CTO是业务和技术非常平衡的那个人，他要把业务弄明白，才能够有效的部署下去，如果业务都不明白，他没办法部署，只能当一个传声筒。
互联网公司里三个关键角色——研发、产品和运营。有些公司把产品加技术放在CTO下面管理；有些公司的产品是独立的放在CTO下面；有些公司因为产品更加独立，以产品为闭环，把研发、运营也放在产品下面，比如像一些APP，它自己有个独立的团队。
《参考》：现在云原生的技术起来之后，未来对整个项目管理和工程师的管理，有没有什么影响?
行癫：阿里本来也不建议前端工程师去做那些非业务系统相关的事情，需要分工合作，因为不懂技术的老板最怕听见“又要建一个新系统”，老板都很难判断这个非业务系统有没有必要性。
云原生之后更加透明化了，资源全部清晰可见，再不用去开发那些底层系统，只要上面跑应用系统就行，它是天然分开的。
注：文/张帅，文章来源：钛媒体(公众号ID：taimeiti)，本文为作者独立观点，不代表亿邦动力网立场。
文章来源：钛媒体
