业务架构的基本思路

大型网站系统有很多功能，一次性明确所有的功能需求并设计出一个庞大的业务架构是一件费力不讨好的事情。因为在项目前期，难免会忽视一些琐碎功能，而随着开发的进行，也会有很多新的想法产生，基本上不会存在完全按照最初的业务架构设计完成的软件产品。因此，业务架构不仅要做到“规整功能模块，厘清产品业务逻辑”，更重要的是如何做到“有规划性地应对项目过程中的需求变更”。

递进思想

传统的软件开发基本上都遵循瀑布开发模型，即项目开发过程必须严格按照需求分析、设计、编码、测试和维护等步骤执行。瀑布开发模型的流程和产出物如图2.5所示。在一般的瀑布开发模型中，每个阶段都需要有明确的产出物，通过严格的评审后才能进入下一阶段。瀑布开发模型的理想状态是每个阶段只执行一次，一次性完成整个项目。瀑布开发模型很大程度上依赖需求分析阶段的明确性，因为在瀑布开发模型中默认需求是充分和明确的，需求几乎不存在被改动的情况，所以设计和编码阶段都是完全以需求分析为依据的。如果在项目后期才发现有重要的需求变更或者有其他遗漏，往往就会导致项目失败或者项目重新启动。

图2.5 瀑布开发模型的流程和产出物

在上节节中曾提到，大型网站系统的需求很难做到完全明确，在项目开发过程中往往会有更好的想法产生。如果我们完全采用瀑布开发模型的思维方式开发大型网站项目，并且想一次性确定需求并交付项目，那么很可能在项目的后期才会发现需求有遗漏，或者很可能在网站基本定型后才发现大部分功能使用起来并没有预想的好。这些情况都会在很大程度上导致项目失败。

瀑布开发模型的弊端很明显，即需求必须是完全明确的，对需求的变化适应性差。瀑布开发模型一般就是我们执行项目时的惯性思维，正是因为这种惯性思维，使得开发者在项目开发过程中对需求的变更是恐惧的。针对瀑布开发模型的弊端，敏捷开发模型被提出来而且逐渐流行。敏捷开发模型不是确切的项目管理框架，它是一套软件开发的原则。敏捷开发主张适度的计划、迭代开发、提前交付和持续改进，并且提倡快速与灵活地看待开发与变更。简单地说，就是在开发过程中保持沟通，不断交付完成的部分，并持续地改进，而不是一次性交付项目。遵循敏捷开发原则的项目流程如图2.6所示。

图2.6 遵循敏捷开发原则的项目流程

不过，软件开发终归逃不出需求分析、设计、编码、测试和维护等步骤，没有一个明确的主体需求也会导致开发无法进行，盲目地持续改进更会造成很大的成本浪费。因此笔者认为瀑布开发模型的流程也不是不能借鉴。敏捷开发提倡的是沟通，通过持续的沟通和改进最终得到一个满意的结果，而非以一开始想象中的全部需求来指导整个项目开发。

因此，不用在意项目开发是遵循瀑布开发模型还是敏捷开发模型，关键是如何在明确需求的同时适应需求变化。笔者认为，项目开发需要有递进思想。

遵循递进思想的项目流程如图2.7所示。可以看到，应先完成主体功能，然后再添砖加瓦，需求不用一次性完全明确，而是持续地进行沟通和改进，每个部分开始编码前其需求必须是明确的，这样通过多个递进阶段完成整个项目。

图2.7 遵循递进思想的项目流程

项目流程只有遵循递进思想，才能更好地应对需求变化。同样，业务架构也需要遵循递进思想，才能有规划地应对项目开发过程中的需求变更。在明确主体需求的前提下，可以适当省略一些次要或琐碎功能的细节，但不能完全忽视这些次要或琐碎功能，完全忽略这些需求会导致工期失控。等主体功能开发完成后，再对次要功能的细节进行明确，等次要功能完成后，再对一些琐碎的功能进行明确，以递进的方式逐步细化和修改业务架构。

版本计划逐渐完善

在上面曾提到，项目流程只有遵循递进思想，才能更好地应对需求变化。那么，项目应该规划为多个版本，以方便逐步完成。一般来说，项目版本可以划分为主功能阶段、次要功能阶段和优化阶段。版本计划逐步完善的项目流程如图2.8所示。

图2.8 版本计划逐步完善的项目流程

1.主功能阶段

主功能阶段主要实现整个主体功能，这一阶段的业务架构需要完全明确主体功能需求，次要功能和琐碎功能的细节可以先忽略，但次要功能和琐碎功能也要体现，因为它们会影响技术架构和迭代计划。项目开发过程中可能会对主体功能进行调整，但是偏离程度不能太大，不能说一开始只想要一个网页，而项目开发过程中却想加入App客户端。

2.次要功能阶段

次要功能阶段的目标是实现之前忽略的次要功能。这一阶段可以根据实际情况进一步细分成多个次要功能阶段。在这个阶段中，不需要一次性明确全部的次要功能，只需要明确当前阶段的次要功能即可。次要功能阶段可能会出现频繁的需求变更，因为次要功能一般是一些用户体验方面的功能，经常会发生改动。但是，最好能按照过往经验和精品网站的要求做尽量好的方案，这样能在一定程度上减少需求变更的发生。

3.优化阶段

因为项目开发过程是不停地让业务部门或者客户使用网站系统的过程，所以其间难免会有很多新的想法，有一些甚至是从来没有提及的需求。这些新需求一定不能在主功能阶段和次要功能阶段添加（除非这些需求所需的工作量非常小，或者这些功能是主要功能或次要功能中必不可少的部分），因为这样会打乱这两个些阶段的开发节奏和既定计划，导致进度失控。要想把进度失控的项目重新拉到正常的状态是很困难的，很多时候失控只会越来越严重。

因此，这些需求可以先记录下来，在优化阶段再仔细评估和处理这些需求。在优化阶段再处理这些“突发奇想”的需求，既可以保证前面的项目进度，又可以集中控制这些需求带来的风险。

持续优化，推陈出新

很多项目的失败与团队经验、技术水平或项目管理水平没有直接的关系。大部分项目失败的原因是妄想网站第一次上线就具备市场上所有的好功能，同时还要具备特色功能。这个想法如果占据主动，则会添加过多其实并不需要的伪功能，也会习惯性地修改需求，最后在不知不觉中导致时间成本和人力成本的严重超支，以致项目崩塌。对于大型网站而言，由于功能繁多，所以值得斟酌的地方也会有很多，加之项目工期较长，开发人员看上去也充足，因此需求经常被改变，导致项目在不知不觉中失控。

罗马非一日建成。时间成本和人力成本是有限的，好的功能也会随着市场竞争被更好的功能所取代。而且从用户使用的角度讲，通过多个迭代版本持续学习新功能往往会比一次性地接受过多功能更有吸引力。因此，大型网站项目应该持续优化，且要不断推陈出新，而非一次性地完成全部功能，即通过一期项目、二期项目、三期项目等有规划地逐步构建大型网站才是合理的。

对于业务架构而言，如果出现一些好的想法或功能，但是其工作量很大，则需要考虑是否将其放在下一期的项目中实现。