技术员有前途吗

技术员有前途吗,第1张

技术员有前途。技术员表明具有实践技能,可以直接参与现场工作业及专业发挥,技术员还是有较宽的就业出路。技术在进步,技术人员必须不断更新知识结构,总结专业经验,不断学习最新技术,才能满足社会对技术人员的新要求。

产品技术员的工作内容

下面是我为大家整理的关于产品技术员的工作内容,以帮助大家更快的找到所需内容,想要了解更多的内容,欢迎关注论坛!

产品技术员岗位职责

1、制订并组织实施技术系统工作目标和工作计划;

2、组织制订并实施技术系统规章制度和实施细则;

3、组织不合格品的审理工作;

4、组织技术、产品开发与创新;

5、组织建立并实施质量体系;

6、公司标准化、计量管理工作;

7、定期进行技术分析和质量分析工作制定预防和纠正措施;

8、重要技术工艺设备、计量器具的申购;

9、技术系统文件等资料的整理保管及公司档案管理工作;

10、公司保密工作。

产品技术员职位要求

1、熟悉公司的工艺工序、工作原理;

2、具有良好的英语阅读能力;

3、掌握AutoCAD、Office等相关计算机软件;

4、熟悉工程设计软件者为优;

5、工作认真积极有较强的责任心;

6、能吃苦耐劳主动性强具有良好的沟通技巧和团队合作精神。

产品技术员发展前景

由于人口的爆炸性增长、城市化规模日益扩大、顾客群不断变化且要求日益苛刻,全球气候和自然资源问题日益严峻,消费品(CP)行业正面临着不断变化的市场形势、渠道挑战和对业务模式创新的新压力。对于消费品企业来说,这些转变正在创造历史性机遇,要求企业具有新思维,采取果断行动,并完美执行。

未来10年内,世界人口预计将增加近20%,主要是在新兴国家。同时,俄罗斯、日本和德国将成为人口增长最少的国家。在全球新增的人口中,很大一部分将居住在城市,因此,城市会越来越大。到2020年,16个城市将超过2000万人口,超过70个城市的人口将超过500万(这几乎与丹麦全国的人口数量相等)。许多新的“超级大都市”都将出现在发展中国家,并将带来一系列的机遇和挑战。

产品技术员职业规划

职业发展路径:产品技术人员→产品技术工程师→产品技术主管→技术支持经理→技术主→技术总监

延伸阅读:

互联网产品开发流程总结

1 概述

软件类项目具有一些与生俱来的复杂性,因此在整个产品生命周期中,往往由于一些环节的处理不当,而造成了进度延误、BUG较多,甚至项目失败的后果。相比之下,互联网类项目除了本身就是软件项目之外,又具备更多的环节、需要更多的交互。因此,互联网项目在产品周期中,更容易出现问题。

一个项目周期可以大致分为这几个阶段:项目规划、需求分析、软件设计、软件开发、软件测试、软件发布,系统运维。而在现代软件(尤其是互联网)项目中,这几个阶段已经不是十分清晰地划分开来,而是通过所谓“迭代”的方式循环前进。尽管项目周期的几个阶段并不能够完全独立地划分,但是每一个阶段都是缺一不可的,对任何一个阶段的过于草率甚至忽略将会带来严重后果。

关于软件开发过程,有很多相关的书籍有详尽的描述。事实上,过于遵循严格的流程定义,也会适得其反,尤其是对于较小的团队。如何能做到最大程度的“敏捷”,应该是一个小规模团队的追求目标。本文将针对互联网项目的几个重点环节,依据已有的一些经验,为软件技术(互联网)类的项目开发提供一些参考性的思路。

2 前瞻性和细节:关于项目规划和需求

21 项目规划

在项目开始之前,一个规划的过程是不可缺少的。规划包括技术方面和非技术方面,对于不同类型的项目,这二者各有侧重。对于大多数项目来数,技术是次重要的。

在这个过程中,有几个主要的事情需要完成:

明确项目目标:没有一个明确的目标,任何项目都无法避免失败的命运。虽然,在项目的进行过程中,目标是会不断地调整,但是,必须在项目初期确立主体目标。也就是说,要明确地描述出这个项目将要做成什么样子,依靠哪几个关键点来赢得用户。尽量通过最简略的语言描述项目目标,如果做不到,或许是对于项目的考虑还不成熟。

往往,很多团队已经小有规模,但是项目目标仍然在不断调整,这实际上是一种无奈之举,因为之前的工作没有做到位。这种情况会产生很多负面影响,无论是对于成本,还是团队士气。因此,对于项目目标的规划,应具备足够的前瞻性。

竞争对手分析:当前的环境下,已经很难找到一个完全没有其他人参与的项目(如果有,可能说明了这个项目没有价值)。而对于互联网项目来说,了解竞争对手的成本是相对较低的。作为用户,去体验竞争对手的网站,可以获取第一手的资料。去发现对手做得好的以及不好的地方,可以为自己节省大量的时间。

发现优势和劣势:每一个商业模式,都是由几个环节组成的。首先要明确,对于团队来说,这几个环节是通畅的。进一步,要考虑对于哪些环节具有优势,这些优势将是带来商业利益的关键点。对于劣势环节,则要考虑如何去克服。在项目规划阶段,对于优势和劣势的分析,要尽量避免乐观思维。

技术选型:尽管不是最重要的,不过技术选型依然是在项目规划阶段要考虑的。系统所运行的平台,开发工具和语言,第三方程序的成熟度。基于项目目标,对这些方面进行初步的分析,理想情况是,尽可能利用现有的东西,尤其是开源产品。另外,工具和语言的选择要考虑人员招聘的需要。

22 需求分析

角色定义:“产品经理”-负责完成需求分析,输出技术团队所需要的需求规格,并跟进项目的开发、运营过程。

产品经理的角色非常重要,尤其是对于互联网项目。首先,对于项目团队来说,产品经理代表了“用户”,通过日复一日地使用自己的产品,调研用户的需求,对产品进行不断改进。另外一个方面,产品经理充当了技术团队和非技术团队之间的桥梁,他们需要把非技术团队的需求转换成技术化的语言传达给技术团队,起到两者之间“润滑剂”的作用。

首先,产品经理需要关注产品的“核心能力”。没有一个产品可以做到面面俱到,产品经理需要找到最能够满足用户需求的核心点,并将其发挥到极致。这种满足了用户需求并做得极致的核心点,最终将成为口碑,并为用户所传播。

其次,产品经理需要对产品的运营保持敏感。通过对统计数据的持续关注,通过在产品论坛上了解用户的反应,产品经理要能够及时了解到产品目前的发展走势,并以最快速度做出调整。

然后,在产品的交互设计方面,尤其是互联网项目,产品经理要把自己当成“最笨”的用户来看待自己的产品,菜单的设置、按钮的摆放、提示语的位置等等,如何让用户能以最简单、最快捷、最不需要动脑筋的方式使用产品,应该是产品经理追求的目标。

另外,关于产品经理的素质,产品经理为了做好产品设计工作,除了对产品的感觉之外,需要有一定的技术功底,例如对带宽、服务器性能、WEB标准等方面应有一定的了解。对于细节的极致追求,也应该是产品经理应具备的特质之一。

小故事:巨人网络的史玉柱,号称自己大部分的时间都花在游戏上,有一段时间他甚至亲自作为客服人员,直接倾听来自用户的反馈。腾讯的马化腾,自从05年之后就从管理事务中脱身,把自己更多地当成“首席产品体验官”的角色。常常在凌晨时分,他会把对产品的意见发送到负责产品经理的邮箱里。

3 差异化思维和迭代开发:关于设计和开发/测试

31 系统设计

不同类型的产品,不同的开发平台,设计思路有非常大的区别。本文不会就具体的软件设计做讨论。这里想重点强调的一点是系统设计中的“差异化”思维。

举个例子,一个西餐厅,平常的客流量基本上是稳定的,但是在情人节等特殊的日子,客流量会有一个突发性的增长。有什么办法可以解决这个问题,即使在忙的时候,也不能让客户过长时间的等待。另外一个例子,盛夏时节,用户家里的空调坏了,维修需要3天时间,作为售后服务方,应如何应对。

这些问题的解决思路,实际上在于如何进行合理的差异化设计。一个热门的互联网应用,在繁忙时间段(例如周末、晚间),会出现带宽、服务器资源紧张的情况,这个时候网络丢包、 *** 作响应变慢,影响用户体验。更严重的情况下,当负荷超过阈值,出现雪崩效应,基本上处于无法服务的状态。

所谓的差异化设计,即要根据业务的本质,对产品所提供的服务按照一定的粒度划分层次,什么是基础服务,什么是增值服务;什么是必须满足的服务,什么是锦上添花的服务。举例来说,对于一个即时通讯业务,发送文本类消息是最基本的,而魔法表情、虚拟形象则是增值服务。在合理地对业务进行了划分之后,就可以在不同情况下作出取舍。系统和带宽空闲的时候、资源紧张的时候,系统出现故障的时候,在不同的情况下,系统的设计要能够支持划分的业务单元按需要进行组合和取舍。

对于业务单元的划分,也可以从另外一个角度来考虑,那就是用户的“愤怒”指数。对于一个具备十几项功能的服务,某几项功能出现问题会使用户觉得无关痛痒,而另外几项则会使用户暴跳如雷,甚至有几项出问题会使用户发誓永远不用你的服务。通过对不同功能的愤怒指数进行设定,也可以得出层次化的划分。

当系统、IDC、网络出现问题的时候,要优先保证最基本的、也就是愤怒指数最高的功能。当问题逐渐升级,功能要逐层取舍。这是在系统设计需要考虑的问题。

回到西餐厅的例子,在业务空闲的时候,餐厅提供的服务可能包括热毛巾、个性化菜单、豪华餐具,甚至跪式服务。而在繁忙的时候,为了能够提高流转速度,餐厅可能需要一份特殊菜单,这份菜单上没有过多的选择,只能像做选择题一样,选择情人节套餐A,B或者C。对于修空调来说,空调的维修需要3天,这个是无法更改的。但是,我们在维修的同时,是否可以为用户提供一个风扇,缓解目前的状况。一切方法是为了降低用户的愤怒指数,而互联网产品的差异化设计的目的也是一样的。

另外一个需要在系统设计时考虑的重要问题是“可扩展性”(scalability),也就是说当系统的压力持续增加时,需要能够通过扩展硬件来达到容量的提升。理想的情况是线性扩展,也就是硬件的增长和用户压力的增长是成线性比例的。但是,大多数系统是做不到线性扩展的,更差的是,很多系统在设计的时候完全没有考虑“可扩展性”,从而无法突破单机的性能极限。

现代的互联网系统基本上都是“分布式”的,把系统划分成前端显示层、业务逻辑层、数据存储层等几个部分,在各个部分能够进行不同策略的负载均衡。例如数据库可以采用主从备份和均衡、数据分片等方案,WEB前段可以使用squid/nginx等进行负载均衡,甚至采用DNS全局负载均衡等方案。

32 开发和测试

互联网是一个快速变化的世界,我们所面临的用户、环境每天都在改变,这就要求项目的技术团队能够适应这种情况,要能够做到“快速迭代”。不同于传统的软件项目,动辄几个月甚至几年的项目周期,互联网项目通常是以周为单位进行迭代。

在大多数情况下,一个网站在应付日常的特性修改的同时,也在酝酿大型的版本升级。因此,技术团队负责人需要对版本进行很好的规划。在开发过程中,借助SVN等版本管理工具,对主线版本和分支版本进行管理,保证日常的BUG修复可以归并到主线版本中。对于需求文档、设计思路、BUG记录等,则可以借用WIKI等工具。通过快速原型的构建,使得产品经理和其他内部客户能够尽早地体验系统功能,及时发现问题和明确方向。

开发团队应当在工作中逐步总结出编码规范,例如,HTML/CSS制作规范、PHP/JAVA编程规范等等。这里要特别强调的是,互联网应用中的安全问题是非常突出的,这方面需要在开发过程中特别关注。常见的互联网安全问题包括:跨站脚本攻击、代码注入、缓冲区溢出、SQL注入、权限验证漏洞、第三方系统漏洞等等。

根据项目的大小不同,测试团队的规模相差也很大。有些项目需要和开发团队人数相当的测试人员,而有些团队的开发人员则兼任了测试的职责。在项目的发展过程中,应尽量对一些基础功能制作自动化测试工具,并不断完善测试用例。这样测试团队可以把更多精力投入到新功能的测试中,而不是每次版本发布都在对已有功能是否被破坏而感到担心。

从管理的角度来说,如何使开发和测试人员热爱自己所从事的产品工作是非常重要的。往往,很多项目都是产品经理和管理层在推动,技术团队只是被动地完成任务,并不断有抱怨产生,这样的项目是不健康的。技术人员同样要成为产品的主人,要具备相当高的主观能动性来投入工作,把所开发的产品看作是自己的孩子般关心和爱护。

4 规范化 *** 作和成本控制:关于发布和运维

41 系统发布

系统发布是指将版本开发完成的系统在生产环境进行部署。对于一个网站来说,系统发布可能是非常频繁的。系统发布需要有严格的发布规范和工具来支持,否则发布错误,版本回退等问题会经常出现。

对于静态内容的日常更新,需要CMS系统来支持。CMS可以使用一些通用的系统,也可以针对自己的应用来定制开发。无论是哪种实现方式,一定要把日常更新和程序发布分开,否则产品和运营人员每次更新内容都需要劳动开发人员进行程序发布,将是非常低效和容易出错的。对于CMS系统的建设,需要对内容的结构和元数据的规划给予足够的重视,在这个阶段的投入将对今后的可扩展性和接口的灵活性起到决定性的作用。

对于程序的发布,也应当有自动化的工具支持。尤其是要支持“版本恢复”功能,也就是一旦新发布的程序如果出现问题,应该立刻能恢复到之前的稳定版本。因为,在互联网项目中,测试不充分的事情时有发生,而且正式环境和测试环境也差别很大。系统发布后出现问题的`概率也较大,这个时候就需要“版本恢复”这样的功能来保证网站的正常运行。

对于大型的互联网应用,“灰度发布”也是较常采用的方式。由于对新开发的功能的性能、用户接受程度等没有百分之百的把握,在这种情况下进行全量发布则风险太大。为了既不影响产品的正常运行,又能够对新功能进行生产环境下的测试,可以采用灰度发布。所谓灰度发布,即仅针对部分用户发布新功能。划分的依据可以有很多种,例如用户来源区域、用户年龄/性别特征,甚至按照一定概率随机选择。一开始先用较小的比重进行灰度发布,如果测试顺利,则逐步加大比重,直到完全发布。

在系统发布的日常管理中,“规范化 *** 作”是非常重要的。这需要自动化的发布系统的支持,以及相应的管理制度来约束。

42 系统运维

系统运维是指系统的日常管理和维护,这包括对服务器硬件、网络、带宽方面的维护,以及软件系统的日常管理。

在互联网项目中,系统运维的核心工作是对服务器和网络的管理。在项目开始的时候,需要进行硬件选型、网络规划;在项目上线后,要对硬件和网络实施不间断的监控,并及时进行调整。往往,很多开发人员不具备系统级的知识和经验,因此他们所开发的程序经常对这些方面的问题考虑不足。这就需要运维团队的系统专业人员给出建议。关于系统对CPU、内存、磁盘、网络等方面的要求,运维团队需要和开发团队紧密合作,来不断完善系统。

需要强调的是,运维团队应当具备成本意识。当互联网应用发展到一定用户规模后,服务器和带宽成本将占据相当大的比重。在很多情况下,服务器和带宽资源出现不足,并不是因为用户压力确实已经不堪重负,而是开发和运维工作没有做细。所谓“Every Byte Counts”,需要具备足够强的成本意识来对待服务器和带宽资源的消耗。

我们常常看到服务器的CPU占用偏高,内存即将耗尽,磁盘IO非常繁忙,IDC出口带宽曲线出现被削平的波峰。在出现这些情况的时候,要使用工具快速发现瓶颈所在。根据二八原则,绝大多数资源消耗在了小部分的功能上。抓住主要问题,针对性地进行优化将很快能够缓解问题。

对于互联网应用来说,有一些常见的问题和优化手段,这里简单列举一二。标准编译的apache和进行裁减编译后的apache进程占用的内存可能有上百兆的差别,在并发请求较高的情况下,内存使用的差异就更大。对于PHP,JAVA等开发语言,都可以进行字节码的缓存,这样可以大大提高执行效率,避免每次请求进行指令解释的开销。对于文件和数据库等磁盘IO比较密集的 *** 作,应考虑不同层面的cache,从文件系统cache、数据库cache、内存cache,第三方CDN,一直到客户端的浏览器cache,优化的cache可以有效地降低磁盘和网络IO,从而提高用户体验和降低系统负荷。

当然了,这些优化工作都是需要时间和精力投入的,始终不要忘记二八原则,关注最主要的问题。

当互联网后台系统规模逐渐发展到一定程度,运维工作需要和其它技术类工作(例如开发和测试)有明确的划分,相互之间需要有明确的交接、输出规定。运维工作中的设备管理、网络管理、发布管理、突发事件管理、客服管理等各项工作需要依据一定的规范来进行。对于IT系统(包括互联网),业界常用的是SLA(服务品质协议)来作为整个运维管理的规范化参照体系。对于小规模的团队来说,没有必要应用过于复杂的流程规范,不过也应该把一些常用的流程明确化,并不断改进。

5 总结

面临这方方面面的问题和陷阱,项目团队需要做好准备来迎接各种挑战。最关键的是构建学习型团队和沟通团队。及时总结经验和教训,从而不重复犯同样的错误,团队在项目的发展中不断学习提高。建立通畅的沟通渠道和分享机制,养成团队成员良好的沟通习惯,分享彼此的经验和教训,是项目成功的必要条件之一。


;

我做网吧技术员已经4年多了,大小网吧都做过,最大的300多台电脑,最小的5台电脑的黑网吧。
这一行适合24岁以下的年轻人,过了24岁你得考虑自己以后的出路了,进公司或自己创业都行,因为在网吧呆不了一辈子。
以200台有盘网吧的技术员为例,基本也就是以下5项要求(也是重点和难点):
1、会做母盘和克盘(即网克),这两点网上都有详细教程。
2、至少会做两种软路由,主要RouterOS。其他的如smoothwall、Ipcop、海蜘蛛等至少也会其中一种。
3、熟悉并掌握至少两套以上主流网吧游戏更新管理软件,比如新浩艺公司的迅闪2008(收费版名为信拓2008)、顺网公司的网维大师、网升科技的“网吧游戏管理更新系统”、湖北盛天网科公司的易游2008等。
4、熟悉并掌握至少两套以上主流网吧收费系统,万象2004版和2008版、pubwin2007这两个是必须掌握的,几乎所有网吧都有这两个,其他的较少用。
5、至少会架设一种点播系统,比如远古流媒体系统。不过现在网吧的都由公司负责,影视系统也是由公司安装的。
以上5点非常重要,
其他的如虚拟磁盘技术,易游、网维大师都自带有,也不难掌握。常用的虚拟磁盘软件,如okstor、ccdisk、网众(包括linux版)等,也不难掌握,官方都有详细的教程,照着教程做就行了。
还有什么ARP双向绑定呀、流量限制呀、防火墙呀七七八八一大堆东西,都不是重点,但也要求你会,这些东西在实际工作中你都会遇到,当然百度上一搜索也是一大堆。
至于修电脑之类的,懂得判断是哪个部件坏了就行了,要求不高。
你给的悬赏分太少了,只能写这么多。

电脑技术员就是在电脑公司负责技术方面的人了,比较多的是做软硬件的维护,安装。有些电脑公司的技术员要求很全面,不但要会PC(电脑),还要会OA(外设,打印机这方面占比例较大),网络工程,监控什么的。总之,技术员是个技术含量比较高的职业,比较难做。但对于新手技术员来说,可能只要会装下 *** 作系统和软件就能对付一阵子了。
比较正规或大的公司会要求有工作经验,甚至是认证工程师的证明。
技术员平时经常和用户接触,做的时间长了就会拥有自己的用户群,以后用户有什么问题就会直接打你的电话,比如要上门维护,购买什么配件,那这些利润就可以自己拿了。工资待遇只是一般般,其他的外块就看你自己的本事了。前途并不是很光明,除非以后能进入公司管理层。
这个职位是不能做一辈子的啊。


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zz/13384932.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-07-26
下一篇 2023-07-26

发表评论

登录后才能评论

评论列表(0条)

保存