扫码阅读
手机扫码阅读
需求访谈的18个注意事项
30 2024-10-01
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:需求访谈的18个注意事项
文章来源:
麦哲思科技任甲林
扫码关注公众号
需求访谈注意事项摘要
有效的需求访谈需要专业训练来掌握关键技巧,以便快速准确地获取客户真实完备的需求。以下是基于实践经验和工作坊练习总结的18个需求访谈注意事项:
访谈准备
- 调研前应准备问题清单。
- 按用户角色分类进行访谈。
- 区分业务场景进行访谈。
访谈过程
- 了解组织结构、业务流程等背景信息及当前现状。
- 明确访谈目标和业务痛点。
- 聚焦目标,避免无关或过分华丽的需求。
- 首先从宏观角度入手,然后逐步深入细节。
- 讨论正常与异常流程,关注频繁与偶然现象。
- 每个作业环节的痛点都需要被发掘。
- 问题询问应有逻辑主线,条理化。
- 使用IPO(输入-处理-输出)方法,确保问题易懂。
- 关注what to do,避免how to do的讨论。
- 团队成员应补充问题,但要保持思路连贯和聚焦。
访谈技巧
- 开放式问题了解现状,封闭式问题引导需求。
- 让客户通过例子说明现状和需求以澄清问题。
- 始终以客户为中心,避免替代客户做选择。
- 询问名词、动词时区分what is it和how to do it,形容词和副词要求量化。
- 不打断客户,鼓励其积极表达思想。
想要了解更多内容?
查看原文:需求访谈的18个注意事项
文章来源:
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
420 篇文章
浏览 69.4K
麦哲思科技任甲林的其他文章
不可重现的BUG的应对策略
问题场景:有一些比较严重的BUG随机发生,难以查找规律的,测试工程师提交上去后,有可能会出现以下三个情形:1.开发人员试图重现,重现不出,Reject回来;2.开发人员找不到规律,所以不去解决,问题一直处于Open状态;3.开发人员因为问题难以解决,所以直接Resolved回来,觉得反正是偶发的,先改成解决状态再说。对开发人员、项目经理和测试工程师来说,正确的处理方法应该是怎样的?解决方案:1 缺
要言不繁的DoD指南
DoD(The definition of done:DoD)完成的定义、完成的标准或完成的准则是敏捷开发方法中的一个重要概念,一个重要实践。本文对DoD如何理解、如何定义DoD及其作用给了简明扼要的论述,供各位实践者参考。 1 DoD的定义 可以从不同的维度理解DoD的定义: 1)DoD就是完成准则,完成就是不需要再做其他任何事情,可以直接交付了...
需求评审的案例分析
案例一:客户需求文档评审 参与人员:1位主持人,1位作者,1位记录员,4位专家,1位咨询顾问旁观 开始时间:15:40 结束时间:17:15 会议工时 :6.3人时 会前准备累计工时:9人时 总工时:15.3人时 会议前发现的问题:25个 会中发现的问题:2个 合计问题:27个 会前评审效率:2.8个/人时 会中评审效率:0.3个/人时 评审文档的规模:13页 缺陷
一个本色的朋友
有个朋友,是项目经理,我的客户,很喜欢自由,很有自己的思想,很直率,很有能力,很幽默,做项目很忙,经常出差。每次访谈他,都为他的坦率、他的幽默而大笑。很正式的访谈,都是在很轻松的氛围进行,笑过之后,却又让你去深思,他给我一种举重若轻的感觉。每次到他们公司做CMMI的运行检查,见到他的机会并不多。有一次约好了半天的访谈,结果他在外边出差,无法及时返回来,让我怅然若失。他是规矩的打破者,他喜欢按自己的
软件需求评审之道
作者:任甲林 来源:CSAI.cn http://www.csai.cn 2005年6月13日 摘要 本文介绍了软件需求评审失败的5个案例,提出对软件需求评审的实践具有指导意义的9个建议。 关键词 需求评审,需求层次,阶段评审,检查单,评审流程 软件需求是软件开发的最重要的一个输入,需求风险也常常是软件开发过程中最大的一个风险,降低需求风险的一个重要手段就是需求评审,但是需求评审是所有
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线