小公司的项目管理（一）-如何做需求分析

如何做需求分析？

 

场景：我们做需求的几乎不懂业务，所谓的业务知识就是临时找一本相关的业务书，突击看个一星期，然后去客户那里调研需求。而客户呢，也没有信息化经验，他们对自己想要什么也说不清楚，他们对业务流程的管理也正在摸索试验中（客户公司是一家新成立的公司，很多人都是才入这个行业，本身对业务也不太懂。本来他们以为我们是业务专家，指望我们提出管理流程方案，这都是销售忽悠吹大牛，其实我们是第一次进入这个行业，完全的一窍不通）。说白了，就是客户和开发方都不懂业务！

 

我的解决方法：首先了解客户的组织结构，岗位职责、业务流程和关键考核指标，搜集了一大堆他们目前使用的业务单据。然后我想先按照他们目前的实际流程做个页面原型，让客户先看看，看能不能引导出一些需求来。结果根本行不同，因为是页面原型，客户根本不重视，看了以后，除了对有些用词提了一点意见以后，其他的都说OK(后来证明，客户只会在系统上线真正使用以后，才重视功能需求)。

 

注：我的用意是想讨论一下，在这种恶劣条件下，有什么办法尽量提高需求调研和分析的质量。就象许三多一样，明知道是impossible mission，但也要尽自己的能力做到最好。

 

后续：一般的大型企业可以分为三个层次：战略决策层（老总）、管理层（部门领导）、执行层（员工），做需求调研要从这三个层面进行，因为每个层面关注的内容都是不同的。但现在有个难题，大型企业的老总级别都是很高的，一般除了乙方的老板外，“闲杂人等”根本不愿接见，弄得有时很难揣摩老总的想法。采用什么办法来征求甲方老总的意见呢？

 

 

没有行业专家就做行业开发和初期信息化的公司
积累都是必须的
所以，建议你们 先从最简单的需求开始开发交付。
这时候挖的太深，将来推倒的可能性都很大。
基础版在使用中，不断了解，不断挖掘，循序渐进
后期控制好需求，签好合同
对交付后产生的需求，尽量归到二期去做

可是如果不挖的很深，业务流程随着项目开发逐渐清晰会导致后面的业务需求使得程序员不得不反复之前的代码。
我还是觉得需求了解需要多做一些。不了解需求吃的亏真的不少。

就我目前的实践来说，利用页面原型来做需求引导和确认，几乎不可行。
其实对这种项目来说，往往实际情况是系统上线以后，才是需求调研的开始。
所以，尽量快速的实现一个简单原型，用这个原型来调研用户的需求，然后推倒重做。这种做法的前提是原型要做的很快，否则，项目进度就跟不上了

脱离用户使用，你们不懂业务，你就能保证开始挖的深，方向都是对的？流程都是对的？
你们不懂客户业务，以后该流程是不可避免的，即便是懂，改的可能还是很大。
先从简单流程入手，让用户不断提出新流程
你们的流程实现，难道是代码级别的???

流程可以做成配置的，这个相对可以用技术解决，但业务实体类的判定和关系划分，也就是领域建模，这个如果刚开始弄错了，后期更改的成本很高

可以感觉的到,这样很难

原型,可以简单一些,用PPT去画,然后专门的业务分析人员,天天去和客户海聊啊,然后把会议记录,拿回来大家讨论,再去海聊,来上几次再开始

就像楼主所说的那样，先找相关行业的书籍狂补一下，对所做业务有了大概的了解之后走进公司调研实际工作情况。从组织管理，到业务流程，再到具体操作。从观察他们的工作模式开始做起，曾经有个BA老人说过，调研需求最好的办法是你住到他们公司一个星期，凡是会用到你即将开发的工具的人你都观察一遍，看他们是怎么干活的。然后书写成需求文档，用图文并茂的形式展现给他们，把你的理解想法展示给不同工作岗位的人，逐一征得同意，你对该行业的了解也就差不多了。最后要签订合同，合同一定要仔细，免得日后麻烦多。客户平时都是友好的，验收付钱的时候是苛刻的。

项目管理的三要素：范围、成本和质量；在需求不明确的情况下，要严格限制范围，在明确的范围内做，否则会死的很惨

一开始做个原型出来，做粗一点，保证大方向正确，后面可以添加细节。推到重做的代价太高了吧？