整理软件行业职位介绍（PM,RD,FE,UE,UI,QA,OP,DBA,BRD,MRD, PRD,FSD等）、组织结构、职责

职位概览缩写
 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中的同样内容，要更加详细，并进行量化。通常在特点和功能需求上更深入细节，并也可能包括屏幕截图和用户界面流程。在那些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)          项目采购管理。
 

 

（2）构架设计师

构架设计师负责在整个项目中对技术活动和工件进行领导和协调。构架设计师要为各构架视图确立整体结构：视图的详细组织结构、元素的分组以及这些主要元素组之间的接口,最终的部署等。因此，与其它角色相比，构架设计师的见解重在广度，而不是深度。

 

（3）需求分析员（与客户业务人员进行业务需求沟通，引导业务人员进行系统需求提出的人员。）

业务分析员通过概括和界定作为建模对象的组织来领导和协调业务用例建模。例如，确定存在哪些业务主角和业务用例，他们之间如何交互。通过描述一个或几个用例的需求状况以及其他支持软件的需求来获取系统功能某一部分的规约。还要负责用例包并维护该用例包的完整性。

职责（  对需求正确性和完备性负全责。）：

a、进行需求沟通：与业务人员深入沟通业务需求，确定软件需求限制和软件同其它系统接口细节。

b、发起讨论：与业务进行重大需求讨论和确认前，应与项目组内部干系人进行需求讨论，达成一致，避免出现不合理需求。

c、出具需求规格说明书：出具完整描述业务需求、无歧义、可执行的需求文档。

d、维护需求状态。

e、解答项目组内其他人员关于需求的疑问。

f、屏蔽业务人员对开发人员的干扰，使得开发人员可专注于系统实现。

 

人员要求：担任系统分析员的人员应该善于协调，并且具有良好的沟通技巧。担任此角色的人员中必须要有具备业务和技术领域知识的人才。

 

 

（4）软件设计师

设计员定义一个或几个类的职责、操作、属性及关系，并确定应如何根据实施环境对它们加以调整。此外，设计师可能要负责一个或多个设计包或设计子系统，其中包括设计包或子系统所拥有的所有类。编写部分模块设计文档和代码，检查软件工程师编写的模块代码。

职责：

1、  定义类的方法和属性以及各个类之间的关联，画出类图。

2、  进行数据库设计。

人员要求：    掌握面向对象分析与设计技术，统一建模语言(UML)。

 

 

（5）UI设计师

界面设计人员通过以下方法来领导和协调 Web 界面的原型设计和正式设计：获取对 Web 界面的需求（包括可用性需求），构建 Web 页面原型，使 Web 界面的其他涉众（如最终用户）参与可用性复审和使用测试会议，复审并提供对 Web 界面最终实施方案（由其他开发人员员创建，如设计师和实施工程师）的适当反馈。

 

 

（6）软件工程师

软件工程师负责完成设计师的设计意图，根据设计文档编写代码；根据设计文档编写单元测试代码，根据测试报告BUG记录修订BUG，完成包或子系统的开发。

职责（对系统功能代码质量负全责，掌握功能发布状况。）：

•   需求沟通：与需求人员沟通需求，了解需求细节。
•   需求评审：评审需求人员编写的需求规格说明书，共同把控需求质量。
•   系统设计：根据需求规格说明书进行系统功能设计，出具可执行的详细设计文档。
•  发起评审：重大功能或核心算法，在编码前，应主动提起设计评审，让项目组相关人员相互取长补短，共同把控系统质量。
•   编码：根据详细设计文档进行系统编码工作，实现需求功能。
•   单元测试：对自己开发的功能进行单元测试，确保功能的正确性。
•   功能发布：负责正确填写更新列表，跟踪功能发布状况。
•   DAT验证测试：接收到配置管理人员更新完毕的通知后，在DAT进行功能验证，确保更新完整性。
•   BUG修改：修改DAT和UAT发生的BUG，及时发布，并跟踪BUG复测情况。
   

注：开发人员享有拒绝权：

若发生需求描述不明确，或与系统不兼容，甚至不能实现等需求问题，开发人员有权利拒绝本需求的开发，并与需求人员沟通提起需求的再分析。若接收到的BUG非系统功能问题，开发人员可进行拒绝处理，并根据实际情况进行解释或提起讨论分析。

 

 

（7）测试工程师

职责： 执行测试，描述测试结果，提出问题解决方案。

B.        需求评审：评审需求人员编写的需求规格说明书，共同把控需求质量。

C.        理解需求：深入理解需求人员给出的需求规格说明书，掌握业务需求要点。

D.       编写测试案例：编写能覆盖需求内容、且能覆盖绝大部分业务行为的测试案例。

E.        发起评审：重大功能或核心功能的测试案例应发现评审，共同把控案例完备性。

F.        执行测试案例。

G.       复测BUG。

H.       出具测试报告：给出能否更新UAT的结论，若不能更新UAT，需给出哪些点不能更新。

 

什么叫测试工程师或质量小组：小组的责任当然是发现在开发中所出现的技术问题和错误，及时的向项目小组报告情况，并督使项目小组相关的开发人员解决被发现的问题。质量小组的人员的组成，当然首先会是开发小组中的全部技术人员。除此以外可以邀请公司里其他非项目小组的同事加入发现问题的队伍。一般项目的质量测试有以下4个过程： 

   　A、白盒测试：就是项目的开发人员自己在平时的开发中，或者是在一个小模块开发完成后。测试自己的所开发模块的过程。其测试内容主要是自己原代码的完整性和规范性，自己开发的模块流程是否清晰、逻辑正确等等。 

   　B、黑盒测试：由开发小组的人员互相交换或者在空闲时间干脆请公司里非开发项目小组的同事来帮助测试各个模块。重要的内容是：检查各个模块的连接是否紧密，各个超级连接是否正确，软件中是否有JS等报错，表单区域中的文本筐等和用户交互的部分是否有长度的限制？是否有超文本语言的过滤？是否有非法字符的验证？在用户填写相关信息出错的时候，程序是否有相关的处理等等。 

   　C、用户测试：主要是邀请本项目外的其他同事以用户的角色来测试项目的功能。其内容主要是：评价每个模块的风格和项目的总体的风格是否冲突？功能是否能否实现，流程是否清晰，界面是否友好，页面安排是否舒适？各种连接所放的位置是否舒适等等。 

   　D、负载测试：当项目看来可以很好的工作了，就可以开始负载测试的阶段。项目小组这个时候应该在公司和客户的帮助下，安排尽量多的用户登陆开发基本完成的项目，使项目尽可能的承受长时间和高强度的测试。这个时候往往会发现相当多的问题（特别是以程序为主的WEB站点）。比如程序运行时服务器出现内存溢出？CUP资源占用瞬间涨满？两个用户在数据库中查询同一数据时造成冲突？一些查询过程时间过长？甚至是一些客户端脚本与浏览器版本不兼容等等。 

   　在质量小组每完成一步测试的时候，都要详细的写好测试结果，测试环境以及问题描述的报告直接交给项目经理，再由项目经理了解大概情况分发给问题相关的开发人员并监督其解决问题。

注1：测试人员享有拒绝权：

若开发人员提交DAT的功能有阻断性BUG或严重BUG较多，测试人员可拒绝相关功能的测试，等待开发人员调整系统。（严重Bug较多：按功能工作量，平均每天发生一个严重Bug）

注2：测试人员享有免责权：

若测试报告为不能更新UAT，但经项目经理及客户同意，将该功能更新到UAT，则测试人员可不对测试报告中提出的不能更新的功能点负责。

人员要求：了解被测试的系统，具备诊断和解决问题的技能，编程技能
 

 

（8）实施工程师

负责软件产品安装调试和部署，完成项目相关系统工程工作，负责客户技术支持，负责编写系统部署方案和使用手册、维护手册，负责系统实施计划和规划。

 

 

学习整理自：
 

http://www.manro.com.cn/news/article.php?colid=222&id=280

https://blog.csdn.net/neikutaixiao/article/details/40819445

https://blog.csdn.net/rootless/article/details/5069726

https://blog.csdn.net/nishiwodeangel/article/details/11367507