51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 17642|回复: 33
打印 上一主题 下一主题

如何学习掌握用户需求?(09-1-12)(获奖名单已公布)

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2009-1-12 17:21:00 | 只看该作者 回帖奖励 |正序浏览 |阅读模式

客户的参与是发布一个优秀软件的关键因素,在项目的开始阶段就应该努力致力于为你的项目征求各个客户的意见。软件需求的成功,和软件开发的成功都取决于开发者是否尽可能地采纳客户的意见。为了征求客户的意见,我们该如何学习/快速掌握用户需求?


感谢会员zero_up提供此精彩问题!如果你也有问题想提出来和大家一起讨论,请点击此处>>
说不定下期讨论的问题就是由你提出的哦,请快快参与吧!




获奖名单
奖项
获奖名单
奖励
答案链接
一等奖
rolei
当当购物卡50元
二等奖
wxm2004734
300论坛积分
luoyear
三等奖
老肥羊
100论坛积分
阿七






相关文章:

软件项目获取用户需求的沟通技巧

获取用户需求的十大沟通技巧

关注用户需求搞好项目管理

更多内容请点击>>>
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

34#
发表于 2009-3-10 15:46:34 | 只看该作者
学习了,我是个初学者,大家讲的很好
回复 支持 反对

使用道具 举报

该用户从未签到

33#
发表于 2009-2-5 16:53:00 | 只看该作者
初学者:总结的好。支持
回复 支持 反对

使用道具 举报

该用户从未签到

32#
发表于 2009-2-4 16:18:22 | 只看该作者
perfect
回复 支持 反对

使用道具 举报

该用户从未签到

31#
发表于 2009-2-3 14:34:43 | 只看该作者
阿七的和老罗的说的不错,学习了
回复 支持 反对

使用道具 举报

该用户从未签到

30#
发表于 2009-2-3 11:40:18 | 只看该作者
回复 支持 反对

使用道具 举报

该用户从未签到

29#
发表于 2009-2-2 17:33:58 | 只看该作者
1 找到真正的操作员,了解她的工作流程,工作方式
2 尽可能全面的搜集相关的纸质表单
3 与用户领导协商召开例会,最好每周一次,进行软件实施情况的反馈,具体的操作人员或用户代表需要参加。如果领导太忙不能参加,最好多利用其他时间与其沟通。理解领导想要达到的真正的目的。
4 不要一下子做的东西太多,从最基本的东西,不会变的东西,一点点做起。这个可以和具体的操作人员沟通。这样在对业务逐步熟悉的过程中,逐步完善系统。
5 最初的需求讨论会议,每周的例会,测试人员参与旁听。
6 开发人员开的概要设计、详细设计讨论会议测试人员也尽量参加。
7 测试人员深入需求的理解,个人认为了解系统的数据库结构很重要。以及数据流的走向,最好能自己画画图,这样可以比较快的深入到系统内部。

当然认真学习需求分析文档这些事情,就不再赘述了。

评分

参与人数 1综合技术指数 +6 收起 理由
默默巫 + 6 感谢参与

查看全部评分

回复 支持 反对

使用道具 举报

该用户从未签到

28#
发表于 2009-2-2 14:51:12 | 只看该作者
如何學習/快速掌握用戶需求?
我覺得,這個問題主要的解決在學習,快速掌握這幾個字上面.
看了上面眾多樓的回覆,注意到大家都忽略了一個問題,就是測試人員自身的知識范圍,理解能力,學習能力,知識搜索速度,知識學習速度等等各種很難處理的人自身的問題,在很多的時候,文檔也有,客戶也會比較的配合,但局限於測試人員自身的能力的問題,會出現很多的問題.
引用<<咨詢的奧秘>>一書中的結論"在整個系統的行為裡面,一般情況下,都是人的問題"
掌握一種學習方法,或者從自己多年的學習經驗中不斷的總結出自己的學習方法,有些人習慣於一目一行的看,有些人習慣於一目十行的看,至於是一行的效果好,還是十行的效果好,因人而異.
掌握準確的理解的方法,這個最常見的例子就是口令快速傳遞的時候,經常會發現第一個傳出的人與最後一個收到的人有千奇百怪的差別,中間為什麼會出錯?百分之九十九屬於理解準確率的問題,所以這就有一點,用更準確的詞語來描述自己碰到的問題及向客戶提出的問題,更快的找出客戶語言或文檔中的不明確,不準確的位置,並進行尋味.
掌握準確的表達方式,如何更有效的表達?如何更準確的表達?有一本書名字叫<<談話的力量>>,同一件事情,不同的表達方式可能會造成天地之別,選用更合適的表達,會更容易掌握到用戶的需求
很多人提出說看需求文檔的效果不如與用戶口頭交流的效果,在某種程度上確實是這個樣子.但是有沒有想過一個問題,A(客戶)腦袋裡面想的需求是A,口頭表達出來的是A-,接收人接收到的信號為A--,當接收人經過自己的大腦處理之後,很有可能變成了A---,再由接收人寫成文檔的時候會變成A----,這個時候,可能已經與客戶的原始需求相差很多,我只是想說明,很多時候,並不是從文檔交流變換為面對面交流是一種更好的方式,如果客戶更擅長於面對面交流,那需要選一個擅長面對面交流的需求分析人員去,如果客戶更擅長於用文檔表達自己的需求,那麼可能選一個擅長面對面交流的需求分析人員,會造成很大的問題...
借一句古話,工欲善其事,必先利其器,在學習/快速掌握用戶需求這個事情上面,我們的器就是測試人員,或者是我們自身,提高自身的種種能力,素質,才會善於學習/快速掌握用戶需求這個事情.

评分

参与人数 1综合技术指数 +6 收起 理由
默默巫 + 6 感谢参与

查看全部评分

回复 支持 反对

使用道具 举报

  • TA的每日心情
    奋斗
    2018-2-28 18:04
  • 签到天数: 40 天

    连续签到: 1 天

    [LV.5]测试团长

    27#
    发表于 2009-2-2 14:44:27 | 只看该作者

    回复 25# 的帖子

    老罗失踪好久了。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    26#
    发表于 2009-2-2 12:03:42 | 只看该作者

    拿把刀

    小样...你不说清楚今天就别想走着出去...
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    25#
    发表于 2009-1-31 15:10:27 | 只看该作者
    这个问题有太多的场景,针对不同的场景也有不同的答案。我就选择其中一种和大家探讨一下:
    项目开发过半,项目组内部已经开始集成,集成测试在即,尚未组建测试团队。在这种情况下,测试团队如何快速熟悉系统需求?

    在这种情况下火烧眉毛,肯定是要从人和管理上去下功夫。
    首先是团队的组成,最理想的方式是选择有相应行业经验的或者相对资深的测试人员组成核心测试团队负责测试设计工作,系统组和需求组人员协助指导和评审测试策略和测试设计;
    其次,最快的知识传递的方法肯定不是看文档/使用和学习系统,肯定是人类最原始最直接的方式:口头沟通。一般建议组织系统设计或需求人员讲一下系统结构和主要功能点;
    第三,在工作中学习,现实的压力加速了解需求。在初步掌握系统结构和系统的主要功能后,按照功能模块划分让各测试人员列出测试要点,在逐步的测试设计中了解需求;
    第四,基于初步的测试要点开始测试工作,同时开始补充设计测试case和交叉评审测试设计。对于E2E的case,可以由需求人员协助先整理一些场景。

    评分

    参与人数 1综合技术指数 +6 收起 理由
    默默巫 + 6 感谢参与

    查看全部评分

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    24#
    发表于 2009-1-20 19:33:20 | 只看该作者
    站在客户立场上看问题!
    和客户多交流!
    没技巧可言!

    评分

    参与人数 1综合技术指数 +6 收起 理由
    默默巫 + 6 感谢参与

    查看全部评分

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    23#
    发表于 2009-1-20 15:57:07 | 只看该作者
    学习下
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    22#
    发表于 2009-1-19 12:16:34 | 只看该作者
    1.在用户角度,对需求彻底分析、理解,对有疑问的及时与用户(多个用户)沟通
    2.对行业的特性、现状及将来发展目标,也要了解、分析
    3.对用户群也要分析

    评分

    参与人数 1综合技术指数 +6 收起 理由
    默默巫 + 6 感谢参与

    查看全部评分

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    21#
    发表于 2009-1-19 09:30:27 | 只看该作者
    学习一下。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
    发表于 2009-1-19 09:30:12 | 只看该作者
    学习一下.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2009-1-18 15:43:40 | 只看该作者
    1.对于用户需求不理解或理解错误,原因有很多,但最根本的就是沟通存在了问题,没有将客户需求转化为我们的产品需求,有的是时候,客户提出了进度等要求时,在没有很好的理解客户需求时,就盲目的开始做设计、编码工作,导致了在需求在没有确定下来,就先入为主的判定需求
    2.对于出现的问题,我们应该不能希望与与客户的沟通,应该讲究一些方法和策略,将成功的理解客户需求的项目,进行分析,看是如何搞定的,应该将这些经验总结起来,作为公司的资产,供以后项目的使用
    3.组织级流程的制定,组织级应该规范,在需求开发的标准过程,将以前好的项目的过程进行积累,作为项目需求开发的标准,以后的项目在此基础上进行裁剪
    4.在需求理解阶段,要做好和客户的沟通计划,在什么时候,沟通什么,怎么沟通,沟通的方式是什么,这些东西最好定义好,最好在项目的每个阶段,每个过程都让客户参加,让客户进行确认,现在很多项目都按照原型进行了开发
    5.人员的确定,在需求开发阶段时,要注意人员的确认,最好有相关经验的人参加需求的开发

    评分

    参与人数 1综合技术指数 +6 收起 理由
    默默巫 + 6 感谢参与

    查看全部评分

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2009-1-17 20:44:29 | 只看该作者

    回复 1# 的帖子

    1.扎实的专业基础=“牛”的技术能力+良好的沟通协调能力。因为掌握用户的需求,本来就是一种的沟通,单单凭借着一身很牛的技术是行不通的;个人认为如果在坚实的技术上加上良好的沟通能力,那应该会加快掌握用户需求。
    2.多从客户和软件的最终用户的角度看待问题,不要只从纯粹技术上想。
    3.有条理地客户提出要求和问题,并对改记录组织人员进行讨论分析。

    评分

    参与人数 1综合技术指数 +6 收起 理由
    默默巫 + 6 感谢参与

    查看全部评分

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2009-1-16 10:21:58 | 只看该作者
    原帖由 rolei 于 2009-1-13 09:17 发表
    1、与客户保持密切关系--关键
    1)多与客户交流,切忌闭门造车。(不能见实际客户,就多与需求人员交流吧,多思考,多提问题,多理解)
    2)多与实际应用的客户交流,软件的目的是为了方便使用。如果只是为了满足某 ...


    写的很好。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2009-1-15 16:14:35 | 只看该作者
    1立即对客户的工作环境和工作需求进行现场的调查观察和简单的小组制的讨论。
    2在单位内部针对上述分析的理念和结果进行问卷调查以进行快速有效的总结。

    评分

    参与人数 1综合技术指数 +6 收起 理由
    默默巫 + 6 感谢参与

    查看全部评分

    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-9-23 06:30 , Processed in 0.096750 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表