又说到需求

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

 

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

 

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

 

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

 

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

 

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

 

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

其实很多开发人员在网上说的话也只是发发牢骚，不一定定代表真实的想法。或是说有点脆弱，不敢面对现实，什么问题都埋怨别人其实只是借口而已。

    1.中国的软件不成熟,不够强大。
    2.软件项目流程不规范.

   这些不是软件开发人员能解决的问题。 

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

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


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


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


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

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

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

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

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

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

客户总是催得很急。

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


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


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

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

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

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