项目经理
介绍了产品经理——正确地做产品与项目经理——正确地做流程。以及微软的职位名称。微软产品团队三足鼎立的角色分配就是PM、开发、测试。PM负责除产品开发和测试之外的所有事情。从某种意义上说,是前面两种角色的综合。微软通常有专门的产品策划,他们和市场部门的专职人员一起,负责产品的长期发展和市场推广。以及微软PM的来历。
典型用户和场景
光看用户的表面语言或行动还是不够的。我们还要找到用户语言或行动背后的动机!不能光根据用户的语言就匆忙做决定。典型用户不再是一个抽象的概念,而应该是一个活生生的人。一个典型用户描述了一组用户的典型技巧、能力、需要、想法、工作习惯和工作环境。在设计软件的过程中,我们往往会以自己使用产品的习惯对软件行业的熟悉程度出发设计,忘记了我们的软件是给千千万万个不那么会用电脑的人使用的。在这种情况下,搞一个“典型用户”会强迫我们在考虑问题时从用户的角度出发。典型用户可以包括以下内容:1.名字2.年龄3.收入4.代表的用户在市场上的比例和重要性5.使用这个软件的典型场景6.使用本软件/服务的环境7.生活/工作情况8.知识层次和能力9.用户的动机、目的和困难10.用户的偏好
从典型用户到场景
有了典型用户之后,我们还得决定每一个典型用户的目标,他使用系统想要达到什么目的。对于每一个目标,列出达到目标所必须经历的过程,这就是场景,也可以叫故事。注意,有些场景描述了成功的结果,有些场景描述了失败的结果。用户和系统有成百上千中可能的交互情况,写场景时要有针对性。场景之间如何区分呢,这就要求我们找到这个场景的特殊之处,对于共同的流程可以一笔带过,重点描述场景中特殊的因素。把场景组织成一个故事,这样就能把一个完整的用户与文件系统交互的流程记录下来,以后进行产品演示或验收都可以以此为基础。
从场景到任务
不同的任务会把一个场景编织起来,虽然有多个开发者参与这项工作,但是应该有一个开发者对整个场景负责。得到开发任务后,我们就可以创建和分配测试任务。
用例,和典型人物、典型场景的方法类似,用例也是很常用的需求分析工具。规格说明书,功能说明书从用户的角度描述软件产品的功能、输入、输出、界面、功能的边界问题、功能的效率国际化、本地化、异常情况等,不涉及软件内部的实现细节。功能说明书的模板1.spec的目标是什么,spec的目标不包括什么?2.spec的用户和典型场景是什么?3.spec用到了哪些术语,它们的定义是什么?4.用户是如何使用软件的功能的?5.各种边界条件是什么,软件功能应该怎样随之变化——这边界条件多了去了:用户数量的变化,输入内容的上限下限,不同国家/地区/文化/语言/硬件/软件版本/环境参数……6.功能有什么副作用,对于其他功能有什么显性或隐性的依赖关系?7.什么叫“好”,什么叫“这个功能测试完了,可以交付了”?8.软件发布出去之后,有哪些项目目标相关的数据可以收集,怎么在实现阶段就能把数据收集的工作准备好?技术说明书又叫设计文档,它用于描述开发者如何去实现某一功能,或相互联系的一组功能。软件的功能多种多样,放之四海而皆准的模板是不太实用的,但是软件的设计总是要遵循一些规律,不遵循这些规律,工程师们往往在实现后面软件的演化中吃苦头。设计文档应该说明工程师的设计是如何体现下列原则的。
以及功能驱动的设计。
第一步:构造总体模型
第二步:构造功能列表
第三步:制定开发计划
第四步:功能设计阶段
第五步:实现具体功能