一、项目立项
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要保证滴水不漏，如单独的会议室、额外的机器、各种福利的申请等等也要考虑到位。任何时候，都要牢记这个树状结构。图仅为树干，具体还需要分支到更细的粒度。
五、 需求文档
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包含逻辑相关的若干功能点。
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）流程描述：分主干、分支和异常三种。描述在这个用例发生的过程中，由什么事件触发，系统和用户之间产生何种交互步骤。建议用时序图和活动图。
