请教：烦劳业界有经验的同仁，谈谈您在进行需求分析的时候，是如何正确获取客户需求（或者说怎样来正确把握这个尺度）的,谢谢!:-)
　

---

在实际工作中，偶也参与过一些对客户需求的获取、分析与相关规范的制定，


理论上的东东也看了不少，比如Rational的RUP等等……


但现在想想，在做客户需求中存在很多的不足之处（比如：在客户没有确定他的需求的前提下，自己做的需求分析也是模棱两可、很多弊端甚至影响到了后面的系统设计），想改变现状，又不清楚应如何下手，请业内有经验的同仁也谈谈您的看法，大家交流一下。谢谢!!

http://www.amazon.com/exec/obidos/ASIN/0201360462/qid%3D1024976410/ref%3Dsr%5F11%5F0%5F1/104-8241826-7767931

估计不久会有中文版出现。但实际操作还是要做需求的人牛。

 最主要靠沟通和交流。
　

---

1）最主要靠沟通和交流。
2）如果在某个项目中有Business Process Architect会比较好，对需求的捕获会很有作用。
3）尺度需要最终用户的检验。
4）使用prototype/user interface，辅助验证您的想法以增进和用户的沟通。
5）Use case是一个不错的形式和技术手段，但是如何好好使用UC技术是有讲究的。记得好像XPROGRAMMER第14期（还是13期）有一篇访谈很有感觉。

 回复: 这本书不错——谁有电子版？
　

---

那位大哥能给俺看看电子版？TIA。

 回复: 最主要靠沟通和交流。
　

---

是啊，不过就目前国内来说有“Business Process Architect”的多乎斋？不多乎！

现在都是大家边摸索边做，其中存在很多不足之处；

做需求分析原本就是“变数”很高，再加之客户变来变去，使整个需求工作变得有些扑朔迷离！

有些人则认为让只要让客户填写需求认可单就行了，但是往往客户再提出其它需求，你能单凭一张“需求确认书”就把他给搞定。这势必会影响与客户之间的关系，在下一步的工作中有可能因为遇到另外的问题。。。。哎！越说越乱了!

只是觉得如何与客户沟通才能更高地提高工作效率，面对看对use case一窃不通的客户又应如何对付呢？

 最有效的方法是：
　

---

别给这样的客户做项目，
客户跑多了才发现，客户的水平真是千差万别呀，有些客户就明确跟你说：我们不知道要做什么，我们基本情况就这样，你先出个方案吧；有些客户就不同，他们水平很高，会明确告诉你该做什么，不做什么，不要弄什么花活。
这两种客户我都遇见过，结果当然先给后者做啦

偶倒是不想要这种吊蛮客户，不过我不是老总：（

而且目前这种客户还是大有人在！

系统没出来之前他什么都不懂；设计已初具雏形，他就又什么都懂了，指出这里不对，那里不恰当。。。。

在我的工作中，有这样一个客户的具体例子：

当时前期的需求分析是我同事来做，后来由于某种原因他离开公司，这个客户就由我来盯着；

在我们的系统已完成75％以上的时候，由客户再来确认，他偏说要把Oracle改成SQL Server…更换理由很充分，他们公司没人懂Oracle。。。。：（他不早说，欠扁！

起初也怪我们更换了人员分工，哎！当时好惨呀~！

项目进行到75%的时候ORACLE的培训都应该早做过了，如果反悔也不会等到这个时候
客户这种行为是我们软件公司给惯的，别怪别人了
碰到我，就是不给他做，看他牛B

搞定客户
让他们的决策者跟你走,找出固定需求(不变的),可变需求也要做一部分,无伤设计的
其实搞需求变更最后还是搞人,不是你搞他就是他搞你,如果你不能采用相应方法
使客户同意你的需求规格说明书(阶段性),小心进入泥潭
说说我做客户的方法
1、先放开谈,让客户谈出需求，在这里你要能控制关键(如业务流，层次)，别让他们说走题了，并且还要有个计划（别骗自己），这样需求讨论的时间能较好的控制
2、记录所有的需求，（你有秘书没有），关键在于你找出你必须做的，和可以
不做的，哪些可以以后再做的。必须做的（如核心流程）还有什么不清楚的，
问明白
3、说服客户，减少你的工作量，这才是最关键的。此处技巧是做人。这个不是一天两天的功夫练出来的。我一般会说服客户主管，说这些做会如何，讲清楚，
他也是打工的，要向领导表现的，他自会考虑。哪一些可以先不做的，你要说明
其做了没意义的原因。看你自己的本事了
4、形成需求规格说明书，需求变动表等，过目，签字（不是你）。这里要说明，在这段时间除非重大变动（核心改变），不改需求。需求变更进行记录，
回来在你的可用品出来后，开评审会再来讨论。说明，钱是按可用品来付的，
我给你改需求是给你们面子，兄弟吗（MM吗）。这一段关键，你有没有办法
让客户按你的流程走，别说这不可能，是你做不到，关键字：人

5、你可以开始了，别忘了做人是无时无刻的

随便给砖
　

方法是次要的，一张白纸，半支铅笔，小人也好，画框也好，大家明白高兴就行，说黄色笑话最形象，为什么不能用，不比USE CASE差，回来你怎么整理说明，那是你的事,回来大家认可就行。

 搞定他
　

---

方法一、你先培训个漂亮MM ORACLE，然后让MM手把手，嘴把嘴地教
ORACLE比WORD可简单多了

 呵呵！这个方法....
　

---

还得向公司申请招个专门的技术支持，呵呵~

不过可行...:)

 做项目经理一定要有成本意识
　

---

知道如何花钱是合理的
如果请客户逛窑子能减少几个月的开发成本和时间的话
花两万也值
呵呵，北京的天上人间才能到这个档次

这些部门的负责人一般是不会主动帮你完成某些“应尽的义务”的，而且部门之间也会存在一些踢皮球的情况，许多时候需要你自己主动完成其中的“协调”工作。
－－现在地客户很精明，几乎全部都是电话里给你确认，提了好多次“可以给各email”的话，从来没收到过。结果就只有写好文档，给他发过去了，谁叫是他们买单呢：）

做事原则：
把握关键

你做一个项目，没搞清谁是关键人物，哪里是关键部门
谁说了算，提需求的人就说了算吗

需求没做好，如果我是你的上司，我就认为是你的原因
这是效果，因为你没有把握事情的能力，你没有变主动
，处处挨打，是不是你的问题呢


所以，这些事是你要把握的

　

在中国许多时候做项目就是做“领导”，但这不意味上面提的要求，下面的人会按质按量的完成，自己不能等着他来完成，必须要自己多联系，把这当成工作一个重要组成部分

　　建议多向业务顾问请教。如果你不懂业务，需求分析就比较难做啦

说的不错，反正要学会say no!

 不对呀！公司为了省钱，哪能请设置那么全的职位分类呀？他们要求分析人员最好是全才，或是至少对此行业有很丰富的经验。。。：（
　

---

为了节省项目经费，当然这些事情都要我们自己来做啦，

或者美其名曰找个客户方的“行业专家”来给讲讲，不过这个过程无非就是和客户吃吃喝喝，吃完了，需求也算调研完。大多没什么太大收获。：（

 呵呵，多谢兄台高见;-)
　

---

没错，的确做人是最重要

a.看来想做好"需求获取"与"系统分析"之前，把客户搞定应提到最先:)不过如果运气不好，搞不定可惨啦。

b.还有就是遇到一大堆客户说了算时，他们的权限级别平行，需求却不相同，这个时候巨愤特啦！得罪了谁都不行:(

 聊天室的发言稍瞬即逝，贴出来还可以让大家借鉴一下啊:)
　

---

我们公司只能用oicq，不过不能去聊天室:-X