做项目的总有成功和失败，成功了需要总结，失败的更需要总结。
以下要说的一个 Case 是我经历过的一个失败的项目，写出来，大家指点一下。
首先介绍一下背景，这个项目的客户是企业内部顾客，应用的范围是为用户收集第三方的意见与建议提供一个渠道和工具，并给 Manager 层的领导提供必要的信息视图，以方便直观地把握问题的种类和问题的数量。
项目在启动以前，用户曾找过我谈，说他们在别的分公司看到了一套系统，非常适合他们应用，希望能移植过来，并希望越快搭建越好。考虑到用户对该系统需求的紧迫性，我们做了初步评估行动:与分公司熟悉系统的人进行初步了解，弄清楚系统的设计背景以及应用情况，得知本地客户需要的系统是一个大系统中的一部分。另，该系统是out sourcing 开发的没有开发人员的支持，现任的治理员对系统的了解程度有限。向分公司同事要帐号，希望进一步了解系统的功能，同时与客户联系，尝试与客户一起来了解系统以方便客户确认，是否该系统就是用户需要的系统，功能是否能满足。得到的回复是客户已经用过这套系统。因为有客户的确认，于是直接进入系统引入安装阶段 了解了系统的软硬件需求，向分公司要来系统Copy，试安装:存在以下安装问题:没有数据库初始化脚本，只有数据库设计文档，与分公司同事交涉。未果，只好根据设计文档自己写出数据库初始化脚本数据库脚本运行成功，但是运行系统发现缺少视图，向分公司同事要其它的视图以及 table 的脚本因为有异地沟通存在，和其它项目的同时进行，时间到此已经过去大约一周数据库预备完成，让用户熟悉系统，提更改需求，初步收到更改需求，因为我们对系统并不熟悉，尝试获得分公司同事的援助，将更改需求发到分公司同事处，请他帮忙确认系统修改的可行性。这里我们主要担心的是系统的更改会不会比重新做一个系统还要复杂?这样的更改需求，实际上就是对原有系统的需求变更，在对原系统以及业务流程不了解的情况下，做系统变更的风险很大分公司同事认为不会影响到系统的流程，在多次沟通后，分公司同事还针对每个修改点粗略地标注好了需要修改的文件和注重事项。这里要说明的是，该同事对该系统其实也并不是很熟悉。这是后话。
有分公司同事的确认和一份比较详尽的修改说明，我们开始修改工作，项目进行到正式实施阶段。初步认为修改只需要两到三天时间。此时时间距离客户找我们第一次谈已经过了两周左右。但是很不幸，系统修改过以后，发现有一个功能不能正常工作，而该功能是这个系统的核心。于是开始尝试熟悉系统，做 deep dig 的工作，时间过得很快，一个星期又过去了，最后确认该系统的可移植性很差，很多 hard code 存在，一些修改后以为正常的地方都有隐患存在。开始意识到，需要了解系统的业务流程，尽管是拿过来的系统，也需要一份客户的需求说明书。
时间流失太多，马上着手与客户沟通，希望能尽快地坐下来一起谈谈需求。考虑到客户不态愿意写需求书的特性，自己根据原有系统，编写了一份初步的需求说明书，请客户确认，但是得到的答复是我们要的就是原有的系统，你照着改就可以了。当我再想细一步向客户确认系统角色的种类时，得到出人意外的答案，客户说他其实只用过该系统很少一部分功能，对系统中的很多东西都不熟悉。所以并不知道原系统定的那些角色有什么用。
于是问题开始升级，向 Manager 求助，要求 Manager 出面一起与客户沟通，试图说服客户从谈需求开始走软件开发流程。强烈建议从客户需求出发，以满足客户需求为核心目标来构建系统。
在讨论过程中碰到一些困难，客户认为，原有的系统运行过了很多一段时间，所以比较稳定的功能也会比较完善，从头开始谈需求没有这个必要。但是对于我们来说，没有需求就成了盲人没有目标，我们怎么知道要去做什么? 最后达成一致意见，与客户部门的 Manager 协商，争取客户部门的 Manager 同意从头做起。但是事情出现很大的变化，最后，客户部门的 Manager 自己动手写了一个小工具来帮助他们完成相应的工作。客户宁愿牺牲自己的时间，也不愿意坐下来谈需求。客户其实知道自己的需求，但是却处在混沌状态，我们没能很好的引导客户，让客户将需求描述出来，这一点我觉得很失败。
