第5章〓需求调研


思维导图


项目启动后，接下来就要进行需求调研了。需求调研主要包括两方面的工作： 第一，熟悉当前业务，弄清楚甲方相关领域是怎么管理的，每个岗位的人员是怎么工作的，物料是怎么流动的，信息是怎么流动的，有哪些单据，做了什么报表等； 第二，获得用户对本系统的需求，了解用户希望本系统提供哪些功能，希望解决什么问题，希望如何通过系统进行工作，对本系统有什么期望等。

有些以提供标准产品为主的项目，可能在项目启动后会立即部署系统，配置演示数据，让用户学习使用，然后以这个标准产品为基础跟用户谈需求。不能不说这种实施方式是非常有效的，因为实施者可以有目的地让用户在提需求的时候围绕标准产品的思路展开，这样就可以让用户的需求更聚焦，减少不能实现的风险，降低定制成本。本书按照定制开发系统的步骤讲述实施工作，但并不代表本书的知识不适用于标准软件产品的实施，这一点相信读者是可以理解的。

5.1熟悉当前业务

实施者在跟用户洽谈系统需求之前，一定要先熟悉甲方相关领域的业务管理方式。如果你对项目相关领域的业务一窍不通，用户提需求时你根本不知道能不能实现，是不是应该实现，实现了对用户的工作有何影响等，那么在这种状态下，你在调研过程中基本上只能记记流水账，根本不可能进行有效沟通和引导，如果遇到某些特别复杂的业务，你甚至根本听不懂别人讲的内容，又怎么能搞好需求调研呢？

当然，也存在一种特殊情况： 这个系统所要处理的业务，是甲方依据这个项目设置的新业务，例如，某个企业专门成立了电商部，依托刚开发的电商系统做线上生意。如果出现这种情况，那么“熟悉当前业务”这个步骤就可以跳过了。

熟悉业务有很多方法，常见的包括使用调查问卷，分析用户正在使用的各种单据，分析用户使用的各种报表等。

5.1.1问卷调查

通过调查问卷了解业务，是一种效率非常高的调研方法。对于调研者来说，不必跑到工作现场跟多个用户沟通，只要编写、发放问卷，通过研究答卷就可以得到大量有用的信息； 对于被调研者来说，不需要打断自己的工作，可以合理安排回答时间，可以进行更仔细的思考。

1. 如何制作调查问卷

调查问卷是由若干题目构成的，这些题目可以是封闭的(选择题)，也可以是开放的(问答题)。要把这些题目编写好并不是一件容易的事情，在编写调查问卷前，最好对相关业务有一定的了解，如查阅甲方资料、找人咨询等。了解得越清楚，你的调查问卷就会编写得越具体，获得的信息也就越有价值。

如果要全面了解甲方一个业务单元(部门)的业务，应该从哪里入手呢？实施者可以试着按这个思路设计问题： 它内部是怎么管理的，跟它外部有什么工作往来，它从外部获得什么，它向外部提供什么，等等。下面列举了一些用于了解一个部门业务的问题，仅供读者参考： 

(1) 部门的组织架构是什么？请画出组织架构图，写明每个岗位的主管。

(2) 有哪些业务？业务流程是什么？

(3) 有哪些岗位？每个岗位的职责是什么？

(4) 每个岗位有多少人员？人员构成情况(学历、性别等)如何？

(5) 每个岗位获得了什么物料？生成了什么产品？

(6) 每个岗位的工作需要什么信息？输出了什么信息？

(7) 每个岗位的工作任务从哪里来？发布任务者通过什么方式发布任务？

(8) 每个岗位完成工作任务时，会有明确的技术要求吗？如果有，包括哪些？

(9) 每个岗位需要对自己的工作完成情况进行汇报吗？如果需要，怎么汇报？什么时候汇报？向谁汇报？





(10) 每个岗位的工作结果会有正式的检测或检查吗？如果有，简述检测或检查的过程。

(11) 有哪些部门跟这个部门有正常工作往来？这些工作分别是由哪些岗位负责的？请分别列举有哪些业务。

(12) 这个部门会跟公司外部的组织发生业务往来吗？如果有，请分别列举有哪些业务(例如，原料仓库会跟外部供应商有业务往来)。

(13) 部门内是否有物料流动？如果有，请说明一般会有什么流动路径，并简述在物料流动的过程中做了什么处理。

(14) 每个岗位在工作过程中产生了哪些被记录下来的信息？是如何记录的？

(15) 除了基本工资外，员工会有额外的薪酬吗(如计件工资、绩效工资、奖金、津贴等)？这些薪酬发放的根据是什么？如果有计算公式，请列出详细的计算过程。

(16) 部门会有员工考评机制吗？如果有，是怎么处理的？如果有计算公式，请列出详细的计算过程。

通过以上题目，可以从管理的角度大致了解一个部门。管理的角度一般不外乎这些方面： 组织方式、考核方式、激励方式、物流、信息流、资金流、工作任务与计划、技术管理、质量管理、沟通机制等。如果把这些方面了解清楚，再去进行更详细的调研就容易多了。

赵峰在甲方实施项目，需要为甲方定制开发一个大型分销管理平台。甲方属于制造业企业，市场在国内，在全国各地有很多分公司，另外还有大量的代理商，货物会经过代理商销售出去。项目已经启动了，赵峰开始进行需求调研，为了提高工作效率，他制作了一份调查问卷给甲方项目经理，希望他能安排相关人员认真回答。

(1) 贵司采购的原材料有哪些类别？采购方式有哪些？如何结算？请分别提供一些比较有代表性的供应商。

(2) 贵司销售的商品有哪些类别？销售方式有哪些？如何结算？请分别提供一些比较有代表性的客户。

(3) 有哪些分公司是直接面向市场的？它们分别销售哪些商品？

(4) 有哪些分公司不直接面向市场，只向其他分公司提供产品？它们分别提供什么产品？如何结算？

(5) 跟代理商的业务往来过程一般是怎样的？请大致阐述处理流程。

(6) 跟代理商如何结算？信用额度是怎么设置的？

(7) 货物是如何运送到代理商手上的？平均下来，货物一般会在代理商仓库停留多久？停留的原因是什么？

(8) 当前时间点，每个代理商手头没有销售到最终客户的货物包括哪些类型？所占资金分别大概有多少？

(9) 各分公司目前有哪些仓库？请介绍这些仓库目前包括哪些货物，大概占用多少资金。

(10) 依据当前信息，能不能计算出每个仓库的库存周转率？如果可以，请计算出每个仓库的库存周转率，并描述信息来源； 如果没有，请估算一下。

(11) 公司将货物运输给客户一般会采用哪些方式(公路、铁路、航空)？各自所占比例大概有多少？

(12) 有哪些物流运输公司与公司合作？它们一般运输什么货物？运输时效情况如何？

(13) 货物从完工到运送到最终客户手上，一般要经过哪些中转点？分别停留的时间大概多久？为什么会停留？

(14) 货物一般采用什么包装方式？包装方式与运输方式有什么关系吗？

(15) 如果客户对公司的货物或服务不满意，它们有哪些反馈渠道？请介绍这些渠道的处理过程。

(16) 客户一般对货物或服务的不满体现在哪些方面？各自所占比例大概有多少？

(17) 业务员的收入跟销售结果有什么关联？一般是如何计算业绩的？

(18) 公司有哪些与采购、库存、生产、运输、分销相关的岗位？这些岗位的职责是什么？

(19) 公司现在使用哪些IT系统？列举每个系统的功能，以及处理的数据。

2. 选择答题者

调查问卷制作完成后，需要物色合适的答题者。很多问题，如果不是相关领域的高手，是不可能回答出来的。理想的答题者应该具备这些特征： 有回答问题的动力，文化程度能够胜任，有不错的文字表达能力，对业务非常精通，擅长总结概括，对数字化管理感兴趣，等等。

根据问题覆盖的业务范围，可以将调查问卷大致分成三个级别： 全局级、部门级(可能还有下级部门)、员工级。对于全局级的调查问卷，最好是充当高层管理智囊团之类的部门来回答，如党政办
、企业管理部、总裁办公室等； 对于部门级的调查问卷，最好由部门负责人亲自作答，或者至少要亲自安排其他对部门管理工作非常熟悉的人员作答； 对于员工级的调查问卷，可以由员工主管来回答，最好另外再安排几个精通业务的普通员工回答，这样有些事情可以相互验证。在实际工作中，遇到的情况要复杂得多，需要具体情况具体分析。

3. 问卷调查的局限性

问卷调查有很强的局限性，这一点在开始调查时就应该有心理准备，其局限性主要由以下这些原因产生： 

1) 相关领域的业务不太容易用文字表达

有些业务内容使用文字很难表述清楚，以软件行业为例，项目经理的工作用文字描述就比较困难，而测试人员的工作相对就容易描述一些。

2) 答题者缺少认真的答题态度

有些员工对这个项目根本不当一回事，甚至还有敌对情绪，拿到调查问卷不是想如何认真回答问题，而是想如何将这件事情敷衍过去，希望能节省时间去做其他事情。在这种心态下答题，其效果可想而知。

3) 答题者没有足够的答题能力

有些员工文化程度高，文字能力强，能清晰地用文字表达自己的业务范围及体验； 有些员工文化程度低，文字能力弱，通过文字很难说清楚。例如，某调查问卷中有一个题目，要求被调查者就自己的某某工作场景画出流程图，可要知道，并不是每个人都会画流程图的，搞IT的觉得画流程图很容易，可现实是，许多人根本不知道流程图是什么。

4) 调查问卷的编写质量不过关

调查问卷的编写质量也制约着这种方法的效果。实施者不可能对每个行业的业务都了解得那么清楚，如果对这个领域的业务知之甚少，那么再怎么努力，都不可能编写出高质量的调查问卷，只能泛泛而问，回答者自然也就泛泛而谈。另外，对于调查问卷来说，要想获得理想的结果，最好提供封闭式题目，让被调查者做选择题或者判断题，这样既保证了回答的准确性，又可以降低被调查者的回答难度。不过遗憾的是，对于需求调研来说，提供封闭式的调查问卷是不现实的，因为这个阶段需要了解的事情太多，使用封闭式答卷获得的信息量太少，几乎没有意义。

总体来说，你收到的答卷，十之八九都比你希望获得的答案简单得多。以笔者的微薄经验来看，通过调查问卷获得的信息一般都不会太深刻，往往浮于表面，要想更深入了解相关业务，必须使用其他方式。

5.1.2分析单据

分析单据就是指要分析甲方当前使用的纸质或电子单据，研究这些单据所承载的信息，分析其产生及流动的方式，从而更深刻地理解当前业务。

1. 单据收集

要进行单据分析，首先需要收集单据： 收集甲方在业务运营过程中使用的各种纸质或电子表单。收集单据有以下注意事项： 

1) 收集的单据务必要全面

收集单据的原则是“宁可错收一把，不可放过一个”，只要跟项目相关的单据都要收集，例如，对于生产管理系统，可能不仅需要收集车间生产的单据，还需要收集销售、采购、库存、财务、成本等跟项目有关联的其他各种单据。当然，也不能走极端，过犹不及，例如做一个OA系统，无须把公司车间所有的生产单据都收集一遍，这没有意义。

2) 尽量跑到工作现场收集单据

收集单据不要图省事，例如，让人收集了送到你手上，或者跑到甲方的单据小仓库撕下所有的空白单据。这样看上去貌似提高了工作效率，但其实丧失了很多熟悉业务的机会。应该尽量亲自跑到工作现场，拿到单据后如有可能立即跟工作场景结合起来进行深入了解： 了解这个单据在这个地方是怎么产生的，跟现在的工作有什么关系，填写者在上面填写了什么信息，根据什么填写的，等等。

3) 收集的单据务必是被使用过的

收集的单据应该是被使用过的单据，因为员工在单据中填写的内容价值很大。仅仅看空白单据上的字段标题，有的时候确实很难理解，而借助填写的内容，理解起来要容易得多。例如，
有时候，单据中填写的内容会体现某种逻辑关系。例如，“金额＝单价×数量”，如果只看空白单据，这种关系不容易看出来。不是所有的字段都像单价、数量、金额这么明显的，甲方一般也不会将逻辑关系印刷在空白单据上。
有时候，用户会在单据的角落上(或背面，或其他空白处)写一些文字，并没有直接填写到格子里面，有时候又有一些格子是空白的并没有填写内容，这往往意味着，这份单据并没有完全按照设计者的意图在使用，有些需要的字段没有设计出来，而有些设计出来的字段却没有用。

4) 每种单据要多收集几张

在收集单据时，同一种单据应该多收集几张，因为不同的岗位，在不同的业务场景下，用户可能会有不同的填写方式。如果同一单据会被不同的岗位使用，那么在每个岗位都要收集几张不同的单据。如果使用的人多，流动的岗位多，承载的信息量大，逻辑复杂，就要多收集些； 如果单据简单，使用的人也少，信息量也少，可能一两张就足够了。

2. 单据分析

收集完单据后，需要对它们进行认真分析，其实这项工作在单据收集工作启动时就应该开始了。单据来自于甲方的业务运作过程，对于实施者来说，这个过程并不容易理解，而且有些工作的专业性非常强，需要你花很多时间学习，要把相关的单据都研究清楚是个相当有挑战性的工作。不过，一旦你把这项工作搞定，以后跟甲方人员沟通就会更加轻松。如果项目够大，涉及的业务够多，那么这件事可能需要一个团队协作完成。单据分析可以从以下几方面入手。

1) 理清每个单据的源头

首先从每个单据的源头开始，了解这个单据是由哪个部门的哪个岗位发出的。需要注意的是，很多单据并不是由唯一一个岗位发出的，例如下面案例中的“原材料领用单”，车间、技术部、工程部等多个部门都需要填写本单据到仓库领材料。甚至有些单据，每个员工都有发起的可能，很多办公层面的单据(如请假单、办公用品领用单)就是这样的。这也是我们强调相同的单据需要收集多份的原因之一，如果只收集一份，很容易忽视这种情况。

赵峰到仓库收集单据，其中有一份“原材料领用单”，是甲车间物料管理员填写的。仓库的材料就是给车间准备的，赵峰觉得这个非常合理，于是在分析了这个单据中的信息后便认为这个单据的分析工作结束了。后来在技术部，发现了一份“原材料领用单”的存根，一问之下，才知道原来技术部也是需要去仓库领用原材料的，主要用来做技术参数的测试。赵峰发现这个问题后，觉得不能掉以轻心： 还可能有别的部门需要到仓库领用原材料吗？于是又重新到仓库针对这个单据做了详细调研，原来不但技术部会领用原材料，工程部也会领用(用于进行机器调试)，采购部也会领用(用于做采购样品)，等等。

2) 理清单据的流动路径

一般来说，大部分单据都会流经多个岗位。有些单据主要在部门内部流动，如某车间的生产调度单，就只在车间内部流动； 有些单据会在不同的部门之间流动，如某仓库的领料单，由领料部门流向仓库； 还有些单据从甲方外部流入，如供应商的送货单，由供应商流入甲方； 还有些单据流向甲方外部，如销售发货单，由甲方流向他们的客户。

单据的流动方式主要有这么几种： 第一种方式，由一条线单向流下去，固定由某一个岗位发起，到某一个岗位结束，如某产品加工卡，由调度人员发起，随着加工件的流动而流动，最后进入某仓库结束； 第二种方式，由多个源头发起，但最终都归于同一个岗位，如某仓库领料单，很多需要领料的部门都可能发起，最终流向仓库结束； 第三种方式，单据在流动的过程中会有往复的现象，即从某个岗位出去，然后又回到这个岗位，例如某车间生产时有一种生产卡片，甲岗位完成某道工序后，在卡片上填写部分内容，再将卡片随着货物移交乙岗位，乙岗位完成某道工序后，在卡片上填写部分内容，又将卡片随货物移交甲岗位做另外一道工序，这就出现了单据流动的往复； 第四种方式，单据的流动会出现分支，即同一单据在某环节出现分支，流动到不同的岗位，这种现象其实很常见，你看那种一式数联的单据，基本都是这种流动方式，例如某仓库的货物验收单，供应商送货后，仓库验收货物，填写验收单，验收单一式三联，一联给供应商送货人带回，一联给仓库管理员记账，一联给财务结账，这就出现了单据流动的分支。当然，现实中单据流动的方式更为多样，某些单据的流动过程可能是这几种不同方式的组合。

3) 理清每个字段的前因后果

仅仅分析每个单据流经哪些岗位是不够的，还要分析每个岗位针对每个单据做了些什么，它们从单据中获得了哪些信息，这些信息对它们的工作有何帮助，在单据上填写了哪些信息，这些信息是在什么情况下填写的，根据是什么，等等。

要理清每个字段的前因后果，首先得弄清楚每张单据的结构。单据最常见的结构有两种，一种是单一形式，一种是主从形式。例如，请假单、生产卡之类的单据，往往都是单一形式，从软件的角度看，核心信息往往对应着数据库中一个表的一条记录； 而像送货单、销售单之类的单据，往往都是主从形式，一般单据的上部是这次业务活动的总体描述，可称之为“头”，如送货单位、送货日期、送货人等，而单据下边是明细信息，可称之为“行”，如送货的品名、规格、数量、单价等，从软件的角度看，核心信息往往对应着数据库中的主从两个表，这两个表的关系是一对多的关系。

现实中，单据的结构不会总是这么简单，可能多种多样、五花八门，设计单据的管理人员一般是不会考虑什么主从结构、一对多这些概念的，一切以使用是否方便，是否有利于管理为出发点。很多单据非常复杂，包括各种信息块，块跟块之间有很多隐含的逻辑关系，这往往需要实施者投入大量的精力去学习研究。

分析清楚结构后，要仔细研究单据上的每个格子。每个格子中的内容都是员工在某个特定场景下填写的，是在工作中生成的，是为某个工作流程提供的必不可少的信息。有些格子填写起来非常简单，例如填写个工号、当前日期什么的，但有些就非常复杂，例如，登记某些需要经过大量测量、分析、计算才能获得的技术参数。

4) 注意在单据边角上书写的不正规内容

员工在使用单据的过程中，可能会在单据的边角甚至背面填写内容，请不要放过这些没有填写在格子中的内容。很多时候，这是大家针对某种信息约定俗成的填写方式。

再来看看单据的生命周期。单据刚刚被设计出来时，往往是最适合业务要求的，因为设计者是根据当时的管理方式设计的。随着业务的发展，单据格式会越来越偏离业务流程与管理要求。当使用者通过这种单据无法处理业务时，自然而然会找个空白的地方书写补充信息，在单据的边角上或背面看到的信息很有可能就是这么来的。补充信息多了，往往预示着现在的管理方式跟当初设计单据时有了很大的变化，也就预示着这个单据就要走到生命尽头了，最后，管理者会根据业务要求重新设计单据以替代原来的单据。

在单据上填写这种补充信息是工作人员在不得已的情况下使用的变通方法，这种信息对管理很重要，有时候比格子里填写的信息还重要。分析清楚这些补充信息可以更好地把握当前的管理思路，忽略它们是不明智的。

5.1.3分析报表

在甲方收集单据当然也包括收集各种报表，但报表跟单据是有本质区别的，单据是在业务处理的过程中由用户填写的，一般具有实时性，往往是一个信息采集、传递的过程，而报表则是根据一定的规则对批量数据进行检索、统计、汇总，是一个信息加工、分析的过程，一般不像单据那么实时。随着计算机的普及，虽然在业务处理过程中纸质单据还大量存在，但在纸张上直接制作报表的情况越来越少见了，即使没有IT系统，甲方也会使用一些常用办公工具制作，如Excel。

可以考虑从这几方面来分析报表： 生成报表的触发条件，报表中每个字段的信息来源，报表的制作逻辑。

1. 生成报表的触发条件

站在业务处理的角度看，报表生成的触发条件一般有以下几种方式： 

(1) 领导临时有要求，相关责任人根据收集的信息制作，例如领导忽然要求统计一下今年的职工离职情况。

(2) 到了某个周期性的时间点，例如日报、周报、月报、季报、年报等。

(3) 发生了特殊事件，例如订单完成后，需要给客户出具一个与这个订单相关的分析报表。

站在IT系统的角度看，报表生成的触发条件一般有以下几种方式： 

(1) 根据用户录入的查询条件(例如日期范围、部门等)生成报表。这种方式是最常用的一种方式，绝大部分报表都是这么生成的。

(2) 到了某时间点时，系统自动生成报表存储在数据库中。这种情况往往是因为需要统计、记录某时间点的实时状态(由于数据在不断变化，过了这个时间点就很难获得当时的状态)。

(3) 在空闲时间段发起运算，生成报表存储在数据库中。这往往是因为运算量太大，就利用系统空闲时间计算生成报表，提高运算效率。

(4) 当然，还有一些报表是混合型的，例如，某报表根据用户录入的查询条件生成，但其中有部分数据是系统在某时间段自动计算生成的。

分析当前使用的报表时，需要考虑如何将业务上的触发条件转换成信息系统的触发条件。对于IT系统而言，生成报表的触发方式与业务层面的触发方式是完全不同的。例如，“领导临时有要求”这种触发方式在业务层面相当普遍，但在系统中，根据报表需求，有可能是根据查询条件生成报表，有可能是时间点触发，有可能是空闲时间段生成； 对于那种日报、周报、月报之类的报表，首先想到需要在某时间点定时计算，但如果统计的信息不需要实时性，运算量也不大，宁可采用根据查询条件生成的方式，毕竟这种方式做起来最容易，开发成本最低。

2. 生成报表的数据来源

正如分析单据一样，也需要分析报表中各元素的数据来源，使用的方法也类似于单据分析，当然也有不同之处： 报表一般不需要过多考虑报表本身的流转过程，分析的重点应该在于生成报表的数据的来源。

3. 分析报表逻辑

仅仅分析报表的数据来源是远远不够的，还需要分析清楚大量的运算逻辑。有些报表逻辑简单，只是对一些数据的汇总显示罢了，有些报表逻辑却相当复杂。要理解报表逻辑，可以考虑以下这些方法： 

1) 使用常识判断

有些报表比较简单，通过一些基本常识就可以判断它的运算逻辑了。例如，报表中有字段“数量”“单价”“金额”，根据常识自然可以想到“金额＝数量×单价”这个公式。随着经验越来越丰富，所掌握的相关领域的知识越来越多，理解报表逻辑也会变得越来越容易。

2) 研习甲方文档

对于有些特别复杂的报表，甲方可能会有特定的文档进行阐述，如技术文档、管理文档、操作说明书等，需要认真收集这类文档，仔细学习。

当然，研习甲方的文档也需要留个心眼，很多甲方的管理要求都没有得到严格执行，有名无实的例子比比皆是。可以将文档中说明的算法当成入门工具，具体是不是真正如此执行，还需要更多的调研。

3) 听用户讲解

如果报表逻辑复杂，很可能需要甲方人员给你讲解。虽然甲方相关人员有义务给你讲清楚所有的运算逻辑，但要注意，一者甲方人员的讲解水平有限，二者你的理解能力有限，所以还是建议在要求甲方人员讲解前先预习一下。如果理解报表逻辑需要用到相关的专业知识，需要先花工夫学习了解。这个过程其实跟上学时听老师讲课类似，如果能够提前预习的话，就可以大大提高学习效率。

这里要特别提醒的是，听用户讲解这个过程相当重要，甲方人员可能理解你不是这个领域的行家，不了解这些逻辑理所应当，但如果他讲了很多次后，你还搞不清楚，他就会对你的能力产生怀疑，导致你在他心目中的地位逐渐下降，从而可能对后面的工作开展造成负面影响——失去威望对于实施者来说简直是一场灾难。

4) 研习电子表格公式

一般情况下，甲方会有两种介质的报表，一种是纸质报表，另一种是用电子表格(一般是Excel)做出来的电子报表。在收集报表时，如果拿到的纸质报表是从电子表格中打印出来的，那么要让甲方提供原始电子表格，因为其中很有可能嵌入了公式，这对于了解报表逻辑非常重要。比起听人讲解，直接看公式了解报表的生成方式要方便得多，也准确得多。

要分析好Excel中的运算逻辑，首先得熟练掌握这个工具，有些Excel高手设计出来的工作簿非常复杂，要分析清楚并不容易，这时候还是需要相关人员向你详细讲解这个Excel文件的设计思路与运算过程。

5.1.4亲自体验

实施者可以亲自到有关部门去顶岗，做一段时间的业务工作，在实践中了解这个岗位的工作。这种方法最大的优点就是能够比较深刻地理解业务。

事实上这种方法使用得比较少，主要原因是成本太大。从学会这项工作，到自己操作，到深刻理解其中的方方面面，可能需要很长时间。如果某些岗位的业务工作实在不容易理解，而对这些业务工作的数字化对项目成败有决定性影响，可以考虑使用这种方式。

使用这种方式熟悉业务，一般发生在甲方自己做项目的情况。由于甲方是自己做项目，项目组成员都是自己的员工，这时候，可以让项目组某些成员跑到业务部门去蹲点，边学边干，直到学会了业务工作，这时候自然而然就熟悉了业务。这么处理的主要原因在于： 一、因为甲方一般不大可能雇佣经验非常丰富的实施与需求分析高手，限于个人能力短期内很难掌握难度较大的业务知识，采用这种方式虽然耗时长，但确实能够解决问题； 二、由于项目组成员是甲方的雇员，长期服务于本单位，深刻理解业务有助于甲方在未来持续优化数字化管理体系； 三、甲方的项目组一般属于公司的服务部门，没有收入、利润之类的指标压力，多养几个人公司领导层也不会太在意，不像乙方那样需要严控成本。

5.2获得用户需求

熟悉了相关业务后，需要进一步了解用户需求，了解哪些业务需要进行数字化管理，需要如何管理，需要系统提供哪些功能，需要实现什么业务规则，等等。

5.2.1需求访谈

获得用户需求最直接的方式是需求访谈，也就是说跟用户进行面对面的谈话，听用户说出自己的要求，或者引导用户提出需求。访谈可以非常正式，提前约好访谈对象、访谈时间、访谈地点，准备好访谈话题与提纲等； 也可以非常随意，在电梯、餐桌、车上都可以进行一次偶遇访谈。访谈也未必都需要面对面，通过电话、QQ、微信、视频聊天等方式进行的沟通，都可以归入访谈的范畴。

1. 访谈对象确定

需求访谈首先要确定访谈对象，一般情况下，访谈对象为本系统相关岗位的主管人员，另外可以再包括1~2名业务熟练的职员。当然，特殊情况很多，关键看岗位的工作性质、人员的分工、人数的多少、本系统的特点等。例如： 

(1) 有些岗位，员工很少，访谈对象比较清晰。例如： 要做一次关于生产计划管理的访谈，全公司可能只有一位计划员； 要做一次关于成本核算的访谈，而全公司可能只有一个成本会计。

(2) 有些岗位，员工很多，但是工作流程简单，工作重复性强，对信息的要求不高，人员文化程度也不高。在这种情况下，就没有必要直接找基层人员，跟他们的主管谈就行。

(3) 有些岗位，虽然有个名义上的主管，但其实主管对工作内容并没有想象得那么熟悉，这时候找主管谈反而没有意义。例如，某部门的主管是某某副总，但他只管大方向，几乎不过问怎么具体工作，自然就没有必要跟他谈细节的需求。

(4) 有些系统，虽然涉及的岗位很多，但几乎都使用相同的功能，那么就不需要每个岗位都访谈一遍，只要访谈一些具有代表性的岗位就行了。例如，实施某OA系统，请假申请、办公用品领用等功能，几乎所有的岗位都会使用，就没有必要挨个访谈，跟分管部门中的某些主管人员谈就可以了，如党政办、行政部、人事部之类。

2. 访谈准备

在进行访谈之前，需要先对访谈对象的相关工作有个基本的了解，例如，可以通过前面介绍的问卷调查、分析单据等方式先了解基本的工作过程，切忌不做准备就随便跑到甲方找人访谈。遇到那种专业性比较强的岗位，人家谈到需求时，必然会涉及一大堆技术术语，如果对此一无所知，肯定无法交流，浪费时间不说，还容易降低威望，增加以后的实施难度。

对访谈对象的相关工作有了一定的了解后，最好能准备一个访谈提纲，列出自己想要了解的问题，在访谈之前发给访谈对象，好让对方有所准备。访谈时未必会完全根据这个提纲进行，但至少用它来引领访谈方向，也可以让访谈对象更容易跟得上你的思路。

如果实在不了解某项工作，很难准备访谈提纲，那么至少需要先准备一些可以打破僵局的突破点，可以要求对方介绍工作职责，介绍工作中需要获得哪些信息，跟哪些岗位有业务往来，对数字化管理有什么想法，希望如何通过IT系统处理事情，希望系统提供什么功能等。

3. 访谈预约

一次正式的访谈可能需要较长的时间，最好先预约，毕竟访谈对象有自己的业务工作，配合你做需求调研可能会搅乱他们的工作节奏。先预约后访谈，可以大幅减少对别人工作的干扰。

访谈时间的确定比较简单，一般都是征求访谈对象的意见，如果上班不是太忙，可以安排在上班时间，如果对方上班时很忙，那么只能安排在班后时间。

访谈地点的选择主要有两种方式，一是在访谈对象的工作现场，二是另外专门找个可以谈话的地方，如某某会议室或者项目部的办公场所等。

将访谈安排在访谈对象的工作场所有很多优点： 首先，可以让访谈对象心态比较放松； 其次，在自己熟悉的场合，看着自己的工作，不容易说漏说丢； 再者，对于你自己来说，由于在访谈对象的工作现场，结合现场的工作场景、物料、单据等，可以更容易理解他说的内容； 另外，可以让访谈对象更容易安排时间，有些人员的工作特殊，要他从工作现场跑开跟你谈话相当不容易； 最后，在工作现场，有些可能会发现访谈对象在描述过程中漏掉的一些异常业务。

当然，在访谈对象工作现场做访谈的缺点也是非常明显的，那就是他陪你谈话时不太容易做到专心致志。由于工作现场可能打扰他的因素很多，他有时不得不中断跟你的谈话。绝大部分访谈对象都认为他现在的工作比这种谈话重要得多，自然会优先处理其他事情，极端情况下，把你晾在那里几个小时都有可能。

实际工作中，可以考虑针对不同的岗位和不同的访谈内容，采用不同的方法。如果遇到要访谈的业务需要现场观摩，或者访谈对象工作太忙不容易抽开身，以及访谈内容比较简短不需要专心思考等情况，都可以考虑放到现场访谈； 对于那种需要耗费大量时间，需要访谈对象冷静思考、总结的访谈，建议约好时间专门找个地方谈话——要让他专心致志地配合你工作。

4. 访谈进行

开始访谈前，先要准备好纸笔用于记录。哪怕是一次极简单的访谈，也需要带上纸笔，一者用以记录，二者也是出于对访谈对象的一种尊重，这不仅是一种方法，也是一种态度。在访谈过程中，还需注意以下几点。

1) 少用录音设备

录音可能会吓住访谈对象，不容易畅所欲言。好多需求来源于访谈对象在访谈过程中的吐槽与抱怨，比如他觉得某某流程不合理，某某绩效方式不公平，某某管理规定没意义等。一旦他知道你在录音的话，心态就完全不一样了，谁愿意冒着让领导不快的危险在你面前傻乎乎地胡言乱语呢？另外，录音设备还会让人产生依赖心理，认为仗着录音可以回放，从而导致访谈时不能专心致志，等到访谈过后再去听录音，很浪费时间。如果觉得有些问题实在太过复杂，不通过录音回放就可能会遗漏重要的内容，那么一定要明确告知对方你在录音。不要偷偷摸摸，这是一种基本的职业道德。

2) 访谈要有线索

访谈时的问话一定要有条线索，如果一条线索不能涵盖你所有调研的内容就多准备几条线索，不要东一榔头西一棒槌，毫无章法。例如，去仓库做需求访谈，可以分成入库、出库、盘点、报表等几条线，具体到入库这条线，可以按照“采购计划的生成→下采购单→供应商送货→验收→入库→上货架→入账”这个顺序访谈下去。几条线问下来，基本上就涵盖了绝大部分内容了，最后再查漏补缺，询问没有涉及的内容。通过这种方式，不但可以让对方更容易思考，而且可以防止弄丢重要的需求。

3) 鼓励访谈对象多说话

有些访谈对象说话不容易收得住，谈论一个话题时可能会偏离主题很远，这时候请尽量保持耐心，在合适的时候把他的话头拉回来，不要随便打断他。

如果访谈对象跟你说的内容你原本知道甚至非常精通，也尽量不要使用“这个我知道”之类的言辞，这有可能会打击对方的信心。你没有必要通过这种方式树立形象，更没有必要让对方觉得他在浪费你的时间。要知道在访谈过程中，最难处理的事情不是对方扯得太远，而是对方的话太少，遇到极端案例，只回答是或否。要想办法引导，鼓励对方多开口说话，他并不那么清楚你知道什么，被你打击多了只能点头摇头了。当对方打开话匣子后，你可以得到许多有用的信息，也许会有意想不到的收获。

4) 适时给访谈对象灌输知识与观点

在访谈过程中，可以围绕访谈的内容，适时给访谈对象讲解一些跟本项目相关的IT知识，介绍你们的工作方式，提醒他们应该如何参与、配合项目实施，以减少未来的实施阻力。

访谈对象多少都会有些忐忑，因为不知道你们的系统会对他未来的工作有什么冲击，要尽量适时化解他的敌对或消极情绪。

还有些人可能对这个访谈莫名其妙，只是领导临时安排过来的，根本不知道访谈的目的是什么。你可以通过介绍未来要做的事情，让他的回答更有目的性，也更容易提出自己的需求。这个阶段，不怕对方提的需求多，就怕什么需求都没有。当然，介绍也要适可而止，当你发现说不清楚或者对方很难理解时，还是少说为妙，这毕竟不是访谈的重点，不要把一次精心准备的需求访谈搞成IT入门培训课。

5) 尽量避免谈论跟利益相关的话题

访谈过程中，应当尽量避免跟访谈对象谈论利益相关话题，除非你有把握让他觉得系统使用后对他确实很有好处，而且你有把握在当前阶段能将这种好处表达清楚，否则就不要过多解释为什么要使用新系统，而是把话题限制在如何实现上，“为什么”的问题已经在售前阶段说清楚了(否则甲方怎么会掏钱买系统呢)，现在要解决的是“如何做”的问题。

6) 及时指出跟上级有矛盾的需求

在访谈过程中，如果访谈对象提出的需求跟他的上级(或上级的上级)有矛盾，需要及时提醒。一般情况下访谈对象会放弃这种需求，或者愿意改变处理方式以跟上级保持一致，但如果访谈对象坚持他的需求，很有可能是因为上级不熟悉他的业务工作，访谈过后需要及时跟他的上级沟通，以确定最终的需求。

考虑到这个原因，访谈应该尽量按照由上到下的顺序进行，先访谈级别高的员工，然后访谈级别低的员工。

7) 一次访谈是不够的

如果不是非常简单的项目，一般来说，仅仅一次访谈是不可能把需求谈清楚的，可能需要进行多次。一次访谈获得相关的需求后，回来消化一下，再去访谈其他的有关岗位，对若干岗位的需求有了综合了解后，对这些需求的理解会有个升华，然后再进行下一轮访谈，谈更深入的问题。通过访谈获得用户的需求，是一个螺旋上升的过程。

5.2.2需求调研会

当需要讨论的问题牵涉的相关人员较多时，可以考虑组织需求调研会。相对于需求访谈，需求调研会参与的人员较多，需要花更多的时间做准备，对讨论过程的把握也更困难，因此本书并不推荐滥用这个方法。如果人员太多，或者准备得不够充分，对会议进程控制不好，很容易把事情搞砸，不但得不到需要的结果，还会把自己弄得威信扫地。

1. 发起会议

当出现了以下情况时，可以考虑召开需求调研会： 

(1) 工作需要协同，牵涉的岗位、人员太多，不在一起开会根本说不清楚需求； 

(2) 不同的人提出的需求相互矛盾，根本无法调和，只能开会谈判； 

(3) 时间急迫，交期紧迫，根本来不及一个一个地去调研； 

(4) 牵涉不同岗位、个人的利益，需要开会由领导拍板； 

(5) 经过调研后已经有了一些结论，需要集中宣讲，同时收集反馈意见。

发起调研会之前需要精心准备这次会议的主题，一次会议未必只讨论一个主题，但主题一定要明确。确定主题后，再确定参会人员。注意，参会人员越少越好。不要让会议室中一拨人在开会，另一拨人闲待着，看上去讨论的事情跟他们没有任何关系，除非某个级别够高的领导能够压住场子，否则调研会的效果应该不会好到哪里去。

另外，发起会议时需要考虑参会人员的工作安排情况。例如，你想把会议安排在上午9∶00，可是车间里可能正在交接班，相关人员很难这个时候来开会，即使来了，可能也因为刚刚上了一夜的班，眼皮都睁不开，只是点卯而已，根本也不可能把问题谈清楚。

2. 会议材料准备

开会之前需要认真准备会议材料，将这次会议需要讨论的问题界定清楚。不管是什么形式的材料，都应该提前发给与会人员，让所有人对会议有所准备。会议材料要有很强的针对性，最好能列出需要讨论的详细条目，例如，确定某跨部门的业务流程，解决某两个岗位的需求矛盾问题，等等。

另外，会议材料准备并不限于实施者，有时候也要求其他与会人员准备一些在会议中可能用得到的材料，例如，要求他们提前整理自己的概要需求，整理某项复杂业务的处理规则等。

一次需求调研会。

会议时间： 9月2日10∶00

会议地点： 三号楼205会议室

参会人员： 王总、黄超(采购部经理)、姜联海(原材料仓库管理员)、李涛(原材料仓库会计)、张家生(财务部经理)、钱天(质量部经理)、陈远向(成本经理)、钱汉林(甲方项目经理)、赵峰(乙方项目经理)

主持人： 赵峰

会议主题： 讨论原材料采购与入库的信息化流程。

讨论内容： 

1. 供应商的送货流程如何设计？需要采购部发通知吗？如何通知？这个通知需要同时发给仓库吗？如果没有这个通知，仓库拒绝收货吗？是针对所有的货物还是某种特殊货物？

2. 供应商如果送货送多了，仓库如何处理？需要发起什么审批流程吗？怎么审批？

3. 供应商送的货物是先入库再检测，还是先检测再入库？仓库要求先检测再入库，因为这样的话入库后可以立即打印带质量等级的标签，但检测部门要求先入库再检测，因为检测量太大，被供应商催着，很容易犯错误。

4. 如果检测不合格，仓库收货吗？如果已经收货了，是不是要退回去？这个流程怎么设计？

5. 采购部要求所有的材料都需要根据采购单入库，但仓库反映有许多零星材料并没有采购单，这种情况如何处理？

6. 财务要求仓库每月底报送纸质报表，但仓库反映报表都在系统中，财务可以自己直接查看、打印。

7. 供应商结账时需要提供什么凭证？什么时候打印？由谁签字？

8. 是不是可以将仓库的收货单与质检部的检验单合并到一张单据上？需要讨论一下格式以及设计使用的业务场景。

9. 财务需要对仓库的月末结存进行检查吗？怎么处理账实不符的情况？

10. 财务检查只是检查数量，还是需要对应到账面上的数量、库位、质量等级？

3. 会议过程控制

会议过程，跟一般开工作会议的要求差别不大，无非就是把握好中心思想，开会前有明确的目标，开会后得到明确的结论，鼓励不发言的多发言，把太离题的话题及时拉回来，支持讨论，不支持吵架，控制好开会时间，做好会议记录，等等。

4. 会议成果整理

开完会后，需要认真整理会议记录。会议记录类似于访谈结果的整理，不是简单的流水账，需要根据实施思路整理，如采用什么流程，打印什么单据，需要什么信息，需要什么软件功能，工作的业务场景等。仅仅如实记录每个人的发言是没有意义的。

然后，将整理好的会议记录发送到所有参会人员，听取他们的意见。也许有些人说的话你并没有理解对，也许有些人在会后对自己的发言感到后悔了，也许有些人在会上没有想起来但会后经过琢磨
又有了相当不错的想法，这些都要认真对待。根据收集到的意见，可以考虑进行一次单独的访谈，或是再召开一次需求调研会。

5.2.3单据中的需求

甲方相关领域在没有使用IT系统时，它的单据体系其实就是它的信息体系，填写单据的过程就是信息录入的过程，单据传递的过程就是信息流转的过程，最终单据被送进档案室就是信息被存放到数据库，只不过这个数据库很原始，查询、检索非常不方便。

将现在的单据体系跟用户所提的需求进行验证，很容易发现用户需求不完善的地方，毕竟用户谈需求只是针对自己的工作内容，很难进行系统化思考，甚至可能是支离破碎的。而甲方的单据体系才是真正系统化的，单据设计者在设计单据时一定对某个领域的管理体系进行了缜密的思考，这个毋庸置疑。

单据带来的需求，是甲方最基本的数字化管理需求，如果不能处理好，实施工作一定不会顺利。当然，这里并不是说数字化管理系统要完全根据原来的单据体系开发，而是想强调，在当前的单据体系中，蕴含着大量的数字化管理需求，这是实施者不能忽视的。

赵峰到仓库收集单据，其中有一张原材料验收单，包括品名、规格、单位、数量、单价、金额这些字段。他在查阅单据的时候，偶然发现在验收单的背面有人写了一些算式，心想这个公司的人也太散漫了，怎么随便拿单据给孩子做草稿纸用。但后来发现几乎每一张验收单的背面都有些算式，计算结果精确到小数点后四五位。

赵峰觉得非常奇怪，就去问仓库管理员。仓库管理员说，这是财务让他们算的，具体是干什么的她也说不清。赵峰又去找财务，才知道原来是财务要求对原材料采用移动加权平均的方式核算库存价值，这个计算出来的结果就是入库时的移动加权平均价格。赵峰觉得很庆幸，没有忽视这个重要的计算库存价值的需求。

5.2.4报表中的需求

甲方为什么要做IT项目？无非是为了改善管理。IT系统对领导来说，最有用的地方就是报表了。领导发起这个项目，领导决定验收是否通过，领导决定付款，不重视领导的需求是非常不明智的，因此一定要重视报表分析。

领导的需求有很大一部分可以从报表分析中获得。通过分析报表，可以深入理解管理脉络，弄清楚甲方管理者感兴趣的信息，可以站在管理者的角度看待IT系统，理解这个系统的目标，从而知道如何给各级管理者带来真正的价值。报表当然不是仅有的目标，但绝对是最重要的目标之一。

另外，通过对报表数据来源、计算规则进行刨根问底式的分析，可以获得大量的功能需求。任何一个看上去非常简单的报表，都有可能隐藏着很多功能需求。有时候，报表中一个字段非常不起眼，可一旦仔细分析下去，你可能会发现，为了这个字段，需要从若干地方采集数据，而从这些地方采集数据，又需要考虑如何将采集过程切合到业务的运行中。为了在业务运行过程中获得这个数据，需要有相应的软件功能支持，需要进行这样那样的流程重组，需要进行各种逻辑运算，等等。

赵峰在甲方实施一款人力资源管理系统。

在进行考勤功能调研的时候，甲方提供了一个现在正在使用的考勤报表，《员工考勤异常统计表》，用于统计每个部门上个月每个班次有多少员工迟到、早退、旷工。由部门的文员在月初的时候编制并报送到人力资源部。

赵峰搜集了几个部门上个月制作的报表，经过报表分析后，觉得有很多问题需要解决，而这些问题可能隐含着很多需求。

(1) 怎么定义员工的迟到、早退？

(2) 不同班次的员工，迟到、早退的规则是不是一样？是不是需要一个班次管理功能？

(3) 怎么知道员工属于哪个班次？怎么安排班次？由谁来安排班次？是不是需要一个排班的功能？

(4) 如何根据员工的打卡记录分析他是不是迟到、早退？他重复打卡了怎么办？是不是需要一个员工考勤分析功能？

(5) 外勤员工怎么办？卡坏了怎么办？忘记打卡了怎么办？是不是需要一个异常考勤处理功能？

5.3完善用户需求

经过一番艰苦卓绝的需求调研之后，理解了甲方相关领域的业务，搞清楚了相关员工的工作方式，明白了用户对这个项目的所思所想，然后获得了大量的用户需求。但这些需求往往是非常随意的，远远达不到研发团队的开发要求，所以还需要进行完善。

完善需求至少包括两方面的重要工作，一是将随意的要求结构化，二是将目标转化成需求。

5.3.1将随意的要求结构化

进行需求调研时，实施者需要跟甲方很多岗位的人员进行沟通，这些人基本上都是系统未来的用户，他们的知识水平、性格、职位、工作内容、工作能力各不相同，但一般都有一个相同之处： 永远都不会像实施者希望的那样描述需求。他们说起自己的要求时总是非常随意的，使用日常使用的自然语言，非常不严谨，容易有歧义，可以多种解读。实施者需要将用户的这种要求结构化，使之更精准，更接近开发要求。

赵峰在甲方成品仓库做需求调研，这次需要了解如何给客户发货。仓库管理员是如此描述的： 我们会根据销售合同整理当天的发货计划(发货计划中一般包括这周需要发货的所有销售合同)，跟客户确认是不是需要发货，客户一般都要求发货越快越好，但特殊情况下也会要求拖几天。确定要发货后，先到成品仓库核查产品库存。如果库存足够，就发货； 如果不够，就联系客户； 如果客户急的话，就先发一部分过去。发货前再跟客户确认好收货地址，因为有的时候，客户会要求将不同的货物送到不同的地方，虽然合同里写了收货地址，但这个地址经常会变化。

这个描述显然蕴含了大量的用户需求，但非常模糊、不精准，需要进行结构化处理。

经过进一步询问确认后，赵峰对相关需求做了结构化的描述： 

 根据销售合同生成发货计划单，一天生成一个发货计划单，生成规则： 交货期在今天以前或者在未来7天之内，尚未发货，并且对应商品物料有结存数量的合同。

 一个发货计划单可以包括多个销售合同，一个销售合同可以对应多个发货计划单，发货计划单与销售合同的关系是多对多的关系。

 销售合同支持分批发货，每一个合同的每一次发货，生成一个发货单，销售合同与发货单的关系是一对多的关系。

 一个发货单支持多地址发货。

 需要提供合同发货延期的功能。

5.3.2将目标转化成需求

对于实施者来说，非常希望用户按照这种方式提出需求： 我要什么功能，想处理什么数据，有什么业务规则，对界面有什么要求，等等。一句话，以研发为中心。但用户不是搞IT的，他们有他们的专业领域，他们只会以业务工作为中心。这就决定他们更关心自己的问题能不能解决，能不能达到某种理想状态，这是他们的目标。第2章讲采购需求时曾经讨论过类似的话题，这里不再赘述。

一些典型的不是需求的“需求”


(1) 我想知道我的下属每天都干了什么。

(2) 客户经常抱怨我们的售后服务，但我不知道我们哪里做错了，他们究竟在抱怨什么？

(3) 我想知道业务员的销售成绩跟绩效工资是不是有关联性，我应该给他们多少提成最合适？

(4) 经常发现仓库丢了东西，但查不到原因，甚至不知道究竟丢了多少。

(5) 车间在交班时乱糟糟的，需要持续太长时间，怎么才能让他们交班快点呢？

(6) 生产计划老是排不好，经常有些人很闲，有些人很忙。

(7) 员工平均薪酬高于同行水平，但离职率并不低。

(8) 一等品率明显低于同行平均水平。

(9) 我们要提高订单的准时交单率。

(10) 所有的工作都要用软件管起来。

在实际工作中，跟上述案例中类似的所谓的“需求”太多了。从严格意义上来讲，这些确实不能说是需求，只是用户抛出的管理问题，他们期待项目组能够解决这些问题。用了你的系统后，这些问题解决得越多，你的工作价值就越大，如果不能解决，往往说明这是个不成功的项目。

有了目标，接下来要思考的是，通过什么方法才能够帮助甲方实现这些目标呢？这个思考的过程就是将目标转化成需求的过程。有的时候可以引导用户思考，提出自己的方案，但大部分情况下，只能由实施者自己策划。

赵峰在甲方的原料仓库调研，分管仓库工作的副总说道： “我们发现仓库经常丢东西，但查不到原因，我们想知道怎么回事。”

这明显并不能算是个真正的需求，但是个非常有代表性的管理问题，甲方希望IT系统能够解决这个问题。

赵峰策划了这样一个方案： 将仓库所有的物品进行规范编码，所有的入库与出库都需要通过系统处理，保证系统能够实时正确地反映物料的流动状况，这样至少知道了仓库中“应该”有多少东西，盘点后如果丢了东西，完全可以责成仓库管理员负责赔偿，这样可以提高仓库管理员的责任心，自然可以大大减少再丢东西的可能性。

这意味着，一个区区几十个字描述的“目标”被转换成大量具体化的软件功能需求： 物料维护、入库、出库、盘点等。