公司有独立的产品研发团队架构吗?

产品架构是对业务的抽象但架構不是完美存在的结果,而是一个不断改进优化的过程

此前我们聊过“”在现实工作中我们 能见到一些公司,产品都已经上线了却找鈈到一份合适的文档描述整个产品的框架,前端和后台由哪些部分组成各自之间有着怎么的关联关系,各个模块如何协同支撑整个业务嘚发展

更有甚者,甚至都找不到一份完整的文档来清晰的界定产品的边界,完全是盲人摸象般的走到哪算哪

我们还能见到不少挂着總监,甚至VP头衔的人仍然讲不清公司的产品的发展方向和未来规划,因为他们从来没有真正的规划过整个产品线的未来慢慢的,整个公司只有各自一大堆的软件或者不同的功能模块,有的是些微的改动有的是重复设计和开发。

我们的疑问是:为什么会出现这种情况以及如何解决这个问题呢?

以本次复盘的O2O平台为例我们把整个平台简化分拆为用户层、服务层和接口层(裁剪掉整个平台中的多租户等实际业务中的复杂应用)。

现在的疑问是为什么要这么分层,又是通过什么方式得出每一层要有这些功能模块的设计呢

本文为你具體解析产品架构的设计过程。

01 产品架构是可视化工具

在前文我们探讨基本概念时我用了一栋房子的例子来描述“产品架构”的概念,“架构”决定整栋方式的位置、朝向、楼层决定了地下几层,地面有几层有多少间房,层高多少米这些东西是不管怎么装修,都改变鈈了的事实

对这栋房子而言,支柱、承重墙是再装修的时候都不能动要动就得大动手术,甚至干脆推到重来

“客厅”、“餐厅”、“主卧”这些功能区域,则是我们在使用某些某个产品的时候所对应的功能模块。这个时候我们就发现如果等房子建好了,再想把原來的一房一厅改成两房一厅就只能做隔断,比如导致每个房间的面积变小或者没窗,或者采光不足等等

从房子的例子,我们可以得絀一个结论:产品架构图是一种产品经理用来抽象表达一款产品的服务和商业模式的可视化工具

产品经理把产品所要实现的具象功能,抽象为一个一个彼此独立又互为关联的模块(这种关联性也是模块的交互关系包括信息和数据,通常以接口的方式实现)并把这些模塊根据一定的业务或数据逻辑进行分层组合,来传递产品的业务流程、商业模式和设计思路

所以,在产品正式进入开发以前绘制一个唍整的产品架构图就成为必然。

架构的根本目的就是为了梳理产品思路从整体上把握产品的发展方向,把控产品的功能重点(卖点)咜决定了产品必须要实现的功能,以及什么时候必须完成的功能也就是产品的架构决定了产品的发展路径。

同时为了满足我们所设定嘚“架构”构想,还必须配备相关的产品研发和市场运营资源以及具体的落地计划包括技术选型和技术路径,市场营销规划等一系列的筞略和措施

产品架构是团队基于某一独特市场和用户痛点的统一沟通语言,也是在产品迭代过程中的业务边界

02 分层是产品架构设计的基本方法

如果你足够细心的话,会发现本文的案例“O2O产品架构示例”中右侧有标记“接口层”、“服务平台”、“终端用户”等字眼,並做了一个标记说明他们说代表的含义和使命,比如“响应终端的服务请求”意味着这一层级的所有功能,都是为“用户”服务的昰针对用户行为的一个信息接受和反馈机制。

比如:在O2O的服务过程中用户有一个设备的维修请求,他通过“用户界面”向平台发送一个狀态信息和请求信息平台端通过一个有效的机制,及时的接受这一信息并让用户理解到,“我已经知道你这边除了状态我正在安排囚采用一些措施来协助你解决问题”。

这就是一种响应机制这一过程就是整个平台的服务端开始处理用户请求的起点,然后整个平台基於这一个被“触发”的机制去调动整个平台的资源,包括各项数据的查阅、各种资源的调动来协同处理这一个业务请求的系列动作。

所以整个产品的架构设计,也就是基于这一个连锁反应进行的业务层和逻辑层的解耦分拆系统性的规划整个O2O平台的前后端如何高效的協同。

同时基于这一个基本规则,我们再考虑平台的未来业务发展甚至我们还需要考虑到未来三五年的业务容量会达到什么量级,由此需要采用怎样的技术设计和资源配置(云端服务资源)

由此可见,产品架构设计首先就是一个分层设计的过程。

常来说最容易实現的产品层级结构就是三层,即用户层、功能层和数据层这种层级关系即可完整的实现前、后台关系的业务系统:

1. 统一的用户感知层

解決的是用户触达的问题,考虑在何种场景下通过何种方式触达用户最表层的业务体验,也就是我们常说的“用户体验”包括界面,布局配色等直观可见的每一个产品页面。

在这个层面我们考虑的是如何更好的表达我们想要表达的业务元素,如何能够更吸引用户的注意力和停留决策它在一定程度上决定了用户是否会立即卸载,或者是带着好奇之心在有效的引导下探索产品

这是产品经理的必修课,洇为它能直观的让人直接评断产品最常见的说辞就是“丑爆了”,而且是任何一个产品都会遭受到这一批评哪怕你是微信也毫不例外。

但真正决定体验的并不是这一层,但又无可奈何必须面对的现实所谓人靠衣装吧,一个打扮时髦的美女你甚至都会觉得她特别让你感觉亲密甚至你会直觉认为她根本就是一个好人,一个让你喜欢的人

2. 解耦的业务功能层

多少产品经理实际在这个层级就开始陷入迷糊狀态,根本不知道甚至没有意识到“功能”的分解和层次设计在他们眼里,任何产品都只需要一个界面+一个数据库即可愉快的完成所囿业务。

也是因为这种主观的判断让多少人总是认为这个东西很简单,那个东西很容易别人都可以做出来,你为什么明天还不能上线以及谁谁谁又做了这么一个功能,我们明天也要做一个

诸如此类的根本原因就是只见树木不见森林。

这一种粗浅的认识也带来大量嘚产品被粗制滥造,胡乱承诺最后不得不草草收场,因为这些产品从一个开始就没有被真正的理解和设计而是想当然的认为“我们只差一个程序员,明天就可以上线”

对这一层级的认知不足,会让我们陷入一种奇怪的局面

一个妈妈生一个孩子要10个月,10个妈妈生一个駭子只需要一个月

“业务功能”的解耦,本质是解决产品的核心功能的设计问题包括如何高效的完成业务功能,如何与用户层进行交互如何与外部系统进行数据通信等一系列复杂的业务处理。

很多人无法理解某个功能为什么要这么设计,为什么不能那样设计就是無法真正理解这一层的设计,从而加剧整个产品在最开始阶段就限定了它的可能性

这里再次用了解耦这个词,为什么会反复用到它根夲性原因就是考虑业务的扩展性,也是考虑整个平台的伸缩性不要把各个功能模块过于紧密的耦合,导致任何些微的改动都必须大动幹戈。

最蹩脚的设计就是所有功能只看到一个业务线,所有人都在忙活但没有人搞得清楚边界。

还有一种糟糕的局面就是完全的各洎为政,没有协同没有次序

这两种情况我都见过,带来的后果除了平台的效率低以外也是资源的浪费,更是阻塞了团队的上升空间——阻塞整个团队获得成就的通道,也阻碍团队能力的提升

3. 集中的数据处理层

相比较于“用户层”,是所有人都直观可见的是所有人嘟知道有一个“数据库”,甭管知不知道数据是什么有哪些,要怎么用它就相当于我们的钱袋子,装得有东西肯定就比没东西更好洅要怎么摆弄摆弄,无法是钱票子装得多点容易数一点的问题。

所以这一层处理的问题就是,产品的数据从哪里沉淀到哪里去。实際上稍微深入一点的问题就是数据如何高效的存储,如何快速的被调用

比如:今日头条的推荐算法,就是根据用户在使用(用户层的荇为)过程中产生的数据来绘制这个用户的习惯偏好,采用一种恰当的规则来推荐相关的内容从而使得这个用户更多的停留在产品上。

然后在此基础上催生更多的商业可能性

让我们在回到案例中的O2O项目。

我们用一个“用户故事”来描述当时我们需要解决的用户问题:

“张三新买的冰箱出现了故障他找到当时的回执单申报了一次售后服务,要求在周六上午处理完冰箱的故障”

从这个描述过程中,我們就能知道3个关键信息:

要有一个方便的界面协助用户申报服务怎么能让用户在申报服务的时候把资料问题录入正确,有没有办法在用戶打开这个界面就直接解决问题有没有一个FAQ供用户查阅。

后台要处理用户的服务请求(申报的售后服务)要安排一个擅长处理这个故障的工程师上门服务(业务技能要匹配,不能派一个不懂冰箱的工程师处理这个问题)时间是周六(资源要调配,距离太远不合适时間冲突不合适等)。

上次的订单是怎么找到的这个用户是不是在服务期内,是不是要额外收费费用是多少。这次处理完的订单怎么和仩次的订单相关联等等

按照这种逻辑,就能清晰的勾勒出在处理用户的服务请求所需要完成的系列动作,整个平台的数据和信息是如哬进行流转以及为了支持整个平台需要开发的产品功能有哪些。

当然单凭这一个“用户故事”就能绘制一个大概的业务轮廓。

这是一種最简单的分层机制我们可以快速的得到一个初步的产品框架,当然一定存在不少边界不清晰分层不明确的问题,我们还需要根据不哃信息层级的边界、同一层级内模块和模块的边界

下一步,则是针对具体的业务展开规划

在前述的”分层“逻辑中,在各个业务层级Φ我用了很多“小豆腐块”表示具体的功能。我想你现在的疑问应该是这些小豆腐块是如何被界定,它们的依据又是什么呢

比如:架构中有“接单”、“履约”、“回单”、“订单列表”,为什么没有登录修改密码这些基础功能,是因为这个产品不需要这些功能吗

这个问题的奥秘在于,产品架构解决的是业务问题而非功能问题。意思就是架构只框定这个产品要完成哪些业务,取得哪些成果以忣相关的支撑数据而不解决为了完成这些业务,所需要进行的每一项具体的功能操作

所以,在整个设计中我们只看到一些简洁的、概括性的词汇,而没有任何的实际功能而且这些词汇甚至可能本身就是整个平台中的一个模块或者一个小产品,也可能其中的词汇永远鈈会在产品中表现为具体的功能比如:“履约”,它代表的就是完成服务的一系列过程

这种设计思路,就是抽象化把具象的业务抽潒为一种概念性的词汇,其目的不仅是为了架构设计的简洁性更是为了整个平台业务的完整性,并把离散的业务过程场景化

通过这一層“抽象”以后,整个平台的业务框架即可完整的呈现只纸面上我们就能把用户发起请求一直到后续的所有关联性业务完整的进行串联,也就能够发现整个过程的不足和缺陷去通过产品的优化来促进业务的优化。

这才是真正的产品价值企业通过部署这一套平台化系统,带来了整个业务流程的优化提升了用户的体验。对2B的产品来说它需要的是系统性的提高整个组织的效率,提升整体的绩效这其中吔必然包括可见的系统部署成本,维护成本以及相应的管理成本的优化。

对用户来说也只有这种全链路的触点优化,才是真正的用户體验

我们再次回到O2O平台的一个“用户故事”来反推如何进行业务的抽象化:“坐席接到用户王五反馈的问题,安排李四上门服务解决用戶的冰箱故障”

在这个描述中实际包括的关键信息有:记录问题,安排资源工程师接受任务,上门服务所以这个过程经过抽象处理後就变成如下形式:

  • 受理:坐席把用户反馈的问题记录在案,并形成一个单据
  • 调度:坐席根据用户信息安排恰当的工程师
  • 接单:工程师接受坐席安排的任务
  • 履约:工程师上门处理用户反馈的问题

我们可以把这种抽象后的关键节点称之为“业务动作”,他们将像一栋房子的支柱和承重墙一样牢牢的支撑起整个平台的运转。

通过这种高度抽象后整个系统非常简洁而又完整,各个环节只需要通过一个订单主線即可完成一系列的任务不管这个过程将要发生多复杂的业务交互,都始终能够围绕用户和订单来进行溯源管理和任务处理

这种抽象後的业务动作即可作为我们构建产品架构的核心信息,通过业务分层和逻辑分层严谨进行分拆,形成最终的产品架构设计并根据这一線索进行恰当的展开和引申,则整个平台雏形便显现在我们眼前

回到问题的起点,假设我们没有能够进行这种抽象性的架构设计我们將面临怎样的局面呢?

04 架构是一个渐进的过程

架构,是一个偏向宏观的事情而设计则是一个偏向细节的事情。这里要区分的一件事就昰技术架构和产品架构技术架构是将产品需求转变为技术实现的过程,产品架构则是将用户需求转变为产品需求的过程

我们可以想象┅栋楼的地基问题所带来的影响,对任何产品而言一旦架构定错,轻则楼盖不高重则根本改不起楼。

所以产品的架构设计,最考验PM嘚判断力和设计能力——体验是设计出来的产品是规划出来的,简洁的架构决定产品的调性

但是,与“房屋”的案例不同的是产品嘚架构不只是“结果”,而是一种迭代的过程它会随着业务的发展而不断优化和调整,对一款产品来说不存在一种始终静态的架构模式。

比如:电商平台在早期很多功能可能都不是关键性业务,在架构设计都可能不会考虑而是随着业务的发展而调整。所以必须保證产品架构具备一定的扩展性和成长性。比如:电商平台的banner随着业务的发展,它能完全成长为一个独立的强运营的业务模块

杜松,公眾号:产品微言人人都是产品经理专栏作家。专注于人工智能方向擅长产品规划和架构设计。

本文原创发布于人人都是产品经理未經许可,禁止转载

}

题主你好我是Ghostcloud的架构师,你这個问题可以参考一个定律——康威定律

在开发微服务中康威定律起到了很大的作用。康威定律指出任何软件代码都是用来反映组织机构洏产生的如果要采用微服务的开发方法,就需要是把团队划分成多个小团队由每个小团队负责一个或多个微服务。所以如果要转成DevOps和CI/CD嘚开发模式就需要采用这种敏捷开发模式,一个团队7-8个人比较合适

    题主的公司一定是在用Docker相关的技术吧,按理说这三者现在都成铁三角了哈哈哈

}

作为HR如果你要去支持产品团队,或者进入技术部门做BP你需要搞清楚那些是核心岗位,今天来拉通一下这块知识点。

互联网产品团队的7个角色

老板和用户就不用介绍叻

产品经理应该是互联网公司最热门的岗位,也是被吐槽最多的一个岗位

比如产品经理什么都“略懂”,但都不精通写代码不如程序员、画设计不如UI(美术设计师)、做用户研究不如UE(用户分析师)、侃数据分析不如BI(数据分析师)、谈合作不如BD(商务经理)、卖产品不如sales(销售人员)。

从这些槽点你大概也能得看出来,产品经理工作界面是最复杂的沟通接口是最多的,而且前线还有用户需求和感受后方还有老板的任务和压力。

交互设计师的主要职责把产品经理的想法最有效地转化成一系列的界面展现给用户。

所以交互设計师的产出更多的是交互原型图,其中包括页面布局、内容展示等众多界面展现例如:使用按钮还是使用图标?字号大小如何如何使鼡tab?用户需要点击还是滑动采用摇一摇还是吹一吹?这些都属于交互设计的范畴

在互联网大厂,都会设立专门的交互设计师岗位但尛作坊或初创企业就不设置了,这部分工作会由产品经理自己来做

交互设计师做出来初步的交互原型稿,接下来就轮到界面设计师制莋丰富多彩的设计文件。

因此大家平时在上网时看到的界面、设计,都是界面设计师的作品他们的使命就是让互联网变得更漂亮。

因此界面设计师主要内容包括负责软件界面的美术设计、创意工作和制作工作。此外除了设计内容本身,配合工程师切图、配置文件也昰界面设计师工作中很重要的部分

在大中型互联网企业中,一个产品团队动辄三四十人需要有个角色在中间做指挥,协调所有分工的任务、时间和进展有就是有了项目经理这个角色。

项目经理的职责是为产品团队在做时间、人力上的协调和安排使命是使得团队协作哽顺畅,保证人力资源的最大化利用

BAT都有项目经理这个角色,产品经理在完成需求设计后会在项目经理这里报备,然后由项目经理来咹排技术、测试资源及整理时间排期小企业没有项目经理角色的,一般由产品经理或技术负责人来兼顾这个角色

开发工程师,传说中嘚 “码农”是指通过计算机语言手段实现产品需求的人。

一般来说有前端和后端,同时会用多种不同的实现语言当产品经理把需求、交互明确后,开发工程师就可以根据需求把项目最终实现成为一个人们在网上使用的产品

后面我们会详细的展开前端和后端岗位的区別。

测试工程师负责前端产品以及后台应用程序的质量把关

具体讲,测试工程师的工作是根据产品经理的需求文档编写测试用例,通過自动化测试(编写程序)或者手工测试对需求进行覆盖验证

结合测试用例,测试工程师会对产品功能涉及的每一个细节、每一个场景、每一个终端(移动端包括各式各样不同的手机、平板等设备)都进行细致认真的排查体验

在发现产品有质量问题时,他们会将bug单给到開发工程师或产品经理在修改后他们会继续测试,直到问题被解决

中大型互联网企业中,测试工程师是标配但一些小型或创业型企業因为资源有限,这个职位也可能由开发工程师或产品经理兼任

运维工程师负责部署后台程序及后台服务的稳定性,确保后台服务可以7×24小时不间断地为用户提供服务

运维工程师管理数据庞大的后台服务器以及监控这些服务器上的服务状态,如何保障服务的高可用性昰运维工程师面临的最大挑战。

在大部分公司后台开发工程师并不是直接将自己开发完成的软件部署到后台服务器,而是交给运维工程師进行部署这样可以让开发工程师更关注开发。

在一些中小型企业后台开发工程师兼任了运维主要工程师的职责。

以上只是标准产品團队的关键角色其实很多互联网企业的团队中所涉角色远不止这些,比如还有数据分析师、用户分析师、客服经理等

技术部门的8个关鍵岗位

如果你进入一个技术团队,你就需要进一步了解每个岗位主要工作内容每个岗位的必备技术。

首先技术部门经常会说到前端和後端。

前端可以简单地理解为凡是运行在用户设备上的技术都可以称为前端技术,比如HTML/CSS/JS甚至移动设备的Obj-C/Swift。

后端就是负责将这些东西葑装在数据包中然后通过网络传送到前端,后端还有一个更重要的职能即保存和提供用户数据,后端技术一般是用户感知不到的

负责PC戓者移动端网站网页的开发,以及配合后台开发人员进行页面功能整合采用的开发语言为:HTML、CSS、Javascript(js)。

当我们想要设计一个Web页面前端開发工程师可以帮助我们实现Web页面的开发,包括各种页面布局、交互、特效等

HTML全称Hyper Text Markup Language,译为超级文本标记语言HTML就是一组标签和文本的组匼,是一个最基本的网页它已经包含了网页常见的元素,比如输入框、图片、按钮、下拉菜单等

CSS又称叠层样式表,简言之是一种用来表现HTML文件样式的样式设计语言CSS能够对网页中对象的位置排版进行像素级的精确控制,实现基础的静态交互设计;而CSS目前的最新版本CSS3能够嫃正做到网页表现与内容分离

Javascript简称JS。CSS刚出现时大家开始觉得这样静态的网页似乎略显无聊,能不能给网页加入一些可以动起来的元素比如点击一个按钮之后变个颜色,因此JS应运而生即为HTML网页增加动态功能,实现更炫酷的交互

(二)HTML5开发工程师

HTML(简称H5)工程师除了具备前端开发工程师的技能特点,同时还需考虑移动设备上的场景结合移动操作系统的能力进行开发。

H5开发工程师是随着移动互联网的崛起需求量开始大增的在很多公司,H5开发工程师和在手机开发客户端产品的终端工程师一起被归类到无线研发部门

负责Android或者iPhone上的Web界面鉯及逻辑开发,采用的语言同样为HTML、CSS、JS但在HTML的使用上,更多采用HTML5协议和特性进行开发

HTML5是一种用于Web应用程序开发、具有变革意义的网络技术。HTML5是HTML的第五次重大修改目前很多移动设备上的网页都采用HTML5协议标准来进行开发。

(三)客户端开发工程师

客户端主要是指在PC电脑上嘚应用程序基于Windows操作系统做开发的,叫Windows客户端开发工程师;基于Mac操作系统OS X的叫OS X开发工程师。

负责Windows、Mac客户端界面以及逻辑开发

Windows客户端開发工程师一般采用的语言为C/C++,开发工具一般用微软的Visual Studio

OS X客户端开发工程师采用的语言为Object-C,开发工具用的是Xcode

(1)Windows客户端开发语言

C/C++是一门基础的高级语言,不仅仅应用在客户端开发商在操作系统,嵌入式系统包括后台开发上都很普及,但在Windows上开发有一些区别

微软为C/C++开發者提供了很多基于Windows的库,很方便为Windows客户端开发者提供界面封装以及系统能力的接口所以我们很多时候看到Windows开发者招聘要求里面,不仅僅要求熟悉C/C++还得熟悉Windows下SDK类库如MFC、ATL等(MFC和ATL都是微软公司对Windows下对系统调用的封装)。

(2)OS X客户端开发语言

C/C++同样用在Mac客户端开发底层部分界媔开发一般都是基于苹果公司推荐的开发语言:Object-C。

苹果公司也为开发者提供了基于OS X客户端开发的类库:Cocoa苹果公司对于苹果应用有着较为嚴格的规定,使用Cocoa编程环境时要让程序在多方面自动遵循苹果公司的人机界面守则

手机主流的操作系统有两种,Android和iOS分别是Google和苹果公司嶊出的操作系统,在这两个系统上开发的工程师分别为Android开发工程师和iOS开发公司

运行在手机上的App都是一个独立的应用程序,来自于终端开發工程师的开发然后用户下载安装后才能运行(内置App除外)。比如Android上的应用App需要Android开发工程师开发。

苹果Apple Store上的iOS应用程序也是由iOS开发工程師开发完成后上传给苹果公司,由苹果公司审核通过后才能显示在Apple Store上供用户下载使用。

负责Android或者iPhone客户端界面以及逻辑开发

Android开发工程師采用的语言为Java,开发工具一般用微软的Android StudioiOS开发工程师采用的语言为Object-C,开发工具用的是Xcode

Android的App开发一般采用的是Java,终端Java和后台Java有所不同虽嘫是同一个语言,但是Android Java有自身的API更多需要了解Android系统本身。

后台Java和终端Java语法相同但运行环境不一样,终端Java有自己的运行环境两者程序鈈能混用。

苹果公司的设备(Mac OS和iOS平台)最初采用Objective-C作为应用程序的开发语言苹果于2014年发布的新开发语言Swift,可与Objective-C共同运行于苹果设备上(OS X和iOS岼台)用于搭建基于苹果平台的应用程序。

苹果为iOS开发者推出的开发SDK叫作CocoaTouch与Mac客户端开发者也是不同的,CocoaTouch开发的应用不能运行在Mac电脑上嘚

前端负责与用户交互,负责数据的录入和展出后台与前端通信,交互数据并对数据进行处理。

简单的说前端工程师为用户开发精美的界面和友好的交互体验。后台工程师为用户带来丰富的内容及信息的处理结果

理解业务逻辑,进行架构设计实现前端用户接口鉯及后台功能的开发。同时还需要对系统进行调优更快更准确地对数据进行处理,返回给前端用户提升用户体验。

后台面对巨量的用戶群和大数据所以在高并发以及可靠性、性能上都有较高的要求。所以后台开发一般都要求有较好的算法基础能快速处理数据,对操莋系统能有较深的研究有较好的挖掘系统能力。

后台开发工程师开发语言多种多样跟公司的文化和历史背景有深厚的关系。

(1)腾讯後台技术——C++

腾讯公司最初是从即时通讯业务发展起来的即时通讯对性能要求非常高,而C++做Web开发开发效率远不如其他语言,但是在运荇效率上来说目前基本还是最好的开发语言之一。目前腾讯的QQ以及微信后台核心功能模块大部分采用C++开发

(2)阿里后台技术——Java

阿里莋为一家电商企业,成立之初就要求能够实现快速开发来适应多变的运营需求。Java在高并发、安全性、开发速度、中间件、开源库等方面佷有优势即使在性能上稍显不足,但阿里的绝大部分后台仍采用Java开发

(3)百度后台技术——C/C++扩展PHP

百度是一家搜索公司,核心的搜索算法实现以及巨量数据处理对运行效率要求较高因此这部分采用的是比较底层的语言,如C&C++但同时百度的产品形态大部分都是Web形式,因此采用了PHP开发语言PHP取得成功的一个主要原因是它拥有大量的可用扩展,比如用C/C++扩展PHP

掌握多种技能,并能利用多种技能独立完成产品的人不但有前端开发的能力,还有后台开发的经验还能对服务器进行管理和维护。

以一个网站为例全栈=前端+后端,可以是前端开发工程師前端开发所需的语言都会,同时还是一个后台开发工程师后台所需的开发语言也会。

以一个App为例全栈=终端+后端,此时全栈工程師就是终端开发工程师与运维工程师的合体了。

运维是一个公司里非常重要的岗位如果你们公司有值班手机,一定是运维同学手里拿着24小时不准关机的。

互联网产品有句话说的好线上不出故障是不现实的。现实的做法是出了故障之后,多久能快速恢复

负责保障机房服务器稳定性,如避免出现机房掉电服务器死机等现象,同时不断提升服务的可用性比如监控内存和CPU占用情况,有异常及时通报给楿关开发人员另一方面确保用户数据安全,如防止数据库被黑客攻击等

通过技术手段优化服务架构、性能调优,提升用户体验如使鼡户访问网页或者App更加流畅等。

通过资源优化组合降低成本服务器资源是公司很大的一个成本开支,运维工程师要合理安排并使用服务器资源

运维工程师必须深刻了解常见的服务器架构,了解各种服务器的性能指标能对设备出现各种问题进行排查。

熟悉操作系统(一般是Linux)的使用和常用命令能解决操作系统出现的各种问题。

能非常熟练地对操作系统常用的软件和服务进行安装和维护如MySQL软件等。

熟悉网络状态熟练将服务器进行组网,比较快速地解决各种网络异常

有一定的脚本编程能力,对硬件设备、操作系统、基础服务、网络等进行自动化检查和监控

根据需求文档编写测试计划、规划详细的测试方案、编写测试用例;执行测试工作(包括编写用于测试的自动測试脚本以及手工测试),提交测试报告

对测试中发现的问题进行详细分析和准确定位,与开发人员讨论缺陷解决方案提出对产品改進的建议,并评估改进方案是否合理;

对测试结果进行总结与统计分析对测试进行跟踪,并提出反馈意见

2、必备核心技术——测试技術

测试专业技能涉及的范围很广:既包括黑盒测试、白盒测试、测试用例设计等基础测试技术,也包括单元测试、功能测试、集成测试、系统测试、性能测试等测试方法还包括基础的测试流程管理、缺陷管理、自动化测试技术等知识。

测试人员知道产品的功能设计规格通过测试证明每个实现的功能是否符合要求。比如测试购买一个商品黑盒测试一个正常用户点击购买最后是否正常购买到了商品。

测试囚员知道开发产品的内部工作过程通过测试证明每种内部操作是否符合设计规格要求,所有内部成分是否已经过检查比如购买一个商品,白盒测试可能会从用户购买行为开始一步步对用户身份、商品库存、账户余额等各种步骤进行测试。

如果在测试中发现了一个问题然后开发人员会来修复这个问题。这时若想知道此次修复是否真的解决了程序的问题或者是否会对其他模块造成影响,就需要针对此問题进行专门测试这个过程就称为冒烟测试。

软件测试人员的编程技能要求也有别于开发人员开发人员编程是实现某些功能,而测试囚员编写的程序应着眼于运行正确同时兼顾高效率,尤其体现在与性能测试相关的测试代码编写上

作为HR,如何跟技术人员沟通

大概搞清楚了这些关键岗位,如何跟他们保持有效的沟通呢这里有三个小建议:

1、学会欣赏对方的逻辑

老婆给当开发工程师的老公打电话:“下班顺路买一斤包子带回来,如果看到卖西瓜的买一个。”

当晚程序员老公买了一个包子回来。

段子中的开发工程师老公脑回路昰if-else模式的,简单来说就是——老婆只让他办一件事就是买包子回来,如果没看到卖西瓜的买一斤包子带回来;如果看到卖西瓜的,买┅个包子回来

总体而言,技术人员是一群理性严谨、逻辑思维强的群体跟他们沟通,重点就是要学会欣赏这用理性的美学会用他们嘚逻辑,而不是责怪人家“死理性派”

2、学会用把专业通俗化

HR和技术人员沟通,尽量不要讲自己的行业术语技术人员并不一定能理解囚力资源那些胡里花哨的概念,什么KPI和OKR什么赋能与组织能力。甩这些词汇并不能彰显HR的沟通能力

但是,如果技术人员首先开始甩术语、甩原理你可以先表示理解,因为这极有可能是他们的思维习惯是长期技术交流所养成的。

HR最需要的是耐心尽早把他拉回来同一个佽元沟通,如果非要谈到技术领域请他们尽量用非技术专业的话进行描述,比如用举例、比喻等方式

3、学习方向要有针对性

比如你们公司产品都是采用Java开发的,那就去了解一下Java相关的基础知识如果数据都是采用MySQL的,那你就去简单了解一下这个数据库相关的知识目标昰能听懂开发人员说的话,以免陷于被动

还要一个建议,可以尝试参加一些技术沙龙更好地了解技术人员的思想和发展方向,以及未來技术的潮流思路

只有保持跟技术人员保持信息同步,你才能在沟通上游刃有余

免责声明:本文来自腾讯新闻客户端自媒体,不代表騰讯新闻、腾讯网的观点和立场

}

我要回帖

更多关于 产品研发团队架构 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信