浅谈业务系统的用户调研与需求分析.pdf

浅谈业务系统的用户调研与需求分析 前几天说了业务系统的产品设计，今天再来说说业务系统的用户调研与需求分析。业务系统 由于其复杂性，在用户调研过程中往往容易被需求方带到坑里，对业务系统而言，只讲表面 需求，对用户的表述奉行 拿来主义“ ”，都是在耍流氓。 1.用户调研与开发流程优化 业务系统由于其复杂性，往往都是根据需求方深度定制，这就要对需求方进行调研。而需求方的想 法往往天马行空、朝秦暮楚，若不能合理规划开发流程，则容易陷入每个阶段都在该需求的怪圈： 程序员焦头烂额、怨声载道，需求方天天催促，产品经理里外不是人。 理想的开发过程大致如下（包含但并不唯一）： 但是理想与现实往往是有差距的，很多同学在用户调研时没有占据主动，那么开发过程可能是这样 ： 1.1症结所在 总结之前的项目经验，造成后期频繁修改的原因主要有以下几个： 1.2对症下药 兵法有云：知己知彼，百战不殆。认识到了问题产生的原因，那么就要对症下药。要想在用户调研 过程中避免被用户带进坑里，就要从调研过程、需求分析、需求确认、内部沟通、需求变更、开发 过程把控六个方面入手。 调研过程 在调研时，用户所表述的需求未必是正确的需求（可能添加个人主观因素等），因此需要向尽可能 多的用户了解需求。 在了解需求过程中要引导用户对需求的表述方式：比如 A 工作怎么完成，为什么要这样完成，其中 的某个步骤是因为解决了什么实际业务的难点（痛点），而不是去听用户在滔滔不绝地讲他们怎么 开展工作（此处可参考故事 我想要一匹更快的马“ ”）。 绝大多数用户都不是专业的互联网人士，因此在调研和沟通时要占据主动，从专业角度给予用户引 导和建议，否则很容易被用户天马行空的思维带到沟里。 需求分析 需求分析对产品经理而言是大坑，需求调研与产品方案之间往往不是简单的因果关系。 这就要求产品经理在整理和分析需求时要深入思考，不要执着于表象，具体在下面的章节会说到。 需求确认 产出原型和 PRD 之后，就需要进入需求确认的环节。需求确认的意义非常重要。这是后期需求变更 或出现撕逼的有力证据。需求确认的常用打开方式一般是这样： ①向需求方讲解产品方案；并打印 书面的、含有原型截图的 PRD ；③ 由需求方签字确认，签字确认应包含签字日期。 需求确认旨在明确双方责任，并非借此保证需求一成不变。其作用是在需求出现变更时，明确因此 对整个项目带来影响的责任主体，以避免出现需求方主动提出变更，但对项目工期不满意的情形。 内部沟通 俗话说的好：沟通不误开发工。内部沟通是避免出现项目组成员对需求理解不一致的重要解决方式 。项目组内部往往包括产品经理、设计师、开发工程师、测试工程师等多种角色，若对需求的了解 不统一，则容易在相应环节出现偏差，影响项目的正常进行。 因此，需求确认、需求变更等状况发生时，需要与相关人员及时有效沟通，同时要求所有相关人员 在出现疑问时主动沟通而不是自我臆造，对于保证开发过程的顺利进行具有重要意义。 需求变更 需求变更在业务系统中是难以避免的，即使用户对原型及 PRD 进行了书面确认，但如果出现确认需 求的相关人员对实际需求了解不够，或者用户在表达需求时有所遗漏，甚至于在开发完成后需求方 修改了相关规章等情况，导致最终确实无法满足需求，那么修改仍然不可避免。 在需求变更时，需及时向各利益相关方告知需求变更事宜，并向需求变更提出方明确由此变更所带 来的影响，包括新需求完成的时间节点，由此新需求占用的人力和由此需求变动造成的其他相关模 块的变更，对既定开发计划的影响等。 开发过程监控 防范胜于救灾。对开发过程的监控旨在防止 BUG ，避免开发人员对需求理解出现偏差。应对开发进 度进行每日回报，形成明确的疑问反馈机制。 过程监控并不意味着产出的完美无缺，但摸索到最大程度减少问题的合作方式，对于提高效率和需 求方满意度是非常重要的。 在用户调研的过程中条条大路通罗马，能够将普遍性与团队、项目、需求的特殊性相结合，具体问 题具体分析，找到最优方案，就是成功的调研。 2. 需求分析 需求分析的难点在于用户表达出的需求未必是真正的需求，用户的表面需求往往隐藏着更深的本质 需求。但是需求分析是工作开展的第一步，若需求理解过程中出现偏差，那么再好的产品设计、再 好的原型，也是没有意义的。 写这一章其实是心怀忐忑的，作者和无数前辈大牛相比还