）项目背景
项目背景主要通过以下五个维度去详细展开说明，这样可以更为清晰的介绍项目，记为5W法：
who 目标用户
what 什么需求
where 何种场景下
why 为什么做/为什么让我们做
when 什么时候要
举例说明：
who：内部BU+外部合作伙伴
what：想要有一个服务展示平台
where：当需要调用服务接口，却找不对应的负责人时
why：因为市面上还没有这种开放类的平台，而我们底层有这些api接口，且数据量庞大、搜索精准
when：9月中之前要
（2）产品规划
所谓产品规划，可以用“仰望星空脚踏实地”来形容：
一是未来产品的终极目标（星空）
二是我们现在需要如何拆解并一步步实现（实地）
（3）商业价值
我们需要站在商业层面，通过业务模式的剖析去转化为商业价值。商业模式在大多数情况下是为盈利模式做铺垫的，纵观互联网时代，任何一家公司都不是无偿付出的
换句话说，我个人认为不以挣钱为目的的公司都不是好公司。当然这句话很有争议，但我觉得如果公司不能自负盈亏，那么就无法养活为它付出工作的人，对员工来讲就是不负责的
（4）功能/非功能需求
在这部分，我们主要是对产品的功能模块以及整体框架作概要说明。功能性需求比如：商城功能、社交功能等，非功能需求就像：交互效果、首页固定位置等
我们只负责宏观模块化认知的建立，而不用讲述具体实现的效果以及一些细节的功能点。因为那些内容是PRD所要展开说明的，我们在这里只需点到为止，明确功能框架而已
需求评审
另一个重要的会议就是需求评审，与立项会议不同的是，需求评审是所有产品迭代都不可避免的一个过程。就像针对一些小型的项目或者比较着急的功能迭代，那么基本是不会有立项会议的。而需求评审是将用户的需求转化为功能，并交由项目团队实现，可想而知，它的重要程度无可替代
需求评审的与会人员也和立项会议有所不同，参与评审的基本上都是开发、测试、市场等负责人所挑选的具体实施人员。所以，他们才是我们真正意义上为这个项目添砖加瓦的团队成员
一般会有ios、Android开发人员+前端H5+后端开发+测试+运营+市场，主体上是由这部分人所组成的，一些大型的项目也会有客服、运维、设计人员的加入
需求评审的相关内容也在之前所提及的文章中有过详细介绍，具体内容见上述链接
2、团队模式
每个公司因为工作模式、业务架构等不同因素，导致各部门的人员构成也不尽相同。纵观当今互联网公司的人员组成架构，基本上都会根据公司规模进行区分，较为普遍的分为以下三种：
大型公司 职能+项目
中型公司 项目
小型公司 职能
大型公司
规模较大的公司，比如上市公司或者员工数在100人以上的公司，大多数会以职能+项目的人员架构方式展开工作。而这一点从座位的分布位置就可以看出来，各部门比如开发、测试、产品等都按各自职能聚在一堆。这种模式可以促进同行们的信息交流，有利于成员间的学习，营造互相帮助的氛围
这种人员架构会出现双领导的情况，即产品经理为项目迭代的领导，而各部门负责人则为人事的领导。比如一个开发人员既需要在项目中按照产品的设计去开发，同时还要听从开发负责人的工作安排
每次组建团队开展项目基本都会有新的面孔，当然大多数队员都是已经共过事的，也不乏新鲜血液的融入。而具体人员名单的确定，则是由各部门直属领导所分配的
优点
可以让团队成员保持新鲜感，通过和不同风格的人员工作交流，会学习到更多知识，同时结交更多朋友
缺点
需要不断重复磨合的过程，由于每次项目都是不一样的成员，刚开始也不了解各位的水平如何，导致总要先适应一段时间才能正常工作
中型公司
市面上也有许多公司发展状况较好，员工数基本都是在50~100人之间，这种公司规模会以项目组作为人员的组织架构
这和大公司的区别就在于，中型公司是按照业务种类或者功能模块等属性进行划分的。每个项目组都是负责各自所属领域的工作，人员相对固定，项目组之间是并行独立存在的
比如滴滴打车里面，可能会按照不同的业务划分具体负责的项目组，所
