Software project management 失败的项目经历及其讨论

做项目的总有成功和失败，成功了需要总结，失败的更需要总结。

以下要说的一个 Case 是我经历过的一个失败的项目，写出来，大家指点一下。

首先介绍一下背景，这个项目的客户是企业内部顾客，应用的范围是为用户收集第三方的意见与建议提供一个渠道和工具，并给 Manager 层的领导提供必要的信息视图，以方便直观地掌握问题的种类和问题的数量。

项目在启动以前，用户曾打过我谈，说他们在别的分公司看到了一套系统，非常适合他们应用，希望能移植过来，并希望越快搭建越好。考虑到用户对该系统需求的紧迫性，我们做了初步评估行动:

[1] 与分公司熟悉系统的人进行初步了解，弄清楚系统的设计背景以及应用情况，得知本地客户需要的系统是一个大系统中的一部分。另，该系统是out sourcing 开发的没有开发人员的支持，现任的管理员对系统的了解程度有限。

[2] 向分公司同事要帐号，希望进一步了解系统的功能，同时与客户联系，尝试与客户一起来了解系统

以方便客户确认，是否该系统就是用户需要的系统，功能是否能满足。得到的回复是客户已经用过

这套系统。因为有客户的确认，于是直接进入系统引入安装阶段

[3] 了解了系统的软硬件需求，向分公司要来系统Copy，试安装:

存在以下安装问题:

{a} 没有数据库初始化脚本，只有数据库设计文档，与分公司同事交涉，未果，

只好根据设计文档自己写出数据库初始化脚本

{b} 数据库脚本运行成功，但是运行系统发现缺少视图，向分公司同事要其它的视图以及 table 的脚本

因为有异地沟通存在，和其它项目的同时进行，时间到此已经过去大约一周

{c} 数据库准备完成，让用户熟悉系统，提更改需求

初步收到更改需求，因为我们对系统并不熟悉，尝试获得分公司同事的援助，将更改需求发到分公司同事处，请他帮忙确认系统修改的可行性。这里我们主要担心的是系统的更改会不会比重新做一个系统还要复杂?

这样的更改需求，实际上就是对原有系统的需求变更，在对原系统以及业务流程不了解的情况下，做系统变更的风险很大

分公司同事认为不会影响到系统的流程，在多次沟通后，分公司同事还针对每个修改点粗略地标注好了需要修改的文件和注意事项。这里要说明的是，该同事对该系统其实也并不是很熟悉。这是后话。

有分公司同事的确认和一份比较详尽的修改说明，我们开始修改工作，项目进行到正式实施阶段。初步认为修改只需要两到三天时间。此时时间距离客户找我们第一次谈已经过了两周左右。

但是很不幸，系统修改过以后，发现有一个功能不能正常工作，而该功能是这个系统的核心。于是开始尝试熟悉系统，做 deep dig 的工作，时间过得很快，一个星期又过去了，最后确认该系统的可移植性很差，很多 hard code 存在，一些修改后以为正常的地方都有隐患存在。

开始意识到，需要了解系统的业务流程，尽管是拿过来的系统，也需要一份客户的需求说明书。时间流失太多，马上着手与客户沟通，希望能尽快地坐下来一起谈谈需求。考虑到客户不态愿意写需求书的特性，自己根据原有系统，编写了一份初步的需求说明书，请客户确认，但是

得到的答复是我们要的就是原有的系统，你照着改就可以了。当我再想细一步向客户确认系统角色的种类时，得到出人意外的答案，客户说他其实只用过该系统很少一部分功能，对系统中的很多东西都不熟悉。所以并不知道原系统定的那些角色有什么用。

于是问题开始升级，向 Manager 求助，要求 Manager 出面一起与客户沟通，试图说服客户从谈需求开始走软件开发流程。强烈建议从客户需求出发，以满足客户需求为核心目标来构建系统。

在讨论过程中遇到一些困难，客户认为，原有的系统运行过了很多一段时间，所以比较稳定，功能也会比较完善，从头开始谈需求没有这个必要。但是对于我们来说，没有需求就成了盲人。

没有目标，我们怎么知道要去做什么? 最后达成一致意见，与客户部门的 Manager 协商，争取客户部门的 Manager 同意从头做起。

但是事情出现很大的变化，最后，客户部门的 Manager 自己动手写了一个小工具来帮助他们完成相应的工作。

客户宁愿牺牲自己的时间，也不愿意坐下来谈需求。客户其实知道自己的需求，但是却处在混沌状态，我们没能很好的引导客户，让客户将需求描述出来，这一点我觉得很失败。

Re: 失败的经验

发表人: zybing

说的太对了。最近我也失败了一个项目，也不能说是最近，原来以为3个月就可以搞定，做了快1年了。中途客户方换了一个项目负责人，和对方前任项目经理达成共识的内容许多没有成文，造成对方换了一个人来负责项目后，将以前的大部分达成共识的内容都给改变了。有些即使是成文了，但成文的如果有2意性，或者不够明确的，到时候都会来挑刺，工作量一下子加重了很多。这下在公司上下不是人，领导怪这么长时间还没做好，下面的人说怎么改来改去还是改这些内容，越做越没意思。做项目需求一定要谈明确，而且一定要成文，成文的内容也要明确，不要向我一样某些地方有二异性造成被动。还有最重要的一点：需求成文后，要对方负责人签字，这点不可遗漏。

Re: 失败的经验

发表人: iceant

我们在做项目时，需求都是有签字的。但是签了字也不意味着用户就真正了解自己的需求。

有时用户认为他说的就已经很详细了，但是对于开发人员来说，这些信息可能只是业务需求，还缺少用户需求和功能需求以及非功能需求等。

对我们来说，目标是经手的项目能够成功。成功的标志是双赢！也就是用户满意，开发人员有成就感。所以，尽管用户签了字，我们也不能说用户签了字，照着做出来，如果不是用户要的，那就用户负责。我们还是要写一份非常详细的文档，再三地向用户确认每一个细节。以免以后因为需求不清，客户埋怨，开发人员白费功夫。

在我失败的这个项目里，当我写出文档给用户一一确认时，用户显得很不耐烦，她认为自己很忙，不愿意参与项目细节的讨论，尽管我一再向她解释不弄清楚这些问题，我们无法开展工作，但也还是难以获得用户的理解。在我们尝试与她们的经理沟通后，他们的经理默默地选择了自己写系统的方案。

不知道谁有处理这样用户的经验?

Re: 失败的经验

发表人: banq

如何真正了解需求？我在实践中发现一个规律：

1.初步接触，需求人员自己设计好简单Use Case，无需给客户看，他们也不一定看懂。这个过程有个结束目标：直至架构师理解Use Case，并能基本确定域对象。

下面分两条腿并行操作：

1.因为有了域对象，通过美工网页设计好相关对象增删改查的界面，让用户有直观认识，在这个过程调整加强域对象的固化和提炼，同时挖掘出流程。

2.有了域对象，使用类似J道数据通用增删改查之类框架，快速开发出有关域对象的增删改查实际功能，并结合界面，供用户使用，由于在前面基础增加了互动功能，可以更加挖掘出深入的用户需求。

最后，结合XP开发方法，不断迭代，不断请用户操作习惯确认。

要注意两点：

1.真正的需求可能很深，用户没有也无法抽象表达，需要通过迭代挖掘。

2.需求也可能会变，系统必须快速跟随变化，这些J2EE系统就体现巨大优势。

Re: 失败的经验

发表人: youngS

我个人是这样认为的：

首先，做项目就要有把项目做到最小规模的心理准备，而且一开始就应该努力朝这样方向去做，不然一般的结果就是失败！

为什么要向着最小规模的方向去做，这样的道理其实是很简单的——这样的系统除去了所有花哨的功能，只保留了最基本的、最需要的功能，这样的系统相比之下是最简单的、最稳固的、最具有扩展性的。

为什么说最小系统是最简单、最稳固、最具可扩展性的？系统论中有个观点，就是简单系统才是最持久、最稳定的；复杂系统功能强大，但是相应的增加了很多不确定的因素，这导致系统内在的就有了不稳定性。在这里，我们承认这个原理，并且准备按照这个准则去进行需求的分析和项目的规划。

那么，我们怎么使用这个准则来分析需求和规划项目呢？概率论中有个观点，就是样本越多，我们依此得出的推断越接近真实。所以，需求分析中首先要做的就是大量的占有需求资料——当然，现实中真实的情况是往往随着项目的不断推进，大量的需求才开始涌现出来。因此，最有效的需求分析方法我的理解是这样的：在自己可以接触的范围内尽可能的收集需求，相关的或者不相关的（不相关的可以略看，不深入，但是最好能有个概念），尽可能在可以接触的范围内做到占有最多的需求样本。接着，在一定阶段内，对所占有的需求样本进行归纳分析，去除不必要的功能，只保留必须的功能，这就是当前需求（记住，当前需求的前提很重要，这说明随着时间的推移，需求可能会变，会增多）下的最小功能集。然后，把这个功能集中不易发生变化的部分和容易发生变化部分区分开来（区分的标准是，考虑在多种需求下哪些功能是相对固定的，哪些功能是容易随着需求的不同发生变更的）。在面向对象的编程方式中，功能是由不同对象的组合提供的，因此要慎重考虑对象进行交互的边界条件，尽可能的把耦合度降到最低；最后设计的结果可能是：某些对象提供的功能是相对不变的，某些对象提供的功能是易发生变化的；这样一来，未来可能的变化都被尽可能的集中在了最小的范围之内——集中在了那些功能易发生变化的对象之内，将来需求改变时，也许90％以上的改动仅仅在这些10％的易变对象中进行改动就可以达成目标了。完成这样的任务以后，在当前需求下的分析和设计任务就算基本完成；当需求发生改变时，在当前的设计上重复使用这种分析和设计方法，可以保证整个系统随着时间的推移，始终保持着一种最小功能集的状态，而且结构简洁、清晰、稳定，可以给以后的版本升级改造提供最大的灵活性和优异的升级架构，也为系统维护减轻很多的工作量。

我没有研究过ISO标准，我觉得那些都是形式化的东西。当真正掌握了科学的项目工程方法和精神，自然会符合ISO；否则，只是形而上学而已。

<script>page2();</script><script type="text/javascript"> cpro_client='ssreich_cpr'; cpro_cbd='#trans'; cpro_cbg='#trans'; cpro_ctitle='#090909'; cpro_cdesc='#444444'; cpro_curl='#008000'; cpro_clink='#000000'; cpro_flush=4; cpro_w=580; cpro_h=90; cpro_template='text_default_580_90'; </script><script language="JavaScript" src="http://cpro.baidu.com/cpro/ui/cp.js" type="text/javascript"></script>

baidu

不能指望用户都能从开发人员的角度去做，只能让开发人员从客户的角度去考虑。给不同层次的用户看他们所能看懂的东西进行确认

，就像西餐厅里并不是所有的用户都看得懂英文菜单，给不同的用户提供不同的菜单，最好加上点菜肴的图片就更棒了。

我来说两句：

1、 在一个项目里边最重要的是需求分析。需求分析的正确与充要的决定了这个项目的成败。系统构架的优劣、技术含量的多少只是决定了这个项目开发需要的时间和软件的健壮性，开发的软件客户绝对可以使用，顶多开发的慢点，移植和扩展比较弱，但是不会影响成败。项目的管理也共同决定了开发的周期和成本。

2、 按照软件工程上讲，一个项目的开始必须要对客户的工作进行业务建模，相当于大学里的数学建模竞赛里做的工作，对客户的争个业务流程进行分析，建立一套“输入”－“公式”－“输出”的模型。我见过的国内比较成功的一个项目，软件开发公司聘请专业咨询公司作业务建模和需求分析，需求完成后技术人员一次开发成功。

3、 在这个过程中，可能会发现客户业务逻辑不甚合理的地方。或者向客户提出改善业务流程的建议（这也是部分客户希望通过我们系统完成的工作），或者在保证系统正确逻辑的前提下对客户的不合理流程进行兼容设计，这样一旦客户发现业务的不合理，打算需求变更的情况下可以有有备无患。

4、 “Iceant”的回复说的很好：“对我们来说，目标是经手的项目能够成功。成功的标志是双赢！也就是用户满意，开发人员有成就感。所以，尽管用户签了字，我们也不能说‘用户签了字，照着做出来，如果不是用户要的，那就用户负责’。”

不能把客户当做我们的敌人，作项目就象打仗，出了问题互相追究责任。也不能抱着应付了事的态度，按照需求书上的内容随便拼凑一些功能给客户了事。最好的态度就是假设自己就是客户，做出的系统就应该让自己在该岗位上工作的时候最方便最顺手。每做一个功能就假设自己就是该功能的用户，看看自己怎么使用最方便，不能怕麻烦就不完善某些功能，我们手头懒一懒，客户就可能要多点几万次鼠标/每月；我们一个粗心大意，客户就可能要加班熬夜。

5、 Banq（板桥里人）是java编程和项目实施在国内的最高成就者，他给出了项目实施的一个可行方案：……

6、 目前公司现行的项目有这样一种情况存在：产品经理在打单和做设计的时候说的天花乱坠，单子打下来后产品经理功成身退；项目经理在项目实施的时候则很少遵守产品经理的设计文档，按照自己对需求的片面了解实现一通。产品经理不考虑实施，项目经理不重视需求。因此如果让产品经理对项目的设计和实施进行全全负责，项目有一个重需求的人负责，这样打单的时候产品经理会知道有些可以答应，有些不可以答应。在项目实施的时候也可以对客户的需求也有了足够重视。