中华楹联博物馆项目需求分析心得

Posted 2020-12-01 lx0411

                                   　　　　　　　　　　　　　　　　　　　　　　　　中华楹联博物馆项目需求分析心得

引言

　　首先，最重要的一个问题就是，为什么要做需求分析，或者说需求分析的意义是什么？每个人对这个问题可能都会有不同的体会。我的看法是，需求分析的意义在于准确无歧义地表达项目需要交付的产品，并且获得甲方的认可，从而为整个项目建立一个基本标准。软件的特性之一就是变化，指望需求不变化是几乎不可能的，不管是开发者还是需求方都有可能随着项目的进展提出变更的需求，所以需求分析（及变更管理）的目标不是定义一个不会再改变的需求，而是从开发开始到项目结束，双方对于需求（包括变更后的）的认知都是一致的。

　　举个例子，前期根据指导老师的描述，我们打算做一个类似百度贴吧的论坛，我们设计好了数据库，做好了项目原型，然而跟甲方面对面沟通之后，甲方觉得论坛不方便管理不想做这个论坛，而是提出做出视频中心、文化中心之类的模块，于是我们又需要对需求、数据库等进行更改，类似的例子还有很多，估计以后在实际工作中也会遇到很多类似的需求更改。

通过此次对中华楹联项目的需求分析，对于需求分析中关键的因素，我自己的体会主要有如下三点：

一、深刻理解业务

　　需求分析人员需要对用户的业务有非常深刻的理解。所谓非常深刻的理解，就是说你能和用户的管理层就他们的业务问题谈笑风生。如果做金融产品不懂风险管控，做论坛不懂SEO，做电力监测系统不懂电压变化，做中华楹联不了解基本楹联知识，如何能对业务有深刻的理解呢？

　　在做项目之前觉得，用户给我讲明白需要做什么功能就行了，我对他的行业了解那么深有什么必要呢？我想说的是，做需求分析也是分很多层次的，层次越高，需要对业务的理解越深。

　　在对中华楹联博物馆项目需求分析的过程中，我们需要对楹联进行分类、这里就需要确定分类标准，于是去查询学习了楹联的相关知识，了解到根据用途分，可以分为贺联、挽联等，而贺联又可以分为结婚、嫁女、乔迁等，根据创作技巧又可以分为拆字联、回文联等，每个楹联可能属于多个分类，又比如在确定学习模块的需求时，我们需要了解楹联学习内容，于是查询各种资料，查找楹联知识，学习到楹联的基本对仗规则、音律平仄、创作技巧、常用的修辞手法等，以便对于学习模块的细化，需求分析完之后感觉自己都快成带诗人了。

二、和用户进行充分沟通

　　首先要搞清楚你有哪些用户，他们之间的关系是怎样的。有句老话叫众口难调，用户之间的观点也会有冲突。比如高管希望采集的数据越多越好，现在用不上将来可能弄个数据挖掘工具就突然有奇效了也说不定；负责采集数据的一线用户当然希望数据越少越好，只要自己够用就行了。有些业务部门不希望自己的业务数据被太多人知道，有些项目甚至会让一些部门失去权力，一些领导丢掉职位。所以在一个项目里，需求讨论会上往往会有各种各样的声音。声音后面是立场，立场后面是利益。缺乏经验的需求分析人员很容易迷失在这些声音里，最后做出来的需求成了四不像，而这正是某些用户希望看到的结果。

　　这时候怎么办呢？我看到过最好的处理方式是：找用户最大的领导讨论项目的整体思路，然后按大领导的意见把用户需求筛选一遍，凡是和大领导思路明显冲突的一律扔到一边，把符合大领导思路的那些需求充分细化。啥叫大领导？不是什么IT部经理、信息处处长、客户项目经理之类的，而是能拍板决定和这个项目相关的业务问题的人，比如做人事系统，大领导至少是人力总监，做财务系统至少是财务总监，当然能再往上让一把手积极参与进来就更好了。和大领导讨论的过程，既是了解大领导思路的过程，也是筛选需求的过程，更重要的是，获取大领导支持的过程。有了大领导的支持，再开会的时候，底下吵吵嚷嚷，你也能气定神闲，胸有成竹。

　　在中华楹联项目中，因为楹联协会会长时间问题，我们前期主要是和指导老师在沟通需求，老师传递协会的需求，然后我们根据自己对楹联的了解，做出了需求分析1.0版，并在此基础上制作了项目原型、设计了数据库，之后老师终于约到了楹联协会会长来和我们当面沟通需求，发现会长提出的需求和我们的需求1.0版本有很大的差异，于是在会上进行各种协调，最终确定了需求，然后我们的项目原型、数据库设计也要相应的更改。工作量瞬间翻倍。

　　通过上面的教训总结，需求的分析以及确定，一定要和用户方有说话权的人进行充分有效的沟通。

三、具备深厚的技术背景和严谨的思维

　　需求分析是业务和技术之间的桥梁，需求文档是一种对用户的承诺。在写需求文档的时候，就需要需求分析人员有相当的技术背景，了解每个需求对应的实现途径、难度、和大致工作量，并且能够把它以一种业务和技术人员都能无歧义理解的严谨表达方式进行描述。有时候一个人可能考虑不全面，最后和小组成员商量一下。当然，这些是建立在前面与用户（包括技术人员）充分沟通的基础之上的。

　　写文档的时候一定要严谨，有时候一句话、一个字都需要反复推敲，一不小心就有可能给自己挖坑，有点做律师的感觉，要让业务和技术都看明白的确不容易，这里我们小组采用的方式是多画图，一张图有时候能抵几千字。什么流程图啊、数据流图啊、组织结构图啊、用户界面示意图啊什么的，能画图的地方就多画图，图加上文字，读者的理解就不容易跑偏。

　　最后，需求文档写完了，打印出来，核心用户一人给一本，告知几天内可以提出一次修改意见，只修改一次就会形成初始需求的定稿，以后再改要走变更控制流程。再印几本存档的，最后多一页签字确认页，让所有收到需求文档的用户最后都要签字确认，最后再给甲方签字。有签字确认的存档就可以作为将来需求变更的依据了。在创新课程中，我们小组当然是以指导老师意见为准。