汤涛滔谈系统需求收集和架构设计

个人简介 汤涛滔，曾任职微软（中国）有限公司顾问咨询部、公共事业部高级行业顾问，历任资深技术顾问，技术总监，副总工程师等，具有相当丰富的项目管理和开发经验。负责过多个大型项目管理、设计和开发工作。作为技术专家设计、规划或评审多个项目，其中包括但不仅限于中国人民银行“人民银行货币调控系统”、海关总署“全国海关统计资讯系统”、“全国海关办公系统”和“移动办公系统”、人事部“全国机关事业单位工资管理系统”等，精通项目管理各个环节，对于软件需求开发管理、软件架构等具有相当丰富的实战经验。在业界具有良好的口碑。

MPD大会是中国软件研发管理者自己的年会，是本土操作实践与海外研发经验分享的年会，主要面向以下软件开发管理人士：首席技术官（CTO）、研发总监、产品经理、开发主管、测试经理等与软件研发团队密切相关的领导成员。

   

1. 今天非常很荣幸在亚太软件研发团队管理年会上采访到微软顾问咨询部资深架构师汤涛滔先生，汤先生先给我们介绍一下你自己？

我最早也是从程序员开始做起，最早CODING，包括做一些基础的工作。那后来一直往项目经理这个角色，以及架构师这个角色在转。再后来呢，就在往这个管理角色在转，就包括现在在做这个叫类似于CEO什么之类，类似这样的角色，等于从最基础的编程开始到项目管理到架构设计，到高级管理等。

   

2. 众所周知，需求是架构的核心，不了解需求的话无法设计出符合需求的系统，那么又要准确而全面的去把握需求也不是一件非常容易的事情，那么作为你在搜集和整理需求的过程中，有没有什么经验和我们的架构师进行分享？

首先第一个问题是要摆正我的方向，首先方向是最重要的，因为如果方向出问题了，那需求做得再好都是有偏差的，所以要从战略的高度来看待我们软件系统的方向。而这个方向并不是说，因为我们有时候在软件开发里边，往往会遇到一些词汇上的一些差异，理解上的差异，比如说我们一直在强调说，我们要搞清楚用户的真实需求，用户的核心需求，什么诸如此类的。实际上根据我自己的经验来理解，那么这么些年来，在这个项目里边我们发现一个共性的东西，第一用户往往阐述不清楚，他到底想要什么；第二即使他阐述清楚了，因为用户的需求往往是无限的。所谓无限的含义是什么呢？就像我们在心理学上有这样的词汇，当我们满足了一些基础需求，用户一定会有更高一层的需求。

   

3. 肯定是。

对，所以这样子，就会导致我们现在项目里边，跟着这个用户的所谓的用户的需求在跑，那这样我觉得实际上这是一个，首先我们要定义方向，就是我们的目标到底是什么，我们的目标真的是用户提的想法或者需求吗？我觉得在我们任何项目和产品设计里边不完全是这样。那我们的目标应该是什么呢？这是我觉得值得探讨的一个问题，就是我把我的一些想法来跟各位分享、沟通一下。实际上，我们在过去很多项目里边，我们会发现有一个很重要的因素，当我们去做一个产品的时候，我们这个产品的目标是什么？是为了占领市场，是为了这个叫生命力很长，长治久安这种，还是为了别的？那这个目标将会涉及我们是怎样来去做需求，以及需求做到什么程度。

假设我们说我们要像微软、像IBM、像HP这样子来去做，这时候我们会发现他们有一个共性，什么样的共性呢？他们实际上往往不是完全跟着用户的需求在走，他们更多的是瞄准他们的战略目标，什么样的战略目标呢？就是我要到底实现我的什么样的商业目标，比如像微软，那微软的商业目标很简单，就是我要占领桌面市场。所以从Windows到Office，它都在做同一件事情，是什么呢？替换用户的功能，我们可以感受到，目前我们几乎现在无论搞IT还是非IT还是管理，我们一大部分功能都被桌面替换掉了，就被微软替换掉了，以前我们做演讲，我们用透明的塑料膜做得的投影机，现在我们几乎很难看到了，因为这项功能已经被替换掉了。

   

4. 还有胶片。

被PowerPoint替换掉了，所以从这个角度讲，我们在做需求的时候，首先要搞清楚我们的战略方向，我们的目标是什么，然后才来根据这样的目标去做取舍和选择。因为有时候对用户来讲，他提出的需求，不一定是跟我们的目标相完全匹配的，这时候我们要放大跟我们目标匹配的需求，而缩小那些跟我们目标不匹配的需求，换句话说叫排除这些噪音。因为在一次软件项目里边，一定会有大量这样的噪音，那如果我们做这到一点，就意味着什么呢，我们让客户对我们产生严重的依赖。我恭喜各位，如果你找这到一点，你就会取得巨大的成功。

   

5. 架构师不仅要懂技术，还要懂得处理与各种人之间的关系，那么要想做一个成功的企业架构师，或者是项目架构师，又必须要处理好与项目经理、开发人员、测试人员等等，甚至和CTO之间的关系，那么在这方面你有什么诀窍呢？

我觉得就说在作为架构师的这个Scale Sets，就是他的这些能力的这些集合里边，实际上有很大一块是非技术的因素，技术只是占其中的一小块。根据我这么多年的经验的理解，技术只是占到其中很小的一块。那其他的很大一块呢，就包含有不仅仅是说素养的问题，那很重要的一块就是个沟通的问题，我们又称之为叫架构的协作。所谓架构协作是指什么呢，就说我们设计出一个架构以后，就相当于是指明了我们未来这个团队在这么长时间的一个方向，也就说我们的战略方向、我们的目标，那在这样一个前提下呢，因为我们知道，要一个团队，这个要完美的来去做好一件事情，一定是需要有统一的思想认识和统一的行动方向。所以就是要拿以前毛主席一句话，叫团结一切可以团结的力量。

所以这时候我们就需要涉足我们的CEO、客户的高管，如果我们做产品化的话，那一定要涉足到不同的部门和线条，让他们能够来支持我们。换句话说，让我们整个一个团队，不仅仅是说开发团队，我们的眼光作为架构师，一定要站在一个更高的高度来去看。这个更高的高度就是，我们看所有周围这些，凡是跟项目未来会有关联的，都是我们的资源，这叫有资源的方式来去看待。而正是由于这些是资源，所以要通过各种方式，沟通是其中一个很重要的渠道，然后把他们这个叫资源，都能够纳入到我们团队，朝着我们团队的方向前进。所以在这一块沟通和这种叫资源的协调，这是一个很重要的层面。架构师不是说我设计好了就不管了，设计好以后，一定要取得团队的认可，开发团队的认可，我们的商务团队的认可，我们的领导团队的认可，所以这一切都有赖于我们怎样来去沟通和协调这些资源，这只是其中的一个Skill Sets里的分支。

   

6. 很重要的一个本质，也有人说做架构就是一个不断去寻找平衡的过程，你比如说你要想让你的系统有非常高的性能，那你可能就会牺牲安全，那你要安全性很好，你可能就会牺牲性能，更多的抽象可能会产生开发的复杂度等等这些东西。那么在寻找这个平衡的过程中，你有什么指导原则和我们的架构师进行分享的？

这个核心的原则，因为我们知道架构师实际上在做架构工作的时候，最关键的就是在做一个取舍，做一个平衡的取舍。这种取舍一定有一个核心的贯穿这个取舍的一个方向，这个方向实际上跟我们前面讨论的方向几乎是一致的，就是商业目标或者战略目标。而这个战略目标一定要清晰话，这种清晰话就说，不仅是说架构师本身要来去找到这样的方向，而且要让整个团队都来去了解这样的方向。这样大家做取舍，才会有一个支点，这个支点在那，因为一个平衡，一个天平，它一定会有一个支起那个天平的那个支点，这个支点在哪，这个很关键。这个支点将决定这个天平它的这个叫，我可以用多少斤的力量来矛动比如说几吨的力量，这个支点很重要。

所以这个支点就是我们前进的方向，我们的战略目标，或者说我们的使命。OK，好，那有这样一个大的方向和大的支点以后，接下来就是我们怎么选砝码，我选那一些作为我来去挑选来去均衡的一些砝码。这些砝码有多方面的因素，有市场的因素、技术因素、团队的因素等等，这些因素实际上在我们每一次架构设计里边，都需要来考量。有用户提出来的一个因素，比如用户的优先级、技术的优先级、市场的优先级等等。由此我们才能真正的把这个平衡把握的很好。

就像你刚才提到的安全和可用性之间，那这的确他会有，像两个葫芦一样的，按下这边，那边冒出来，按下这边，那边冒出来。那现在问题就来了，要选择一个平衡点，这个平衡点到底在哪？那就是根据综合的因素，实际上我们在做架构的时候，往往会有这样的一些因素的考量，这些因素考量现在有一些算法，或者说一些公式来去做这样的一些均衡的取舍。这些大家可以参照一下需求方法论里头，像一些这种叫用力的权重什么之类的，类似这样的东西，那里边涉及到有环境的因素、有技术的因素、有用户的因素等等。

   

7. 在您的演讲中你也提到了架构师要有创新思维，创新同时意味着探索，在另外一种意义上来讲，也意味着风险，那么您是如何来看待创新和风险的关系的？

创新一定会有风险，因为有投入，而且产出是不可预知的，对吧。但是不创新的风险更大，为什么这么说呢，因为就说如果你不创新，那么我们的竞争对手会比我们跑的更快，在竞争领域里，不是说这个我们不能单单把这个眼光放到团队内，而是要放在整个市场，放在我们的竞争对手，放在我们的整个市场环境上。如果我们不创新，别人一定会创新，并且跑的比我们还快。那对于这个创新思维呢，像Intel的一些总裁们，他们是对这个很有理解，所以我们看到像现在Intel的CPU，他是不断自己在超越，就像摩尔定律，三个月更新，三个月更新。像这个就是他自己自我更新，不断的推出更好的、更新的，更能满足市场需要的一些新产品，所以综合起来就这一句，创新有风险，不创新风险更大。

   

8. 架构师也有很多的分类，有企业架构师、业务架构师，还有服务架构师。那在您看来架构师应该怎么分类会更好一点？

这个分类就跟我们市场细分一样，他有很多的细分的变量，这些细分的变量会使得我们分层的不一样。比如说我们从这种大的方向上来分，通常架构师是分成企业架构和解决方案架构，这样两个层面，一个企业架构就相当于我要来去规划整个企业未来的信息化，如何来支持业务，包含一大堆的系统，可能需要五年、十年怎么发展；那对于应用架构师，就相对是我们在软件内部的，在比如说我们做一套系统，那这时候应用架构师就开始承担起相应的职责。那实际上在应用架构师里边又可以进一步细分，比如说分数据库的架构的，这个网络架构、安全架构等。当然企业架构层面也可以细分，比如说Infrastructure，就基础架构的架构的，然后信息化的，Informational Architect，Solution（解决方案）之间怎么结合。

所以呢，在这个Enterprise Architect这个层次呢可以细分，那在Solution Architect又可以继续细分。但目前的分法呢，就是从大的范围来讲，就是Solution Architect和Enterprise Architect这样两个领域，因为他们之间差别还是蛮大的，那个Enterprise Architect，他关注的不是说我继续去解决某一个用户的单个的问题，而是解决一个企业未来的发展方向和这个整体的问题。那Solution Architect解决的是相对细，就我某一个方向，比如说我的HR，我的这个ERP，这样比较具体一些。所以对于EA，就是Enterprise Architect来讲呢，相对呢，他是应该说是叫在这些不同的Architecture之间一些关联，这样一个就是分类的一个模型。

那具体的在应用方面，当然可能还有些其他的分法，在业界目前来讲，这个EA和SA这两个领域是大家比较公认的，那至于具体内部在怎么细分，就各有各的不同的分法，微软可能有微软的分法，IBM可能有IBM的分法。大概是这样。

   

9. 现在我们知道面向服务的架构，也就是SOA越来越完善，随之也诞生了新的架构师的抬头，叫SOA架构师，那SOA架构师与传统架构师，你认为在职能上有没有什么主要的区别？

因为刚才咱们提到，传统架构师应该讲它还是两个层面的，有EA和SA之分，就是Enterprise级别和Solution级别的，那我估计你提到的这个传统架构师，应该是大部分应该是叫在SA的这个范畴的，Solution这个范畴的。那Solution这个范畴和SOA架构师之间，确切讲它有些重叠，有一些不同，这个重叠体现在那里呢？就说SOA应该它更多的面向服务的这种架构，他既可以作为我这个叫SA这个底层，就是我一个Solution的底层。比如我们假设做一套系统，这一套系统是我们企业的ERP，因为ERP要跟太多的系统打交道，要跟供应链打交道，要跟HR打交道，要打财务打交道。那么他们之间的关联实际上就可以通过SOA来做，这时候SOA架构师呢，就跟这个SA的架构师它的职能就蛮重叠了。

那么还有一些就说是我们企业内的这些不同系统的整合，和企业的系统跟外部的系统的整合，这时候它就不会涉及到比如我系统内部一些细节，关注的只是系统与系统之间怎么来交互，怎么来实现流程编排。那这时候呢，SOA的架构师的关注点就会在系统间的这个服务接口，系统间的这个交互这一块，所以这时候它跟传统的SA呢，就会有一些差异。这种差异呢，并不是说它本质的区别，而是说随着技术的发展的一种区别，那可能以前大家都是通过传统的架构师来去设计标准的接口，现在我们把这个设计标准接口这一块，因为我们要跨系统、跨平台，那很难做了。我们就通过SOA来去实现，这时候SOA架构师相当于就把传统的接口设计这一块放大了，就类似于这样，所以他们之间是一个既有重叠，又有不同，这样一个关联，是这样子。

   

10. 不论是在国外还是在国内很多架构师也都是从程序员转型过来的，刚才在您的介绍中，您也提到您也是从程序员一步一步走到现在的，那么您认为就是您的程序员的经历，对您后来作为一个构造架构师的职业有什么具体的铺垫？

这个实际上是蛮关键的，这个实际上跟我们设计软件、设计产品是一样的，每一个人你首先需要有个目标，如果没有目标，那就意味着，就说你不会去关注你周围的跟这个目标相关的事情。比如假设我们说，我们想成为比如说我想学开车，如果是说这个你不定义这样一个目标，假设天天周围有大量的这些信息你不会去关注了，在心理学上有一个重要的法则叫吸引力法则，就说只有当你心里有所想，这些信息它才会来找你。因为您周围，比如说我们每个人接触的信息量太大了，就说曾经有人估算，大概是在几千万亿的比特的信息量，我们每天接受的。但实际上大概我们真正能吸收的，或者说我们能抓住的这些信息，大概只有几千亿个比特的这种信息抓在我们脑子里边。

比如说像在我们这个场馆里边，我们这边挂的这种壁画或者油画，我相信大多数人可能不会去关心。但是如果是一个油画家进来，我相信他首先就看，这个画怎么样，它的风格是什么，OK这就是我们所谓的吸引力法则。所以作为程序员来讲，首先你需要定义你的发展方向和目标，假设是说我就以架构师，或者我以项目经理作为发展目标，那这时候呢就说，我们都知道这样的一些角色他有他的一些职业技能的一些要求，或者说我们叫Scale Set。那这种Scale Set它里边有很多分支，那这些分支呢，我们就需要来去考量，比如说我，在这些技能上，哪些是我的长板，哪些是我的短板，那我们就需要来考量怎么来去补这些短板，怎么样来去补这些短板，这样子我们才能逐步的往这个方向来走。

比如我们从程序员发展，我们想来成为一个架构师，这里头就有几个关键的技能是必须的，第一个我们刚才提到的沟通能力，演讲能力，因为你需要带着团队，你需要来让团队所有人按照你的设计思想往前来走，所以呢演讲力、沟通力这是必备的。那同样我们需要有领导力，我们要把整个团队能够领导拧成一股绳，所以这个领导力又变得很关键。所谓领导是这样的，拿传统的一个思路来讲，实际上就是一个叫领袖和导师，所以这里头不仅需要带着别人往前冲，还要作为导师来去教别人。所以这个时候，类似这样子的一些，还有很多其他的，我们只是举了其中的几个小例子，这样的这些技能方向一定是要来去关注，这种关注不是说我就天天坐在那想，我要成为一个架构师，我要成为一个架构师。

不行，一定要具体化，就说作为一个架构师那需要有这些能力，OK，那我们应该怎么样来去，我想成为架构师的话，我就必须演讲力、表达力、沟通能力提升上去。这种时候我们就要来去通过各种方式、各种手段来去改善和提高，这样子才能一步一个脚印（走上去）。实际上这对我们任何人，就说职业生涯规模也是一样的，就不单单是说从程序员发展到架构师，这个我相信是通用的。你首先需要把你的目标具体化，才具备可执行的价值，才有可实施的这个叫力量，你才会真正的往前走，那只是说天天想，我要一个别墅，我要有一个别墅，那是不行的。

   

11. 一定要具体化。那最后我们再简单的总结一下，你认为作为一个称职的架构师需要具备那些特质，如果说这个是一个Senior Developer，就是一个高级的程序员，他想成为一个架构师，一个成功的架构师，他应该怎么做？

实际上知识的学习是很重要的一个层面，我们刚才已经提到了，我们要这些知识技能都要来去学，那么学，我们说形成知识技能是不够的，一定要让它应用并且形成自己的智慧，这才是有价值的。培根说了知识就是力量，那发展到今天，我们越来越发现实际上，就像彼得•德鲁克说的，著名的管理大师说过，知识本身这个它不产生价值，哪怕它在我们脑海里装的太多太多，只是知识而已，只是装在脑袋里的知识，东西而已，让它产生价值最佳的方式是什么？应用和分享知识，才能带来价值。就像我们在这边跟大家来分享，这个分享是有价值的。

那同样，我们比如说我们成为这个要成为架构师的话，那我们可能把这些技能都开始一个一个练了。练完以后，它形成你的一个一些智慧，形成你的知识，但是我们还要作为架构师这个角色来训练。这时候可能很多人会问了，我们在企业里边我们没有这样的机会，我们每天都在忙着自己的代码呀，这里头就有个很关键的点，什么关键的点呢？主动积极去做你所想的，试图来去实现的目标的事情，也就说，虽然可能你不是一个架构师的角色，你是一个比如说程序员，或者高级程序员，或者是类似诸如此类的。那在任何一个项目里边，那一定会有架构设计团队来去做相应的工作，那这时候你把自己想象成那个组里的人，如果你是那个组里的人你会怎么做，你会不会做类似像他们这样的设计？或者说你有没有更好的想法？

如果你有，把它写下来，把它做出来。然后呢，换句话说，就叫贡献你的力量，贡献你的知识，哪怕就说这种贡献是没有任何回报，但是这种贡献对自己绝对是一次极好的锻炼和成长的机会，因为你站在架构师的角度去想问题了。也就说当你的内心改变了，你的外在才能来去改变。那这样一步一步下来，你会发现你的思维模式你的思考方式已经变的，跟你们这个团队的架构师的小组一致了，或者甚至比他们想的更多了，那试想，如果某一次做产品设计也好，做架构设计也好，你的老板的老板，你们的CEO发现你具备这个能力的时候，各位就不用我多说了。

   

12. 好，非常感谢汤先生接受我们的采访。

OK，好。