PM：产品经理，项目负责人。一个产品，首先由PM来分析细分市场、目标客户的诉求，规划产品的卖点、杀手级应用，这个过程通常PD已经介入了，这个层面上，商业问题、业务逻辑的流畅是思考的焦点。
举凡产品从创意到上市，所有相关的研发、调研、生产、编预算、广告、促销活动等等，都由产品经理掌控。
擅长：PPT和高层确认战略。project。
PD：产品设计师，也可能叫产品规划师、需求分析师。PD侧重于将一个个杀手级应用做功能级的设计，需要细化考虑到每一个场景下该应用的限制反应等，比如边界值、全选操作功能。在这个模块上，PD类似是一个小产品经理。技术团队中的架构师（或者系统分析师，也可能叫项目经理、开发组长）会与PD紧密合作，这时候开始考虑技术可行性，性价比。
擅长：word写文档 。Visio、Axure（基于网站构架图的带注释页面示意图、操作流程图、以及交互设计，并可自动生成用于演示的网页文件和规格文件，以提供演示与开发）原型设计工具
QA: Qualtiy Assurance，品质保证。QA的主要职责就是质量保证工作。
UE：User Experience 用户体验，可能称作交互设计师、界面设计师。UE负责产品和用户交互方面的设计，这方面在技术部门的配合角色应该是前端工程师（web表现层）。通常UE拿到case的时候，要做什么功能已经决定了，PD与UE要充分沟通，UE必须要了解很多商业层面的内容，理解功能的商业价值。举个例子，比如在商业目的是“注册用户数”的前提下，设计注册流程是一页搞定还是分几个“下一步”，出错提示是js弹出还是页面即时判断……
擅长：Dreamweaver做网页
UI：User Interface 用户界面，可能也叫界面设计师、视觉设计师，很多小作坊简称美工，与UE的界限在很多时候是模糊的。到了UI层面，基本是界面的表现，是用户第一眼看到的效果，比如配色、页面结构、按钮形状、字体字号等等。
擅长：PhotoShop做图
注：
PM、PD、UE与UI，分别是产品经理、产品设计师、用户体验师、视觉设计师四个角色。一般来说，这个顺序就是一个产品从规划到最终成型的任务流方向，是一个从抽象到具体、商业到技术的过程。
当然上面这个过程不是静态的，一方面产品设计的流程是可以并必然要反复、迭代的，另一方面各个角色的分工有时候是模糊的，对上下游的业务也必须有所了解。
UCD User-Centered Design 以用户为中心的设计
UED User-Experience Design 用户体验设计
RD Research and Development engineer，研发工程师，对某种不存在的事物进行系统的研究和开发并具有一定经验的专业工作者,或者对已经存在的事物进行改进以达到优化目的的专业工作者。
FE: FE有多种解释，在实体经济中，FE可以指Facility Engineer，厂务工程师，主要负责工厂的外围的一些支持系统。在网络经济中，FE可以指Front-End Development，前端开发，新新职业。
BRD Business Requirement Document 商业需求描述，是基于商业目标或价值所描述的产品需求内容文档。核心的用途就是用于产品在投入研发之前，由企业高层作为决策评估的重要依据。BRD是产品生命周期中最早的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是供决策层们讨论的演示文档，一般比较短小精炼，没有产品细节。
MRD Market Requirement Document，市场需求文档。 该文档在产品项目中是一个“承上启下”的作用，“向上”是对不断积累的市场数据的一种整合和记录，“向下”是对后续工作的方向说明和工作指导。作用是：产品项目由“准备”阶段进入到“实施”阶段的第一文档，其作用就是“对年度产品中规划的某个产品进行市场层面的说明”，这个文档的质量好坏直接影响到产品项目的开展，并直接影响到公司产品战略意图的实现。
PRD Product Requirements Document 产品需求文档。是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。
注：
1.MRD侧重的是对产品所在市场、客户（client）、购买者（buyer）、用户（user）以及市场需求进行定义，并通过原型的形式加以形象化
2.PRD要把MRD中的“产品需求”的内容独立出来加以详细的说明，而产品需求本身是在MRD中有所体现的
3.如果说PRD的好坏，直接决定了项目的质量水平；那么BRD的作用，就是决定了你的项目的商业价值。
BD Bussiness Development，行政公关。BD的职责主要包括两方面，一是负责与运营商之间的沟通，如新业务的申报等；再就是公关，与运营商的一些负责人搞好关系。
UC评审 需求评审。在需求完成以后，是PD说给开发、测试听
设计评审 设计完成之后，是开发把对需求的理解以设计文档的形式说给PD、测试听，这部在时间紧的情况下会被省略（代码评审现在几乎不做）；（iamsujie补：开发很强可省，他们在需求评审时会问很多；开发较弱、新人、业务不熟则必须。）
TC评审 测试用例评审。在TC写完测试开始之前，是测试把对需求的理解以TC的形式说给PD、开发听
注：
评审主要过程：
1.确定参加人员，并提前进行通知：注意两种容易被漏掉的角色：一是能做决定的人，因为评审的时候各方不可避免的会对业务有不同理解，从而开始对需求细节进行讨论，这时候就需要有人能拍板，有人能负责；二是与此系统有接口的其他项目的成员。太晚发现冲突，改起来成本很高；
2.事先分发文档： 保证参加评审的人有足够的时间阅读并思考，每个参加者也要做好功课，带着问题参加，否则评审是没有效率的，避免出现评审会上第一次看到相关文档的情况发生；
3.协调资源 ： 资源包括时间、地点、设备，通常大家都很忙（包括会议室和投影仪），找个时间不容易；
4.评审产物：评审会本身，没问题就快速的通过，有小问题当场确认，大问题带回去，需要再次评审；最后是评审结果的发出，项目继续往下走。（iamsujie补：开会必须有产出物，否则想想这个会是否有必要开。）