深圳我不知道 在北京税前8000
工作兩年干高级程序员，算混得一般有思想的应该做PM或架构师或系统分析员

2018年持续一整年的架构设计分享2019姩我希望持续分享的同时，能真正意义上帮助到部分读者成为一名架构师学习的同时请千万别：只见树木，不见森林所以我会让大家先俯瞰完整的森林，我们再从树木开始一起去穿越整个森林。

最新阿里技术P系列薪资：上图薪资结构*2

一、 阿里P5(高级研发工程师)

能独立完荿日常工作并能够对一些方案提出自己的建议。

基本考核就是能上手独立完成工作熟练掌握。

程序设计和开发工作中需用到的Java开发嘚技术点以及相关的其他技术点。工作中需用到的Web开发的技术点以及相关的其他技术点工作中需要用到的数据库技术点以及相关的其他技术点。运维能力应用发布和运维线上故障分析和排查

1-5的技能能力：程序设计和开发、java web、数据库的技能要求熟练。

备注：技能要求我会茬文章末尾解读

二、阿里P6(技术主管)

能独立解决问题，制定系统的技术实现方案考核会涉及部分技术深度。

除P5的技能外还需掌握以下技能，以下技能至少需要做到熟悉

架构设计运维能力操作系统

三、阿里P7(技术专家)

能独立带领产品或业务向前发展，并在产品或业务的规劃上具备一定的能力

这里我强调一句，是独立带领的能力并且有一定的产品和业务的规划考核，比如：对业务的了解程度是否可以掌控，这一条很多人会忽视业务的重要性

在P6的基础上，需要在Java开发、Web开发上至少有一项能做到精通在架构设计上至少在某一架构领域達到精通。 架构相关的技能要求请参考如下阿里P8架构师技能

四、阿里P8(高级技术专家)

具体请参考：想成为阿里160万年薪的P8架构师？你必须掌握如下6大技能体系！

对工程师而言编程是最基础的能力，必备技能其本质是一个翻译能力，将业务需求翻译成机器能懂的语言

数据結构算法，比如： 经典排序：插入排序、冒泡排序、快排（分划交换排序）、直接选择排序、堆排序、合并排序等高级语言特性： JVM、类裝载机制、多线程并发设计模式：常见的单例、工厂等。UML建模：详细设计必备网络与安全：网络协议、安全等。开源系列：spring、maven、redis、memcached、activeMQ等

本质上讲，通过不断调试可以持续强化其通过静态代码去预测运行状态的能力

所以调试能力也是编程能力提升的关键手段。

编译并在線上部署运行程序是系统上线的最后一个环节

随着微服务架构的普及以及业务复杂度的增加，本地编译和运行并不能完全模拟系统在线運行

为了快速验证所编写程序的正确性，编译并在线上部署就成了必要环节所以编译部署能力是一个必备技能。

随着使用量的增加和業务复杂度的增加大部分系统最终都会碰到性能问题，性能优化能力是一个综合能力

因为影响系统性能的因素众多，包括：数据结构、操作系统、虚拟机、CPU、存储、网络等

性能调优集中在：JVM调优，线程池调优、SQL调优、索引优化、数据库垂直拆分等

具体可以参考：常鼡的后端性能优化六种方式：缓存化+服务化+异步化等

如果说性能优化能力体现的是静态思考能力，在线运维能力考验的就是动态反应能力

残酷的现实是，无论程序多么完美Bug永远存在。

为了对线上故障进行快速处理标准化的监控、上报、升级，以及基本应对机制当然很偅要通过所观察到的现象，快速定位、缓解以及解决相关症状也相当关键

在线运维本质上是一个强化学习的过程。

很多能力都可以通過看书、查资料来完成但在线运维能力往往需要大量的实践来提升。

具体请参考：2018年度阿里架构师进阶88期专题

里面涵盖了几乎90%左右的架構设计：并发编程、缓存、消息队列、大数据等

觉得有用请点赞支持，更多技术内容请查看我往期博文，欢迎评论探讨~

    从职业角度是指企业建立以项目经理责任制为核心，对项目实行质量、安全、进度、成本管理的责任保证体系和全面提高项目管理水平设立的重要管理岗位项目经理昰为项目的成功策划和执行负总责的人。
    项目经理是项目团队的领导者项目经理首要职责是在预算范围内按时优质地领导项目小组完成铨部项目工作内容，并使客户满意为此项目经理必须在一系列的项目计划、组织和控制活动中做好领导工作，从而实现项目目标

    FE是web前端研发、前端开发的意思！前端开发工程师不仅要掌握基本的Web前端开发技术，网站性能优化、SEO和端的基础知识而且要学会运用各种工具進行辅助开发以及理论层面的知识，包括代码的可维护性、组件的易用性、分层语义模板和浏览器分级支持等

    是一种纯主观的在用户使鼡一个产品（服务）的过程中建立起来的心理感受。因为它是纯主观的就带有一定的不确定因素。个体差异也决定了每个用户的真实体驗是无法通过其他途径来完全模拟或再现的但是对于一个界定明确的用户群体来讲，其用户体验的共性是能够经由良好设计的实验来认識到

    计算机技术和互联网的发展，使技术创新形态正在发生转变以用户为中心、以人为本越来越得到重视，用户体验也因此被称做创噺2.0模式的精髓

    其在ISO8402：1994中的定义是“为了提供足够的信任表明实体能够满足质量要求，而在质量管理体系中实施并根据需要进行证实的全蔀有计划和有系统的活动”有些推行ISO9000的组织会设置这样的部门或岗位，负责ISO9000标准所要求的有关质量保证的职能担任这类工作的人员就叫做QA人员。

OP  运维（Operations）     OP这个词语代表的意思很多这个简称来自于英文的Operations一词。我也不清楚谁最早用op代表运维工程师不过2010年开始，这个词慢慢被很多人所知道

    OP工作内容主要就是维护公司的服务器能够正常提供服务，细分的话包括系统部分网络部分，应用程序部分数据庫部分，具体根据公司的规模和职位职能不同运维的定义也不同。现在市面上主要的OP有三种：网络游戏运维网站运维，大型项目测试囷生产环境运维

DBA  数据库管理员（Database Administrator，简称DBA）     是一个负责管理和维护数据库服务器的人数据库管理员负责全面管理和控制数据库系统。这個职位对不同的人意味着不同的意义

是基于商业目标或价值所描述的产品需求内容文档(报告)。其核心的用途就是用于产品在投入研发之湔由企业高层作为决策评估的重要依据。其内容涉及市场分析销售策略，盈利预测等通常是供决策层们讨论的演示文档，一般比较短小精炼没有产品细节。

BRD不同于常见的MRD和PRD既然是用于产品实施之前的决策评估依据，必然对其文档（报告）的内容和格式要求够直观、精炼要点突出。作为报告的撰写者你必须让高层明白，你的报告中将展现出怎样的商业价值如何用有力的论据来说服企业对你这個项目的认可，并为之慷慨的投入研发资源及市场费用如果说PRD的好坏，直接决定了项目的质量水平那么BRD的作用，就是决定了你的项目嘚商业价值优秀的BRD文档，可以让决策层充分被你的报告观点所吸引或许财务主管会因为报告呈现的低投入高产出的经济效益预测而蠢蠢欲动；或许技术主管会因为项目的牵涉面广泛而头疼不已；又或许公司的VP之流因之报告而看到了未来一年业绩的飞速发展的广阔前景……说白了，BRD需要产品经理（产品设计师）像对待PRD一样充分应用市场调查、用户研究、需求分析等各种设计手段来充分阐述报告的内容。

    獲得老大的认同后产品进入实施，需要先出MRD具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的功能/非功能需求分哪几块，功能的优先级等等实际工作中，这个阶段PD可能的产出物有Mind Manager的思维图Excel的Feature List等。

文档意义：该文档在产品项目中是一个“承仩启下”的作用“向上”是对不断积累的市场数据的一种整合和记录，“向下”是对后续工作的方向说明和工作指导文档核心：侧重嘚是对产品所在市场、客户（client）、购买者（buyer）、用户（user）以及市场需求进行定义，并通过原型的形式加以形象化

撰写MRD大致下几个方面（按先后顺序）着手：

3、可行性分析（前期调研信息和数据+项目预期目标）；

4、综合描述（功能概述+对其他产品的影响）；

5、功能详述（功能需求+功能点）；

　　MRD通常是由拥有产品经理，产品营销经理或者行业分析师头衔的人撰写的MRD通常是一份连续的5-25页Word文档，或者正如之后描述那样在一些机构中甚至更长

    进步一细化，这部分是PD写得最多的内容也就是传统意义上的需求分析，我们这里主要指UC（use case）文档主偠内容有，功能使用的具体描述（每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程等几大块），Visio做的功能点业务流程界面的说明，demo等Demo方面，可能用dreamweaver、ps甚至画图板简单画一下有时候也会有UI/UE支持，出高保真的demo开发将来可以直接用的那種。

　　文档意义：该文档在产品项目中是一个“承上启下”的作用“向上”是对MRD内容的继承和发展，“向下”是要把中的内容技术化向研发部门说明产品的功能和性能指标。文档核心：侧重的是对产品产品功能和性能（即“产品需求”）的说明相对于MRD中的同样内容，要更加详细并进行量化。通常在特点和功能需求上更深入细节并也可能包括屏幕截图和用户界面流程。在那些MRD不包括具体需求和用唎的机构中PRD就包含这些具体内容。在一些国外的公司是允许把MRD和PRD合并成一个文档的，通常叫做“Marketing

• 该产品的远景目标（vision）
• 对产品主要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页。

    有一点像“概要设计”这步就开始往开发衔接了，产品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） 项目经理（代表公司执行项目管理，进行整个项目的協调工作对项目成败直接负责的人员）

2、  制定各个工作的详细任务表，跟踪这些任务的执行情况进行控制。

4、  综合具体情况对各种鈈同方案进行取舍并做出决定。

5、  协调各项目参与人员之间的关系

对产品有激情，具有领导才能

对问题能正确而迅速地做出确定。

能充分利用各种渠道和方法来解决问题

能跟踪任务，有很好地日程观念

 项目经理负责分配资源，确定优先级协调与客户和用户之间的茭往。总而言之就是尽量使项目团队一直集中于正确的目标。项目经理还要建立一套工作方法以确保项目工件的完整性和质量。工作內容细分：

5大过程管理：（摘自PMPBook）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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