作者：张帅来源：钛媒体
全文共字，阅读需要16分钟
年，网景创始人、著名风险投资人马克·安德森(MarcAndreessen)写道，“Softwareiseatingtheworld”(软件正吞噬整个世界)，用以表达各行各业都被软件所瓦解，之后再重构，未来所有的公司都是软件公司。
事实证明，马克·安德森的预判远比大部分人想象的还要长远。
今天，全球市值最高的几家公司尽数为软件公司，不同领域的巨头内部有着相同的软件工程师群体。这么一群高智商、高薪酬的人聚在一起，是脑力的风暴还是角力的漩涡，是在冥思苦想还是在浑水摸鱼，很大程度上决定了一家公司的生产力。
不仅如此，随着数字化升级的深入，越来越多的企业组建起自己的软件开发团队，以满足自身在业务上的定制以及业务发展需求。因为系统复杂性的提高，软件团队的规模也变得越来越大，管理难度也随之呈指数增加状态。如何有效管理创新开发团队，也成了很多传统企业的一个隐形痛点。
而对于管理超大规模开发团队的经验和教训，阿里云智能总裁、达摩院院长张建锋(花名行癫)可能是最有资格回答的人之一，当年他带着12个人三个月完成天猫商城项目开发就是经典的案例。本期《云栖战略参考》(以下简称《参考》)就和行癫仔细探讨了这个问题。
01管理超大规模研发的秘籍《参考》：很多客户其实非常好奇阿里巴巴管理超大规模研发团队的经验和教训，阿里巴巴有怎样的最佳实践?
行癫：这是个很好的问题，但是我想先说说我对最佳实践的看法。
首先，阿里巴巴未必有最佳实践，因为业务的成功会掩盖很多真相。就像当年谷歌说有很多创新，是因为员工可以有20%的时间考虑“与工作无关的东西”。这就有可能弄错了因果关系，谷歌并不是因为这个原因成功的，而是因为谷歌成功才可以这么做。
所以这里面有个挑战是要知道哪些是真正可以复制的最佳实践，哪些只是因为业务成功之后总结成的“最佳实践”。结果很容易看到，但真正找到“因”是很难的一件事情。
我们可以通过这本内刊和读者一起来寻找最佳实践，和大家分享、碰撞一下。
我没办法告诉银行家，他应该怎么做“一二三步”，因为我没有办过银行，但如果这个银行家有足够的领悟能力，他会从阿里巴巴的最佳实践、阿里云的客户的最佳实践中取得一些借鉴，获得启发，然后提出他自己的问题。
我们只能说我们在这个行业里面做了什么，或者自己不见得成功，但是提倡的理念是成功的，能够引领未来的。比如说以后的办公是数字化的，像钉钉这样的平台；比如以后软件的开发是碎片化的。这些我觉得是趋势，未必见得在我们这里成功，可能在我们的客户里实现成功，比如太平洋保险，用了钉钉之后，把很多系统就自己开发上去了。
《云栖战略参考》就是把这个行业里的先行者的探索、实践，呈现出来。但是“核”永远不可能靠别人告诉你——如果我能告诉你，那意味着我能做你的业务。
《参考》：关于创新的研发管理最大的挑战是什么?
行癫：你觉得研发人员不好管理，是因为你不知道应该做什么。最基本的“管理”，就是告诉下属应该做什么，而程序开发是项目化、组织化程度最高的一个活动。
所有项目第一个动作都是立项，第二个动作是所有项目都要被准确的评估，到底要花多少时间进行开发，比如我当年做天猫商城，在规定时间内要把天猫商城上线。评估很重要，比如一个系统登录usecase(用户用例)，通常有经验的程序员写这个usecase，三天可以写完。我们尽可能把所有的usecase都给列出来，如果列不出来，说明这个需求没弄明白，需求没有弄明白就去做，肯定是很难收敛的，做到最后就会发现做的不对。
所以第一步就是把所有的usecase都要列出来，列不出来的话，就不要开始后续的工序，就要弄明白这个软件到底有哪些功能。列完之后就在后面标注三天、五天、六天、七天，所有加起来就是总共花的工时。比如可能要花个工时，就需要思考，个人做一天，还是个人做10天，还是10个人做天?这肯定不一样的，但绝不可能个人做一天就做完了。必要的周期还是要有的，这个周期有经验的管理者会有自己的判断。
我们根据必需的时间，把人员核算好，就开始做。精髓是，需求必须明确！
我们才能够按部就班列出来，然后得到一个工时数，确定所有的资源投入，之后就是标准化的系统管理：什么时候应该研发介入，什么时候应该测试介入，什么时候应该提交测试，提交测试的提交标准是什么——这都是非常标准的流程，只是很多软件开发团队没有严格去遵循。
比如，听别人说很多软件公司不做测试了，自己也不要测试了，开发工程师来测试就可以了，但实际上有些测试很重要，甚至需要有一半人做测试。原则很简单：如何让总体研发时间最短、成本最低。但一个项目应该是测试多，还是应该是开发多？不同的项目不一样，管理者自己决定。但必须保证总体的时间最短，投入的资源最少。
《参考》：阿里有没有自己的软件开发方法论?
行癫：方法论可以探讨，但是方法论需要固化成为工具。你必须要有一整套工具来支撑方法论落地，怎么管理需求、怎么提交代码等等，我们内部有Aone。
但Aone是很重的，比较适合于大型项目的开发，小公司可能不需要这么重的工具，可以去做裁剪，我觉得各自有各自的做法，认同你的方法论就会采用你的工具，不认同你的方法论人家也不会采用你的工具。
很多公司没有方法论，只关心工具——这是两个层面，都需要