软件交付那些事儿

内容提要

本书通过一个个通俗的故事，详细阐述软件交付的过程，揭开其中的奥秘，是所有人都能看懂的软件开发宝典。我希望通过这本书，让所有人更理解软件交付的过程，包括相关的管理理念、流程、实践、工具和技术，分享成功的经验和失败的教训，从而促进用户、业务人员与IT交付团队彼此的理解和融合，改善协作模式，形成双赢局面，获得成就。对于IT从业人员来说，这本书也可以是给用户最好的礼物，帮助促进彼此的友好协作。

版权信息

书名：软件交付那些事儿

本书由人民邮电出版社发行数字版。版权所有，侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。

如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。

作者序

企业用户如何获得高效、稳定的企业软件？不管对于用户，还是IT部门来说，软件项目的交付过程总是痛苦不堪，如何突破这种窘况？

如今，几乎所有企业都需要软件。作为业务人员或企业用户，人人都想获得好用、稳定的企业软件，这将极大地提升业务效率，增加利润，帮助企业和员工获得更大的成功。特别是作为甲方，谁都希望这钱花得值，能够在预算内得到想要的企业软件或商用软件。

对于非IT人员来说，软件开发是一个神秘的过程。也正因为这个原因，很多用户认为只要说出对软件的期望，专业的IT团队就会把他们想要的软件“变”出来，然而，现实已无数次证明这并不可行。

笔者从事软件开发超过十七年，也有超过十三年的软件项目管理经验，笔者的最大感悟是，成功的软件交付，是业务人员或用户与IT通力合作的产物，最重要的就是双方的深入理解和融合。特别是在今天这个时代，为了快速应对急剧变化的市场环境，我们追求敏捷交付，共同实现业务价值的最大化。软件交付，并不仅仅是IT的事情，用户的深度参与也是成败的关键。这就像装修，要想得到自己满意的效果，就是要频繁沟通、天天盯着和持续反馈。当然，作为IT人，我们并不需要也不希望被天天盯着，但是彼此的协作模式必须要改变。所以我也特别不想用“甲方”、“乙方”这样的词汇。这并不是因为IT通常以“乙方”的身份出现显得低人一等，而是这样的身份定位其实是一种割裂，不利于彼此的协作，往往会使双方陷入对立，导致双输的局面。

本书通过一个个通俗的故事，详细阐述软件交付的过程，揭开其中的奥秘，是所有人都能看懂的软件开发宝典。我希望通过这本书，让所有人更理解软件交付的过程，包括相关的管理理念、流程、实践、工具和技术，分享成功的经验和失败的教训，从而促进彼此的理解和融合，改善协作模式，形成双赢局面，获得成就。对于IT从业人员来说，这本书也可以是给用户最好的礼物，帮助促进彼此的友好协作。

“以前有什么功能将来就要有什么功能！”——糟糕的需求是万恶之源

本章出场人物（以出场次序为序）：

“我的需求很简单，以前有什么功能将来就要有什么功能！”立项时，人力资源总监王章对项目经理陈诚说。人力资源部现在所使用的系统是购买第三方供应商的，后续的定制化开发也是由供应商提供，由于供应商已经倒闭了，目前这个系统已经没法维护，也不能再加入新的功能，所以人力资源部决定更换系统，为了避免今后类似情况的发生，这次人力资源部要求软件开发部自己开发一套新系统。所有的定制化功能也要迁移到新的系统上。

陈诚找到了软件开发总监老莫。让他安排人接下这个项目。老莫了解了一下自己部门的人手安排情况，决定让韩峰接盘。他把原始的项目需求文档给了韩峰研读。

这将是韩峰第一次独立去做一个项目。过去四年，韩峰的表现让老莫非常满意。他独立负责一个核心系统的维护和开发，该系统作为基础组件提供给其它项目组根据项目需求做二次开发。韩峰的技术和对其他项目组的支持，得到了项目组的一致好评。但一个月前，他和韩峰做绩效面谈的时候，韩峰提出他做了四年的核心系统维护和开发，一直都是一个人在工作，工作性质和其他同事挺不一样的，其他同事都是做项目的，需要面对用户，甚至需要说英文，他觉得自己在这方面经验很欠缺，因为他的“用户”就是其他项目组，也就是自己部门的同事，虽然目前的工作是他所擅长的，但他也想去尝试一些不同的挑战，否则将和其他同事形成很大的差距，所以也想转型去做项目，接触真正的用户。老莫其实是不想让韩峰调岗的，他觉得目前的岗位更适合他的特长和性格，但既然对方已经提出来了，也肯定是经过深思熟虑的，他也需要满足，决定让他去试一试，现在也刚好有一个全新的项目，时间上接得上。

翌日，老莫安排韩峰和项目经理陈诚还有业务分析师李媛见面，陈诚详细地介绍了一下项目的情况，目前最困难的是，由于旧系统的供应商已经倒闭，人力资源部也没有系统地维护好那些定制化需求的资料，所以挖掘需求是一个难点，他们就给了一句话—— “过去有什么功能，以后这些功能都要保留下来。”另外一点是时间上非常紧，人力资源部只给了四个月的时间，陈诚说：“根据以往的经验，我规划了一下项目计划，我计划这四个月里了35%的时间，也就是一个半月，用在需求分析上，40%的时间，也就是大一个半月，在用户验收测试（UAT）上，所以你们的开发时间只有一个月！”听到这里，韩峰有点不敢相信自己的耳朵，虽然他没有什么项目开发经验，但是凭直觉，开发一套全新的人力资源系统怎么可能只用一个月就能完成呢？陈诚看出了韩峰的担忧，他说：“老莫给你的文档，其实是人力资源系统的基础功能需求，你们可以先按照这份文档来开发，李媛会在这段时间尽力去跟用户澄清那些定制化需求，所以我说的一个月其实是定制化需求的开发时间，之前还有额外的一个半月做基础的功能开发。”韩峰绝望地说：“那也不够啊！”陈诚摊开手板说：“没办法呀，老的系统已经没有人维护了，很多新需求也做不了，人力资源部也着急啊！这确实是一块硬骨头，我们的压力也很大。”

会后，陈诚把老莫留了下来，他说：“老莫，我知道韩峰是你的得意弟子，但我也知道他没有项目经验，这个项目挑战性这么大，你还真敢用人啊。坦白说，你的决定让我信心大减。”陈诚和老莫是同一批进入公司的，算是老朋友。岗位上，陈诚隶属于变更管理部门，面向业务部门，负责业务部门的软件变更项目立项、项目管理和需求管理。老莫隶属于软件开发部门，对接变更管理部门，负责软件开发、实施与维护。因此，在这家公司，每个软件开发或实施项目都需要这两个部门的合作。陈诚和老莫已经是老搭档，所以彼此说话都比较随意和直接。老莫首先开玩笑说：“其他人没有档期啊。”他接着说：“这次的新系统是全新的自主开发，需要技术比较强的人，韩峰技术上在我这里是数一数二的，至于项目管理经验，不是有你老哥和我罩着嘛，这也是他自己的意愿，我相信他会学习和成长的。”陈诚说：“你要让他学也拿个小项目来学啊，这个项目我都觉得棘手。”老莫说：“反正有什么问题我会帮你撑着的。”

接近年末，王章和整个人力资源部都非常忙碌。绩效考核、年终奖计算和来年的预算，都是有严格的时间限制的。加上国家近期的税制改革，现有系统已经无法升级，现在所有员工的薪酬都不能通过系统来计算，只能通过Excel人工来做，他的人这几个星期每天都在加班。陈诚和李媛每天都会发邮件和打电话过来，要求他们给出定制化的具体需求。王章实在抽不出人手，他指派了招聘专员小罗去应付他们。最近招聘停了下来，小罗是他唯一可以分配的人员了。本来他对她是另有安排的，但经不住陈诚和李媛三天两头的“骚扰”。即使是这样，他们还不满意，陈诚说：“小罗对核心业务和系统都不熟悉，我们在她那里挖不到需求啊。”王章说：“说实在的，现有系统已经运行了十多年，我们部门的人在这里年资最长的也只有六年，我们也不可能什么都知道。你们是软件专家，我们还是要依靠你们来好好研究系统。”

李媛很失望，却又无可奈何。要说现有系统是自己开发的，有源代码在手上，还可以通过研读代码这个手段，但这个系统是别人开发的，手上根本就没有代码。没辙，现在李媛只能尽量在旧系统做详尽的功能分析，把每个功能都当作需求写下来，然后让人力资源部签署作为确认。

韩峰一边仔细研读文档，一边思考这个新系统的设计。现有系统是“胖客户端”（Thick Client）的模式，每个用户都需要在自己的计算机上安装客户端软件才能使用，每次系统有更新时还可能需要在每台用户的计算机上重新安装新版的客户端，当用户比较多的时候，使用和维护都比较麻烦。

过去流行这种模式是为了把大部分的运算和处理保留在用户的计算机上，减轻服务器的负担，由于服务器是集中在一台或几台计算机上，一旦出现性能问题，处理不过来，或者网络传输出现问题，就会成为所有用户操作的瓶颈。

但随着服务器的性能提升和网页技术的进步，“瘦客户端”（Thin Client）模式越来越流行，就是使用时，不需要在用户的计算机上安装任何软件，用户可以通过自己计算机的Windows自带的网页浏览器（比如Internet Explorer, IE）访问服务器上的网页应用（也叫“基于Web的应用”）来处理用户操作。由于大部分的运算和处理都交由服务器来进行，对用户计算机的要求也降低了。因此，新系统应该采用“瘦客户端”模式，做成网页应用。

在这一领域，韩峰经验非常丰富。在大学毕业前，他就已经开发过一个校友交流平台和一个网上商城了，都是网页应用。而他之前负责的核心系统也是一个网页应用。老莫正是看中他之前有这方面的经验，当初在他入职时就让他这个新人掌管核心系统这么重要的“资产”的。

但很快韩峰又有些担忧，人力资源部已经明确说“过去有什么功能，以后就要有什么功能”，由于当时网页技术的局限，大部分的处理过程是从用户网页浏览器的网页上把用户输入的信息发送到服务器，服务器处理后返回信息显示在用户网页浏览器的网页上，也就是说要经历1）从用户计算机提交信息和操作到服务器的上传过程；2）服务器运算和处理的过程；3）从服务器返回处理后信息的过程。如果网络传输速度不好，或者服务器的性能出现问题，都会导致用户需要等待，影响体验。有一些诸如验证输入格式的简单处理可以直接在用户计算机的网页上处理，不需要经过服务器。但是很多在客户端软件可以轻易实现的操作功能在网页应用上可能会是难点。在功能需求并不清晰的当下，这个技术选型本身就是一个风险。但是和陈诚、老莫商量后，他们也一致同意网页应用的方案，这样今后每次升级只需要在服务器上部署就可以了，大家使用也方便。至于可能会遇到的技术问题，总能有办法解决。

韩峰和团队开始按照原始的需求文档对基础功能编写外部设计。所谓外部设计就是面向用户的设计方案，内容包括每个功能的界面设计、操作流程等，让用户可以确认系统的外部行为。

在和李媛进过几次沟通后，一周后，外部设计文档敲定了下来，李媛拿去给小罗，让她尽快拿到王章的签署，好让韩峰他们开始内部设计和开发。两周过去了，李媛依然没有拿到签署。她一直在催小罗，小罗说文档一直在王章那里，她也催过几次。没办法，又要陈诚出马了。王章表示最近实在太忙，设计文档又比较长，他实在没有时间细读，他建议陈诚安排一个会议把设计过一遍，他安排部门骨干参加，这样可以一次性敲定。

陈诚同意这个提议，但同时也暗自抱怨，早干嘛去了，白白浪费了两周时间。陈诚、李媛、老莫、韩峰以及人力资源部一众人等都聚集在会议室，韩峰把设计文档过了一遍，但由于这次设计是基于基础功能的需求，对人力资源部来说，远远没有达到他们想要的，所以他们也不好下结论。

王章问：“这个设计将来改起来困难吗？”

老莫说：“改设计文档不难，但要看是什么时候提出来改，如果我们按照这一版外部设计已经做好了内部设计和开发，那么一旦有任何修改，涉及的功能都要重做，这个功夫和时间就难说了。”

王章说：“这可不好办，现在这版肯定不是我们想要的，太基础、太简单了。”

陈诚说：“我们也希望能尽快获得完整的需求再做设计，但是现在快一个月过去了，我们没能从你们那里获得太多有用的信息。李媛现在也只能基于自己的理解写需求，但进度不理想，也不知道怎样才算完成，毕竟我们不是用户。”

人力资源部薪酬经理说：“其实我们的需求很简单，以前有什么功能，以后就有什么功能。我们并没有提出什么新需求啊。”

韩峰说：“那你能告诉我们以前有什么功能吗？”

老莫瞥了韩峰一眼，韩峰的这个问题让场面有点僵。老莫说：“这样吧，我们这么耗下去也没用，时间不等人，我们能不能先按照这一版设计做了，等李媛的定制化需求出来了，我们再做变更，到时候，我们会把变更的影响，包括成本和时间，跟大家详细说明，走一个变更管理流程。不过我需要大家现在一致同意我们按照这版先做。”

王章点了点头，他说：“好，这就拜托大家了。”

会后，李媛把会议记录整理了一下发给所有与会者，当作对当前设计的签署。

韩峰和团队开始内部设计。所谓内部设计就是按照需求和外部设计，做出编程前的设计，供程序员参考，包括系统架构、采用什么编程语言和技术、模块划分、代码结构、流程图、数据库设计等。

韩峰的团队一共有3个人。除了韩峰，还有两个程序员罗飞和李志宏。罗飞的能力比较强，李志宏能完成编程任务，但是其沟通能力、文书能力和程序代码的可读性都比较差。程序代码除了是给计算机运行外，可读性也非常重要。文档很多时候是靠不住的，因为如果文档不及时更新，其信息就会过时，更可怕的是，你在阅读时无法判断这份文档是否已经过时，过时的信息会带来严重的误导。因此，很多时候，要获得最真实的信息，正在运行的程序代码成为唯一可靠的来源。但是如果程序员不注意代码的可读性，就会对后人阅读和分析代码带来很大的麻烦。而且，程序不是一成不变的，一旦出现故障，或者要添加新的功能，都需要分析和修改现有的代码，可读性差的代码也会为后续的维护和开发带来灾难。

韩峰按照标准的项目执行流程，花了两周时间把内部设计做好，并和罗飞、李志宏进行了交流。

一个网页应用，在系统架构上大体分为前端、后端和数据库三个部分：

• 前端就是网页的部分，是用户可见的和与用户交互的部分，主要运用网页技术，如HTML（一种描述网页静态内容和结构的标准语言）、JavaScript（在网页上通过网页浏览器直接执行的控制代码，比如验证用户输入的格式是否正确，具体例子是，如果输入框要求输入的是手机号码，那么它要求输入的格式就应该是11位的数字，不允许输入数字以外的其他字符，这种验证可以通过JavaScript来实现，确保输入正确，而且不需要把内容发送到服务器处理，响应速度快）和动态语言脚本PHP、ASP或JSP（在网页里嵌入一些在服务器上执行的程序代码，比如从服务器或数据库上获取数据，显示在网页上，或者与后端服务器程序进行对接）。

• 后端是运行在服务器上的程序，接收前端发送的数据和请求并把按照业务逻辑的处理结果返回给前端，按照推荐的架构模型，大部分的业务逻辑应该放在后端实现，并调用数据库进行数据读取或写入。虽然在网页上的动态语言脚本也能实现相应的过程，但这会导致网页杂糅了HTML、JavaScript和含有复杂逻辑的动态语言脚本，内容臃肿，结构复杂，难以维护和修改，所以推荐把运行在服务器上的业务逻辑代码集中在后端程序中实现，使得程序隔离性更好，结构清晰，并可实现不同功能的模块化，更有利于维护和修改。目前最流行的后端程序开发语言是Java语言。

• 数据库是管理数据的特殊软件，目前广泛使用的数据库类型是关系型数据库，由多个数据表组成，每个数据表类似于Excel中的一个Sheet，是一个由字段（列）和记录（行）构成的二维结构。每个数据表通常表达一个实体，比如员工是一个表，部门是一个表，表之间可以建立联接，比如某个员工属于某个部门，把员工表和部门表关联起来，构成完整的员工信息。目前最流行的关系型数据库有MySQL、Oracle、SQL Server等。

三人便按照各自的强项，分配了一下开发任务：

1．韩峰负责全部的前端和数据库脚本；

2．罗飞负责较核心功能的后端程序；

3．李志宏负责其余功能的后端程序。

由于时间紧迫，韩峰对于大家的进度都非常紧张，他除了要完成自己的编程任务外，也要不断询问罗飞和李志宏的情况。从汇报上看，罗飞的进度还不错，但李志宏好像有点跟不上。而韩峰自己也焦头烂额，有点顾不上。以前，他一直是一个人开发和维护一个系统，虽然也有压力，但和管理一个团队相比，简直是轻松。他现在不光自己要忙很多事情，还要顾及团队成员的进度和他们遇到的各种障碍。更可怕的是，软件开发的进度是一个看不见摸不着的东西，他总感觉自己获得的所谓进度是一种虚幻，一点都不踏实。他也不知道各自开发的模块集成在一起的时候会怎样。

目前他们能做的，就是尽力完成自己负责的开发和测试。按照要求，每个人完成自己的程序都应该对其进行测试，以确保其满足需求和保证运行质量，这个过程叫作单元测试，通常由程序员自己完成。他们也要对彼此的程序进行评审，以确保程序符合约定的规范、执行效率和可读性。

一个月后，按照各自的汇报，基础功能各模块的开发和单元测试总算完成了。开始进行集成测试，也就是把各模块放在一起，以功能为粒度进行前端到后端的测试。两个齿轮放在一起尚且需要磨合，一次性把一堆齿轮放在一起，肯定会出现各种问题。这也是集成测试的“宿命”。集成以后，他们首先看到的只有“500内部服务器错误”这一行字。系统根本运行不起来，他们要查系统日志（Log）找原因。一般来说，由于程序执行是一个看不见摸不着的过程，程序员都会有意地在程序执行过程的关键节点写系统日志，这样可以追查程序执行到哪一行代码，以便追溯相应的代码是否编写有误。

另一边，李媛的进展更不顺利。她好不容易加班加点把旧系统的功能摸了一遍，并记录在需求文档中。期间，她也陆陆续续地把已经完成的部分分享给小罗，希望她能带领人力资源部的同事一起评审，尽快给出意见，争取时间。但得到的反馈一直是其他同事都很忙，没有时间看，还是等她全部完成后一次性审阅。

尽管陈诚和李媛心里很清楚这样下去肯定会出问题，但现在是皇帝不急太监急，他们也没辙，他们也听说这段时间人力资源部的平均下班时间都是晚上十点。当李媛把完整的需求文档整理好并邀请人力资源部开会审阅文档后，她得到的反馈是需求太概要和抽象，他们没法给出意见，这可把李媛给气坏了。陈诚只能拿出杀手锏，如果人力资源部不签署这份需求文档，项目只能停下来。结果王章去找了CEO张钟国。由于王章比陈诚高好几个级别，这一状况让整个变更管理部都很紧张，陈诚面临着巨大的压力。

“这也是我为什么在项目计划里规划40%的时间做用户验收测试（UAT），按照以往的经验，用户总是不认真对待需求文档，当我们把软件做出来了，交到他们手上的时候，他们才发现很多功能细节不是他们想要，于是提出各种问题和需求，可以说，很多时候，UAT阶段才是项目真正开始的时候，这也是为什么大部分项目都会延期交付的重要原因。现在我们只能先按照李媛写好的需求做，尽快开始UAT。”

韩峰极力反对这样的做法，他说：“一个功能要经历需求分析、外部设计、内部设计、程序开发、单元测试、集成测试、功能测试、UAT多个阶段，有任何变更，都要重走这几个阶段，返工的成本非常高，怎么可以允许用户在UAT这么后期的阶段随意改需求呢？我们应该咬定需求一定要先确定再开工。”

陈诚不耐烦地说：“不用你给我抛书包，如果现实有那么理想，一个项目有你们几个程序员就够了。在这里，用户就是最大的！”他们不欢而散。

这一边，罗飞总算把大部分集成的问题都解决了，按照基础功能需求做出来的系统终于可以运行。韩峰通知李媛开始这一部分的功能测试。同时，他们开始根据新的需求文档进行开发。为了管理好已经写好的代码，他们使用了版本控制器。通过版本控制器，他们可以把所有代码都上传到版本控制器的服务器上，并为每一次的上传自动生成一个版本，这样的好处是：

1．可以保证代码安全，避免因为某个程序员的计算机出现故障而导致代码丢失。对于一个软件来说，源代码是最重要的资产；

2．由于上传的代码有版本记录，程序员可以随时抛弃不满意的修改或者回退到某个版本；

3．任何人都可以从版本控制器下载所有代码，以便接手别人的程序；

4．当系统需要部署到某台服务器时，也可以为这次部署的所有代码打一个部署版本标签，自动记录这个部署版本与代码版本的对应关系，实现软件部署和发布的版本化管理，可以明确某台服务器在运行哪个部署版本的代码。

他们为当前的代码打了一个部署版本，作为一个基线，成为后续开发的里程碑。他们在消化新的需求文档的过程中，也觉得这一版的需求有点抽象，比如有一个需求只有“当需要进行社保基数调整时，系统会自动计算员工上一年度的总收入作为社保基数上报金额” 这么一句话。但这里有几个疑问：

1．社保基数调整的时间点是什么时候？是自动触发还是人工触发？

2．所谓上一年度具体是什么时间段？

3．总收入的定义是什么，哪些收入要纳入，哪些要扣除？

4．上报的具体操作是什么？

这些细节在需求文档里都没有体现，没有这些细节，后续的工作都没法开展。而这只是冰山一角，整份文档还有大量类似的信息需要细化。而当韩峰要求李媛细化这些需求时，她说她现在要忙于基础功能的测试，没有时间再去搞需求文档，她叫韩峰有什么具体问题一个个来问吧，然后记录在外部设计文档里。韩峰觉得这样下去，开发一定不可能在一个月内完成，UAT的时间必须延后。但陈诚的态度也很坚决，这个死线不能动！

韩峰找了老莫。其实老莫一直都关注着这个项目，他完全明白问题出在哪里，但这也是几乎所有项目的常态，他也没什么招。他只能安抚韩峰尽力而为，必要时就加加班，加班费不是问题，这也许是他能给韩峰最有力的支持。

韩峰几乎每天都要就需求的细节询问李媛，李媛每天也有功能测试发现的问题要找韩峰修复，韩峰的性格有点急，幸好李媛耐性很好，两人的关系还是维持得不错。尽管李媛发现的问题很多都是在原始需求里没有提到的内容，韩峰也没有说什么，都尽力去改。他明白李媛也不容易。

修复问题叠加开发新需求，使得团队的工作量积压得很厉害。两周过去后，新需求的开发只完成了1/3，其实这只是编程和单元测试的进度，集成测试和功能测试还没算上，总体进度其实更糟糕。

陈诚每天都会询问韩峰的进度，当每次韩峰报的进度不如预期时，陈诚就会问这问那，搞得韩峰很烦，觉得在浪费他宝贵的时间。他有些时候也想虚报一个假的进度，好清静两天。但是这欠下的债迟早还是要还的，最终总是躲不过去的。他觉得这样报进度其实毫无意义，就像罗飞和李志宏跟他报进度一样，都是虚假的表象。软件开发根本就不是一个线性的过程，说百分之多少完成根本没有什么实际意义。但是项目管理汇报不会关注细节，只关注总体进度。

时间过半，进度却跟不上，陈诚的压力更大了。他几乎每晚失眠。作为项目经理，他总感到无力，事情都要靠别人去做，很多时候，他能做的只有催促，用户、交付团队都会给他压力。表面上，似乎总是他在给交付团队施压，但实际上，如果交付团队没法满足计划，去面对用户的就是他。

因为经济不景气，业务萎缩，最近公司在精简人员，辞退了好几个像他这样在公司干了很多年但未进入管理层的人。他很担心公司会拿这次项目的问题向他开刀。上次王章到CEO那里告状，他从上司的办公室出来的时候，几乎全身湿透。他真真切切地感受到什么叫“中年危机”。他很清楚地知道，李媛、韩峰都在尽力，他比谁都清楚问题出在哪里。但他能使劲的地方也只有冲着自己人。

他找了老莫，看看他能不能多安排几个人赶赶进度。老莫手上的项目也很多，没有富裕的人手。有另外一个项目也是陈诚的，没那么赶，他俩一致同意把该项目中一个程序员借调给韩峰两个月。对于韩峰来说，他还要花时间给这个“新人”讲解项目的情况和让他熟悉业务与系统。这个人半个月能上手就不错了。

按照计划，UAT开始的日期到了，新需求的开发只完成了2/3，还有一些基础功能的测试缺陷没有修复，集成测试和新需求的功能测试也没有开始。陈诚只能把UAT的日期往后压一周，催促韩峰和李媛尽快把已经开发完的功能的集成测试和功能测试给做了。

测试的进度很不理想，李媛和韩峰的团队每天都要挑灯夜战，一周过去后，测试只完成了一半。陈诚觉得不能再拖了，丑媳妇终究还是要见公婆，况且，很多用户真实的需求只有通过UAT才能出现，他只好通知小罗开始UAT。可气的是，一周过去了，人力资源部那边没有任何动静，他们还没开始测试，理由还是忙。

按照王章的计划，他们要先忙完了年底的工作，也就是系统上线前两周，才有人手进行UAT。他当初觉得，这个项目需求明确，人力资源系统也不是特别复杂的事情，应该不会有什么问题，两个星期测试应该足够了。

当初陈诚跟他说要把UAT提前一个月，他已经明确过表示那个时间没有人手。现在陈诚不断催促，他有点烦，但还是吩咐了小罗安排测试。小罗只是招聘专员，主要负责搜集、筛选简历和跟踪招聘个案，业务面比较窄，对其他业务也不熟悉，特别是最复杂的薪酬和考勤部分，她只能催促其他同事配合。而薪酬组恰恰是现阶段最忙碌的。

不过，小罗自己测试时倒发现一个重大问题，就是没有历史数据。原来，由于大家都忙于新需求的交付，系统迁移中最最重要的数据迁移，也就是把有用的历史数据从旧系统转换和导入到新系统，还没有开始做，这项任务在陈诚的计划里是有的，而且应该要在UAT前完成，但由于还有很多需求没有做好，新系统的数据库结构还要不断修改，数据迁移被搁置了。如果没有这个过程，用户需要在新系统手动录入所有的数据，包括历史数据，由于数据量太大，用户不接受。而UAT过程中，用户需要模拟实际的操作，要求在历史数据上进行。系统的上线时间铁定是要推迟了。

陈诚紧急召集李媛、老罗和韩峰商讨，他希望能拿出一个最短的延迟时间。老罗说：“按照目前的进度，最起码还要一个月”。韩峰说：“借调过来的程序员可以专门负责数据迁移脚本，这一块比较独立，蛮适合一个‘新人’来处理。”李媛说：“我去跟他们商量一下哪些功能必须先上，哪些功能可以缓一缓。”陈诚说：“好，现在没办法了，只能争取先满足上线条件，上线后边使用边修复。”

韩峰其实有点厌倦了。他原本想辛苦冲刺一段时间，做个了结，现在看来，这个项目肯定要拖成一个持久战，以系统目前的状态，他都不敢想象上线后会出什么问题，他心里一点底都没有。这苦日子可长着呢。但这条路是自己选的，现在也没得后悔，只能硬着头皮撑下去。

王章听到UAT中自己的下属各种反馈和吐槽，还有系统上线日期要延后一个月的消息后，他坐不住了，对陈诚兴师问罪，陈诚也只能解释项目中的各种困难，当然他不会吐槽用户不配合这一点，这可是罪加一等。

王章又去找CEO张钟国告状，要求更换项目经理。这一次张钟国并没有附和王章。上次王章告状后，他向变更管理部门总监了解过这个项目的情况，也认同项目最大的问题出在需求和用户配合度上。他履历非常丰富，做过很多不同的角色，包括软件销售，对软件交付还是有一定的经验和理解。他本来想提醒一下王章，但后来事情多就忘了。这次王章主动找上门，他也想借这个机会和他聊聊。

“你觉得这个项目现在这种状况，问题出在哪里？”

王章说：“我觉得项目经理太不给力了。本来我以为陈诚经验丰富，这个项目又那么简单，四个月完全不是问题，没想到弄成这样。”

“你真的觉得这个项目很简单吗？”

“是啊，我们压根就没有提出过新的需求，就是以前有什么功能，将来有什么功能。”

“你们有说清楚以前有什么功能吗？”

“说实在话，旧系统年代久远，没有留下什么文档和资料，供应商也找不到人了，我们人力资源部也不断换人，确实我们也没有办法列举所有的功能。但是需求点双方都是确认过的。”

“需求点是在什么时候确认的？在项目一开始吗？”

“没有，在项目中期。”

“既然换了个系统，你们有借这个机会重新梳理和审视现有流程，然后通过新系统来实现新的流程吗？”

“他们现在连原有的功能和流程都做不好，怎么可能还指望他们做新的需求呢？”

张钟国有点严厉地说：“我问的是，你们有重新梳理和审视现有流程吗？你不觉得都换了一个系统，还延续原来可能因为迁就旧系统而遗留的流程不合理吗？”

“我们这几个月在忙什么您是清楚的，我们哪有这个时间啊。”

“我觉得这个项目的问题主要责任在你！首先，你们人力资源部确实有一些不合理的流程，这是人所共知的，也是你们的痛点，有一些是因为现有系统的局限，不得已而为之，这次更换系统，本来是很好的一次洗牌的契机，但是你们没有做；其次，所谓的‘以前有什么功能，将来就要有什么功能’压根就不是需求，只是一个期望。期望和需求是不一样的。需求的重点在于细节，而据我了解，这些细节并没有得到你们的配合。我觉得陈诚最大的责任是过于乐观，没有把风险事先估计充分并和跟你们做充分的沟通，他的腰板也不够硬，做了过度承诺。但是没有你们的充分配合，神仙也搭救不了。我明白这段时间你们确实很忙，不是实施这个项目的好时机。但是其实现有系统的风险我们早就知道，项目预算年初我就已经批了，我也一直催促要尽快上马这个项目，怎么会拖到年底呢？”

“我一直跟您说我们人力资源部人手是不够的，这一年下来都没喘过气。而且变更管理部和软件开发部也没有人手提前开工啊。”

张钟国一时也无语，受到市场不景气的拖累，公司今年的业绩下滑，已经不得已要启动裁员，他也费了很大的力气才把裁员控制在小规模上。他决定结束这场对话：“这样吧，事已至此，再去追究是谁的责任已经没有意思了。我也不认为现在更换项目经理能起到什么作用。既然你们现在有时间了，我建议你们和陈诚的项目组坐下来好好商量这个项目怎么收尾，先把已经做好的功能上线，剩余的需求分阶段上线。一定要积极配合项目组的各种请求，要明白，你们才是用户，系统做不好难受的是你们。现在项目肯定是超支的，我会尽量给你们开绿灯。”

会后，王章召集了人力资源部的骨干和陈诚的项目组共同商讨对策，李媛提出要把需求点全部梳理一遍，确定哪些需求点必须要先上线，哪些可以在系统上线后分阶段发布。确定了系统上线的新范围后，王章要求他的骨干一定要全力参与UAT。

果不其然，通过UAT，用户摸到真系统，提出了很多新的需求细节，系统上线无奈又延后了一个月。最后，在人力资源部勉强签署下，系统上了线。上线后问题不断，韩峰要一边修复问题，一边完成剩余需求的开发，忙得不可开交。借调的程序员也要归还了。

韩峰对罗飞很满意，但对李志宏有点忍无可忍，然而现在这个时势，把他开掉肯定不允许再招新人了。他问老莫能不能帮他从其他项目组换一个人。老莫看在韩峰的窘况，强行以借调的名义把另一个项目组的程序员和李志宏做了交换，让韩峰的羽毛丰满些。

三个月后，系统总算稳定了下来，不像早期那样问题层出不穷。期间，部分剩余功能也陆续上线，但还是有一些遗留的功能。由于项目严重超支，张钟国不能再批新的预算，遗留功能和新的需求的开发只能放在明年的预算计划中。项目组解散，陈诚、李媛和韩峰都开始各自忙新的项目，罗飞也跟着韩峰开始新的项目，但会兼顾这套系统后续的维护。

很多软件问题，是由需求这个源头产生的。Garbage In, Garbage Out。由于业务人员或用户与软件交付团队的知识不对等，彼此可能存在巨大的交流鸿沟。说清楚需求，从来不是一件容易的事情。有些时候，业务人员或用户认为某些需求很简单，就是一句话的事情，但一旦抠起细节来，却无比复杂。所幸，这个问题并非无解，但我们需要另辟蹊径。在后面的章节中将有分解。