小公司的项目管理（一）-如何做需求分析如何做需求分析？?场景：我们做需求的几乎不懂业务，所谓的业务知识就是
小公司的项目管理（一）-如何做需求分析
如何做需求分析？
?
场景：我们做需求的几乎不懂业务，所谓的业务知识就是临时找一本相关的业务书，突击看个一星期，然后去客户那里调研需求。而客户呢，也没有信息化经验，他们对自己想要什么也说不清楚，他们对业务流程的管理也正在摸索试验中（客户公司是一家新成立的公司，很多人都是才入这个行业，本身对业务也不太懂。本来他们以为我们是业务专家，指望我们提出管理流程方案，这都是销售忽悠吹大牛，其实我们是第一次进入这个行业，完全的一窍不通）。说白了，就是客户和开发方都不懂业务！
?
我的解决方法：首先了解客户的组织结构，岗位职责、业务流程和关键考核指标，搜集了一大堆他们目前使用的业务单据。然后我想先按照他们目前的实际流程做个页面原型，让客户先看看，看能不能引导出一些需求来。结果根本行不同，因为是页面原型，客户根本不重视，看了以后，除了对有些用词提了一点意见以后，其他的都说OK(后来证明，客户只会在系统上线真正使用以后，才重视功能需求)。
?
注：我的用意是想讨论一下，在这种恶劣条件下，有什么办法尽量提高需求调研和分析的质量。就象许三多一样，明知道是impossible mission，但也要尽自己的能力做到最好。
?
后续：一般的大型企业可以分为三个层次：战略决策层（老总）、管理层（部门领导）、执行层（员工），做需求调研要从这三个层面进行，因为每个层面关注的内容都是不同的。但现在有个难题，大型企业的老总级别都是很高的，一般除了乙方的老板外，“闲杂人等”根本不愿接见，弄得有时很难揣摩老总的想法。采用什么办法来征求甲方老总的意见呢？
?
?
1 楼 hocus 2009-01-07 没有行业专家就做行业开发和初期信息化的公司
积累都是必须的
所以，建议你们 先从最简单的需求开始开发交付。
这时候挖的太深，将来推倒的可能性都很大。
基础版在使用中，不断了解，不断挖掘，循序渐进
后期控制好需求，签好合同
对交付后产生的需求，尽量归到二期去做
2 楼 zhang.jianhui 2009-01-07 可是如果不挖的很深，业务流程随着项目开发逐渐清晰会导致后面的业务需求使得程序员不得不反复之前的代码。
我还是觉得需求了解需要多做一些。不了解需求吃的亏真的不少。
3 楼 风清云淡 2009-01-07 就我目前的实践来说，利用页面原型来做需求引导和确认，几乎不可行。
其实对这种项目来说，往往实际情况是系统上线以后，才是需求调研的开始。
所以，尽量快速的实现一个简单原型，用这个原型来调研用户的需求，然后推倒重做。这种做法的前提是原型要做的很快，否则，项目进度就跟不上了 4 楼 hocus 2009-01-08 zhang.jianhui 写道可是如果不挖的很深，业务流程随着项目开发逐渐清晰会导致后面的业务需求使得程序员不得不反复之前的代码。
我还是觉得需求了解需要多做一些。不了解需求吃的亏真的不少。
脱离用户使用，你们不懂业务，你就能保证开始挖的深，方向都是对的？流程都是对的？
你们不懂客户业务，以后该流程是不可避免的，即便是懂，改的可能还是很大。
先从简单流程入手，让用户不断提出新流程
你们的流程实现，难道是代码级别的??? 5 楼 风清云淡 2009-01-08 hocus 写道zhang.jianhui 写道可是如果不挖的很深，业务流程随着项目开发逐渐清晰会导致后面的业务需求使得程序员不得不反复之前的代码。
我还是觉得需求了解需要多做一些。不了解需求吃的亏真的不少。
脱离用户使用，你们不懂业务，你就能保证开始挖的深，方向都是对的？流程都是对的？
你们不懂客户业务，以后该流程是不可避免的，即便是懂，改的可能还是很大。
先从简单流程入手，让用户不断提出新流程
你们的流程实现，难道是代码级别的???
流程可以做成配置的，这个相对可以用技术解决，但业务实体类的判定和关系划分，也就是领域建模，这个如果刚开始弄错了，后期更改的成本很高 6 楼 xidaboy 2009-01-13 可以感觉的到,这样很难
原型,可以简单一些,用PPT去画,然后专门的业务分析人员,天天去和客户海聊啊,然后把会议记录,拿回来大家讨论,再去海聊,来上几次再开始 7 楼 bingtears 2009-03-02 就像楼主所说的那样，先找相关行业的书籍狂补一下，对所做业务有了大概的了解之后走进公司调研实际工作情况。从组织管理，到业务流程，再到具体操作。从观察他们的工作模式开始做起，曾经有个BA老人说过，调研需求最好的办法是你住到他们公司一个星期，凡是会用到你即将开发的工具的人你都观察一遍，看他们是怎么干活的。然后书写成需求文档，用图文并茂的形式展现给他们，把你的理解想法展示给不同工作岗位的人，逐一征得同意，你对该行业的了解也就差不多了。最后要签订合同，合同一定要仔细，免得日后麻烦多。客户平时都是友好的，验收付钱的时候是苛刻的。 8 楼 happehope 2009-03-02 项目管理的三要素：范围、成本和质量；在需求不明确的情况下，要严格限制范围，在明确的范围内做，否则会死的很惨 9 楼 pcial 2009-03-08 风清云淡 写道就我目前的实践来说，利用页面原型来做需求引导和确认，几乎不可行。
其实对这种项目来说，往往实际情况是系统上线以后，才是需求调研的开始。
所以，尽量快速的实现一个简单原型，用这个原型来调研用户的需求，然后推倒重做。这种做法的前提是原型要做的很快，否则，项目进度就跟不上了
一开始做个原型出来，做粗一点，保证大方向正确，后面可以添加细节。推到重做的代价太高了吧？ 10 楼 风清云淡 2009-03-08 pcial 写道风清云淡 写道就我目前的实践来说，利用页面原型来做需求引导和确认，几乎不可行。
其实对这种项目来说，往往实际情况是系统上线以后，才是需求调研的开始。
所以，尽量快速的实现一个简单原型，用这个原型来调研用户的需求，然后推倒重做。这种做法的前提是原型要做的很快，否则，项目进度就跟不上了
一开始做个原型出来，做粗一点，保证大方向正确，后面可以添加细节。推到重做的代价太高了吧？
这也是没法子的事，在国企事业单位里，那些业务人员看不到真正可使用的系统，根本不会认真看，文档和类似文档的东西，他们只是大面过一眼，就说行，即使你让他签字，他们也无所谓，因为你也不可能因为需求变更增加费用。
11 楼 风清云淡 2009-03-09 mock1234 写道楼上：
这大概就是本事不同造成的。本事高的，可以让客户不但对参与开发过程感兴趣，而且愿意发表文字的意见对许多功能的开发顺序进行取舍。本事弱的，把责任都推在客户不配合上。
呵呵，或许确实俺的水平有限。
一般信息化都是一把手工程，如果一把手不重视，下面的人很积极几乎不可能，干好了没功劳，干差了要承担责任，而且刚启用信息化的时候，很多纸质的表单也不能废除，等于双轨制，平白增加了业务人员的工作量，再加上很多岁数大的业务人员对计算机很陌生，对信息化没概念，你给个文档，他能认真揣摩提意见吗？
中国的官僚邋遢作风，很多时候，个人是无法抗衡的，项目经验多的人应该深有体会 12 楼 风清云淡 2009-03-09 mock1234 写道这很能说明问题——但不是用户的问题，而是软件公司所能派出的负责人自身的问题。没有人格魅力，没有“关系渠道”，没有直截了当满足客户重要需求的能力，没有搞过许多大单子的自信，一味地推销垃圾商品，就算给了权限也无法迅速做出决策，没有对自己公司开发和服务团队的影响力，在用户的不论上层还是下层人群中也都不被看重。
这样的人除了学习，又能怎样？
中国的很多软件公司能打什么单子，不是项目经理决定的，老板不会考虑公司的现状能不能做，他觉得只要单子能签下来，就OK了。
就我前面描述的，单子涉及的业务是全新的，乙方公司没有人熟悉业务，而甲方也是新成立的公司，业务人员也不懂业务，在双方都不懂业务的基础上，你怎么确定用户的重要需求？甚至甲方领导直接下行政命令说不必做需求调研，因为人家认为乙方是业务专家（这是老板和市场人员的忽悠功力，对甲方说在这个行业经验是多么丰富），其实这个时候乙方在甲方眼里既是咨询顾问公司，又是软件开发公司，但实际不是如此。老兄，如果是你，你怎么办？
呵呵，批评人很容易，但解决问题是另一回事！
当然有人说这样的公司，趁早离开，我是这样认为的，条件越恶劣，锻炼价值越大，因为生活在中国，不能老想自己的手下都是高手，客户都很配合，领导会给足够的资源。 13 楼 风清云淡 2009-03-09 mock1234 写道项目经理不需要打下大单子，但是绝对需要做过大单子。
明知道问题在哪里，那么你归咎问题的方式就能看出你思考问题的方式。已经显得捉襟见肘了，赶紧弥补啊。项目经理不要用一堆底下人才可能出现的事务性的抱怨来逃避更重要地那几件事情。
哈哈，怎么弥补啊，说空话谁都会。你说了半天，就没见你说一句有实际意义的解决方法。
例如，就我说的那种状况，假如是你，你会怎么做？
什么是大项目的标准？人月数？项目金额？代码行数？再说，我说的情况和项目大小没有必然联系。我做过上千万的项目，不知算不算大项目？但每个公司和项目的具体情况都不同，困难程度差别也很大。
我原来的公司，只做一个行业的项目，所以业务积累很多，不夸张的说，对业务的了解比客户还要深，很多问题的把握自然水到渠成，但现在这种甲乙双方都不懂业务的情况，我确实是第一次遇见，所以才绞尽脑汁想各种办法来克服。
14 楼 jok 2009-03-12 to xidaboy:
你的那个logo，不是Nazi吗?能不能换一个？真的太不舒服了。不是对你本人，是对那个logo。谢谢！
