第九章，项目经理
我知道了典型的软件团队里面除了能些代码，测试代码和画图做设计的成员还有一类角色，不做上面这些事情但是也很重要，他们就是项目经理。
PM的M就是Manager，但是P有：Product Manager--产品经理，正确地做产品，Project Manager--项目经理，正确地做流程，Program Manager--微软的职位名称 在不同的行业和公司，他们的作用各不相同。
接着了解到了微软PM的来历。随着业务的发展和团队的壮大，团队成员之间的交流的成本急剧增长和有很多开发和测试之外的事情，需要专人负责的问题出现了。在这样两个突出问题存在的情况下，微软经过不断的改革，最后发明了PM。有做功能设计的PM，有些PM需要对商业和客户有很强的了解能力，有些PM需要具备广泛的经验和知识面，以及商业拓展能力，有些是驱动流程的PM，也有专门深入某一领域的PM，还有和研究人员合作，琢磨如何将前沿技术引入主流产品，做技术转换的PM。一名PM要在整个项目的生命周期管理风险，对于软件项目来说，风险是在正常生命周期事件之外的，可能发生的影响项目的成功的事件。应对风险有进一步研究，接受，规避，转移，降低，制定应急计划的手段。风险管理的水平有多个层次：1.啊呀，大问题！2.缓和并防止问题3.预计4.把问题变为机会。要想成为一名合格的PM需要具备各种能力。包括：1.观察，理解和快速学习能力2.分析管理能力3.一定的专业能力4.自省能力。拥有这些能力的PM带领整个团队形成团队的目标/远景，把抽象的目标转化为可执行的，具体的，优美的设计。管理软件的具体功能的生命周期。创建并维护软件的规格说明书，让它成为开发/测试人员及时准确的指导，而不是障碍。代表客户和用户的利益，主动收集用户反馈，预期用户的新需求，协调并决定各种需求的优先级。分析带领其他队员对缺陷/变更需求形成一致意见。带领其他队员确保项目保持功能/时间/资源的合理平衡，跟踪项目进展，确保团队发布令客户满意的软件。收集团队项目管理和软件工程的各种数据，客观分析项目实施过程中的优缺点，推动项目成员持续改进，从而提升士气。
第十章，典型用户和场景
不能只看用户的表面语言或者行动，我们还要找到用户语言或行动背后的冬季。不能光根据用户的语言就匆忙做决定。然后对典型用户进行了介绍。接着要定义典型用户，定义典型用户首先要定义用户的角色，软件系统中也分为受欢迎的和不受欢迎的典型用户。典型用户的模板可以包括名字，年龄和收入，代表的用户在市场上的比例和重要性，使用这个软件的典型场景，使用本软件/服务的环境，生活/工作情况，知识层次的能力，用户的动机、目的和困难，用户的偏好。有了典型用户之后，我们还得决定每一个典型用户的目标。对于每一个目标，列出达到目标所必须经历的过程，这就是场景，也可以叫故事。通过针对每一个场景，设计一个场景 入口，接着描述典型用户在这个场景中所处的内部和外部环境，然后给场景划分优先级，按优先级排序写场景。有了场景，下面就由架构设计师和各个模板的负责任一起，沿着子系统/模块的所属关系把场景分开。和典型任务和典型场景的方法类似，用例也是很常用的需求分析工具，用例的基本元素有：标题，角色，主要成功场景，步骤，扩展场景。然后又介绍了规格说明书，主要分为软件工能说明书，软件技术说明书。功能说明说从用户得见角度描述软件产品的功能输入，输出，界面，功能的边界问题，功能的效率，国际化吗，本地化，一场情况等，不涉及软件内部的实现细节。而技术说明书则描述开发者应如何去实现它，接下来讲功能驱动设计，主要包括：第一步：构造总体模型 第二步：构造功能列表 第三步：制定开发计划 第四步：功能设计阶段 。
个人感受：
以前是怎么做的：以前合作较少，没有涉及到过项目经理的概念，也没有选出过项目经理。
为什么这么做不好：没有一个好的项目经理，会增加项目出现的风险，并且会降低维护风险的能力，少一个带头的人也会降低大家的积极性。
解决办法：在合作开始的时候，通过投票，选出一个优秀合格的项目经理来管理团队。