今天阅读了《构建之法》关于典型用户和用户场景的部分，让我对于用户的需求有了更深入的理解。让我更容易的站在用户角度思考问题，为用户解决问题。
书中摘的一则漫画引发了我的思考，光看用户的表面语言或行动还是不够的。我们还要找到用户语言或行动背后的动机！不能光根据用户的语言就匆忙做决定。我们的目的不是简单的做出用户写出或说出的几点要求，而是要深入的分析用户的真正需求，做出用户真正想要的效果。那么如何才能更高效的分析用户的深层次需求呢？
在做需求分析的时候建立典型用户能迫使我们去站在用户的角度思考问题。首先要定义用户的角色。正如戏剧中有正面和反面的角色，软件系统中也有受欢迎的和不受欢迎的典型用户。如果用户有不同的安全需求，切记要定义不同的角色来适应这些需求。如下面的例子：
受欢迎的典型用户——指那些按设计者的期望使用系统的用户，如“网站的购物者”；不受欢迎的典型用户——指那些有不正当目的的用户，如在一个房地产业主论坛中滥发房屋中介广告的用户——这些用户也许在别的系统中（如房屋中介论坛）是受欢迎的。在这里要注意一点：我们的软件不是为所有人服务的。我们的软件就是为了解决特定人群的需求的，若非要做的很全只会造成一个用户也没有的局面。
因为典型用户只是我们的设想，这些都是纸上谈兵。所以在定义了最初的典型用户之后，我们还要和这些典型用户的代表交流，理解用户，理解他们的工作方式和需要。然后再修改，细化典型用户。有了典型用户之后，我们还得决定每一个典型用户的目标——他/她使用系统想要达到什么目的。对于每一个目标，列出达到目标所必须经历的过程，这就是场景。需要注意的是，有些场景描述了成功的结果，有些场景描述了失败的结果。用户和系统有成百上千种可能的交互情况，写场景时要有针对性。我们需要针对每一个场景，设计一个场景入口（描述场景如何开始）。接着描述典型用户在这个场景中所处的内部和外部环境（内部环境指心理因素等）。然后给场景划分优先级，按优先级排序写场景。
有了场景，还需要由架构设计师和各个模块的负责人一起，沿着子系统/模块的所属关系把场景划分开。在UI层，逻辑层，数据库等不同方面划分子任务。不同的任务将会把一个场景编织起来，虽然有多个开发者参与这项工作，但是应该有一个开发者对整个场景负责。得到开发任务后，我们就可以创建和分配测试任务了。
我的思考：上一次我以为认真的把用户要想的做出来就是用户需求分析了，没想到还有这么多门道。关于用户及场景分析还有很多需要学习的地方。真正站在所有用户的角度上，把每一个场景都考虑到位，才能称得上是软件工程师。都说未来的五十年互联网时代重体验化，产品经理会主宰世界。我等还需要继续努力才是。