今天给大家梳理下，完全从个人认知的角度，有不准确的地方，请大家斧正！
缩写注解GM(GeneralManager)总经理VP(VicePresident)副总裁FVP(FirstVicePresident)第一副总裁AVP(AssistantVicePresident)副总裁助理CEO(ChiefExecutiveOfficer)首席执行官，类似总经理、总裁，是企业的法人代表COO(ChiefOperationsOfficer)首席运营官，类似常务总经理CFO(ChiefFinancialOfficer)首席财务官，类似财务总经理CIO(ChiefInformationOfficer)首席信息官，主管企业信息的收集和发布CTO(Chieftechnologyofficer)首席技术官类似总工程师HRD(HumanResourceDirector)人力资源总监HRBP(HRBusinessPartner)人力资源业务合作伙伴OD(OperationsDirector)运营总监MD(MarketingDirector)市场总监TL(TeamLeader)部门经理/团队负责人PM(ProductManager)产品经理RD(ResearchandDevelopment）研发工程师BD(BusinessDevelopment)商务运营UE(UserExperience)交互体验师UI(UserInterface)用户界面设计师QA（QualityAssurance)测试工程师OP(Operations)运维工程师DBA(DatabaseAdministrator)数据库管理员由于篇幅的原因，就列举出这样职位缩写，如果有没有提到名字的岗位，请大家千万不要误会！小编一直笃信：每个人每个岗位在公司中都会起到相应的作用，不必说离不开谁，但起码我们都付出了劳动与汗水，一定会体现出应有的价值！下面我们深入介绍下，表格中下半部分的职位，毕竟这些职位都是和我们息息相关的，平常日常工作中高概率接触的，至于上半部分职位，我们就把它们当成我们的职业目标，深深地默默地埋藏在心底，就好了~我们先来聊一聊HR和HRBP，刚入职的时候，成天和HR斗智斗勇，从来没有听过HRBP的概念啊，可能是当时的公司小？或者是当时还没有流行HRBP这个岗位？不甚了解啊，至于这两个岗位什么区别，请看这个图：PM产品经理(ProductManager)
在互联网企业中，PM通常被理解为产品经理的意思，刚入职场的时候，一度认为PM是项目经理(ProjectManager)的意思，好高大上的感觉，从此立志把成为一名合格的PM作为我职场的第一课，可“入坑”了，也就那么回事吧，哈哈，戏言，纯属戏言~我还是很爱我的职业和岗位的，毕竟一直以能提高产品变现能力，实现营收最大化为己任….咳咳RD研发工程师(ResearchandDevelopment)
软件RD工程师就是软件研发工程师，诸如PHP程序猿，Java程序猿，无论是爱疯的还是安卓的都是属于这一类别。偏向于后端的技术实现。FE前端（Front-End）；前端开发（Front-EndDevelopment）
FE是web前端研发、前端开发的意思！前端开发工程师不仅要掌握基本的Web前端开发技术，网站性能优化、SEO和服务器端的基础知识，而且要学会运用各种工具进行辅助开发以及理论层面的知识，包括代码的可维护性、组件的易用性、分层语义模板和浏览器分级支持等。UE用户体验（UserExperience，简称UX或UE）
UE是一种纯主观的在用户使用一个产品（服务）的过程中建立起来的心理感受。因为它是纯主观的，就带有一定的不确定因素。个体差异也决定了每个用户的真实体验是无法通过其他途径来完全模拟或再现的。但是对于一个界定明确的用户群体来讲，其用户体验的共性是能够经由良好设计的实验来认识到。另外还有有个组合叫法：UED（产品交互设计师，用户体验师）。UI用户界面（UserInterface）
UI设计则是指对软件的人机交互、操作逻辑、界面美观的整体设计。好的UI设计不仅是让软件变得有个性有品味，还要让软件的操作变得舒适、简单、自由、充分体现软件的定位和特点。关于UE和UI，之前也是傻傻分不清楚，那时候也闹过尴尬。记得当年刚进入职场不久，写好一份需求，兴奋地去找设计师当面对下UI细节，我还是比较礼貌的说了句：您是UI设计师吧，谁成想，妹子当时给我来一句“我是UE不是UI，谢谢.......”……怼的我半天没说出话来~~心想有啥区别吗？其实区别还挺大的，吃了没文化的亏啊！QA测试（QualityAssurance）
在ISO：中的定义是“为了提供足够的信任表明实体能够满足质量要求，而在质量管理体系中实施并根据需要进行证实的全部有计划和有系统的活动”。有些推行ISO的组织会设置这样的部门或岗位，负责ISO标准所要求的有关质量保证的职能，担任这类工作的人员就叫做QA人员。OP运维（Operations）
OP这个词语代表的意思很多，这个简称来自于英文的Operations一词。我也不清楚谁最早用op代表运维工程师，不过年开始，这个词慢慢被很多人所知道。OP工作内容主要就是维护公司的服务器能够正常提供服务，细分的话包括系统部分，网络部分，应用程序部分，数据库部分，具体根据公司的规模和职位职能不同，运维的定义也不同。现在市面上主要的OP有三种：网络游戏运维，网站运维，大型项目测试和生产环境运维。DBA数据库管理员(DatabaseAdministrator)
是一个负责管理和维护数据库服务器的人。数据库管理员负责全面管理和控制数据库系统。这个职位对不同的人意味着不同的意义。另外还有DB，既数据库（Database）。
各职位具体职责:
目的：明确项目组各相关人员责任和权力，明确任务分工，降低各角色之间协调的成本，提高开发效率。
（1）产品经理
职责（对项目成败及收益负全责）
制定产品的目标。
制定各个工作的详细任务表，跟踪这些任务的执行情况，进行控制
组织会议对程序进行评审
综合具体情况，对各种不同方案进行取舍并做出决定
协调各项目参与人员之间的关系
人员要求
对产品有激情，具有领导才能
对问题能正确而迅速地做出确定
能充分利用各种渠道和方法来解决问题
能跟踪任务，有很好的日程观念
能在压力下工作
（2）构架设计师
构架设计师负责在整个项目中对技术活动和工件进行领导和协调。构架设计师要为各构架视图确立整体结构：视图的详细组织结构、元素的分组以及这些主要元素组之间的接口,最终的部署等。因此，与其它角色相比，构架设计师的见解重在广度，而不是深度。
（3）需求分析员（与客户业务人员进行业务需求沟通，引导业务人员进行系统需求提出的人员。）
业务分析员通过概括和界定作为建模对象的组织来领导和协调业务用例建模。例如，确定存在哪些业务主角和业务用例，他们之间如何交互。通过描述一个或几个用例的需求状况以及其他支持软件的需求来获取系统功能某一部分的规约。还要负责用例包并维护该用例包的完整性。
职责（对需求正确性和完备性负全责）
进行需求沟通：与业务人员深入沟通业务需求，确定软件需求限制和软件同其它系统接口细节
发起讨论：与业务进行重大需求讨论和确认前，应与项目组内部干系人进行需求讨论，达成一致，避免出现不合理需求
出具需求规格说明书：出具完整描述业务需求、无歧义、可执行的需求文档
维护需求状态
解答项目组内其他人员关于需求的疑问
屏蔽业务人员对开发人员的干扰，使得开发人员可专注于系统实现
人员要求
担任系统分析员的人员应该善于协调，并且具有良好的沟通技巧
担任此角色的人员中必须要有具备业务和技术领域知识的人才
（4）软件设计师
设计员定义一个或几个类的职责、操作、属性及关系，并确定应如何根据实施环境对它们加以调整。此外，设计师可能要负责一个或多个设计包或设计子系统，其中包括设计包或子系统所拥有的所有类。编写部分模块设计文档和代码，检查软件工程师编写的模块代码。
职责
定义类的方法和属性以及各个类之间的关联，画出类图
进行数据库设计
人员要求：
掌握面向对象分析与设计技术，统一建模语言(UML)
（5）UI设计师
界面设计人员通过以下方法来领导和协调Web界面的原型设计和正式设计：获取对Web界面的需求（包括可用性需求），构建Web页面原型，使Web界面的其他涉众（如最终用户）参与可用性复审和使用测试会议，复审并提供对Web界面最终实施方案（由其他开发人员员创建，如设计师和实施工程师）的适当反馈。
（6）软件工程师
软件工程师负责完成设计师的设计意图，根据设计文档编写代码；根据设计文档编写单元测试代码，根据测试报告BUG记录修订BUG，完成包或子系统的开发。
职责（对产品功能代码质量负全责）
需求沟通：与需求人员沟通需求，了解需求细节
需求评审：评审需求人员编写的需求规格说明书，共同把控需求质量
系统设计：根据需求规格说明书进行系统功能设计，出具可执行的详细设计文档
发起评审：重大功能或核心算法，在编码前，应主动提起设计评审，让项目组相关人员相互取长补短，共同把控系统质量
编码：根据详细设计文档进行系统编码工作，实现需求功能
单元测试：对自己开发的功能进行单元测试，确保功能的正确性
功能发布：负责正确填写更新列表，跟踪功能发布状况
BUG修改：修改BUG，及时发布，并跟踪BUG复测情况
注：开发人员享有拒绝权：
若发生需求描述不明确，或与系统不兼容，甚至不能实现等需求问题，开发人员有权利拒绝本需求的开发，并与需求人员沟通提起需求的再分析。若接收到的BUG非系统功能问题，开发人员可进行拒绝处理，并根据实际情况进行解释或提起讨论分析。
（7）测试工程师
人员要求
了解被测试的系统，具备诊断和解决问题的技能，编程技能
职责
执行测试，描述测试结果，提出问题解决方案
需求评审：评审需求人员编写的需求规格说明书，共同把控需求质量。
理解需求：深入理解需求人员给出的需求规格说明书，掌握业务需求要点
编写测试案例：编写能覆盖需求内容、且能覆盖绝大部分业务行为的测试案例
发起评审：重大功能或核心功能的测试案例应发现评审，共同把控案例完备性
执行测试案例
复测BUG
出具测试报告：给出测试过程中的bug情况，出具上线标准确认书
什么叫测试工程师：工作的责任当然是发现在开发中所出现的技术问题和错误，及时的向项目小组报告情况，并督使项目小组相关的开发人员解决被发现的问题。一般项目的质量测试有以下4个过程：
1）白盒测试：就是项目的开发人员自己在平时的开发中，或者是在一个小模块开发完成后。测试自己的所开发模块的过程。其测试内容主要是自己原代码的完整性和规范性，自己开发的模块流程是否清晰、逻辑正确等等。
2）黑盒测试：由开发小组的人员互相交换或者在空闲时间干脆请公司里非开发项目小组的同事来帮助测试各个模块。重要的内容是：检查各个模块的连接是否紧密，各个超级连接是否正确，软件中是否有JS等报错，表单区域中的文本筐等和用户交互的部分是否有长度的限制？是否有超文本语言的过滤？是否有非法字符的验证？在用户填写相关信息出错的时候，程序是否有相关的处理等等。
3）用户测试：主要是邀请本项目外的其他同事以用户的角色来测试项目的功能。其内容主要是：评价每个模块的风格和项目的总体的风格是否冲突？功能是否能否实现，流程是否清晰，界面是否友好，页面安排是否舒适？各种连接所放的位置是否舒适等等。
4）负载测试/性能测试：当项目看来可以很好的工作了，就可以开始负载测试的阶段。项目小组这个时候应该在公司和客户的帮助下，安排尽量多的用户登陆开发基本完成的项目，使项目尽可能的承受长时间和高强度的测试。这个时候往往会发现相当多的问题（特别是以程序为主的WEB站点）。比如程序运行时服务器出现内存溢出？CUP资源占用瞬间涨满？两个用户在数据库中查询同一数据时造成冲突？一些查询过程时间过长？甚至是一些客户端脚本与浏览器版本不兼容等等。
在质量小组每完成一步测试的时候，都要详细的写好测试结果，测试环境以及问题描述的报告直接交给项目经理，再由项目经理了解大概情况分发给问题相关的开发人员并监督其解决问题。
注1：测试人员享有拒绝权：
若开发人员提交DAT的功能有阻断性BUG或严重BUG较多，测试人员可拒绝相关功能的测试，等待开发人员调整系统。（严重Bug较多：按功能工作量，平均每天发生一个严重Bug）
注2：测试人员享有免责权：
若测试报告为不能更新UAT，但经项目经理及客户同意，将该功能更新到UAT，则测试人员可不对测试报告中提出的不能更新的功能点负责。
最后结合自身工作经验，说几点对于PM的理解与认知：
产品经理的使命：协调所有的资源，通过产品来实现公司的战略目标和收入变现
产品经理的入口：从专业（研发/测试/设计、市场/运营）入手，不要搞零基础，那样只是害人害己
产品经理的硬技能：原型制作技能、文档撰写能力
产品经理的软技能：逻辑分析、全局观、数据分析
产品经理的人格能力：同理心、沟通力、领导力、时间管理能力
以上大部分信息来自个人工作中的心得体会，同时也有借鉴百度/CSDN信息
如有不准确之处，请大家
转载请注明：http://www.bujiadicar.com/zjjyq/4654.html
