企业培训_需求调研及管理教材

信息安全事业部产品管理部 需求调研及管理 内容提要 需求开发面临的困境 需求管理过程的输出产物 如何管理需求 如何调研和采集需求 什么是需求 客户需求与开发人员之间的矛盾 客户 用户的抱怨 开发人员的抱怨 操作层客户满意度持续低迷需求总是不能完全满足开发进度总是太慢使用 问题 总是太多对业务的支撑总是不能有效和及时开发效率总是在一个低水平没有提高 需求总是在不断的变化和追加总是在为实现 边角功能 而消耗太大代价我们天天都在加班 却永远都无法完成用户提出的需求和 问题 客户突发性的事件和需求总是打乱了原来的计划客户需求的计划性太差 客户需求与开发人员之间的矛盾 项目经理听说要个秋千 调研完成后主观思考应该是加根板子或绳子 客户需求与开发人员之间的矛盾 公司拿到需求后难以理解3根绳和板子的原理 擅自改为两根绳子和一个板子 由于秋千的作用描述不准确 设计后变成横向拉力设备 研发人员开发后秋千架错地方不能摇 客户需求与开发人员之间的矛盾 现场安装为了解决bug 部署时打通树干 其实客户要的结实的秋千是轮胎绑个绳就够了 需求分析过程的改进是开发效率提高的起点 软件项目实施周期的正确方向 项目启动 需求分析 设计 开发 测试 部署上线 运营维护 需求分析 设计 开发 测试 部署上线 运营维护 软件项目实施因需求分析误差导致的偏移 失之毫厘 缪以千里 内容提要 需求开发面临的困境 需求管理过程的输出产物 如何管理需求 如何调研和采集需求 什么是需求 什么是需求 什么是需求 通过与用户交流 了解用户需要什么 通过分析用户需要的特征 总结成软件需求 并没有一个清晰 毫无二义性的 需求 术语存在 真正的 需求 实际上在人们的脑海中 任何文档形式的需求仅是一个模型 一种叙述 需求三要素 呈现方式 Why 为什么需要这个需求及需求的基本要求如何 需求概貌 How 用户是如何使用这个需求的 发生的场景如何 这是需求的核心内容 What 此需求实现后的最终表现方式是什么样的 这是需求关键内容 业务场景 需求概述 内容提要 需求开发面临的困境 需求管理过程的输出产物 如何管理需求 如何调研和采集需求 什么是需求 从一则笑话看需求调研的精神 某日 老师在课堂上想考考学生们的智商 就问一个男孩 树上有十鸟 开枪打死一只 树上还剩几只 男孩反问 是无声枪么 不是 枪声有多大 80 100分贝 那就是说会震的耳朵疼 是 在这个城市里打鸟犯不犯法 不犯 您确定那只鸟真的被打死啦 确定 老师已经不耐烦了 拜托 你告诉我还剩几只就行了 OK OK 鸟里有没有聋子 没有 有没有关在笼子里的 没有 边上还有没有其他的树 树上还有没有其他鸟 没有 方圆十里呢 就这么一棵树 有没有残疾或饿的飞不动的鸟 没有 都身体倍棒 从一则笑话看需求调研的精神 算不算怀孕肚子里的小鸟 都是公的 都不可能怀孕 决不可能 打鸟的人眼里有没有花 保证是十只 没有花 就十只 老师脑门上的汗已经流下来了 下课铃响起 但男孩仍继续问 有没有傻的不怕死的 都怕死 有没有因为情侣被打中 自己留下来的 笨蛋 之前不是说都是公的嘛 同志可不可以啊 性取向都很正常 会不会一枪打死两只 不会 一枪打死三只呢 不会 四只呢 更不会 五只呢 绝对不会 那六只总有可能吧 除非是猪生的才有可能 从一则笑话看需求调研的精神 好吧 那么所有的鸟都可以自由活动么 完全可以 它们受到惊吓起飞时会不会惊慌失措而互相撞上 不会 每只鸟都装有卫星导航系统 而且可以自动飞行 恩 如果您的回答没有骗人 学生满怀信心的回答 打死的鸟要是挂在树上没掉下来 那么就剩一只 如果掉下来 就一只不剩 老师当即倒 需求调研过程的问题 案例1一般软件公司接到了软件实施案子 第一步是急吼吼的去做需求调研 首先集中要使用软件的一帮人在一起开座谈会 有使用部门的 有间接使用的部门 有计算机管理部门 有大老板 有二老板 甚至有的时候连前台也来了 好几个部门的人集中在一起 每个人角度不同 层次不同 关注的重点不同 大家从自己的角度唧唧喳喳的说了一通 然后需求调研人员将这些都记录下来 形成需求文档 拿回去开发软件 经过一段时间的努力 终于可以给相关使用人员演示了 一演示 问题来了 某某部门的说刚才我突然发现我这里有个东西你这软件没做 某某部门说我这里还有个流程你还没做进去 某某又说有个关键的报表你做的跟我们实际要的不同 某个以前没关注的部门突然又提出需求 我也要用这个软件 新软件上我不能使用 软件公司项目开发人员把这个部门人员请来一聊 最终发现这个部门确实有使用这个软件的理由 再一翻以前的调研 这个部门给漏掉了 没办法 把这个部门的需求在加上 继续进入开发中 需求调研过程的问题 问题提炼用户参会人员不全导致无法形成完整需求 甚至漏掉需求 直接管理项目的局方负责人没有参与调研 领导一句话直接推翻所有 每个人关注的重点不同 记录后很难形成最终需求 开发出的东西客户使用后发现调研时某功能是必要的但之前没想到 发现功能有但是没有和业务流程结合起来无法使用 发现调研时表达的需求和项目方理解其实不一致 实现不对 需求调研过程的问题 案例2 喂 是小明吗 我是人力资源部的小丽 我们在使用你编写系统时遇到一个问题 一个职员想把她的名字改成井边小玉 而系统不允许 她国籍变日本人吗 小明问道 不 仅仅是要更改她的名字 而且身份证已经变更了 小丽回答 就是这问题 好像我们系统只有国籍变了名字规则才变 当然是这样 我从没想过谁会莫名其妙地更改自己的姓名 我不记得你曾告诉我系统需要处理这样的事情 小明说 小丽说 我想你当然知道每个人只要愿意都可以随时合法更改他 她 们的姓名 但不管怎样 我们希望在下周五之前解决这个问题 否则小玉将不能报销 你能在此前修改好这个错误吗 我现在正忙着做一个新的性能检测系统 我只可能在月底前修改好 一周内不行 很抱歉 那我怎么跟小玉说呢 小丽 你要明白 这不是我的过错 如果你一开始就告诉我 你要能随时改变某个人的名字 那这些都不会发生 因此你不能因我未猜出你的想法 需求 就责备我 小丽不得不愤怒地屈从 好吧 好吧 我恨死这个系统了 需求调研过程的问题 问题提炼客户和项目经理都对该领域有一定理解 比较简单或常规流程不讨论 结果遗漏了实际可能存在的问题 客户因不熟悉或突发奇想仅有模糊的概念 没有梳理出需求的能力 需求调研过程的问题 案例3某金融公司的高级管理郑某 会见软件公司的XX系统项目经理级 郑某说 我们需要建立全网人员及权限管理系统 该系统可以把公司所有系统的权限分几种管理 这样在这个平台上维护帐号后针对该系统权限直接授权就简单了 而不必登陆到各系统进行细粒度授权 你们小组能在五个月内开发出该系统吗 项目经理说 我已经明白这个项目的重要性了 但在我制定计划前 我们必须收集一些系统的需求 郑某觉得很奇怪 你的意思是什么 我不是刚告诉你我的需求了吗 项目经理说 实际上 你只说明了整个项目的概念与目标 这些高层次的业务需求并不能为我们提供足够的详细信息以确定究竟要开发什么样的软件 以及需要多长时间 我需要一些熟悉各系统使用要求的人员及相关技术人员进行讨论 然后才能真正明白达到业务目标所需的各种功能和用户的要求 才能明确达到目标的具体功能有哪些 我们系统目前为满足哪些业务及技术 也许我们甚至并不需要开发一个新的子系统 这样可节省许多钱 需求调研过程的问题 问题提炼用户各种需求带来过度的耗费和降低产品的质量 客户因不熟悉或突发奇想仅有模糊的概念 没有梳理出需求的能力 需求调研 分析 开发 交接各环节没有明确输出 过分简略忽视细节导致需求变形 客户认为事情就这么简单没必要告诉你 剩下的是软件公司的专长了 忽略某类用户角色的需求将导致众多客户的不满 用户总是在原有需求开发阶段提出新的需求而不考虑是否在计划时间内是否能实现 5W1H分析法 5 什么场景下使用该操作 3 用户是谁 6 如何进行需求规格的分析与下阶段的设计 实现工作 4 什么时间 可以或必须操作这个功能 2 要做什么 实现什么 1 为什么用户要引入系统 需求调研的思路 第一 了解背景第二 理流程第三 理思路第四 确认数据流关系第五 确认特殊流程和特殊需求第六 补充建议 如何与客户交流需求 需求调研前的准备工作1 准备好需求调研模板 需求调研问题列表等需求调研表单以及需求调研过程用到的工具 资源和材料 2 制定好需求调研计划 开始时间和结束时间 确保在预计时间内完成需求调研 3 了解被调研对象的组织机构 关键人物及其业务背景 如何与客户交流需求 需求调研过程的注意事项1 客户想要什么 需求调研过程要注意记录用户所说的一切并做好记录 做到多记少说 切忌在调研过程附带任何解决思想 2 客户要这干什么 客户描述完需求后 首先一条一条的复述 在复述的同时可以发表建议 是建议 不是意见 所以态度要把握好 要把客户的需求合理化 简单化 3 客户为什么这么想 需要搞清楚他们的行业流程或说业务逻辑 看看他们到底想让我们用程序为他们实现什么功能 4 客户会不会有别的想法 在一定的范围内发掘潜需求 如何与客户交流需求 如何把控需求1 明确划分需求阶段 严格把控需求迭代性开发任务新提出的需求原有需求的变更2 明确需求上线时间需求与用户确认后 用户需要提供一个明确的上线计划时间 需求开发工作应以此时间作为目标时间 如何与客户交流需求 如何审核需求1 明确每一个需求最终实现的重要性 必要性 可行性 需求调研过程问题综合解决 解决方案理顺组织架构及沟通流程良好的项目组织结构是软件项目成功的保障之一 要建立合理的组织结构 包括三方的组织架构 明确客户项目组织结构 包括参与到本项目中各个人员的工作职责及工作内容 明确的沟通协调流程项目需求是双方共同理解的过程 共同理解其实也是不断沟通交流的过程 确定沟通协调平台如客户例会 或请求局方发起专题会议 确定需求调研计划确定被调研的部门 组织 角色 具体业务人员 在需求调研计划中 确定参与需求调人员的姓名 联系方式等一些详细信息 良好的调研记录1 无论是客户口述 还是客户的想法 先以用书面的形式将录下来 2 采用过程文档进行记录 不容易遗漏某个想法 或某次需求 3 分阶段的 逐步确认需求 每次需求都有一份过程文档进行记录 每次都要进行一次需求确认 详细的需求分析说明书比较直观的界面1 界面设计前奏 在客户需求确定之后 在此基础上进行设计开发 是一个增量式的系统原型 2 界面原型设计 动态可操作 直观地给客户展示 内容提要 需求开发面临的困境 需求管理过程的输出产物 如何管理需求 如何调研和采集需求 什么是需求 需求提交 项目方人员与用户确认完需求后 项目方人员在将需求确认完毕后 需要将需求调研报告 需求分析说明书等材料提交到Mantis平台 由产品管理人员统一管理 需求管理流程 需求提交到Mantis平台后 进入需求管理阶段 我们规定按如下步骤处理需求 大区经理审核需求后分派给产品管理部产品管理部审核需求 根据需求内容及计划上线时间设置需求的优先级 见下表 优先级备注特急要求在近一周内完成的高要求在近一个月内完成的中要求在近3个月内完成的低大于3个月内的 远期规划型的需求产品管理部人员根据需求分析说明书编写需求规格说明书和原型设计产品管理部人员完成需求规格说明书和原型设计后交与项目方人员 项目方人员与客户确认客户确认后 产品管理部人员组织需求规格说明书和原型设计评审会 研发人员与测试人员同时参与需求规格说明书及原型设计评审通过后 产品管理人员将相关文档上传至相应需求单号下并邮件周知产品管理部人员将需求交接给研发负责人和测试人员 需求管理流程 研发人员分析需求后编写研发计划后将计划上传至相应需求单号下 并发邮件周知 如果后续计划有所修改也要将新计划上传至相应需求单号下并周知 并做好版本控制 要求文档命名格式如下 xx省 xxx项目研发计划v1 0 后续修改计划文档名称中版本号递增 如v1 1 研发人员开始概要设计文档编写 测试人员开始测试用例编写研发人员组织概要设计评审 产品管理人员和测试人员参与测试人员组织测试用例评审 研发人员和产品管理人员参与研发人员开始详细设计文档编写 并组织详细设计评审研发人员开始代码开发研发人员完成开发 提交测试部测试对于项目定制化开发的需求 研发人员完成需求开发后直接将补丁包上传至相应需求单号下 并添加任务注释 由项目方人员自行处理后续工作 对于产品化开发需求 研发人员完成需求开发后交由测试部测试后走公司公共产品部产品发布流程 为什么要写好需求描述 为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解 使之成为整个开发工作的基础 一旦写错 研发人员有可能要做大量重复工作 糟糕的需求描述不能指导产品管理人员写出标准的需求规格说明书 明确的需求分析说明书可以指导测试人员编写测试计划 指导研发人员编写研发计划 需求描述的六大特征 Yoursitehere 3 必要性 5 明确性 1 正确性 4 优先权 6 可证实性 2 可行性 高质量需求描述的其他特征 Yoursitehere 3 可修改性 1 完整性 4 可追踪性 2 一致性 高质量的需求不仅是包括长长的功能性需求列表 还包括外部接口描述和一些诸如质量属性 期望性能的非功能性需求 Yoursitehere 完整性 不应该遗漏要求和必需的信息 可以使用以下方法来实现 将需求以分层目录方式组织 将帮助评审人员理解功能性描述的结构 使他们很容易指出遗失的东西 通过应用用例图来抽象化需求 能够从不同角度查看需求的图形分析模型 也可以检查出不完整性 Yoursitehere 一致性 避免与软件中其他的需求或高级别的系统需求发生冲突 注意 修改需求时一定要谨慎 如果只审定修改的部分 没有审定与修改相关的部分 就可能导致不一致性 Yoursitehere 可修改性 当每个需求的要求修改了或维护其历史更改时 必须能够审定需求 也就是说每个需求必须相对于其他需求有其单独的标识和分开的说明 便于清晰的查阅 可以将相关的需求分组 建立目录表 索引 以及前后参考 也即将需求按性质进行分类 Yoursitehere 可追踪性 应能将一个软件与其原始材料相对应 如高级系统需求 用例 用户的提议等 Yoursitehere 编写需求的方法总结 句子和段落要短 采用主动语气 使用正确的语法 拼写 标点 使用术语 要保持一致性 并在术语表或数据字典中定义它们 避免包含多个需求的长的叙述段落 努力正确地把握细化程度 尽量避免在一个需求中使用 和 or 或 密切关注是否多个需求合并成了单个需求 如果你认为一小部分测试可以验证一个需求的正确 那么它已经正确的细化了 如果你预想到多种不同类的测试 几个需求可能已挤到了一起 需要拆分开 案例分析 主帐号信息同步管理功能 功能描述 为在4A系统实现对主帐号的统一管理 4A系统需从UUM侧同步主帐号的相关信息 数据同步接口要求满足广东移动统一用户管理系统设计 UUM 规范 该模块采取 UUM数据同步接口使用指南 中 同步方式一 设计 可满足系统闲时定时增量同步和相关人员手动增量同步操作 其中 定时增量同步在每10分钟自动执行 手动增量同步操作只有主帐号管理人员和4A系统管理人员能够执行 如果同步失败 应该是可以主动以电子邮件方式提示主帐号管理人员 并有系统日志记录 属于需求背景 最好单独说明 不要放在功能描述中 这是同一个需求的两种实现方式 测试人员编写测试用例需要覆盖到 建议使用 分层目录 方式具体说明 什么是增量同步 描述模糊 闲时是对定时同步而言还是对手动同步而言 怎样才算闲时 如何衡量 体现了需求的不可证实 要避免像 应该 的这类不确切的词 这个功能是能实现还是不能实现 体现了需求的不准确性 此处为何只提示主帐号管理员 体现了需求的不准确性 Yoursitehere 输入 同步执行时4A系统将根据组织机构和主帐号现行同步状态决定是否调用UUM提供的webservice接口获取异动数据 到底现行状态如何才可以决定是否调用同步操作呢 体现了需求的不完整性 功能描