《人人都是产品经理》读书笔记20120320.docxVIP

《人人都是产品经理》读书笔三章：项目的坎坷一生项目的坎坷一生的详图，如下图所示重点一：产品 VS. 项目 and 产品经理VS.项目经理产品：是解决问题的东西项目：是一个过程。产品经理：靠想。产品经理是做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润。最重要的是判断力和创造力。项目经理：靠做。项目经理是把事情做正确，把事情做得完美，在时间、成本和资源约束的条件下完成目标。最重要的是执行力和控制力。重点二：立项团队组建典型的项目组织结构，如下图：项目督导委员会：为项目提供各种资源，监督项目过程。PD:负责整个项目的需求。开发经理及其团队：负责开发相关任务。测试经理及其团队：负责测试相关任务。UE(用户体验团队)：负责产品给用户的展现。服务团队：负责产品帮助的编写，以及上线后的服务工作等。如果项目牵涉到其他产品，还需要设置各种职能的接口人以协同工作。计划确定里程碑确定：需要在更大的力度上把开发计划、测试计划、发布计划等合并为项目计划，确定项目的几个里程碑，也是监控点，通常是需求完成、编码完成、发布上线。WBS拆分：有经验的项目可以利用原来用过的WBS模板，自顶而下地优化并套用，无经验的项目可以自下而上，列出一个个最小的任务点，再组装起来。工作量估算：三点估算法“工作量=(最乐观+最悲观+最可能)/3”或“工作量=（最乐观+最悲观+最可能X4）/6”总结：做项目的本质就是保证品质的前提下，在时间要求、人财物花费、项目范围三点上做平衡。（TRQ：项目时间【Time】;项目资源【Resource】;项目质量【Quality】） 。重点三：需求需求开发文档说明：BRD：Bussiness Requirements Document 商业需求文档MRD：Market Requirements Document 市场需求文档PRD：Product Requirements Document 产品需求文档FSD：Functional Specifications Document 功能详细说明PRD(产品需求文档)介绍：PRD模板目录结构示意图修订历史：写清楚每次修订的日期、版本号、说明和作者，便于以后追溯。项目概述：简单描述项目的背景、意义、目的、目标等。功能范围：给出本PRD的业务逻辑图，重点描述系统中角色的职责、与周边系统的关系、全局的商业规划等。用户范围：对本PRD设计的角色、系统做出简单的说明。词汇表：对本PRD设计的专有词汇、术语、缩写等做出说明。非功能需求：如性能需求、数据监控的需求等。其他说明：其他任何需要说明的内容都可以写在这里。UC(User Case)部分：首先对用例的整体进行说明，接着就是对一个个用例进行说明(即用例文档)。用例(User Case)文档介绍：说明各个用例之间的关系，一般有类图、用例图、状态图、时序图、活动图等。现以“小明下馆子”为需求来举例说明各个图。类图：Class Diagram,描述系统中出现的各个对象之间的关系，以及和外部系统的关系。类图举例用例图：User Case Diagram,描述各个用例之间的关系。用例图举例状态图：State Diagram，表达系统里实体的状态转换。状态图举例时序图：Sequence Diagram，也叫顺序图，描述事物变化在时间维度上的先后顺序，善于表达对象的交互，比如多个页面之间、多个角色之间。时序图举例活动图：Activity diagram，比较接近我们常说的流程图，描述各个动作如何引起系统变化，善于表达泳道较多、分支较多的情况。活动图举例UC模板参考UC_用例名称：用例ID用例概述业务描述商业目标，用户目的等业务内容需求描述产品需求，需要实现哪些功能点行为者该用例的Actor前置条件Pre-Conditions后置条件Post-Conditions其他说明任何其他的说明信息等界面描述UI示意图：页面名称Demo截图1截图说明1(给出Demo文件的地址)界面元素——表单：表单名称名称类型|长度必填默认值规则∨界面元素——列表：列表名称名称类型|长度排序规则界面元素——按钮名称规则界面元素——其他：通用描述名称……规则业务规则序号规则1（UC通用规则写在这里，流程中某步的私有规则写在流程里）流程描述流程1(主流程)：流程名称触发事件：触发事件时序图 Or 活动图（尽量用途表达，下面的文字描述可选）步骤用户系统规则12分支流程-11产品Demo制作过程Demo一般会经历从低保真到高保真，从抽象到具体，从全局到细节的渐变过程。重点四：概要设计与详细设计设计文档的书写原则：第一：不以写的东西是需求还是设计区分职责，而以“业务”或“技术”区分。第二：细枝末节的设计经常重复，PD应该和开发工程师一起协商，渐渐沉淀出产品规范。重点