整理软件⾏业职位介绍
（PM,RD,FE,UE,UI,QA,OP,DBA,BRD,MRD,P。。。
职位概览缩写
GM(General Manager)总经理
VP(Vice President)副总裁
FVP(First Vice President)第⼀副总裁
AVP(Assistant Vice President)副总裁助理
CEO(Chief Executive Officer)⾸席执⾏官，类似总经理、总裁，是企业的法⼈代表。
COO(Chief Operations Officer)⾸席运营官，类似常务总经理
CFO(Chief Financial Officer)⾸席财务官，类似财务总经理
CIO(Chief Information Officer)⾸席信息官，主管企业信息的收集和发布
CTO(Chief technology officer)⾸席技术官 类似总⼯程师
HRD(Human Resource Director)⼈⼒资源总监
OD(Operations Director)运营总监
MD(Marketing Director)市场总监
OM(Operations Manager)运作经理
PM(Product Manager)产品经理 (Production Manager)⽣产经理
游戏开发工程师需要学什么TM( Team Manager ) PM( Project Manager ) 项⽬经理
PL( Project Leader ) 项⽬组长
TL( Team Leader ) SE( System Engineer ) 系统⼯程师 BSE( [...]
PM  项⽬经理( Project Manager )
从职业⾓度，是指企业建⽴以项⽬经理责任制为核⼼，对项⽬实⾏质量、安全、进度、成本管理的责
任保证体系和全⾯提⾼项⽬管理⽔平设⽴的重要管理岗位。项⽬经理是为项⽬的成功策划和执⾏负总责的⼈。
项⽬经理是项⽬团队的领导者，项⽬经理⾸要职责是在预算范围内按时优质地领导项⽬⼩组完成全部项⽬⼯作内容，并使客户满意。为此项⽬经理必须在⼀系列的项⽬计划、组织和控制活动中做好领导⼯作，从⽽实现项⽬⽬标。
当然在互联⽹公司这个有着项⽬经理or产品经理的意思。
RD 研发（Research and Development）
如：软件RD⼯程师就是软件研发⼯程师，诸如PHP程序猿，Java程序猿，⽆论是爱疯的还是安卓的都是属于这⼀类别。偏向于后端的技术实现。
FE  前端（Front-End）；前端开发（Front-End Development）
FE是web前端研发、前端开发的意思！前端开发⼯程师不仅要掌握基本的Web前端开发技术，⽹站性能优化、SEO和端的基础知识，⽽且要学会运⽤各种⼯具进⾏辅助开发以及理论层⾯的知识，包括代码的可维护性、组件的易⽤性、分层语义模板和浏览器分级⽀持等。
UE  ⽤户体验（User Experience，简称UX或 UE）
是⼀种纯主观的在⽤户使⽤⼀个产品（服务）的过程中建⽴起来的⼼理感受。因为它是纯主观的，就带有⼀定的不确定因素。个体差异也决定了每个⽤户的真实体验是⽆法通过其他途径来完全模拟或再现的。但是对于⼀个界定明确的⽤户体来讲，其⽤户体验的共性是能够经由良好设计的实验来认识到。
计算机技术和互联⽹的发展，使技术创新形态正在发⽣转变，以⽤户为中⼼、以⼈为本越来越得到重视，⽤户体验也因此被称做创新2.0模式的精髓。
另外还有有个组合叫法：UED（产品交互设计师，⽤户体验师）。
UI  ⽤户界⾯（User Interface）
UI设计则是指对软件的⼈机交互、操作逻辑、界⾯美观的整体设计。好的UI设计不仅是让软件变得有个性有品味，还要让软件的操作变得舒适、简单、⾃由、充分体现软件的定位和特点。
UI还有其它的意义，如Unit Interval，Univ of Iowa，Unlock Instruction，Urgent Interrupt。
QA  测试（QUALITY ASSURANCE，中⽂意思是“质量保证”）
其在ISO8402：1994中的定义是“为了提供⾜够的信任表明实体能够满⾜质量要求，⽽在质量管理体系
中实施并根据需要进⾏证实的全部有计划和有系统的活动”。有些推⾏ISO9000的组织会设置这样的部门或岗位，负责ISO9000标准所要求的有关质量保证的职能，担任这类⼯作的⼈员就叫做QA⼈员。
OP  运维（Operations）
OP这个词语代表的意思很多，这个简称来⾃于英⽂的Operations⼀词。我也不清楚谁最早⽤op代表运维⼯程师，不过2010年开始，这个词慢慢被很多⼈所知道。
OP⼯作内容主要就是维护公司的服务器能够正常提供服务，细分的话包括系统部分，⽹络部分，应⽤程序部分，数据库部分，具体根据公司的规模和职位职能不同，运维的定义也不同。现在市⾯上主要的OP有三种：⽹络游戏运维，⽹站运维，⼤型项⽬测试和⽣产环境运维。
DBA  数据库管理员（Database Administrator，简称DBA）
是⼀个负责管理和维护数据库服务器的⼈。数据库管理员负责全⾯管理和控制数据库系统。这个职位对不同的⼈意味着不同的意义。
另外还有DB，既数据库（Database）。
BRD  商业需求⽂档（Business Requirement Document）
是基于商业⽬标或价值所描述的产品需求内容⽂档(报告)。其核⼼的⽤途就是⽤于产品在投⼊研发之前，由企业⾼层作为决策评估的重要依据。其内容涉及市场分析，销售策略，盈利预测等，通常是供决策层们讨论的演⽰⽂档，⼀般⽐较短⼩精炼，没有产品细节。
BRD不同于常见的MRD和PRD，既然是⽤于产品实施之前的决策评估依据，必然对其⽂档（报告）的内容和格式要求够直观、精炼，要点突出。作为报告的撰写者，你必须让⾼层明⽩，你的报告中将展现出怎样的商业价值，如何⽤有⼒的论据来说服企业对你这个项⽬的认可，并为之慷慨的投⼊研发资源及市场费⽤。如果说PRD的好坏，直接决定了项⽬的质量⽔平，那么BRD的作⽤，就是决定了你的项⽬的商业价值。优秀的BRD⽂档，可以让决策层充分被你的报告观点所吸引，或许财务主管会因为报告呈现的低投⼊⾼产出的经济效益预测⽽蠢蠢欲动；或许技术主管会因为项⽬的牵涉⾯⼴泛⽽头疼不已；⼜或许公司的VP之流因之报告⽽看到了未来⼀年业绩的飞速发展的⼴阔前景……说⽩了，BRD需要产品经理（产品设计师）像对待PRD⼀样，充分应⽤市场调查、⽤户研究、需求分析等各种设计⼿段来充分阐述报告的内容。
MRD　市场需求⽂档（Market Requirements Document）
获得⽼⼤的认同后，产品进⼊实施，需要先出MRD，具体来说要有更细致的市场与竞争对⼿分析，通过哪些功能来实现商业⽬的，功能/⾮功能需求分哪⼏块，功能的优先级等等。实际⼯作中，这个阶段PD可能的产出物有Mind Manager的思维图，Excel的Feature List等。
⽂档意义：该⽂档在产品项⽬中是⼀个“承上启下”的作⽤，“向上”是对不断积累的市场数据的⼀种整合和记录，“向下”是对后续⼯作的⽅向说明和⼯作指导。⽂档核⼼：侧重的是对产品所在市场、客户（client）、购买者（buyer）、⽤户（user）以及市场需求进⾏定义，并通过原型的形式加以形象化
撰写MRD，⼤致下⼏个⽅⾯（按先后顺序）着⼿：
1、项⽬背景；
2、名词解释；
3、可⾏性分析（前期调研信息和数据+项⽬预期⽬标）；
4、综合描述（功能概述+对其他产品的影响）；
5、功能详述（功能需求+功能点）；
6、其他问题描述。
4⽂档核⼼
  市场需求⽂档（MRD）重点放在为⼀个被提议的新产品或者现有产品的改进定义市场需求。与BRD
指出商业问题和解决这些问题的解决⽅案不同，MRD更深⼊提议解决⽅案的细节。它包括⼀些或者所有这些细节：
a. 解决商业问题所需要的特⾊
b. 市场竞争分析
c. 功能和⾮功能需求
d. 特⾊/需求的优先级
e. ⽤例
  MRD通常是由拥有产品经理，产品营销经理或者⾏业分析师头衔的⼈撰写的。MRD通常是⼀份连续的5-25页Word⽂档，或者正如之后描述那样在⼀些机构中甚⾄更长。
PRD　产品需求⽂档（Product Requirements Document）
进步⼀细化，这部分是PD写得最多的内容，也就是传统意义上的需求分析，我们这⾥主要指UC（use case）⽂档。主要内容有，功能使⽤的具体描述（每个UC⼀般有⽤例简述、⾏为者、前置条件、后置
条件、UI描述、流程/⼦流程/分⽀流程，等⼏⼤块），Visio做的功能点业务流程，界⾯的说明，demo等。Demo⽅⾯，可能⽤dreamweaver、ps甚⾄画图板简单画⼀下，有时候也会有UI/UE⽀持，出⾼保真的demo，开发将来可以直接⽤的那种。
  ⽂档意义：该⽂档在产品项⽬中是⼀个“承上启下”的作⽤，“向上”是对MRD内容的继承和发展，“向下”是要把中的内容技术化，向研发部门说明产品的功能和性能指标。⽂档核⼼：侧重的是对产品产品功能和性能（即“产品需求”）的说明，相对于MRD中的同样内容，要更加详细，并进⾏量化。通常在特点和功能需求上更深⼊细节，并也可能包括屏幕截图和⽤户界⾯流程。在那些MRD不包括具体需求和⽤例的机构中，PRD就包含这些具体内容。在⼀些国外的公司，是允许把MRD和PRD合并成⼀个⽂档的，通常叫做“Marketing & Product Requirements Document”。该⽂档⼀般可以包括以下内容：
该产品的远景⽬标（vision）
⽬标市场和客户（target market and customers）的描述
竞争对⼿分析（competitive summary）
对产品主要feature的⽐较详细的描述
这些feature的优先级
初步拟定的实现进度安排。
⽤例（use cases），这可以是较粗略的⼤致描述，未必⼀定要UML Use Case图。
产品的软硬件需求
产品的性能要求
销售⽅式上的思路、需求（直销还是渠道？直销怎么做？渠道怎么做？）
技术⽀持⽅式上的思路、需求（提供什么样的技术服务？）
开发⼯具推荐 ：
Rational Rose★★★★－－熟悉项⽬发⽣的相关业务⾏为。
visio 2007★★★★－－将业务，从产品层⾯肢解开来，做到抽丝剥茧部分与整体统⼀
mind manager★★★－－把项⽬条⽬化，条理化，⽬录结构具体规定好。
Axure★★★－－前台结构布局，合理规范的将系统脱去朦胧的华纱。
Word★★★★★--穿针织⽹，把需求综合起来，整理成最终的产品需求⽂档。
产品需求⽂档（PRD）重点放在为⼀个被提议的新产品或者现有产品的改进定义市场需求。与MRD侧重于从市场需要⾓度看需求的不
同，PRD侧重于从产品本⾝⾓度看待需求。通常在特点和功能需求上更深⼊细节，并也可能包括屏幕截图和⽤户界⾯流程。在那些MRD不包括具体需求和⽤例的机构中，PRD就包含这些具体内容。
在PRD中，只重视“产品功能”的描述，⽽缺乏对产品其它指标项的说明。在⼀个完整的PRD中，⼀共需要对产品的10个产品需求项指标进⾏说明，分别是“功能要求、开发要求、兼容性要求、性能要求、扩展要求、产品⽂档要求、产品外观要求、产品发布要求、产品⽀持和培训要求、产品其它要求”。
PRD通常是由拥有产品经理，⾏业分析师或者产品分析师头衔的⼈撰写的。PRD通常是⼀份连续的20-50页Word⽂档，或者针对复杂产品甚⾄更长。
  提醒：⼀些机构将这⾥描述的MRD和PRD合并成⼀个⽂档，并称最后的⽂档为MRD。在这种情况下，MRD包括本段描述的内容，也包括上⼀段描述PRD的内容，并且可能超过50页。
FSD　功能详细说明（Functional Specifications Document）
有⼀点像“概要设计”，这步就开始往开发衔接了，产品UI、业务逻辑的细节都要确定，细化⽂档并保持更新。相应的，有很多内容，⽐如表结构设计，要由项⽬经理来编写了。
  功能规格⽂档（FSD）把焦点集中在实现，定义产品功能需求的全部细节。FSD可能通过⼀张张的截屏和⼀条条功能点来定义产品规格。这是⼀份可以直接让⼯程师创建产品的⽂档。
与MRD和PRD侧重于以市场需要和产品⾓度看需求不同，FSD把重点放在了以表格形式定义产品细节，再让⼯程师实现这些细节。FSD 也可能包括完整的屏幕截图和UI设计细节。
FSD通常是由拥有产品分析师，⼯程领导或者项⽬经理头衔的⼈撰写的 – 作者通常属于⼯程部门。通常⼀个连续⼏⼗页的Word或类似⽂档。
项⽬开发⼈员结构：
项⽬最顶层是项⽬负责⼈，接下来项⽬会落实到PM(项⽬经理PM)，项⽬经理将任务分成若⼲个⼦项⽬，每个项⽬由⼀个PL(项⽬组长)负责。在每个⼦项⽬中，由SE(系统⼯程师)带领PG(程序员)共同完成。
其中，PM和PL⼀般为具有资深项⽬管理经验、长期开发实践和良好交流能⼒的⾼级技术⼈才。SE需要具有独⽴的设计和提案能⼒，具有长期开发实践经验和交流能⼒。⼀般⼜可分为三种类型：第⼀种，
纯技术型SE，这种⼈往往会成为技术专家；第⼆种，技术兼管理型SE，将来有希望成为PL、PM，甚⾄更⾼级的职位。Bridge型SE(BSE)，通常是负责与客户的沟通，以及团队内的协调⼯作。
PG（ProGramer），也就是程序员，这类⼈才在企业中所占数量最多，通常占到了整个项⽬员⼯数的70%，也是企业中最紧缺的⼀类职位，⼀般为具有专业知识的软件⼯程技术⼈员。通常，理⼯科的⼤学毕业⽣通过短期培训后，都可以胜任这个职位。
各职位具体职责:
⽬的：明确项⽬组各相关⼈员责任和权⼒，明确任务分⼯，降低各⾓⾊之间协调的成本，提⾼开发效率。
（1） 项⽬经理（代表公司执⾏项⽬管理，进⾏整个项⽬的协调⼯作，对项⽬成败直接负责的⼈员）
职责（对项⽬成败及收益负全责。）：
1、  制定产品的⽬标。
2、  制定各个⼯作的详细任务表，跟踪这些任务的执⾏情况，进⾏控制。
3、  组织会议对程序进⾏评审。
4、  综合具体情况，对各种不同⽅案进⾏取舍并做出决定。
5、  协调各项⽬参与⼈员之间的关系。
⼈员要求：
对产品有激情，具有领导才能。
对问题能正确⽽迅速地做出确定。
能充分利⽤各种渠道和⽅法来解决问题。
能跟踪任务，有很好地⽇程观念。
能在压⼒下⼯作。
项⽬经理负责分配资源，确定优先级，协调与客户和⽤户之间的交往。总⽽⾔之，就是尽量使项⽬团队⼀直集中于正确的⽬标。项⽬经理还要建⽴⼀套⼯作⽅法，以确保项⽬⼯件的完整性和质量。⼯作内容细分：
5⼤过程管理：（摘⾃PMPBook）
a)        项⽬启动过程，
b)        项⽬规划过程，
c)        项⽬执⾏过程，
d)        项⽬监控过程，
e)        项⽬收尾过程。
9⼤领域管理：（摘⾃PMPBook）
a)        项⽬整体规划，
b)        项⽬范围管理，
c)        项⽬时间管理，
d)        项⽬费⽤管理，
e)        项⽬质量管理，
f)        项⽬⼈⼒资源管理，
g)        项⽬沟通管理，
h)        项⽬风险管理，
i)          项⽬采购管理。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。