如何快速定义需求——用户行为定义

毕业10年,在上千人大公司和几十人小团队都干过,对于开发人员和需求人员(小团队无专业需求人员,一般由销售或产品提出)之间或多或少有鄙视链。 

开发一直拿需求人员无完善的文档说事,而需求人员一直拿开发人员SB说事;并且经常会有或多或少的矛盾产生,去年就有企业报出产品和开发人员干架的事情,可自行度娘“产品和开发打架”的新闻。

度娘的结果显示很多互联网大企业都有的事情,何况小企业小团队呢?专业的需求分析和文档形成本文就不去讲述,这方面文档资料太全面了,本文重点讲述在小团队或无规范文档流程的企业如何快速定义用户需求,化解开发和需求人员之间的矛盾!

首先,需要引出“用户行为定义”的,大数据的今天很多企业通过用户行为分析来重新定义用户行为,是倒逼式的;正式的企业或将用户行为定义(客户需求)行成专门的需求文档,相当于对用户行为的标准化文档转换输出。当我们与客户交流需求时,客户更多是告诉我们需要什么功能,如扫码支付、一键报警等,但具体到用户层面如何实现呢,就需求对用户行为进行拆分,模拟用户执行扫码支付的过程,同时把异常情况考虑进去;这个过程就是用户行为定义,而本文也从用户行为定义来代替需求分析。

所以,如何快速定义需求,从实践过的经验来看,用户行为定义书足以实现满足内外文档表述,一个文档即可连接客户、产品、开发、测试几方人员。具体步骤如下:

1. 功能名称

在与客户沟通时将客户需要的功能名称用简要的词语总结归纳出来,不建议超过6个汉字。

2. 确认场景

需求与客户确认使用场景(区域、使用者、最终用户),主要为后续功能拆分各异常case提供数据基础。

3. 使用过程

对客户提的功能最终使用过程需要确认,客户有时会对某些功能有误解,若不能及时确认使用过程,那么我们造成的产品将很难通过验证;当然,部分客户并没有明确的使用过程,此时就需要对接人员对客户功能的场景在现与客户深度交流,或先凭借自身经验将使用过程以流程图和文字形式输出,给到客户进行二次确认。

4. 行为拆分

行为拆分实际是对用户使用过程的拆分,对每个过程的可能出现的异常情况进行描述,一定要确认异常时对用户的提示(即交互)。

5. 图文输出

完整的用户行为定义书必定是有文字描述和流程图,有整体流程图和各过程的详细流程图,对用户的操作(输入) 和结果(输出)明确定义,图是最能表达思想的工具,繁琐的文字描述不便于沟通和演示,文字是对流程图细节进行补充的工具,二者缺一不可。

6. 客户确认

将行成的用户行为定义书与客户进行二次确认,以确保我们的使用过程符合客户预期。

7. 内部评审

当与客户确认修定完成后,即可进入内部实现评审过程,对于需求或产品原则上是不关注开发人员以何种形式实现,而仅告诉开发人员需要什么样的操作和结果,开发人员实现技术和环节同开发人员自己的事情,完整的用户行为描述相信任何一个开发人员都是能看懂的。

如上 7 步完成,客户、需求(销售、售前、产品、需求、项目经理)、开发、测试各环节可参考,也无须繁琐的文档,相信团队中任何一个人员都能完成上述工作,只需要学习绘制流程图、文字总结即可,流程图有在线的ProcessOn、离线的Visio等。

上述若能配合UX|UE人员把交互设计好不更Easy了,但一般的小团队是没有UX|UE角色的,最多一个UI。所以,对于一切从简的团队不防一用,欢迎讨论,谢谢!

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值