导语
2011年，网景创始人、著名风险投资人马克·安德森(Marc Andreessen)写道，“Software is eating the world”(软件正吞噬整个世界)，用以表达各行各业都被软件所瓦解，之后再重构，未来所有的公司都是软件公司。事实证明，马克·安德森的预判远比大部分人想象的还要长远。
而对于管理超大规模开发团队的经验和教训，阿里云智能总裁、达摩院院长张建锋(花名行癫)可能是最有资格回答的人之一，当年他带着12个人三个月完成天猫商城项目开发就是经典的案例。本期《云栖战略参考》(以下简称《参考》)就和行癫仔细探讨了这个问题。
揭秘阿里研发团队
阿里定义下的架构师
阿里架构师的变迁史很复杂，原来就是技术水平最好且最了解业务的人，才是架构师。这个人往往后来都会成立架构组或者架构部，但架构部一成立就脱离了业务，所以阿里也是在来来回回调整，架构师在部门里面-独立出来-又融合，一直在循环。但是架构师越来越难培养，因为业务系统越来越复杂。
所以后来阿里把系统模块化，所有人能处理问题的边界都是有限的，阿里有很多系统，每个人来负责一个系统，系统里一个主要的人就是架构师，他必须把自己的系统全部做好。
再到后来项目逐渐变多，一个项目里面有项目经理、架构师、产品经理、程序员，但在业务系统里面那个人不再叫架构师，一般是系统分析师。架构师偏纯技术，系统分析师比较偏复杂的业务系统分割，梳理好系统之间的关系。
技术架构师现在的地位被削弱，因为太多的东西都标准化，没有必要从技术的角度想一个新方案出来，但业务架构师因为复杂业务系统越来越多，比如银行是典型的复杂业务系统，他们需要的就是好的业务架构师。
业务架构师的培养周期很长。技术架构师从A公司到B公司，是能够很快去接手的，业务架构师需要很多年的积累。他一定是技术出身的，因为业务的知识相对容易积累，技术的知识业务人员是积累不起来的。
研发人员层级分布
阿里的开发人员大概5-6万人，中间层P7/P8最多。
阿里把工程师分为不同层级，做研究的在达摩院，还有做基础工具、基础平台，阿里云的工程师开发业务产品，阿里巴巴电商系的工程师也有开发电商技术。但都遵循四个标准：稳定是底线，稳定压倒一切；第二是效率；第三是成本，效率高还要考虑成本；第四要有创新，创新技术能够反向推动业务，比如人脸识别技术可以简化登录。
淘宝、天猫的技术研发不是产品研发，产品是淘宝、天猫。这个看似很简单：把技术能力变成产品，把产品变成市场。但是有很强的能力，不见得就有很好的市场。
阿里的老程序员有两种，没有贵贱之分，因为每个公司都需要非常熟练的人。一个公司里面百分之八九十的工作就是把业务能够快速的变成一个系统，然后去迭代试错。
可能有百分之十、二十的工作才是需要去想怎么把整个系统的水准提到非常高的水平，然后把关键的系统写出来，关键系统永远是只占不到10%。所以这两种人都重要，某种程度上，一批很熟练的人更重要，特别是新的业务需要快速推出的时候。
软件开发方法论
方法论可以探讨，但是方法论需要固化成为工具，要有一整套工具来支撑方法论落地，怎么管理需求、怎么提交代码等等，比如阿里内部有Aone。
但Aone是很重的，比较适合于大型项目的开发，小公司可能不需要这么重的工具，可以去做裁剪，行癫认为不同公司各自有各自的做法，认同阿里方法论就会采用阿里的工具，不认同就不会采用。很多公司没有方法论，只关心工具——这是两个层面，都需要关注。阿里现在的方法论，所采用的工具是自研的Aone。行癫要求工具一定要开源，开源之后所有的工程师才会来使用，甚至会反过来优化你的方法论。
原来中国的软件开发，基本上工具决定了方法，有些工具很重很重，互联网公司不能用，因为互联网强大之处在于反复迭代，容错性很高，关键流程不出错，其他东西有点瑕疵无所谓。但是站在其他行业的软件开发维度来看，软件分发出去之后修复成本很高，需要在分发前反复测试。
管理超大规模研发的秘籍
管理体系的建立
阿里一开始没有形成规模的研发管理体系。一个经典的问题就是工程师到底应该属于哪个部门？现在很多工程师都不属于业务部门，而是个资源部门，那么哪个需求优先做，就是个很现实的问题。
阿里现在的业务工程师占70%左右，工程师的工作是不能精准量化的，最终看贡献，包括技术能力、对组织的贡献。技术体系的晋升是个相对性的事情，无法追求绝对公平。
追求绝对公平的有两个体系，一个是行政体系，第二个是技术委员会，技术委员会不会特别考虑业务的问题，而是从纯技术角度评价员工的能力水平。
行癫认为技术委员会是阿里相对超脱的一个组织，就是工程师自治的组织，它是从技术品牌对外的影响力来思考，比如如何吸引更好的员工来加入。技术人员从来都不是一个商业部门的核心问题，业务部门最大的挑战永远都是业务在市场上有没有竞争力，而这种竞争力绝大多数都不是技术决定的。
管理“最佳实践”的分享
最基本的“管理”，就是告诉下属应该做什么，而程序开发是项目化、组织化程度最高的一个活动。
所有项目第一个动作都是立项，第二个动作是所有项目都要被准确的评估，到底要花多少时间进行开发。根据必需的时间，把人员核算好，就开始做。精髓是，需求必须明确！
按部就班列出来后，然后得到一个工时数，确定所有的资源投入，之后就是标准化的系统管理：什么时候应该研发介入，什么时候应该测试介入，什么时候应该提交测试，提交测试的提交标准是什么——这都是非常标准的流程，只是很多软件开发团队没有严格去遵循。
比如此次“双11”这样的大项目，阿里管理流程的关键就是模块化，每天模拟“双11”的情况，模拟最坏情况下，怎么做降级处理的操作。当然研发一个模拟系统，这是另一个重要的工作。如何定义问题，大的项目里需求的定义变得非常重要。需求定义是最关键的！
行癫认为很多的产品不好，是因为需求是没有想明白。有时所谓的“提需求”，并不是在提需求，而是在讨论，因为提需求的人自己也不知道这是否是个需求。
云原生后的管理转变
阿里不建议前端工程师去做非业务系统相关的事情，需要分工合作，因为不懂技术的老板最怕听见“又要建一个新系统”，老板都很难判断这个非业务系统有没有必要性。
云原生之后更加透明化了，资源全部清晰可见，再不用去开发那些底层系统，只需要在上面跑应用系统，它是天然分开的。
来源：钛媒体
编辑：阿里云研究院内容运营主管 赵子千
