又说到需求

软件需求很重要，从PMP项目管理角度说，需求与项目范围相关，做过项目的人都知道项目三角，范围scope就是最重要的一边，因为范围大小决定了实现成本和时间，这也是为什么大多项目最终倒在“范围蔓延”这个魔咒脚下的原因。

 

最近javaeye有两篇贴都是讨论需求的，需求要怎么做？为什么国内项目客户和开发商之间在这个需求上面矛盾尤其尖锐？讨论很激烈，但是我发现一个有意思的现象，就是我们开发的作为“乙方”，总有很多理由去攻击“甲方”──我们的客户，他们很无知，什么都不懂，要这要那，比孙猴子还善变，很难缠，我靠，简直比爷还难伺候，听到这些你不觉得很怪异吗？客户给你钱，你却做不好，做不好了还骂娘，怨这怨那，你们是什么人，难道当了白领就拿豆包不是干粮了不？我这里想打各比方，开发人员们，你不是永远都当乙方，你不是永远都当孙子，你也有当爷的时候，比如你有钱了，买房了，你请人来给你装修房子，装修方给你糊弄一下弄得马马虎虎，然后你怒了，你要求翻工或者赔偿，对方还骂你，说你无知，你虽然不懂水泥工匠的活吧，但你住屋里你舒不服舒服你总知道吧？你有什么反应，我靠，脾气暴点的早把对方活劈了。

 

不要以为搞了IT了，这种常识的原则就能够违背，我知道在中国干事情很困难，搞IT苦，工资不高，老加班，卖青春，受劳受怨，被老板剥削，但这些不能是你不专业的借口吧？不能是你搞不好个项目了还把责任推给客户的理由吧？跟如同奶娘的客户敌对是没有好下场地，看看吧，看看现在你们的口碑，有多少个是好的拿的出手的，看看你们现在能出的价码，一个行业的好坏是这个行业的人决定的，不是客户，你搞的好肯定就有客户，有票子，但是你们搞好了吗？如果你是一个有良心的开发人员，摸摸自己的心口看看身边几个人是负责任做事情的？

 

客户不懂技术，这是他们吃亏了说不出口的原因，他们没有机会来javaeye灌水，来跟你们对骂，也骂不过专业的你们，但是如果有投诉热线，我肯定，IT业准保是投诉率排前几名之中的一个。

 

其实我也干这个行当，这么骂也是在骂自己，但不骂不能清醒，还自以为自个儿很牛b，晕晕然不从自己这边找问题，埋怨客户，然后抱怨整个行当，自个一点长进没有，这种不专业如何能够让客户相信你信任你？如何才能跟你有良好的沟通渠道去解决共同面对的问题？

 

所以，要解决需求问题，首先要纠正“客户有问题”这种错误想法，进而让自己做事专业起来，才能有希望改变这种局面。

 

后续会写些东西来表达对这个话题的个人看法。知道必然会挨砖头，呵呵，来吧，理不是这样不辩不明麻！

评论

22 楼 qiudawei115 2009-07-22  

    楼主说的帖子应该是我发的，虽然这帖子说的难听了点，但是还是有一定道理的，学习了。
    不过有些地方我不敢苟同，比如对于同一个问题，客户内部不统一，当然不统一的原因有很多，而且涉及到用户对自己需要做的业务都不熟的时候，你怎么办？你只能是先做出个样子去给客户看，让客户有个直观的印象，进而进行修改，维护。
    “客户有问题”的想法没有错，因为客户本来就是有问题的，你需要做的是在规定的时间内去解决这些问题。
    令不要拿装修房子来举例子，在装修工的眼里，你永远都是有问题的，那是肯定的

21 楼 lt0604 2009-07-20  

个人觉得首先应该从软件公司解决根本是的一个错误：
开发人员!=需求人员
看到这个很多人都要出来说话了，“我经常在公司一个人搞一个项目，从头弄到尾家常便饭。”出来说这些话，其实我自己本身也深受其害。看看以前写过的需求文档，越看越像设计文档的时候，就会发现以前是多么的幼稚，顶着领导重视你的荣誉，替他干着5，6，7，8个人的活，承担着5，6，7，8个人的风险（各种细节问题就不说了，因为几天时间都不够）。最后收获的是一份工资，畸形的项目思维理念，如循环发展下去，后果真的很难想象。你所培养出来的惯性和意识直接影响到你前（钱）途。

20 楼 xixix2004 2009-07-19  

虽然不太喜欢你的口气,但我赞成你的观点.

我一直觉得跟客户的交流沟通是项目里最重要的一环,只有让客户保持开心逾越的心情,他才乐意把他的想法表达出来,开发人员才会知道自己要做什么,才不用加班加点的做一些无用功.这其实也涉及到很多方面的因素.

很多时候,我们一直在抱怨,可是改变是从每一个人做起的.别说这是痴人说梦.

19 楼 skyxk 2009-07-16  

需要变更也是可以再前期中避免很多的，这就要看前期需求调研的时候是否充分挖掘客户的潜在需求了，而且可以多为客户想一点，比如一个功能点，可能用户在提出需求的时候没有想到的一些东西。你也一样可以提出来，站在这样的角度，我们也同样会被客户认可，使客户跟我们乙方保证有一个共同的目标 就是更好的完成这个项目。

18 楼 kenn 2009-07-13  

   很认同需求的变更！我也很喜欢需求变更，有点变态！！哈哈。为什么这么说呢！从两个方面来说，一、可以检验你的系统架构，套句不着调的话，是否真的做到了低耦合，高内聚。二、需求有变更，说明业务在发展，如果系统跟不上业务发展，上线了有什么用，如果你不理解系统为什么要这么做，说明你还没有做到领域专家的级别。

17 楼 whaosoft 2009-07-13  

客户就是上帝啊 没办法 !~! 上帝要什么 我们做什么!

16 楼 hunray 2009-07-08  

我做了5年程序员，基本都是做维护工作，我一直认为it是一个服务行业！~把客户当上帝，诚心的对待他，好好供着他，很多问题都迎刃而解了。

15 楼 stonecat 2009-07-06  

呵呵，离开发越来越远都不好意思来这里逛逛了。如果你对一个行业有5年左右的持续理解，也许你就不会感觉到他的需求总在变化，真正的需求是很少变化的，变化的是我们的理解。当你晚上闭上眼睛，程序能在你大脑中跑起来的时候，你也不会迷茫需求怎么变化，变化都在你可以处理的范围。去理解、分析你的客户，而不是看着用例编程，需求真的很少变化。“拥抱变化”值得揣摩，包含了太多的东西。呵呵，这是我做了6年系统分析不大的一点收获，希望对大家有用。

14 楼 eclipse2008 2009-07-03  

合作生财，在项目中增加一个项目监理的角色改善甲方与乙方的沟通。

13 楼 xyh 2009-07-03  

有些公司不重视需求，以为就是那么一回事，认为技术才是最重要的，让不专业的需求调研人员去搞需求，所以造成需求质量低下、混乱、无药可救。

12 楼 containsoft 2009-07-03  

看了这帖子很有感触啊！原来大家都有差不多的遭遇。
呵呵，根据自身经验，我也说几句，项目开始前，需求一定要了解清楚，需求确定书一定要客户签字盖章，以后需求变更才有个说法。在了解需求的时候，最好做些模型，用dw画静态html就行，多跟客户交流，有很多需求客户自己也只是一个很模糊的轮廓，真的需要引导，客户自己也才清楚。

11 楼 woaiwofengkuang 2009-07-01  

不要以为搞了IT了，这种常识的原则就能够违背，我知道在中国干事情很困难，搞IT苦，工资不高，老加班，卖青春，受劳受怨，被老板剥削，但这些不能是你不专业的借口吧？不能是你搞不好个项目了还把责任推给客户的理由吧？跟如同奶娘的客户敌对是没有好下场地，看看吧，看看现在你们的口碑，有多少个是好的拿的出手的，看看你们现在能出的价码，一个行业的好坏是这个行业的人决定的，不是客户，你搞的好肯定就有客户，有票子，但是你们搞好了吗？如果你是一个有良心的开发人员，摸摸自己的心口看看身边几个人是负责任做事情的？

如果是你你的老板让你天天加班还不给调休给你的工资还不足以维持正常的生活开支。请问您老人家回很有责任心的去工作吗。

10 楼 seemoon 2009-06-26  

kunee 写道

明确告诉你，你没干过需求协调的活。

为什么一动需求就说系统架构就不行了？
说明架构先天就不行，为什么先天就不行，因为客户就给那么点钱。

这不是专业问题，是商业问题。

kunee 写道

客户总是催得很急。

客A:这个系统赶紧上线，一定要在XX日使用，领导那天要检查。就先做这些需求，一个列表过来
研B：这些需求我们要看一下，要好好设计一下。
客A：这个我不管，反正那天一定要用。你们可以先搞上去嘛，就用这些。
经理C：好，没问题。B，你赶紧搞一下。
研B开发加班赶紧搞


数月后
客A：上次那个需求要如何如何改。
研B：不是上次说就那样就可以了，怎么改动这么大。
客A：你们系统怎么扩展性这么差啊。
经理C忙道歉，研B继续加班。。。。


如何解释？我最经常遇到的情况，除了A，BC角色都扮演过，A你又得罪不起，当时做需求的时候他确实是很急

说明C不适合做项目经理。

9 楼 warison_2008 2009-06-26  

需求没做好，造成后期泛泛修改，开发员当然会骂人，正常的。。。习惯啦。。

8 楼 thinkx 2009-06-25  

客户不成熟是大环境，大部分的客户根本不知道自己具体想做什么，只有个大方向，甚至有些客户就是为了花钱才做项目，再有就是想的东西天天变，一天一个样，最闹心的是客户内部意见和利益不统一，几个爷你都得伺候。
不过，既然客户愿意花钱搞这个又不知道具体要搞啥，才会有这么多人去忽悠客户，说不定就把下一个项目给拿了。

7 楼 yiding_he 2009-06-25  

楼主说的就是我们当前存在的一个很恶劣的事实。刚入行的人最先听到的往往就是：“客户什么都不懂”，“客户不会告诉你任何东西”，“我们要引导客户”之类的奇谈怪论。于是，直到他自己去做需求之前，他都会用鄙视的目光去看客户。

6 楼 kunee 2009-06-24  

明确告诉你，你没干过需求协调的活。

为什么一动需求就说系统架构就不行了？
说明架构先天就不行，为什么先天就不行，因为客户就给那么点钱。

客户总是催得很急。

客A:这个系统赶紧上线，一定要在XX日使用，领导那天要检查。就先做这些需求，一个列表过来
研B：这些需求我们要看一下，要好好设计一下。
客A：这个我不管，反正那天一定要用。你们可以先搞上去嘛，就用这些。
经理C：好，没问题。B，你赶紧搞一下。
研B开发加班赶紧搞


数月后
客A：上次那个需求要如何如何改。
研B：不是上次说就那样就可以了，怎么改动这么大。
客A：你们系统怎么扩展性这么差啊。
经理C忙道歉，研B继续加班。。。。


如何解释？我最经常遇到的情况，除了A，BC角色都扮演过，A你又得罪不起，当时做需求的时候他确实是很急

5 楼 RCFans 2009-06-20  

目前要让开发人员直接去接受客户那一套想法，很难。因为开发人员这个群体还没有发展、分工起来，只有呆的时间长了，经验积累起来了后，才可以承担一些接近需求的工作，但现在基本上对很多开发团队来说，都是漠视需求分析阶段，所以，做这个角色的一般是项目中能力最弱的人去跑跑堂，吃几回亏就会学多点了，可惜的是，现在很多PM还是相信“马上开始编码”那一套。

4 楼 lihangnet 2009-06-20  

长年当乙方，以前不理解为什么甲方在需求上总是不配合，在项目工期、成本的压力下，也干过几次把责任推给甲方的事。其实心里很清楚，客户是花钱买我们的服务，用来解决问题，问题解决不好当然是服务不到位，肯定不是客户的错。
今年有幸当了一回甲方，应该说我们有很强的行业背景，同时对软件开发技术也有一定了解，毕竟用技术做过相关的项目，但说句老实话，我根本不愿意看乙方给我们提供的需求规格说明书，不是看不懂，而是凭什么让我看，甲方需要乙方实现功能，解决问题，你让我看一大堆的架构、设计、类、用例干嘛，还让我签字，承担责任。我真的没有义务给你们做项目设计的评审，这是你们的专业也是你们的责任，不能说我买个汽车，还要来负责汽车零件的设计吧。小人画 的再好，也要有用才行。
再者，不要总用居高临下教训的口气和甲方说话，实际上你们的水平和所谓的先进技术我们真的没必要知道，甲方只要结果，甲方不是为架构编码付钱，而是为好用的软件系统解决问题的功能付钱。
所以，反思一下，我们在做项目时是不是也没把客户利益放到第一位，是不是也总是以技术实现为中心，不考虑用户的感受。应该是改变的时候了，软件开发人员真的和服务业的工作人员没什么区别，应该抛弃高人一等的“精英意识”，平等对话（不是指表面装出来的尊敬，而是发自内心的尊重甲方的专业性），或许这样可以真正了解用户的需求，减少不必要的心理对抗，实际上，这样会更有利于我们更快、更好的完成工作。毕竟谁也不能和钱过不去。

3 楼 metadmin 2009-06-14  

引用

我们的客户，他们很无知，什么都不懂，要这要那，比孙猴子还善变，很难缠，我靠，简直比爷还难伺候

呵呵，这个我也经常告诉开发人员不要这样子。这样是不对的。

开发人员每天都有进步，相反搞市场、搞管理的人，看起来每天都是那样子。


需求是很难在项目初期就能确定的。但项目大方向和项目“起色点”也就是项目亮点、重点，是可以事先确定的。
以后的任何努力必须满足这个大方向，就可以了。


另外，我们也确实要看到我们的软件水平不行。改动一下，动不动就说涉及到架构，会造成巨大麻烦。这也是开发人员抱怨需求变更的重要原因。


系统不纯粹，有很多耦合是不好的。因此有了n层架构，有了很多框架。呵呵，殊不知很多框架反而束缚了我们。
权限与业务的耦合，大家解开了吗？据我的项目经验，完全解开权限与业务耦合，就能给让系统很灵活、更容易应变。如何解开权限与业务耦合，尤其是细粒度的，欢迎来我BLOG做客。

我期望一个后台比较简单，编写代码时间少，而前台细腻的系统，能真真正正的让客户舒心，帮助客户解决实际问题。