书摘《人人都是产品经理》——4年产品经理的思维书3

项目的定义：只会进行一次，包含多项相互关联的任务，并且有绩效、时间、成本和范围限制的一项工作。

产品是一个解决问题的东西，而项目是一个过程

产品经理关注的是做正确的事，关注的是产品的生命周期，关注的是产品能否赚钱，能否持续的赚钱。因此产品经理必须能够规划整个产品的架构和发展路线，能够确定产品的定位和受众，能够预计产品真正的价值和效益。最重要的是判断力和创造力决定做不做、做什么、做多少、保证方向正确。

通用的沟通方式：项目晨会、项目日报、评审会、项目变更申请、发布预告和公告、誓师大会。

15min的誓师大会KICK OFF：

【项目背景：我们在哪里啊？说过去，做项目之前的悲惨境地，明确为什么要做这个项目，以让听众痛下决心为终极目标。

项目意义、目的与目标：

我们去哪里啊？说将来，做项目之后的美好前景，解决什么问题就算成功了，以让听众面带桃花为终极目标。

需求、功能点概述：我们怎么去？说现在，具体用什么方法促使过去到将来的转变，以让听众跃跃欲试为终极目标。

项目组织架构：目的是让项目成员相互认识，明确什么事找谁。关键人物到场比如很重要的监督委员会成员，他们可以高屋建瓴低给项目成员描绘项目的重要性和伟大前景，说不定还会一时兴起追加一点团队建设费啥的，鼓舞士气。项目早期务必让老板多多参与，反复确认正确的方向，这时候做各种调整的成本都比较低。

主义不要遗漏工作不多的项目成员如服务部门，配合部门的接口人和客服

项目计划：1项目的时间点与里程碑2个时间段需要的资源也就是每个人要在各个阶段做什么事情

沟通计划：大多数事情不顺利都是沟通的问题所以和全体成员明确沟通计划就显得尤为重要。大家都做不到一直主动、彻头彻尾低沟通，所以有个规矩来逼着做一些沟通的工作并且在项目开始的时候就约定好可以免去很多麻烦

最后一点：凡是会议就总有人缺席，别忘了把会议记录发给所有干系人】

做项目目标：多快好省  范围大、时间短、品质高、资源省

项目TRQ:TIME/RESOURCE/QUALITY/QUANTITY

综合一下我们做项目的本质是在保证品质的前提下，在时间要求、人财物花费、项目范围三点上做平衡。

产品经理从抽象到具体过程主要产出的文档：BRD/MRD/PRD/FSD

商业需求文档：最先需要，设计市场分析、销售策略、盈利预测等通常是给大老板演示的PPT，比较短小精炼，没有产品细节，有点像创业者给投资人看的商业计划，主要是为了获得认可，争取资源。

市场需求文档：获得老板的支持后产品进入实施阶段，需要写MRD。要有更细致的市场与竞争对手分析，包括通过哪些功能来实现商业目的，功能，非功能需求分那几块，功能的优先级等。实际工作中，PD在这个阶段常见的产出物有产品的Feature List、业务逻辑图等，是从商业目标到技术实现的关键转化文档。

产品需求文档：对产品功能的进一步细化。新人写的最多的文档，需求开发的过程。文档主要包含整体说明、用例文档、产品demo等，会对产品功能做具体描述。

通常一个项目会包含一到多份PRD，每一个会包含逻辑相关的若干个功能点，这些相关需求在需求打包的环节已经被识别出来，也就是产品需求类表里的若干行。

UC：use case 用例

Functional Specifications Document功能详细说明。比较像我们长些的用例文档，经常包括在PRD当中，从这部开始会出现很多技术内容，产品截面、业务逻辑的细节都要确定，比如网页上的某个表格重的数字应该如何对齐走左中右。保留几位小数点。有点像概要设计。与此同时硬件系统的设计、数据库设计、表结构设计等工作，也开始由架构师、系统分析师编写了。

UML：unified modeling language统一建模语言将软件工程的过程规范化。提供了一系列标准图形化的表达方式，把需求开发的过程串起来。

类图：描述系统中出现的各个对象之间的关系，以及和外部系统的关系，这是对业务领域的描述，外行人看了之后可以了解此系统是做哪方面事的。

用例图：描述各个用例之间的关系比如include和extend，用例包，用例和行为者之间的关系。

状态图：表达系统里实体的状态转换，同样也是贯穿多个用例的。

UC要写的内容：用例的唯一标识、用例名称、业务描述、需求描述、行为者、前置条件、后置条件、其他说明、UC主体【界面描述、业务规则、流程描述（时序图、活动图）】

UC一般只用于描述功能需求，而非功能需求一般写在PRD总体说明里。UC对语言的要求比较高要求无歧义、完整、一致、可测试等。