关于需求调研的心得

1、需求调研工作心得我因为第一次接触新项目，本着学习的态度参与到 XX 项目，两周的时间进行项目前期需求的调研和确认，联系之前作为产品人员的经验，在此期间总结了如下几点经验。1、尽量到交易中心各部门、各科室的办公现场去调研需求。在大多数情况下， 一说到需求调研， 客户方面就喜欢将相关人员请到会议室， 以座谈的方式进行沟通交流。 对于客户来说， 这种方式不会影响他们的日常办公， 而且显得更加重视这个项目。 但是，这种方式有个很明显的不足，这种会议一般都是临时召开，座谈对象事先准备得不充分的话， 就不能将他们的业务细节完整地描述给需求调研人员， 而需求调研人员也无法准确判断出客户所描述的是否有遗漏，

2、这样就导致调研的效果并没有达到最佳， 部分需求还是要反复再去琢磨考究。 另外， 这样的会议上一般会有客户方的领导参加， 会议过程中经常出现话题偏离或者是围绕一个话题反复讨论的情况，造成需求调研的效率很低。相反， 如果移步到办公现场去调研， 只要细心观察， 需求调研人员就会发现客户业务上的很多细节，并且很容易收集到各种原始表格、范本、标书等资料，如果正巧有实际业务在办理， 那就可以了解到更多实际业务细节。 如果没有看到客户的实际业务过程， 没有看到实际的业务表单、 范本、标书等资料， 单凭客户的描述是无法真正理解实际业务的， 会有许多细节了解不到， 特别是关于业务上各种异常情况的处理。 未来可能

3、正好因为这些异常情况的处理细节， 可能导致整个系统架构要推倒重来。 之前做太原网上业务交易系统关于招标文件审核的需求调研工作就出现过这个问题， 第一次去只是跟业务科聊了一下大概的需求， 了解了大概情况， 回来就做了整个招标文件审核的新需求， 在第一版系统进行演示的时候， 对方业务人员又没有到场确认， 结果系统上线后对方发现这版系统仅能处理正常顺利招标的文件审核业务， 对一些异常情况下的招标文件审核却无法按现有系统需求处理， 最终导致的后果就是，我们推倒之前的所有需求， “逼”着开发人员重新开发了招标文件审核的功能。所以， 每一个需求都要参与到实际业务中去认真观察， 拿到第一手的完整资料， 反复

4、与相关业务人员确认，这样的需求才是真正完整、成功的需求。当然，如果对方业务上有与电子化交易冲突需进行调整的，而对方业务人员无法做主，需要对方领导进行拍板决定的需求项， 则一定要在充分考虑并整理出相关需求结果后， 联系对方领导召集相关业务参与人员组织会议， 就业务调整后可能出现的问题进行讨论并确定最终处理方式。2、收集完整的所有业务表单、招标范本、投标文件、评标报表、业务流程、规章制度等资料，以及相应的电子版资料。大多数情况下， 我们的需求调研人员去找相关业务人员调研需求， 这些业务人员也只描述了大概的情况，基本都是正常情况下的业务处理过程， 对于细节、异常情况的处理， 客户不可能面面俱到地讲给

5、我们听。此时，就要靠我们自己去分析、去理解、去询问。除非我们本来就很熟悉客户的业务， 否则， 我们必须仔细分析客户的业务表单、 招标范本、 投标文件、评标报表、 业务流程、规章制度，要学会分析哪些是有效的资料， 哪些资料与我们的需求无关，然后通过有效的资料搞明白每种业务的细节， 不明白就去问业务人员， 几经交流， 就可以完全明白业务的真实情况。3、调研过程中，必须对照事先写的调研提纲，务必将提纲中所列事项全部搞清楚需求调研工作必须有计划、有步骤地进行，以防止调研的盲目性。 一般说来，调研前需根据自己的经验和对当地交易中心整体业务的了解， 列出调研提纲。 这样， 可以条理清晰的开始需求调研工作，

6、 而且不会因反复找业务人员确认需求而影响客户的正常工作。 根据调研提纲进行细化， 可以防止在某个环节的需求调研上存在遗漏， 任何遗漏都可能造成已完成的需求被推翻重做。4、要学会写调研记录（或笔记） ，根据完整的记录来整理需求才不会有遗漏。在需求调研过程中， 笔记本和笔是必备用品， 好记性不如烂笔头。 尤其是在要确认的问题很多的时候，你能记住一两个，却肯定记不住全部（多年经验告诉我脑子再好也记住） 。而且，需求调研时客户往往说的很快，不可能等我们全部记录之后，再讲下一个问题。因此，只能在笔记本上速记，有时只能记录两三个关键字。因此，每天调研结束之后，当天回去后必须整理当天的调研情况，完善每一条调

7、研结果及需求实现方式，否则，过几天 （以我的经验， 一般第二天就记不清了） 之后就会记不清了。 在整理当天的调研记录时，还要整理出待明确的问题，下一次再找机会与客户再沟通、确认。4、调研之后，尽量马上制作原型（系统实现模型） 。任何文字描述、 语言描述，都无法给人一个准确的感性认识。 由于理解上的偏差， 客户以为完全清楚地表达了他的想法， 他以为我们也完全了解了， 但事实上我们有可能理解成另外一种场景了，与客户的想法可能有较大出入。因此在调研结束后， 需要立即做一个初步的粗原型出来， 把我们所理解的直观地表达出来给客户看，有偏差马上修改。 这种方法可能会导致调研工作时间比较长， 但是， 相比后

8、期才发现问题、再来修改，是非常值得的。当然，这个原型在最终提交需求文档的时候，还是 需要进行完善和细化的，因为开发人员一般都是根据原型来研发满足客户需求的系统的。5、建议项目组全体成员相互沟通、每个人都要了解全局。大多数情况下一个项目由多个系统构成， 每个系统之间肯定会有联系。 有些时候， 各系统互为输入输出， 比如公共资源交易系统发布的招标公告， 需要发布到公共服务平台。 此时，在设计公共资源服务平台时， 就必须考虑全局的需要， 包括数据接口以及业务流程， 都要考虑全局。 再比如编制系统的范本， 很多内容涉及到了交易系统和公共服务平台的网上业务操作， 例如招标文件要从哪里获取、 投标文件如何

9、递交， 这些也要两个系统的需求设计时提前沟通好，否则对于任何一个系统都是严重影响业务的 BUG。试想一下， 需求人员只了解自己负责的系统， 而不清楚其他系统与自己做的系统有何联系，那不就是“盲人摸象” ，最终做出的几个系统再去对接起来是十分困难的，严重的话，整个需求还可能要推翻重做。 所以， 在整个项目中确定各个系统的每一个功能需求时， 各个负责人员都要进行必要的沟通， 了解全局系统的需求， 在最终实现需求的时候， 各系统各模块之间才能完成有效的衔接。当然， 有些项目， 各个子系统之间的联系不是太紧密， 比如编制系统和专家抽取系统就没有多大的联系，此时， 也不必强求每个项目组成员都了解全局。

10、但是，至少项目经理必须要了解全局，这样才能保证技术方面、进度方面、质量方面不会出现意外。关于需求调研，按我的经验， 认真做好以上5 点， 基本上就可以做得比较好了， 当然这是我个人的经验， 多和其他需求调研人员沟通学习， 才能不断完善自己， 成为一个合格的需求调研人员，或者说是项目人员。因为需求调研是一个项目的开头，如果头开的好，让客户认为我们很专业、很认真，后面的事情就会好办很多。最后， 分享一下从其他同事那里学到的几点与客户沟通需求的技巧， 都是做需求和实施的前辈们教给我的：1、做为一个实施人员，不仅需要聆听客户的需求说明，还要懂得在客户已说明的基础上进行拓展， 发掘客户没有讲出来的潜在需

11、求。 在已有业务的基础上进行模拟业务流程， 分析业务是否走的通并且有无逻辑上不合理的地方。2、找最合适的人谈需求。很多时候，需求做的差，很大的原因是没有找到正确的人。由于我们公司做的项目基本都属于是政府项目， 合作单位都是公共资源交易中心或者招标投标管理办公室等事业单位。 政府很多项目都是领导牵头的， 但实际了解真实业务的却是下面的工作人员，我们的系统也是这些工作人员用。如果找领导谈需求，听其高谈阔论半天，做出来的东西，下面的人肯定不满意， 业务上也可能与实际有出入。 谁用这个系统找谁谈，这个是关键，开始就要定位好。3、不要跟客户谈技术。技术没有高不高级，只有合不合适。客户对你使用什么技术实现

12、，不大感兴趣的，而是对系统的业务条理、页面的美观大方、开发速度、系统安全性、稳定性、易用性等关心较多。尤其是业务是否正确，业务不对，其他都一文不值。此外，客户对操作体验也很重视， 点一个按钮能做到的千万别让他得点两下， 这点在设计上要充分考虑。关于页面的美观，也要问清楚的，同样单位的工作人员， 有些喜欢简单大方、有些就喜欢花哨靓丽。至于安全性、稳定性、响应速度之类的，客户在需求阶段倒是不太关注。4、要引导客户走向有利于自己公司的轨道上。客户的一些需求，有些对整个业务其实是可有可无的， 如果不麻烦，那最好了， 如果在实现起来很麻烦的话， 要有技巧的引导客户放弃这个需求， 免得开发员开发起来麻烦， 自己还可能被开发训。 还有就是我们公司做了这么多地方的项目