产品VS项目

项目定义：是只会进行一次，包含多项目关联的任务，并且有绩效、时间、成本和范围限制的工作。
本质上来讲：产品是解决某个问题的东西，而项目是一个过程。
从以下几点可以看出一个产品和项目的区别：

1. 从生命周期的角度来看，我们做一个产品的时候，没法确定一个产品到底什么时候完结，因此，会有一个已经“结项” 的项目，但不会有一个已经“完成” 的产品（只有不断完善的产品，除非被新的产品进行替代）。
2. 从具体做的事情来看，我们产品的负责人会不断地修正自己的判断，给出适宜的创新，而项目在开始时就已经有明确的目标，更注重计划与控制，项目更像是在执行一个过程，而产品更像是区创造某个东西。
3. 从具体产出的东西来看，产品是可以批量生产或者可以满足大批量用户的，所以相对通用，而项目则是只执行一次并且满足特定的需求而产生的，不一定是产品。

产品经理和项目经理

二者都叫做PD，只不过一个是Product Manager，一个是Project Manager
产品经理——靠想法，产品经理是做正确的事情，其所领导的产品是否符合市场的需求，能否给公司带来利润。
项目经理——靠做，项目经理是把事情做正确，把事情做完美，在时间、成本和资源约束条件下完成目标。
在公司中，我们总会让产品经理兼任项目经理，或者让项目经理兼任产品经理。这会导致的问题是
产品经理会导致不断地给项目增加需求，导致项目总是无法按期完成，而项目经理呢为了完成项目那么就有可能追求更小的工作范围而忽略了更好的满足用户的需求，使得整个产品做出来比较挫。
但一个事物必然有它的正反两面，如果你只看到了一面，说明你只看到了系统的一部分，这时你一定要跳出去，寻找另一面，之后再努力寻找“对立”背后的“统一”，正如黑格尔所说的正反和。
作为产品经理和项目经理来说，如果认识到问题的本质和公司的良苦用心，也就无须在形式上过分地在意到底是谁来做项目管理了。
好的项目经理明白，一个项目真正的成功并不是看它是否能在规定的时间和预算完成，而是它是否达到了拟定目标。好的产品则明白，如果项目被不断地延期并且从未投入市场，又或者因为大大超过预算而被结束，那么所有的产品功能特征就会变得毫无意义。

一切项目从kick off 开始

首先，明确做项目的本质是在保证品质的前提下，在时间要求、人财物话费、项目范围三点上做平衡。

一切项目都要从kick off 说起。

工作量预估

但不要忘记了，我们需要对工作量进行预估
需要从工作量中推算出“工期”，工作量 = （最乐观+最悲观+最可能*4）/6
按照经验‘1人天’通常等价于5-6“人小时”，我们不能够按照一天8个小时去算，因为人的精力是有限的，注意力集中的时候大致也就5-6个钟头罢了。。

Kick Off的大致也就15分钟

一般的Kick Off 大致也就十五分钟，需要传达的信息也就以下几点罢了：

1. 项目背景
   我们在哪里？说过去，做项目之前的“悲惨境地”，明确为什么要做这个项目，以让听众“通下决心”为终极目标。
2. 项目意义、目的与目标
   我们去哪里？说将来，做项目之后的美好前景，解决了什么问题就算是成功了？以让听众“面带桃花”为终极目标。
3. 需求、功能点概述
   我们怎么去？说现在，具体用什么方法促使“过去”到“将来”的转变，以让听众“跃跃欲试”为终极目标。
   上面这三点与BRD里的项目背景、商业价值、需求描述大同小异，但以下这三点就是新鲜的了。
4. 项目组织架构
   关键人物必须要到场，项目的早期，务必要让老板多多参与，反复确认正确的方向，这时候做各种的调整，成本都比较低，注意不要漏掉了边缘的工作人员。
5. 项目计划
   让所有人都必须要了解两个关键点，
   第一：项目的时间点与里程碑
   第二：各个时段需要的资源，即每个人在各个阶段做什么事情。
6. 沟通计划
   项目的沟通非常重要，因为大多数事情的不顺利都是沟通的问题。

写文档咯

我们来看以下PD到底要写那些文档吧。
BRD：Business Requirements Document 商业需求文档，其中包括，市场分析、销售策略、盈利预测等。通常是给大老板演示的PPT。
MRD：Market Requirements Document 市场需求文档，获得老板的支持之后，我们需要写出MRD，要有更细致的市场分析和对手分析，包括可通过那些功能来实现商业目的，功能、非功能需求分哪几块，功能的优先级等。PD在这个阶段阶段产出Feature List 、业务逻辑图等，这是从商业目标到技术实现的关键转化文档。
PRD：Product Requirements Document 产品需求文档，PRD是对产品功能的进一步细化，文档主要包含整体说明、用列文档、产品demo。
FSD：Functional Specifications Document 功能详细说明， 比较像是用列文档，经常包含在PRD中，从这步开始很多技术内容，产品界面、业务逻辑细节要确定，比如网页上某个表格应该是左、中、右对齐？保留几位小数？，一次同时硬件系统的设计、数据库的设计、表结构的设计也将会被编写。

UML图

UML unified Modeling Language ，统一建模语言。
包括状态图、类图、用例图、时序图、活动图。
类图，描述各个对象之间的关系

用例图，包含各个用例的关系

状态图，表达系统里实体的状态转换

时序图，描述事物变化在时间维度上的先后顺序，善于表达对象的交互。

活动图，比较接近我们常说的流程图，描述各种动作如何引起系统的变化

用例文档UC

参考UC模板

demo也得做

可以找一个白板，简单画一画，大家可以开始沟通了。

需求活在项目中

做过的项目中，最重要的三种角色就是PD、开发人员、测试人员，所以大致有三种评审——需求评审、设计评审、测试评审。
说白了哈，评审就是项目中相关的几个小团队坐在一起，一方讲，另外几方听并且确认，统一认识，消除误解，及时发现偏差，防止问题随时间扩大。
有的小伙伴可能认为不做评审会更好，但这样子看似省了时间，实则隐藏着巨大的问题，待到其爆发的时候会耽误更多事情。

下面来一个具体的日常开发流程

bug等级有多高

我们将bug等级分为五个等级，其中缺陷类型分为功能缺陷和需求缺陷，如下：

bug流转过程

以终为始

发布成功，所有人可以回家睡个好觉了！
所有人终于舒了一口气，但作为一个合格的项目经理，事情还没完。
第一件事情就是赶紧发布一封E-mail“项目发布公告”。
之后，写一份项目小结，比如碰到了那些问题，原因是什么，怎么解决的，如何避免再犯，分析出了什么结果，项目的商业目标是否达到等。