今天完成的事情：

用了一上午的时间，给线下的师弟讲解后台设计思路，通过与他讨论对后台的业务重新思考了一下，我回想了一下，一开始接触后台是在百度上搜索，大概明白后台用来管理前台，然后研究后台管理模块，分不清用户管理和角色管理，后来请教师兄用户管理是管理谁可以登录后台，角色管理是登录后台的人有什么样的权限，今天我和师弟讨论的点是他的设计思路是在新增账户是同时进行角色分配，这其实就是对后台的业务逻辑没有明白，因为后台的用户数量一定大于角色的数量，如果每增加一个账户都需要 设置一遍权限，那么角色管理这个功能等于没有了，我理解的是后台的角色是我预先设置好的角色，当添加新账户时直接为账户选择角色即可，这是我基于我目前所能了解到的后台的逻辑的理解。

然后说刚刚结束的消息推送，后台需要消息列表、查看消息、新增消息、编辑消息，

消息列表主要展现消息的属性，标题、发送时间、是即时消息还是定时推送、是已发送还是待发送、推送的形式，已发送的消息在消息列表的操作只可以查看和删除，未发送的消息可以编辑和删除，这些都是需要理解他的业务逻辑以后才可以去学习的。

下午听了老大的敏捷开发的演讲，敏捷开发不是迅速开发表面意思，是一种持续可交付的开发方式。

明天的计划：继续任务10喽

遇到的问题：明天我需要一张银行卡进行绑定和解绑

收获：

对于功能需求的分析主要从两方面入手：业务场景和系统界面。

一、业务场景

什么是业务场景？

场景是我们设计功能时的一个重要参考依据。

所谓场景，就是用户在进行这步操作时所处的周围环境。

这里的周围环境包含的维度很多，比如用户的属性，年龄、身份、工作等。

场景不仅指物理环境，比如在车上、飞机上、教室里，还指任务场景，比如开空调的业务场景是因为夏天很热，需求是身体凉快不热。

任何产品都是一种物质存在，要使其有意义，就应该置其于恰当的社会环境中，而且这种环境与其他工具或人密不可分。

可以通过一个表格来描绘业务场景，比如描绘信评人员在财报更新的时候需要做跟踪评级。

为了保持寝室卫生，大学几个室友在寝室决定轮流打扫寝室卫生

用户在提需求的时候，多问几个为什么，为什么要提这个需求？目前是遇到什么困难？现在是怎么做的？

如果涉及到业务数量的，还可以问下量大不大？比如某公司就只有一个客户做某业务，为了这一个客户去开发一个大功能，浪费人力、物力甚至造成项目延期。

但也不是说，就不做，如果后续做这项业务的客户会越来越多，开发功能是需要的。

将用户提出的需求业务场景梳理清楚后，接下来就是需要过滤用户的需求，有时候客户提出的需求并不是“真”的需求。

很多时候因为客户自己本身对业务的不了解或者对行业知识不了解，基于某些情况，客户提出一些假需求，客户提出“假需求”的情况有：

• 客户对自己本身对业务或行业上的知识不是很了解；
• 客户基于“花少的钱获得更多的功能”心理提出很多个性化的需求；
• 客户在提需求的时候有时候也会撒谎；
• 客户不知道自己要什么导致假需求的产生。

识别客户的需求到底是不是真的需求，最重要的一条是识别客户提出需求的动机，知道为什么客户会提出这个需求？（又回到业务场景的问题了）

知道客户提出需求的动机以后，多问几个为什么，如果客户在回答问题的时候前后不连贯，或者没有逻辑，这类需求往往就是假的需求。

在过滤掉客户假的需求以后，需要知道如何去表达需求，为了使需求更连贯和完整，建议采用“情景场景剧本”的方式来表达需求。

把需求当成一个情景剧，有人物、有业务场景、有目标、有故事背景、有做事的动机、有情节等，可以用语言或者图形的方式将故事描绘出来。

如果发现故事中有些情节是是断裂的或者是讲不通的，那有可能你的需求并没有真正弄清楚，需要重新去梳理一下你的这个需求。（侵删）