第九章 项目经理
9.1PM是啥
软件团队里除了能写代码、测试代码和画图做设计的成员，还有一类角色，不做上面这些事情但也很重要，我们叫他们项目经理——PM
PM的M就是Manager，但是P有这几种：Product Manager、Project Manager、Program Manager，在不同的行业和公司，他们的作用各不相同。接下来介绍的是项目经理——Program Manager
Product Manager：产品经理——正确地做产品 Project Manager：项目经理——正确地做流程 Program Manager：微软的职位名称
微软产品团队三足鼎立的角色分配就是PM、开发、测试。PM负责除产品开发和测试之外的所有事情。从某种意义上说，是前面两种角色的综合。微软通常有专门的产品策划（Product Planner），他们和市场部门的专职人员一起，负责产品的长期发展和市场推广
9.4 PM 的能力要求和任务
能力要求：
-
观察、理解和快速学习能力——PM要能够在一个新的领域中很快上手
-
分析管理能力
每天项目中发生的事情千头万绪，PM要能够分析出重点，找到优先级，做判断、做决定……一个项目和一个人一样，每天都会碰到各种问题：重要而紧急的
网站崩了！程序员小飞突然提出离职！重要而不紧急的
按照流量和内容的发展趋势，三个月后，目前的架构似乎撑不住，但是现在还凑合……程序员们都不写文档，他们三个月前说等忙过之后会写的，但是……不重要而紧急的
老板的老板问到了项目的进度！要写一个PPT，向若干人征求意见，并及时得到反馈不重要且不紧急的
领导想召开全公司大会，要表演节目…… -
一定的专业能力
如果一定要说专业能力的话，PM的专业就是理解和表达，你能否理解不同人的心理、需求和言外之意？你能否借助文字、图表、草图，甚至代码来清晰准确地表达自己的想法？PM通常也能写代码，能玩转Excel、PPT、Visio、甘特图，会PS，有文字功底，写的博客有人爱读，反正，总得有几招绝活吧！不用说还要有大量的阅读，对IT行业、用户心理、社会都要有广泛的了解 -
自省的能力
一个PM做第一个项目时可以拍脑袋定工期，拍胸脯打包票，最后拍屁股走人（谁没年轻过呢），但是失败之后要有自省和自我改进的能力
第十章 典型用户和场景
10.1 典型用户和典型场景
①怎样定义典型用户？
我们首先要定义用户的角色。正如戏剧中有正面和反面的角色，软件系统中也有受欢迎的和不受欢迎的典型用户。
受欢迎的典型用户——指那些按设计者的期望使用系统的用户，如“网站的购物者”不受欢迎的典型用户——指那些有不正当目的的用户，如在一个房地产业主论坛中滥发房屋中介广告的用户——这些用户也许在别的系统中（如房屋中介论坛）是受欢迎的
典型用户只是我们的设想，还要和这些典型用户的代表交流，理解用户，理解他们的工作方式和需要。然后再修改，细化典型用户
②从典型用户到场景
有了典型用户之后，我们还得决定每一个典型用户的目标——他/她使用系统想要达到什么目的。对于每一个目标，列出达到目标所必须经历的过程，这就是场景，也可以叫故事。注意，有些场景描述了成功的结果，有些场景描述了失败的结果。用户和系统有成百上千种可能的交互情况，写场景时要有针对性。
③场景怎么写？
首先针对每一个场景，设计一个场景入口（描述场景如何开始）接着描述典型用户在这个场景中所处的内部和外部环境（内部环境指心理因素等）然后给场景划分优先级，按优先级排序写场景
④场景之间如何区分呢？
找到这个场景的特殊之处，对于共同的流程可以一笔带过，重点描述场景中特殊的因素把场景组织成一个故事，这样就能把一个完整的用户与系统交互的流程记录下来，以后进行产品演示或验收都可以以此为基础
10.2 用例
和典型人物、典型场景的方法类似，用例（UseCase）也是很常用的需求分析工具。用例有这样一些 基本元素：
标题：描述这个用例要达到的目标角色（Actor）：和软件系统交互的角色，例如用户，其他实体，甚至时间（在描述一些和时间相关的场景时有用）主要成功场景（Main Success Scenario）：一系列步骤描述角色是怎样和系统交互，从而达到目标的步骤（Step）：描述每一步的交互（例如一套正常的ATM取款流程）扩展场景（Extension）：描述一些扩展的交互，例如一些意外情况（例如取款时账户余额不足）
10.3 规格说明书（Spec）
①规格说明书（Specification）简称Spec，分为以下两种：
-
软件功能说明书（Functional Spec），主要用来说明软件的外部功能和用户的交互情况（把软件当作一个黑盒子）
-
软件技术说明书（Technical Spec），又叫设计文档（Design Doc），主要用来说明软件内部的设计规范（把软件当作一个透明的箱子）
②写好一个Spec
第一，定义好相关的概念
第二，规范好一些假设（Assumptions）
第三，避免一些误解，界定一些边界条件
第四，描述主流的用户/软件交互步骤
第五，一些好的功能还会有副作用
第六，服务质量的说明
标签：典型,场景,用户,笔记,Manager,构建,九十,描述,PM From： https://www.cnblogs.com/lmyy/p/17366426.html