人人都是产品经理总结 第三章1

产品与项目的区别，产品经理与项目经理的区别

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

2、做产品与做项目的区别：

    2.1、产品的生命周期长，从产品的规划、制造、维护和消亡的整个过程都是在做产品，而项目通过验收就结束了；

    2.2、产品负责人需要不断修改自己的判断，给出适宜的创新，而项目在开始时就有了明确的目标，更注重计划与控制，目标是尽快的按质量完成；

    2.3、产品是提供给大量用户的，相对通用，例如设计师设计的一个款式、大公司做的一套管理软件，可以卖给很多酒店；项目可以看成独家定制的过程，例如裁缝制作的一件衣服，小公司为某用户制作的一款管理软件等。成熟的产品是通过一个个项目实现的，但不是简单地累加。当产品丰富后，可能升级为产品线，表现形式上叫版本（例如QQ的PC端各类版本）、模块（Advanced System Care中的各个模块，360软件的各个模块）、增值服务（晨星网的付费服务）等。

3、产品经理vs项目经理

    产品经理——靠想。产品经理是做正确的事，其所领导的产品是符合市场的需求，是否能给公司带来利润。内部驱动，重要的是执行力与判断力。

    项目经理——靠做。项目经理是把事情做正确，把事情做的完美，在时间、成本和资源约束下完成目标。外部驱动，重要的是执行力与控制力。

4、要产品经理管理项目的好处与坏处

    PD考核的是产品的商业价值，例如用户活跃度等，而这些指标与产品的用户体验关系很大，因此产品经理需要让开发的同事做很多价值不大的细节工作以增强用户体验。

立项阶段，一切从kick off开始

1、人员

PD新人不适合做项目经理，通常要和团队混到脸熟以后才可以，方便和其他人员要人力资源以及协调各种事务。

有时要成立项目督导委员会，成员一般是项目成员的老板，甚至是老板的老板，当项目延期时，可以看成是项目经理对自己和本项目成员的保护。（类似实习时，我的主管偶尔会叫他的主管参会讨论项目进展，并作汇报）。

项目中各种成员的职责：开发经理及其团队，负责开发；测试经理及其团队，负责测试；UE（用户体验团队），负责产品给用户的展现效果；服务团队，负责帮助文档的编写，以及上线后的服务工作等；

一般来说，项目经理（统筹项目）、PD（写需求文档）、开发经理（指定开发计划）凑齐后，就可以做下一步的任务了。

2、计划

典型的网页项目，周期一般在两周到一个月，大的最多不超过3-4个月。

在项目计划阶段，开发人员看到PRD之后，可以估算自己的工作量，并转化为工期。工作量=（最乐观+最悲观+最可能）/3     或者    工作量=（最乐观+最悲观+最可能*4）/6。这里的工作量粒度很细，至少精确到1人天，但是1人天通常等价于5-6人小时。

通过增加资源投入来缩短项目时间，这取决于具体情况。如果各个任务相互独立，则可以更多的并行，可以通过投入资源来缩短时间，但是如果人物之间依赖严重，则投入更多资源可能反而会延长项目时间。

3、项目中成员的沟通机制

周期：以“日”或者“周”为单位；渠道：会议、邮件等；发起者：由项目经理、开发经理、测试经理主导；参与者：注意不要遗漏项目边缘的同事。

几种常用的项目沟通方式：项目晨会、项目日报、评审会、项目变更申请、发布预告及发布。

4、誓师大会不可或缺

誓师大会上的主要内容：项目背景（明确为什么要做这个项目）；项目意义、目的与目标（解决什么问题就算成功了）；需求功能点概述；项目组织架构（关键人物都要到场，比如很重要的督导委员会成员）；项目计划（项目时间点和里程碑、各个阶段需要的资源，大家在各个阶段做什么事情）；明确沟通计划

5、全新项目入手最初的几步

首先分解任务（WBS Work Breakdown Structure），重视完整性，尽量滴水不漏（例如工作环境准备需要额外的机器等），WBS模板在书中的第126页，入职以后，要随着自己做的项目越来越多，应该一边做项目，一边形成自己的WBS模板，做到心中有“树”。

写文档

1、各种类型的文档

BRD：商业需求文档。产品生命周期中最早的文档，涉及市场分析、销售策略、盈利预测等等，通常都是给大老板演示的ppt，短小精悍，像创业者给投资人看的商业计划。

MRD：市场需求文档。更细致的市场与竞争对手分析，PD在这个阶段常见的产出物有Feather List、业务逻辑图等。

上述两个都是给老板看的，偏商业的内容。

PRD：产品需求文档。PRD是对产品功能的进一步细化，PD新人写的最多的文档。主要包括整体说明，用例文档，产品demo等。

FSD：功能详细说明。像日常写的用例文档，经常包含在PRD中（类似于业务保障的规范）。很多技术性内容在这里确定（产品界面、业务逻辑的细节，例如表格中的数字应该左、中、右对齐等）。

2、细说PRD

文档的开始是一些总体说明（修订历史、项目概述之类的，参考业务保障规范），之后是UC部分，UC部分分为以下几点：整体说明；UC正文。

UC是需求人员写给开发人员看的一种最基本的文档，UC里面要写的内容：

UC概述部分：用例唯一的标志；用例名称；业务描述；需求描述；行为者；前置条件；后置条件；其他说明。

UC主体部分：界面描述；业务规则；流程描述。

UC一般只用来描述功能需求，不便于描述系统扩展性、系统容量、人员培训非功能需求，这些内容一般写在PRD总体说明里。

3、需求文档之后的评审

需求评审：PRD评审、UC评审、Demo评审的统称，评审会上PRD上PD把PRD和UC说给开发和测试听，Demo评审由UE的同学主讲，PRD评审会重点关注商业内容，建议叫上老板、营销人员、服务人员和用户来听。

设计评审：开发工程师把对需求的理解以设计文档的形式说给PD和测试听。

测试评审：测试工程师把对需求的理解以TC的形式说给PD和开发听。

注意，需求评审会不要漏掉两种人：能做决定的人和此项目有关的产品接口人。

开发、测试、发布阶段

对于特定的项目，应该在开始前就约定好各种管理方法，比如文档如何管理、测试过程怎么管理、使用哪些技术工具等等。

开发阶段流程：设计->设计评审->编码->单元测试

测试阶段流程：TC编写->TC评审->冒烟测试->功能评审->测试

bug修复过程：

    1、bug级别定义标准：功能缺陷：Urgent、Very High、High、Medium；需求缺陷：Low

    2、bug的修复流程：p148图

    3、项目发布时，所有的bug状态必须是closed或者deferred才可以，但是对Low或者Medium级别的bug未必如此。

发布过程：

    1、发布流程：发布评审->预发布->发布->线上验证

    2、会安排专门的SVN管理员，负责项目每日的代码更新，从每位开发人员的开发环境->测试环境->预发布环境->生产环境一步步更新的。

    3、把握不大的项目，要设计”回滚“方案，一旦发布不成功及时回滚。

    4、正式的发布过程，是从更新”预发布环境“开始的，预发布环境会尽量模拟生产环境上的真实状态，例如用同一个数据库。测试人员会在预发布环境进行最后的回归测试，没问题即会更新”生产环境“，测试人员再做一次简单的回归测试，完成发布。（回归测试越做越简单，直至包含最重要TC的”最小集“）。

    5、正式发布前，可能要填写各种申请单子等等。

    6、发布之后，项目经理要尽快写一封email——“项目发布公告”，告诉大家项目已发布。

    7、写一份项目小结，对于一个几周或者两三个月的项目来说，比较适合在发布后半个月内完成。小结一下项目的心得体会，碰到了哪些问题，原因是什么，如何解决的，如何避免再犯；项目的资源评估是否合理，收货了哪些经验；根据数据监控的反馈，分析出了什么结果。

    8、为了防止项目完成后大家可能忘记做过什么，可以采用日报或者周报的形式随时记录每天的情况，到总结时就水到渠成了。

    9、书中p153有周报的模板，但是只做参考。