一、项目立项

1、什么是项目？

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

项目TRQ：项目时间time，项目资源resource、项目质量quality

2、产品经理与项目经理

对产品经理来说，最重要的是判断力和创造力，决定做不做、做什么、做多少。

对项目经理来说，最重要的是执行力和控制力，决定怎么做、谁来做、何时做。

两者要在用户需求与有限资源之间取得平衡。

3、项目立项

立项阶段

二、团队组建

1、项目组织结构

项目组织结构

注：督导委员会一般是项目成员的老板，用于申请资源的审批与项目进度的督导；服务团队负责产品帮助的编写、上线后的服务工作等；项目经理有时由PD担任。

2、分工

PD：写需求文档（PRD）；项目经理：制定项目的开发计划。

三、计划确定

1、确定工期

a）基于网页的软件，项目周期一般两周到一个月；大一点的项目，最多不超过3到4个月。

b）参考BRD中的初评工作量，再次评估并推算工期。产品会议结束到制定项目计划时，PD也在细化PRD，工作量评估可以更准确。

c）开发经理把任务分配给最合适的人；把高手调入关键路径（影响项目完成时间的关键任务）。

d）工作量=（最乐观+最悲观+最可能）/3 或者 工作量=（最乐观+最悲观+最可能*4）/6。

e）项目经理要把开发计划、测试计划、发布计划合并为项目计划，并确定项目的几个里程碑，如需求完成、编码完成、发布上线。

项目时间安排

注：TC=test case

2、项目沟通

项目晨会、项目日报、测试日报、需求评审（PD）、设计评审（开发）、TC评审（测试）、功能评审（集体）、项目变更申请、发布预告及公告。

四、项目kick off会议（KO）

1、会议内容（一般15分钟即可）

a）项目背景

b）项目意义、目的与目标

c）需求、功能点概述

d）项目组织架构

e）项目计划：时间点与里程碑、每个人要在每个阶段做什么。

f）沟通计划：确认接口人、定下沟通的规矩。

g）发送会议纪要给所有干系人

2、分解任务（WBS，work breakdown structure）

WBS模板

WBS要保证滴水不漏，如单独的会议室、额外的机器、各种福利的申请等等也要考虑到位。任何时候，都要牢记这个树状结构。图仅为树干，具体还需要分支到更细的粒度。

五、 需求文档

BRD，business requirements document：商业需求文档。内容包括市场分析、销售策略、赢利预测等，没有产品细节，通常是演示PPT的形式。

MRD，market requirements document：市场需求文档。细致的市场与竞争对手分析，包括可以通过哪些功能来实现商业目的，功能、非功能需求分哪几块、功能的优先级等。常见产出物有feature list、业务逻辑图等。

PRD，product requirements document：产品需求文档。对产品功能的进一步细化，包含整体说明、用例文档、产品demo等。

FSD，functional specifications document：功能详细说明。类似于用例文档，经常包含在PRD中，在这里产品界面、业务逻辑的细节都要确定，如表格中的数字对齐方式、保留小数位等。

六、产品需求文档

1、PRD

通常一个项目会有一到多份PRD，每份PRD包含逻辑相关的若干功能点。

PRD模板目录

2、总体说明

a）修订历史：每次修订日期、版本号、说明、作者。

b）项目概述：项目背景、意义、目的、目标等。

c）功能范围：给出本PRD的业务逻辑图，重点描述系统中角色的职责、与周边系统的关系、全局的商业规则等。

d）用户范围：对本PRD涉及的角色、系统作简要说明。

e）词汇表：对涉及的专有名词、术语、缩写等做出说明。

f）非功能需求：如性能需求、数据监控需求等。

g）其他说明

3、用例文档

a）整体说明：对本PRD的所有用例进行说明，给出用例的可视化表示，说明各个用例之间的关系，一般有类图、用例图、状态图几种表示方法。

b）用例文档：由一个个用例组成（注意要包括边界条件、判断、异常情况）。

c）对单个UC的说明：注释，如界面、交互、文案细节的引用来源。

4、UML：类图、用例图、状态图

UML，unified modeling language：统一建模语言，将软件工程的过程规范化。

a）类图（class diagram）：描述系统间出现的各个对象之间的关系，以及和外部系统间的关系。

b）用例图（use case diagram）：描述各个用例之间的关系，用例包（一组相关用例打包而成的模块）、用例和行为者（actor）之间的关系。

c）状态图（state diagram）：表述系统里的实体状态转换，同样也是贯穿多个用例的。

5、用例文档

a）用例标识：如uc_homepage，唯一标识，不能重复。

b）用例名：如管理订单。

c）业务描述：商业目标、用户目的等业务内容，说明为什么要做这个UC。

d）需求描述：产品需求，需要实现哪些功能点，这个UC要做什么。

e）行为者：该用例的actor。

f）前置条件：触发这个用例的前提。

g）后置条件：用例完成，后续动作是什么。

h）其他说明：任何其他信息，针对这个UC的特殊说明。

i）界面描述：界面截图，界面上元素的说明。

j）业务规则：整个用例的通用规则，非界面元素或流程的私有规则。

k）流程描述：分主干、分支和异常三种。描述在这个用例发生的过程中，由什么事件触发，系统和用户之间产生何种交互步骤。建议用时序图和活动图。