模板
教程
环境
性能
功能
管理
失败的项目经历及其讨论
失败的项目经历及其讨论
blueski推荐 [2005-2-27]
出处：jdon论坛精华(整理)
作者：iceant
做项目的总有成功和失败，成功了需要总结，失败的更需要总结。
以下要说的一个 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；否则，只是形而上学而已。
客户是上帝没错，可是不能一味的满足客户，因为客户不了解软件系统的开发特点。如果一味的满足客户，除了给软件开发人员增加不必要的麻烦和工作量，也是一种对工作不负责任的态度，因为这样就失去了实事求是的精神，而不实事求是的采取行动，失败自然在前方悠闲的等着。
Re: 失败的经验
发表人: agilejava
我们这儿有客户签名也不行，说改就得改，烦！
Re: 失败的经验
发表人: jia2612
没关系呀，有了客户签名，而后来又不按签字的需求做事，起码开发人员不那么被动了，这样客户也没借口说三道四了
Re: 失败的经验
发表人: iceant
TO:jia2612
我知道很多开发人员会这样想。
但是我们的目标不太一样，我们的目标不是做到让客户不投述就可以了。
我们的目标是客户满意，开发人员有成就感。
我们需要长期的发展与合作，不能说因为这一次项目失败是因为客户没说清楚需求，或不愿意说需求，就将责任推给客户。没有很好的了解客户需求，没有帮助客户达到他们要求的效果与功能，开发人员白忙了一段时间，我们的工作就是失败了。同时，将责任推给客房的做法，会永远失去客户，这也不是我们想看到的。
我现在的想法是首先做好宣传工作，在明年的工作中，将软件开发过程中需求收集的重要性以及收集的方法通过各种渠道传递到客户那里，希望在浅移默化中给客户灌输软件工程的思想。这样也许能更有利于以后的工作。
Re: 失败的经验
发表人: missxkl
我也来扯上几句，：）
我们的第一原则是：客户就是上帝，客户永远是正确的。
做项目就是这样，不同的用户素质也不同。
不能指望用户都能从开发人员的角度去做，只能让开发人员从客户的角度去考虑。给不同层次的用户看他们所能看懂的东西进行确认
，就像西餐厅里并不是所有的用户都看得懂英文菜单，给不同的用户提供不同的菜单，最好加上点菜肴的图片就更棒了。
需求是一个不断变化的过程，感觉如果产品化程度不高的东西，就不要用什么软件工程的东西来套。
做到开发前考虑尽量周全，包括系统可扩展性，打有准备的仗。
开发的时候边做边确认，边确认边修改。
这样就会避免做完以后，跟用户想象差距太大的情况。
当然形成书面需求，需求没有二义性也是很重要，而且领导的感觉是最重要。在中国有时候优秀！＝成功，只有领导认可＝用户认可
＝成功。
觉得iceant的想法很好，如果客户那边能有专门的对口人员，时间再给多一些的话，还是很有机会挽回的。
Re: 失败的经验
发表人: lironghai
用户就是上帝，上帝会把你累死的！！在需求分析阶段这句话没错，但是到了需求分析完成之后，就大错特错了。在软件开发过程中执行是很大的一个问题，往往客户并不会按照原先业务分析中的东西去实现，这就是问题。其中有很多次的反复过程，最关键的客户方能有一个领导阶层的人可以保证你的客户可以很好的旅行需求中所定下的一些东西。
Re: 失败的经验
发表人: laofei
同意lironghai 的说法，如果时时刻刻把客户当成上帝，那不但项目完了，你们公司也完了！！一个我认为比较好的变通办法是：如果用户需求变更比较大，那么可以把这部分工作放到二期去做，当然这需要一定的努力让用户理解你的工作，不过我想作为一个项目经理应该是有这个能力的，除非你的客户太过于固执或者他们根本不想让你做以后的工作
Re: 失败的经验
发表人: zybing
我说需要客户签名并不是代表将客户放在对立面，把客户当成敌人。
现在的项目经理最难当。客户不断更改需求，公司又要让你快速结束项目。
虽然说为客户考虑可以节省很多时间，但客户的想法，客户的需求始终处于不断变化中，而且做下来的程序在使用中客户也会有新的想法，或者调整使用方式，或者进行功能的扩展。如果完全都按照客户的想法实施，或者完全替客户考虑，一个用户分析系统可以做成庞大的CRM系统。
让客户签名的作用是在一开始需求讨论的时候对需求的范围作限制，否则以后客户无限制的扩充需求项目无法收尾（如无白纸黑字的签名有100%的客户会不承认当初的定义），或者某些地方做需求的扩充作为交换省去某些不必要得需求，为项目早日结束作伏笔。
各位的讨论非常精彩，我已经作成文档在公司里传阅。并加上了如下的部分
发表人: sprsong
我来说两句：
1、 在一个项目里边最重要的是需求分析。需求分析的正确与充要的决定了这个项目的成败。系统构架的优劣、技术含量的多少只是决定了这个项目开发需要的时间和软件的健壮性，开发的软件客户绝对可以使用，顶多开发的慢点，移植和扩展比较弱，但是不会影响成败。项目的管理也共同决定了开发的周期和成本。
2、 按照软件工程上讲，一个项目的开始必须要对客户的工作进行业务建模，相当于大学里的数学建模竞赛里做的工作，对客户的争个业务流程进行分析，建立一套“输入”－“公式”－“输出”的模型。我见过的国内比较成功的一个项目，软件开发公司聘请专业咨询公司作业务建模和需求分析，需求完成后技术人员一次开发成功。
3、 在这个过程中，可能会发现客户业务逻辑不甚合理的地方。或者向客户提出改善业务流程的建议（这也是部分客户希望通过我们系统完成的工作），或者在保证系统正确逻辑的前提下对客户的不合理流程进行兼容设计，这样一旦客户发现业务的不合理，打算需求变更的情况下可以有有备无患。
4、 “Iceant”的回复说的很好：“对我们来说，目标是经手的项目能够成功。成功的标志是双赢！也就是用户满意，开发人员有成就感。所以，尽管用户签了字，我们也不能说‘用户签了字，照着做出来，如果不是用户要的，那就用户负责’。”
不能把客户当做我们的敌人，作项目就象打仗，出了问题互相追究责任。也不能抱着应付了事的态度，按照需求书上的内容随便拼凑一些功能给客户了事。最好的态度就是假设自己就是客户，做出的系统就应该让自己在该岗位上工作的时候最方便最顺手。每做一个功能就假设自己就是该功能的用户，看看自己怎么使用最方便，不能怕麻烦就不完善某些功能，我们手头懒一懒，客户就可能要多点几万次鼠标/每月；我们一个粗心大意，客户就可能要加班熬夜。
5、 Banq（板桥里人）是java编程和项目实施在国内的最高成就者，他给出了项目实施的一个可行方案：……
6、 目前公司现行的项目有这样一种情况存在：产品经理在打单和做设计的时候说的天花乱坠，单子打下来后产品经理功成身退；项目经理在项目实施的时候则很少遵守产品经理的设计文档，按照自己对需求的片面了解实现一通。产品经理不考虑实施，项目经理不重视需求。因此如果让产品经理对项目的设计和实施进行全全负责，项目有一个重需求的人负责，这样打单的时候产品经理会知道有些可以答应，有些不可以答应。在项目实施的时候也可以对客户的需求也有了足够重视。
Re: 各位的讨论非常精彩，我已经作成文档在公司里传阅。并加上了如下的部分
发表人: hymmyh 发表文章: 12 / 注册时间: 2003-01
项目成功的关键因素
客户的参与度 19%
高层管理者的承诺 16%
需求的澄清 15%
听ibm项目经理的演讲中所说.
Re: 失败的经验
发表人: happlyin
首先我们要明白：
客户需求变化是一定的。
我们要尽可能去满足客户的需求。
确定了上面的两点后，我们要做的就是：
首先要求开发人员理解需求变化是不可避免的，不要反感，反对这种现象。
再就是向客户和领导尽量争取更多的时间来应对需求。
采取好的开发过程，例如敏捷软件开发过程等，来包容这样的变化。
聘请一个在需求领域有项目经验的，而且又具有很好的设计思想的人。
我认为这样的问题，跟前期的需求分析没有太大的关系。因为在前期，需求本身就不完整，即使是完整的，到客户见到成品后，也会更改需求。
Re: 失败的经验
发表人: jiyun512
用户需求是在变的，然后就是用户自己也无法对自己的业务有一个清晰的认识，开发人员然则不如用户了，所以说需求分析部分一般情况下不可能在项目进行的初期完成，即使完成，以后还有较大的修改，这是一种对业务模型的共同模糊所造成的，当然也有用户自己对自己业务有一个清晰认识和说明的，不过我还没遇到，这种情况对开发人员的要求非常大，所以有种情况是可行的，就是开发人员可以以很快的开发速度来完成他对由用户对业务模型认识的不断清晰而带来的重新改变己经完成的某些设计部分，如果开发人员不能完成对这种情况的快速反应，就会出现头痛等一系列问题，如果你可以以足够快的时间和速度来响应用户的这种要求，那么你们的合作会是快乐的，否则则会充满了意想不到的痛苦。
以上完全个人意见
学会与客户中争取主动
发表人: pathfinder
我去年底参加了某大型高速OA系统的二级管理处需求分析，总结了一个小小的经验，与机关打交道时，我们完成的需求分析一定要有个标准，也就是统一的标准，所有有争议的细节，包括客户的使用习惯，都必须适当改变，理由很多：比如这是无纸化办公，信息时代啦，在于表达，一切以此标准为准则，前期工作量很大。
Re: 学会与客户中争取主动
发表人: wyse
其实，如果目标系统是客户的核心业务系统，或者关键系统，就很少有失败的项目，因为客户方的重视程度不一样。我们正在开发的系统比较庞大，公司派出的开发团队稳定在80多人，客户方的技术人员、业务人员超过100人，封闭开发，遇到需求不明确等问题时也曾遇到楼上几位谈到的情况，但是不论如何都能解决，只是迟早。所以有几点我认为比较重要：
1、把客户项目当作自己的事情，不推诿；
2、控制局面，学会与客户有效沟通。
3、派有经验、有责任心、有耐心的骨干人员跟客户沟通。
4、减少硬编码，满足客户需求时有一定的预见性。
5、等等．．．
