有些时候为了对用户角色更加深入的了解，一般会对重要的用户角色建立角色实例。角色实例是一个贴近生活的用户场景，通过角色实例可以建立起一个真实的人物，让我们对角色有更真切的了解。如果上班族是我们主要的目标用户，我们为上班族建立一个角色实例如下：
有业界的大大建议在设计新系统时对一些极端人物建立角色卡。这些极端人物并不是产品的典型用户，但是他们却是真的会使用我们的产品。比如一些花痴小妹妹，叫外卖或许对她们来说并不是必须的，但是她们可能仅仅是为了看某个送外卖的帅哥，而经常定那家餐厅的外卖。我们不需要浪费太多时间在这些极端人物身上，甚至这些人物的需求根本不会被实现，但是花点时间在这些用户身上，或许会产生一些意想不到的灵感。
2.2 需求源于角色
前面在用户角色建模上浪费了很大精力，其实都是在为这里的需求收集做准备。不同的角色肯定会有不同的需求，这个时候，我们需要将自己代入角色，仔细想想如果自己是这个角色，会有什么样的需求。将所有考虑到的需求都记录下来，为以后的需求整理做准备。
比如，作为一名上班族，很晚才回到家，这个时候叫外卖肯定希望外卖会很快的到达。而且上班族一般都习惯刷卡，如果提供刷卡或者网上支付功能会很方便。而“饿了么”软件就为用户提供的外卖到达时间的预估，用户可以方便的选择可以快速到达的外卖。
再考虑学生，学生这是个没有收入的群体，所以物美价廉的外卖是他们的首选。学生一般对快递的送达时间会有相对较大的容忍度。学生中对刷卡的需求不是很迫切，他们一般更喜欢现在付款，所以如果有货到付款的服务会很合适。同时，如果可以用学生卡打折，我想会很受学生们的欢迎。
3.欲望也有轻重缓急
在需求收集和整理完成后和项目开始开发之前，我们需要召开需求评审会来确定每个需求的优先级和开发计划。如果你的团队正在使用 Scrum 敏捷开发，那么你们一定在用用户故事来整理用户需求。用户故事通常使用客户和团队都可以看懂的表达方式来写，每一个用户故事都是产品的一个需求。当然，用户故事还包括需求的商业价值和相关人员。使用用户故事可以方便的与客户沟通，而且不用查看繁琐的需求文档。
用户故事一般使用如下格式：为了[商业价值]，作为[角色]，我想要[做某事]。还是使用“饿了么”软件为例，比如上班族想找到送外卖快的餐厅的需求可以表述为：为了让外卖更快的送达，作为上班族，我想要查看每家餐厅的外卖送达预估时间。
在用户故事确定以后，我们需要召集开发人员，客户还以一些产品的相关人员来参加需求评审会。在会议上，我们需要对每个需求的商业风险，技术风险，开发耗时和优先级作出评估。
首先需要确定的是商业风险，也就是确定哪些是核心需求，哪些是亮点需求。核心需求需要尽早完成，缺失了产品就不完整。而亮点需求有则会给产品加分，没有也不会影响用户的使用。一般来讲，核心需求的商业风险会比较低，因为这些需求都是产品必须的，被砍掉的可能性很低。而亮点需求的商业风险就会高，可能会因为开发时间不足而被砍掉或者被放入下次版本迭代的周期中。
下来需要确定技术风险和开发耗时，技术风险代表的是这个需求开发的难易程度。如果这个需求所需要的技术开发团队从来没接触过，需要对这个技术从头开始学习。那么这个需求的技术风险就会很高，因为这个新技术不知道开发团队是否能掌握，多久才能掌握。技术风险的评估对开发耗时的评估有很大影响。开发耗时在 Scrum 开发团队中一般用时间点来计算，一个时间点代表一个理想工作日。在我的团队中，一般使用斐波那契数列来划分时间点的等级。因为我们发现工程师经常在为一个需求的时间点而争论不休。如果为一个需求是 2 个时间点还是 3 个时间点而争论，这是有意义的，因为 3 个时间点比 2 个多了一半的工作量。但是如果在为一个需求是 99 个时间点还是 100 个时间点而争论就是没有意义的，因为这一个时间点的差别对我们的影响很小。为了避免这种无意义的争论，我们使用斐波那契数列来划分时间点，这个时候工程师只需要考虑这个需求的耗时更靠近 89 还是 144 ，而不用为了细小的差别而争论不休。在评估技术风险和开发耗时时，一般都有技术人员和项目经理来确定，其他人员不应该左右技术人员和项目经理的思维。
更多详细信息，请您微信关注“计算网”公众号：
