专业做网站建设公,科学新概念外链平台,三亚海棠警方拘留3名涉黄人员,网站一般建什么目录
一、试用期与加班工资
二、招聘
三、月度答辩和转正答辩
四、可信考试认证
五、接口人
六、问题缺陷单
七、代码检视
八、功能开发
九、出征海外
一、试用期与加班工资
一般而言#xff0c;试用期持续的时间为3-6个月#xff0c;工资、奖金都按正式员工的标准…目录
一、试用期与加班工资
二、招聘
三、月度答辩和转正答辩
四、可信考试认证
五、接口人
六、问题缺陷单
七、代码检视
八、功能开发
九、出征海外
一、试用期与加班工资
一般而言试用期持续的时间为3-6个月工资、奖金都按正式员工的标准计算。唯一的区别在于试用期的员工周末加班不能转调休相当于白加班。因此不到最忙的时候组长PL不会叫试用期的员工周末加班如果非得加班也会通过外出公干的方式让他们调休。
如果周末两天都加班双倍工资就是4天这样相当于基本工资涨80%接近翻倍了。当然这种连续的周末加班也很消耗精力无论你有多么强的体魄或是多么年轻最终都不得不承认命要紧。现在周末加班依然按双倍工资计算但不会下月发而是给你累计直到8年一次换工号或者离职的时候才会统一给你结清。并且周末加班也需要主管审批不再按打卡时间直接计算。
二、招聘
刚毕业那会就听说过华为只要是985/211的学生就招编程题通过就行几乎不看你的个人经历。华为会以不信任员工为基础建立一套完善的制度和流程让员工把活干漂亮。承受不了压力的人被淘汰承受住压力并遵从制度和流程的人能活下去在这基础上智商、情商特别高的人会拿钱到手软。
在华为非HR也要参与招聘这几乎成了他们在华为职业生涯中的必经之路。他们会根据现有的人才库挨个打电话询问就职意愿并引导他们做面试题、在线编程并参与面试官的1对1面试。
存储的招聘预算不太够因此招聘一般倾向于招OD/WX的员工。OD的员工工号以300开头WX的员工工号以WX开头这两种员工都不算华为的正式员工其中OD的员工相对更优秀些主要从事开发工作。而WX开头的员工基本只能从事测试工作他们按照测试文档一步步执行并查看是否符合预期绝大多数WX员工并不知道自己为什么要这么执行预期的结果代表着什么因为他们没有资格参加方案的设计和串讲也没有TDE(Test Design Engineer负责设计测试用例的华为员工)愿意跟他们讲解。
由于外包的人员流失较大因此招聘的任务就很重。同时又倾向于招聘OD/WX的员工所以招聘难度会很大。总结一下就是有能力的人看不上OD/WX没有能力的人又过不了在线编程等考核。
三、月度答辩和转正答辩
在试用期每个月都会有一次月度答辩你要做PPT详细描述在这一个月内你做了啥学到了啥并现场回答评委的问题。在转正那一次又需要准备转正答辩把整个试用期的工作进行总结。
在答辩过程中评委们都会认真听你讲并经过思考询问你一些问题这种气氛还是不错的。实际上答辩对绩效的作用并不是特别大因为你平时做的事情大家都能看到也能估算出分量。
答辩最大的作用在于防止新员工偷懒。当一名员工进入公司后在完全熟悉流程成为一颗忙碌的螺丝钉之前会有短暂的空窗期。在这个阶段由于你啥也不懂没人会找你也没法给你分配任务。这时如果你知道每个月都需要报告工作和学习进展就会产生足够的动力尽快融入团队。转正答辩完成后基本上你已经是一颗标准的螺丝钉了这时候不再需要答辩通过绩效考核进行激励即可。
四、可信考试认证
对开发而言每个人都需要通过可信考试。可信考试分专业级和工作级一共四门课四个考试往往新来的员工更容易通过因为他们有更充足的时间而老员工没有时间学习几乎都是裸考除了科目一的在线编程其他科都是理论知识涵盖的范围包括编程语言语法和技巧、编程语言规范、需求分析、安全红线、设计模式、敏捷开发等等。这些经验被总结成精炼的语言通过以考促训的思想灌输到每个员工的脑子
五、接口人
从入职到导师脱手其实就差不多两个月时间。最重要的任务就是通过可信认证考试。两个月后开始接手一些简单的任务修改问题单或者承担一些简单的功能开发。但在一些部门这时候往往会给你一个恐怖的任务----接口人。
一般而言一个产品会被分为多个模块每个小组维护多个模块。当测试发现属于某个组的模块出现问题或者别的模块依赖该模块的部分工作不正常时他们需要有人能帮忙查看原因这个人就叫接口人。
一个组大概10个人负责的模块代码量在数十~数百万行的级别。乍一看会觉得应该选一个经验丰富的员工对组内负责的模块、历史情况等掌握很清楚的人作为接口人。但实际上帮他人看问题找原因是一种吃力不讨好的工作因为领导看不到身边的同事也感知不到。
在有些公司通常是主管当接口人他会对问题进行简单的分析再根据组内成员的擅长领域、负载情况 选择合适的人去分析该问题。在华为类似的岗位是PL为了绩效他们不可能每天把时间浪费在这上面。同时组内的每个人都忙得要命最熟悉该领域的人可能正在完成紧急任务根本没时间去分析。因此PL通常会找组内资历浅一些的同事去充当接口人并按固定期限轮换。
一个组维护的代码量不算小让新员工去做接口人美其名曰“锻炼”实际上是让他去抗压。作为接口人PL的要求就是尽可能不打扰到组内其他人所有问题除非真正是Bug否则不能让测试提单。这样的要求看似简单但对于新员工而言很多时候测试咨询的问题你连他讲的啥意思都不明白再加上设计又存在各种历史原因、特殊情况的考虑新员工大多是懵逼的。想求助经验丰富的同事如果项目不太紧张的时候还好说项目紧张起来每个人都戴着耳机在通话你可能好几个小时都见不到他们空闲下来。而测试对你的响应时间是有要求的一小时不给清楚解释那就提单吧。
举个例子你在分析A问题发生的原因阅读完全陌生的代码另外2个测试给你留言找你咨询B、C问题。你简单扫了一下B、C问题都不是你熟悉的领域需要花时间去读代码了解设计才知道是不是问题所以你暂时没回复。两分钟后两个测试分别给你打电话你很烦不想接电话但他们不停的打并在留言中告诉你再不接电话就提单。你只能接起电话好言相劝告诉他们现在真的很忙只能请他们先登记排队等你的消息。没多久你读到A问题中一部分看不明白的代码逻辑想找人问一抬头组内所有人都在打电话。于是你咬咬牙一边跟A的测试确认测试用例的逻辑一边忽略部分看不懂的代码去猜测后续的逻辑。这时候B、C的测试告诉你不能再等了上面催着要提单你只能暂时放下代码再次解释给他们合理的截止期限并请求他们接受。突然电话又响了是一个电话会议问题很严重线上四五个开发正在一起讨论需要你做确认TDE催促让你赶紧看搞不定就往上捅。你赶紧放下A问题一边读D问题的现象一边凭你的理解去回答这几个开发的问题。D问题的难度不大但涉及的条件特别多变量也多逻辑很绕你得理一理正在理的过程中A测试的TDE气愤的给你留言都看了两个小时了怎么还没结果必须提单了。
如果实在搞不定了测试等不及要提单一般是要跟PL讲的。但作为新员工你要做好心理准备因为这时候免不了一顿臭骂。因为PL永远是忙得要死他有方案要讨论有设计要做还有大量组内杂事本来已经焦头烂额你不仅不能帮他分担还告诉他现有的某个问题搞不明白他也是很崩溃的。但这顿骂往往又是值得的因为PL会快速给你指明方向因为如果是定位偏了他会快速纠正你的方向。
六、问题缺陷单
刚才提到很多次“提单”就是指的问题单。测试提的问题单一般代表某个模块的功能有Bug。
问题单的跟踪华为有一套系统叫DTS测试提单开发解决的流程大致如下
测试外包员工在DTS系统中创建一个问题单填写产品、版本、问题描述等信息。问题单提给负责该模块的测试TDE华为正式员工审核。测试TDE把问题单转发给负责该模块开发的组内PL。组内PL再把问题转发给需要解决该问题的开发。开发把问题解决提交代码填写根因分析并把问题单转给组内PL。开发同时需要与测试TDE预约时间与测试TDE串讲问题单发生的原因和修改后的影响。组内PL等串讲完成并且最新的Build包含开发的Commit Id后将问题单转给测试TDE。测试TDE将问题单转交给测试外包员工进行验证。
这么一套流程走下来感觉脱了层皮。对于上级领导来说他不需要知道细节只需要要求一个组的问题单的目标数量即可。比如今天整个组剩下40个问题单明天的要求是35个后天是30个...
于是为了达成目标PL非常反感问题单走到自己组头上。有的问题单涉及到模块间的协调处理测试提单的时候发现的是A模块的问题但A模块经研究后发现实际问题出在A模块依赖的B模块身上B模块由另一个组维护于是跟B模块的接口人沟通。这种情况即使已经基本确定是B模块的问题B模块的PL、接口人也会想尽一切办法拖延问题单走给B模块的时间定位问题根因和修改方案后才会同意问题走到B模块。毕竟每天的问题单目标放在那里多一个在自己头上都是沉重的负担这种时候A模块的PL肯定也不希望问题单在自己组所以这时候就看他们两个PL的PK了作为PL至少都在华为奋斗了好几年大家像战友一样有感情互相理解下这次留给你下次留给我互相不撕破脸。
在这套流程中开发最不喜欢的步骤就是测试串讲。这个设计的初衷是好的担心你的改动造成的影响测试不清楚从而无法对受影响的场景进行测试。但遗憾的就是这个规定太死板绝大多数的串讲根本没有意义只需要测试进行原场景复现并检查问题是否解决即可。
问题单的设计如此复杂依然是对员工的不信任。在其它公司流程就简单多了
测试创建问题单填写产品、版本、问题描述等信息。问题单提给需要解决该问题的开发者。开发把问题解决提交代码填写根因分析和需要重点测试的场景把单转回给测试验证。
步骤的简化就对员工的素质要求高。就拿问题单与测试的串讲来说一般开发人员觉得这个改动的影响比较大可能需要重点测试一些场景的时候就会在问题单上注明同理测试如果意识到开发人员的改动有风险或者对开发人员的根因分析不太理解时也会主动找开发人员沟通。
华为的流程复杂它的基本逻辑是信任DE/TDE这种在华为干了很长时间的老员工新员工不值得信任。配套的激励也是倾向于PL/DE/TDE这会让新员工做得很憋屈但这没关系因为总会过滤出一批忍得住憋屈愿意遵从规则坚持努力下去的人。
复杂的流程导致了一个问题就是测试TDE的繁忙程度超乎想象。因为一个测试TDE往往负责多个模块也就是对应着多位开发当问题单较多的时候容易形成了单点瓶颈。举个例子假设一名TDE手上有10个外包测试员工分别测出了10个问题这10个问题对应着8个开发那这8个开发人员修复完问题后跟外包测试员工串讲并不算数必须排队给这名TDE串讲从而形成了单点瓶颈。
测试TDE忙得找不着北脾气自然也不会太好。开发更是一点也不敢得罪测试如果TDE不爽你别的不说就单单在串讲里给你挑刺、或者把你的串讲排到最后都会大大拖慢你的工作进度和工作热情。
七、代码检视
代码检视也就是Code Review。每个开发写好代码后都必须发代码检视才能合入主干分支。
在其它公司开发一般会找对这个领域比较熟悉的两个开发进行检视得到两个Approve以后就顺手合入了。
在华为代码合入理论上需要以下步骤
选择两个开发检视检视通过后选择一个Committer审核审核通过后选择具有合入权限的人合入。
一般Committer是在一个团队里的资深员工技术比较强并且做事仔细认真。
在其它公司代码合入步骤简化为
选择一个开发检视检视通过后找一个Commiter检视并审核再合入。
Committer的数量是很少的大概占20%左右。100个人要合入代码都得找这20个人进行代码审核。这部分人基本已经是DE(Design Engineer)主要承担方案设计、困难问题攻关等任务同时还要帮大量的同事检视代码。所以他们大多也会忙到找不到北。
这些Committer一方面承担着方案设计等项目上对自己未来有利的工作另一方面检视所有人的代码有任何问题会得到耐心的解释不解释清楚就不会给你审核通过所以他们的进步会很快。而新员工大多只是执行者对整体规划、背景原理等都搞不清楚他们想让Committer耐心解释是不可能的只有在审核代码的时候能学到点东西但也是零零碎碎的。
这样以来新员工和老员工(Committer)的差距就拉开了。最终导致的结果就是知识断层新员工很容易流失因为他们只能在繁琐的工作之余进行自学老员工没时间教他们同时他们得到的激励也相对较少除非拼死拼活爬到Commiter这个位置否则未来的发展一片渺茫。
八、功能开发
一个需求过来需要评估完成的时间。但这只是一个参考每一级都会想办法把时间往短了压。导致最后到开发者这一层几乎是不可能完成的任务。
举个例子一个任务参与设计的开发和测试预估124天版本给的要求是103天但当这个任务真正给到参与实现的开发和测试时可能只剩下61.5天。
中间的时间到哪儿去了从上到下每一层领导都担心任务完不成所以想预留一点缓冲。所以时间从103天传达到下层变成82.5天逐渐往下最终变成61.5天。所以功能的开发极其紧迫你想在规定的时间里完成几乎是不可能的。
一开始会因为完不成任务非常焦虑。后来发现大家都完不成目标放在那儿成了摆设虽然目标时间快到了就开始催但实际上做不完也不会怎么样。不过催你的人心里是有底线的这个底线就是他的上级给他的要求只是这个底线他永远不会告诉你。
九、出征海外
出征海外一般是指上一线去海外销售华为产品可以选择的驻扎地很多几乎全球都可以。但是选择欧洲那些条件好的国家补贴很少选择非州那些条件不好的国家补贴很给力。
每年需要出征海外的人数是有指标的几乎每个团队都要出人。除了极少数愿意舍家弃子去海外打拼的小伙伴绝大多数人是不愿意去的。所以要求你去海外和逼你离职差不多基本成了淘汰人的方式。
华为也有经验比较丰富的员工被要求出征海外。他们虽然没有Committer这么拼但五年左右的时间也让他们积累了很多知识也算是骨干员工。无奈的是由于这个硬性规定不得不选择离开开发岗位。
这些工作五年左右的员工对他工作过的模块应该是很熟悉了。好不容易达到了这样的水平也适应了华为的工作强度。正好应该是他们发光发热的最佳时期但华为却让他们出征海外重新招新员工进来再经历一次痛苦的学习和适应过程。
实际上这些开发者的知识对海外销售而言起不到多大作用你掌握了产品中你们组负责的某个模块里面包含数百个结构体和数千个字段你能理解每个字段的含义和设计它们的原因。所以呢那又怎么样在销售的时候客户对此是不感兴趣的。客户感兴趣的内容还是需要像新人一样参加销售培训那为什么不直接让新人去做销售呢
