失败的经验

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

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

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

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

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

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

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

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

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

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

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

要注意两点：
1.真正的需求可能很深，用户没有也无法抽象表达，需要通过迭代挖掘。
2.需求也可能会变，系统必须快速跟随变化，这些J2EE系统就体现巨大优势。

我们这儿有客户签名也不行，说改就得改，烦！

没关系呀，有了客户签名，而后来又不按签字的需求做事，起码开发人员不那么被动了，这样客户也没借口说三道四了

TO:jia2612

我知道很多开发人员会这样想。

但是我们的目标不太一样，我们的目标不是做到让客户不投述就可以了。
我们的目标是客户满意，开发人员有成就感。

我们需要长期的发展与合作，不能说因为这一次项目失败是因为客户没说清楚需求，或不愿意说需求，就将责任推给客户。没有很好的了解客户需求，没有帮助客户达到他们要求的效果与功能，开发人员白忙了一段时间，我们的工作就是失败了。同时，将责任推给客房的做法，会永远失去客户，这也不是我们想看到的。

我现在的想法是首先做好宣传工作，在明年的工作中，将软件开发过程中需求收集的重要性以及收集的方法通过各种渠道传递到客户那里，希望在浅移默化中给客户灌输软件工程的思想。这样也许能更有利于以后的工作。

我也来扯上几句，：）
我们的第一原则是：客户就是上帝，客户永远是正确的。
做项目就是这样，不同的用户素质也不同。
不能指望用户都能从开发人员的角度去做，只能让开发人员从客户
的角度去考虑。给不同层次的用户看他们所能看懂的东西进行确认
，就像西餐厅里并不是所有的用户都看得懂英文菜单，给不同的用
户提供不同的菜单，最好加上点菜肴的图片就更棒了。
需求是一个不断变化的过程，感觉如果产品化程度不高的东西，就
不要用什么软件工程的东西来套。
做到开发前考虑尽量周全，包括系统可扩展性，打有准备的仗。
开发的时候边做边确认，边确认边修改。
这样就会避免做完以后，跟用户想象差距太大的情况。
当然形成书面需求，需求没有二义性也是很重要，而且领导的感觉
是最重要。在中国有时候优秀！＝成功，只有领导认可＝用户认可
＝成功。
觉得iceant的想法很好，如果客户那边能有专门的对口人员，时间
再给多一些的话，还是很有机会挽回的。

补充一下，感觉iceant的这个项目中项目经理有一定的责任
不会就是iceant自己吧，嘿嘿

我来说两句：

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

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

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

4、 “Iceant”的回复说的很好：“对我们来说，目标是经手的项目能够成功。成功的标志是双赢！也就是用户满意，开发人员有成就感。所以，尽管用户签了字，我们也不能说‘用户签了字，照着做出来，如果不是用户要的，那就用户负责’。”
不能把客户当做我们的敌人，作项目就象打仗，出了问题互相追究责任。也不能抱着应付了事的态度，按照需求书上的内容随便拼凑一些功能给客户了事。最好的态度就是假设自己就是客户，做出的系统就应该让自己在该岗位上工作的时候最方便最顺手。每做一个功能就假设自己就是该功能的用户，看看自己怎么使用最方便，不能怕麻烦就不完善某些功能，我们手头懒一懒，客户就可能要多点几万次鼠标/每月；我们一个粗心大意，客户就可能要加班熬夜。

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

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

用户就是上帝，上帝会把你累死的！！在需求分析阶段这句话没错，但是到了需求分析完成之后，就大错特错了。在软件开发过程中执行是很大的一个问题，往往客户并不会按照原先业务分析中的东西去实现，这就是问题。其中有很多次的反复过程，最关键的客户方能有一个领导阶层的人可以保证你的客户可以很好的旅行需求中所定下的一些东西。

项目成功的关键因素
客户的参与度 19%
高层管理者的承诺 16%
需求的澄清 15%
听ibm项目经理的演讲中所说.

首先我们要明白：
客户需求变化是一定的。
我们要尽可能去满足客户的需求。

确定了上面的两点后，我们要做的就是：
首先要求开发人员理解需求变化是不可避免的，不要反感，反对这种现象。
再就是向客户和领导尽量争取更多的时间来应对需求。
采取好的开发过程，例如敏捷软件开发过程等，来包容这样的变化。
聘请一个在需求领域有项目经验的，而且又具有很好的设计思想的人。

我认为这样的问题，跟前期的需求分析没有太大的关系。因为在前期，需求本身就不完整，即使是完整的，到客户见到成品后，也会更改需求。

我说需要客户签名并不是代表将客户放在对立面，把客户当成敌人。
现在的项目经理最难当。客户不断更改需求，公司又要让你快速结束项目。
虽然说为客户考虑可以节省很多时间，但客户的想法，客户的需求始终处于不断变化中，而且做下来的程序在使用中客户也会有新的想法，或者调整使用方式，或者进行功能的扩展。如果完全都按照客户的想法实施，或者完全替客户考虑，一个用户分析系统可以做成庞大的CRM系统。
让客户签名的作用是在一开始需求讨论的时候对需求的范围作限制，否则以后客户无限制的扩充需求项目无法收尾（如无白纸黑字的签名有100%的客户会不承认当初的定义），或者某些地方做需求的扩充作为交换省去某些不必要得需求，为项目早日结束作伏笔。

我去年底参加了某大型高速OA系统的二级管理处需求分析，总结了一个小小的经验，与机关打交道时，我们完成的需求分析一定要有个标准，也就是统一的标准，所有有争议的细节，包括客户的使用习惯，都必须适当改变，理由很多：比如这是无纸化办公，信息时代啦，在于表达，一切以此标准为准则，前期工作量很大。