作者：杨长春
由衷佩的服能把日常工作总结提炼书写成一本书。中国乃至全世界工薪阶层规模之庞大，在其岗位日复一日年复一年的劳作，能把自己工作岗位上所做所想总结提炼书写出来的少之又少，凤毛麟角。为什么呢？其一可能工作内容过于机械化，属于重复劳动，做一辈子跟做一段时间，区别不大，按步骤1、2、3即可以完成；其二可能工作内容灵活性大，按现有经验可以做，但是没有体会到做得更好的要领，为了做而做，没有思考，没有学习，知其然不知其所以然。其三没有写书的需求，缺少动机，或是受文档能力限制想出书，心中千言万语，落到纸上不知从何说起。毕竟站在金字塔尖上的人少啊。一本书的落成，在每个方面都需要深入细节，带有自己的思考，哪怕是在站在前人的肩膀上思考。就拿自己来说，项目管理、需求分析、产品、售前岗位都有涉足，但是讲真真的提炼不出这么多信息，做的过程凭以往工作中学习同事的方式方法、公司的流程、领导的指导，加之百度或谷歌搜索下，基于零散学习，没有系统学习，所以缺少完整的知识体系（PMP除外），认识上没有跟上，更谈不上出书论著了。
需求分析需要具备哪些能力？大致分6方面，一行业知识，二技术知识，三调研方法，四沟通技能，五项目管理，六文档编写
行业知识
浅而易懂，比如政府行业、金融行业、电力行业，需要了解行业的业务、业务管理方式、组织管理模式这样在需求调研分析过程能跟用户保持在同一个频道，避免客户说的一些术语台词，听了一脸懵逼，还要客户解释，这样影响在客户心目中高高在上的专家形象，不利于需求把控，工作开展。或者需求人员满嘴专业技术术语，客户听不明白，把客户整懵圈了，感觉是鸡同鸭讲，对牛弹琴，后果是客户给不出真实信息，需求有效性大打折扣。怎样提升行业知识？老人靠积累，新人靠学习。老人在一个行业里面呆久了，经过日积月累自然而然的形成了丰富的行业知识。新人可以通过网上搜索行业信息，发展蓝图、白皮书等进行学习，还可以向有经验的同事或客户请教学习，并在实践中不断总结提升。三人行必有我师，不懂就学习，不打无准备的仗。
技术知识
软件工程、开发语言、数据库、架构等等，无需太深入研究，能用就行，重要的是与时俱进学习新的技术潮流。
调研方法
观察法，通过观察用户日常办公过程，这种涉及体力劳动有显现的步骤有效，对于脑力活动没有显示出来效果不理想。业务体验，扮演用户实际办公，需要客户方有人带并且周期长，成本高，非特殊情况不建议使用。问卷调研，设计一套问卷，请相关岗位人员进行回答，需要对业务有一定了解，否则也问不出个所以然。面谈法，需求人员和用户进行一对一的面谈，在一定的框架内，可以引导用户最大化挖掘真实需求。焦点会议，聚集相关人员通过会议方式展开交流讨论。原型法，根据原型交互体验，用户提出针对性需求，不会泛泛而谈，同时具有一定的引导性。
沟通技巧
可控双向信息交换，达到沟通目的同时，确保沟通过程使对方保持愉悦感，使对方敞开心扉，畅所欲言，卸下防御外壳。这个需要多学习沟通技巧、心理学知识、仪表仪态，平时注重锻炼，在日常工作生活中不断完善提升。
项目管理
需求分析服务于项目，因此需要懂一定的项目管理，对项目时间、成本、范围、质量要心中有数。要甄别出异性天开需求，在技术上根本实现不了，或是不属于本项目范围需求。在技术对需求变更流程的理解和落实，需求实现进度把控，并能应用到实际项目中。
文档编写
涉及需求的文档需要需求人员进行整理编写，文档质量直接影响下一个环节工作，作为项目的前期输入文档，对项目成败起举足轻重作用。常见文档有《用户需求说明书》、《需求分析报告》、《需求规格说明书》，按公司或项目特有文档模板编写，根据实际项目环境进行剪裁，不求全，适用项目就好。一些项目可能还涉及招投标书的编写。
什么是需求分析？需求分析要做些什么事情呢？需求分析目的是为了确定软件系统要实现功能。软件系统可以理解为一组输入数据经过后端处理再输出到界面。输入一般是人机交互，通过可视化界面进行信息输入，后端处理包括业务逻辑和数据库操作，输出到页面界面展示。那么需求分析也就是围绕这3大块内容进行展开。要实现什么功能？功能输入，业务逻辑，产生哪些数据需要存储，最后展示出来什么效果。每一项再往详的分，每个阶段采用相应的技术和工具。
功能页面
系统页面是人和系统沟通的桥梁，功能页面一般强调易学、易用、健壮性、交互性。 易学指的是根据使用者的电脑操作习惯，无需专业培训或是文档查阅，所想即所得能把业务操作下去，因此需要了解使用者的电脑操作习惯，了解每个人的操作习惯是不现实，一般了解此行业主流系统采用哪种风格，或是大众软件的操作习惯。比如微信等，当然微信带有自传播性，软文教育宣传或是身边前朋好友手把手教与。 易用性是指使用起来很方便，考虑功能的连贯性，页面布局合理，鼠标移动间距断、键盘回车等。健壮性是指系统对容错的处理，事情避免出错、出错后可回复、出差后影响少，比如查询时间进行开始和截至的判断，手机号码进行位数判断等，输入前处处为用户考虑，如果真的出差可以通过反业务处理。不要让用户在使用系统时候战战兢兢，如履薄冰。交互性是指再一些关键操作给出提示比如删除给出确认提示，一些不符合业务规则的操作，在用户的角度给出友善明意的提示，不要适用技术语音。比如说文件导入方式录数据，提示XX行业，数据错误插入失败。这个对问题解决，起不来多大的帮忙，无非是指着你录入的数据有问题，是要诛心吗？正确的做法是提示具体什么问题，正确的应该怎样。以便用户采取纠正措施。
页面的布局，信息录入页面常见的布局有全屏录入、分类录入、tab页、或是这三种信息录入方式组合，一般录入信息是7-10项。查询页面一般分为上页面查询条件区域，下页面结果展示，查询结果行详情按钮链接到详情页面；左边查询区域，左边结果展示；上页面查询条件区域，中间结果展示，下面区域详情展示。
业务逻辑
涉及多个维度的探讨，业务权限、功能灵活性；业务权限包括菜单权限、功能点权限、数据权限；功能点权限是指同一个功能页面权限高的使用者可以看到某个功能点，比如账单管理功能包含了账单查询和账单调整两个功能点，一般使用者无账单调整权限，但是主管角色可以使用。数据权限，比如主管可以看全组信息，一般使用者只可以看自己的信息。功能灵活性，常见方法有代码写死、数据字典控制、循环判断、开关控制、工作流程引擎配置。代码写死，比如说if x=隔壁老王，就要小心防火防盗防隔壁老王。但是如果住的是老宋，也要提防啊。数字字典控制，就是理解为if x=man,man可以是老王，也可以是老宋，看邻居而定。循环判断，有X个步骤，实际情况可能为了赶工期或开发人员偷工减料只判断前面一步或是几个步骤，正常情况是X步都要判断，这样实现成本可能会高一些。开关控制，就是一个业务可能这样，也可能那样，这种情况建议启用开关控制，把选择权交给使用者。工作流程引擎，对于哪些可以固化的工作流程，系统流程可以固化，对于经常变的流程可以采用工作流程引擎方式，支持流程可自定义。关于功能灵活性，需要综合考虑项目实际情况，结合项目工期、成本进行符合项目当前情景选择，也要考虑不给后续的项目运营带来更多的运维成本。
业务梳理完以后需要画业务流程图以体现业务逻辑，以业务流程图为输出，流程开始到结束，流程涉及哪些岗位，中间有哪些分支。
系统功能流程图，分解系统所有功能，并勾勒功能之间的访问关系。以对系统全局功能有个概览了解。方便设计系统功能模板以及菜单布局。
数据库分析
以实体关系图ER开始，来源于企业表格、单据，建议是拿实际填写的单据，这样反馈实际情况并能展示一些说明备注，还能根据填写内容理解表头。实体一般包括实体名、属性、key就可以，ER图分为1对1，1对多，多对多关系。跟进ER图设计数据库时，需要考虑数据库设计范式，第一范式时保持字段原始性，理解为一个字段要给用途，不能拆开当作多种用途，比如编号前面两位字母代表地市，有的需要取地市的就根据前面两位代码来取，这是违反第一范式的。第二范式必须要有依赖关键字，比如员工信息，员工编号作为关键字。第三范式关键字不能作为令一个关键字依赖关系，比如员工和部门关系，员工所在部分这个信息，可以单独新建一张员工关系表，而不是在员工表中新增一个部门字段。BCNF范式，最小数据冗余，这是对前面范式的补充说明，就是删除一个数据，删除一处就可以，不用每处都删除。如果需要用到数据冗余，第一需要思考一定需要冗余嘛，这样做有什么理由。
数据流图
此图网上借用链接 ttps://blog.csdn.net/qq_38230811/article/details/80798538）
需求变更
需求变更内容一般划分为页面、业务逻辑、数据存储字段、历史数据。页面变更如不涉及系统框架的改变，相对来讲一般影响比较小，改下页面字段位置名称或是增加显示列等。业务逻辑变更，依据实际情况了，看是否伤筋动骨了，极端情况是推倒重来。数据库的字段，一般新增影响不大，可能业务可能多处要进行相应调整。历史数据调整，一般需要数据割接，技术难道不是太难，但是风险高，影响系统正常使用。
产生需求变更原因多种多样，有早期需求人员能力或责任心问题没有获取到客户真实需求；有客户业务真的发生了变化；有客户想法变化了；有前期需求方向本身就是有问题，中间发现了问题进行纠正；无论是哪一类问题，都需要积极心态正视而不能消极选择忽略视而不见。对于需求变更，我们强调以开放的心态拥抱，平常心对待，并不断的宣贯项目需求变更是避免不了，已司空见惯，以安慰自己，从而逃避一定责任。为了需求变更在受控状态，需要在需求变更前，需求变更过程中，需求变更后3个环节进行严格把控。需求变更前，在需求调研环节一定要尽心尽力，死而后已，不把需求调研当作走过场，轻视用户，感觉用户提不出什么好的需求，按自己多年XX的经验，实现这套够你们用了。一定要放空自己，多引导客户讲，自己少讲，用心聆听，以获取真实需求。在需求变更过程中，对于变更需求的内容，需要和用户谈判，在项目时间成本范围质量有限的条件下，给用户做选择，需要挑选重要的优先实现。哪些是必须的，哪些是应该有的，哪些是可以有的，哪些是可以不要的。不能一味的迎合客户的需求，也不能拒绝所有的变更需求，乙方的项目目标在满足时间、成本、范围、质量条件下是解决客户实际工作中问题。甲方的项目目标还有收益、风险。如果不变更他的收益实现不了，或最后会存在负收益。可能还会导致发生其他的风险，比如影响他的职务高升。那么这个项目存在的意义就要再评估，最后乙方项目经理估计也没有好果子吃，通过高层关系施加压力，各种挖坑陷阱，项目最后能否通过验收，拿到项目款项都是一个未知数。所以拒绝所有的需求变更，不明智，不可取，可能会迎来狂风暴雨般的报复。个人承受不了，公司也承受不了，此乃下下策。
需求变更后，在需求实现上充分考虑需求动态性和可预见性，今天这么想，明天会不会改变想法，A分公司是这样的，B公司是不是另外一个样。在了解客户真实需求基础上，功能需要保持一定的前瞻性，比如客户提了一个客户等级评级需求，年度消费100万及以上归类为VIP客户，50万-100万归类为大客户，30万-50万为合作伙伴，30万一些为一般客户；略加思索，会考虑到市场在变，规则可能也会变，今天100万是VIP客户市场景气，明年可能就是80万就成为VIP客户，因此这个需要在数据库字典进行设计，代码上不用写死if custom>=100万。
需求变更提升客户的黏度，需求变更在不同项目环境需要控制在一个相对平衡的度，不能多，也不能太少，太少或者没有说明客户没有使用系统或者对业务没有新的发展，对系统的依赖没有那么大，这是需要敲响警钟，系统是否还有生存的意义。太多可能是系统没有规划好，随着客户视野开阔，见识更好的业务厂家，随时会抛弃你。因此原则是变更不是系统规划不当，而导致经常变更。应该是客户业务发展的变化而引起变更，才是更有意义的。
原型说明
从几方面进行阐述，目录划分粒度，统一需求，共有规则、注意事项、需求描述、数据表单
目录划分粒度划分：建议到6级，超出这个级别的建议用分段方式，一般喜欢最多到5级。
统一需求.数据库：插入数据库写创建人，创建时间，备注说明。修改数据库写更新人，更新时间。
统一需求.业务判断：开始时间小于截至时间。日期是日期格式。页面结果加载条数
共有规则：手机号码11位验证，邮箱验证，身份证验证，生日大于1990
注意事项：通用明了的不用写，比如上一页，下一页，重置
需求描述：重要功能进行引用，查询条件进行模糊和精准查询说明表示，加载页面说明。主页面场景（主流程判断分支=是），扩展业务场景（分支流程，判断分支=否）、前置条件（进入此流程需要前面做什么操作，比如会员卡充值，得线会员登陆）、后置条件（触发后会有什么变现，比如银行卡取钱后，显示余额还有多少）
表单描述：描述数据库表、表字段、取值范围、数据来源、特殊说明、案例
规则描述：需要遵守规则，比如批量数据导入条数需<=1000条。
报表需求，如果说在功能实现之后再进行调研，可能会铸成大错，留下隐患。没有上系统之前，各个岗位会存在一些手工统计数据，这些也需当作前期需求进行调研。报表涉及数据取数来源、数据计算公式、列表展示、统计周期、统计条件，数据取数来源可验证功能设计是否有遗漏，是否考虑周全，在调研没有提到的需求，在报表体现出来了，需要扩展进行补充调研。一个系统设计合理性，报表是一个很好的尺子。
未完待续。。。
网友评论