久久精品国产一区二区电影,久久精品国产亚洲av瑜伽,精品无人区一码卡二卡三,久草热8精品视频在线观看 ,久久99精品久久久久麻豆

互聯(lián)網(wǎng)職場中的那些“唬人”的縮寫(職位篇)

作為一名“欠資深”的互聯(lián)網(wǎng)從業(yè)人員，工作中總會聽到各種各樣的職位簡稱，一開始真心不習慣，也不是很了解其中的含義，也鬧過不少笑話和尷尬~

今天給大家梳理下，完全從個人認知的角度，有不準確的地方，請大家斧正！

縮寫 注解

GM(General Manager) 總經(jīng)理

VP(Vice President) 副總裁

FVP(First Vice President) 第一副總裁

AVP(Assistant Vice President) 副總裁助理

CEO(Chief Executive Officer) 首席執(zhí)行官，類似總經(jīng)理、總裁，是企業(yè)的法人代表

COO(Chief Operations Officer) 首席運營官，類似常務總經(jīng)理

CFO(Chief Financial Officer) 首席財務官，類似財務總經(jīng)理

CIO(Chief Information Officer) 首席信息官，主管企業(yè)信息的收集和發(fā)布

CTO(Chief technology officer) 首席技術官 類似總工程師

HRD(Human Resource Director) 人力資源總監(jiān)

HRBP(HR Business Partner) 人力資源業(yè)務合作伙伴

OD(Operations Director) 運營總監(jiān)

MD(Marketing Director) 市場總監(jiān)

TL( Team Leader ) 部門經(jīng)理/團隊負責人

PM(Product Manager) 產(chǎn)品經(jīng)理

RD(Research and Development） 研發(fā)工程師

BD(Business Development) 商務運營

UE(User Experience) 交互體驗師

UI(User Interface) 用戶界面設計師

QA（Quality Assurance) 測試工程師

OP(Operations) 運維工程師

DBA(Database Administrator) 數(shù)據(jù)庫管理員

由于篇幅的原因，就列舉出這樣職位縮寫，如果有沒有提到名字的崗位，請大家千萬不要誤會！

小編一直篤信：每個人每個崗位在公司中都會起到相應的作用，不必說離不開誰，但起碼我們都付出了勞動與汗水，一定會體現(xiàn)出應有的價值！

下面我們深入介紹下，表格中下半部分的職位，畢竟這些職位都是和我們息息相關的，平常日常工作中高概率接觸的，至于上半部分職位，我們就把它們當成我們的職業(yè)目標，深深地默默地埋藏在心底，就好了~

我們先來聊一聊HR和HRBP，剛?cè)肼毜臅r候，成天和HR斗智斗勇，從來沒有聽過HRBP的概念啊，可能是當時的公司??？或者是當時還沒有流行HRBP這個崗位？不甚了解啊，至于這兩個崗位什么區(qū)別，請看這個圖：

PM 產(chǎn)品經(jīng)理(Product Manager)

在互聯(lián)網(wǎng)企業(yè)中，PM通常被理解為產(chǎn)品經(jīng)理的意思，剛?cè)肼殘龅臅r候，一度認為PM是項目經(jīng)理( Project Manager )的意思，好高大上的感覺，從此立志把成為一名合格的PM作為我職場的第一課，可“入坑”了，也就那么回事吧，哈哈，戲言，純屬戲言~

我還是很愛我的職業(yè)和崗位的，畢竟一直以能提高產(chǎn)品變現(xiàn)能力，實現(xiàn)營收最大化為己任….咳咳

RD 研發(fā)工程師(Research and Development)

軟件RD工程師就是軟件研發(fā)工程師，諸如PHP程序猿，Java程序猿，無論是愛瘋的還是安卓的都是屬于這一類別。

偏向于后端的技術實現(xiàn)。

FE 前端（Front-End）；前端開發(fā)（Front-End Development）

FE是web前端研發(fā)、前端開發(fā)的意思！前端開發(fā)工程師不僅要掌握基本的Web前端開發(fā)技術，網(wǎng)站性能優(yōu)化、SEO和服務器端的基礎知識，而且要學會運用各種工具進行輔助開發(fā)以及理論層面的知識，包括代碼的可維護性、組件的易用性、分層語義模板和瀏覽器分級支持等。

UE 用戶體驗（User Experience，簡稱UX或UE）

UE是一種純主觀的在用戶使用一個產(chǎn)品（服務）的過程中建立起來的心理感受。

因為它是純主觀的，就帶有一定的不確定因素。

個體差異也決定了每個用戶的真實體驗是無法通過其他途徑來完全模擬或再現(xiàn)的。

但是對于一個界定明確的用戶群體來講，其用戶體驗的共性是能夠經(jīng)由良好設計的實驗來認識到。

另外還有有個組合叫法：UED（產(chǎn)品交互設計師，用戶體驗師）。

UI 用戶界面（User Interface）

UI設計則是指對軟件的人機交互、操作邏輯、界面美觀的整體設計。

好的UI設計不僅是讓軟件變得有個性有品味，還要讓軟件的操作變得舒適、簡單、自由、充分體現(xiàn)軟件的定位和特點。

關于UE和UI，之前也是傻傻分不清楚，那時候也鬧過尷尬。

記得當年剛進入職場不久，寫好一份需求，興奮地去找設計師當面對下UI細節(jié)，我還是比較禮貌的說了句：您是UI設計師吧，誰成想，妹子當時給我來一句“我是UE不是UI，謝謝.......”……懟的我半天沒說出話來~~心想有啥區(qū)別嗎？其實區(qū)別還挺大的，吃了沒文化的虧??！

QA 測試（Quality Assurance）

在ISO8402：1994中的定義是“為了提供足夠的信任表明實體能夠滿足質(zhì)量要求，而在質(zhì)量管理體系中實施并根據(jù)需要進行證實的全部有計劃和有系統(tǒng)的活動”。

有些推行ISO9000的組織會設置這樣的部門或崗位，負責ISO9000標準所要求的有關質(zhì)量保證的職能，擔任這類工作的人員就叫做QA人員。

OP 運維（Operations）

OP這個詞語代表的意思很多，這個簡稱來自于英文的Operations一詞。

我也不清楚誰最早用op代表運維工程師，不過2010年開始，這個詞慢慢被很多人所知道。

OP工作內(nèi)容主要就是維護公司的服務器能夠正常提供服務，細分的話包括系統(tǒng)部分，網(wǎng)絡部分，應用程序部分，數(shù)據(jù)庫部分，具體根據(jù)公司的規(guī)模和職位職能不同，運維的定義也不同。

現(xiàn)在市面上主要的OP有三種：網(wǎng)絡游戲運維，網(wǎng)站運維，大型項目測試和生產(chǎn)環(huán)境運維。

DBA 數(shù)據(jù)庫管理員(Database Administrator)

是一個負責管理和維護數(shù)據(jù)庫服務器的人。

數(shù)據(jù)庫管理員負責全面管理和控制數(shù)據(jù)庫系統(tǒng)。

這個職位對不同的人意味著不同的意義。

另外還有DB，既數(shù)據(jù)庫（Database）。

各職位具體職責:

目的：明確項目組各相關人員責任和權力，明確任務分工，降低各角色之間協(xié)調(diào)的成本，提高開發(fā)效率。

（1） 產(chǎn)品經(jīng)理

職責（對項目成敗及收益負全責）

制定產(chǎn)品的目標。

制定各個工作的詳細任務表，跟蹤這些任務的執(zhí)行情況，進行控制

組織會議對程序進行評審

綜合具體情況，對各種不同方案進行取舍并做出決定

協(xié)調(diào)各項目參與人員之間的關系

人員要求

對產(chǎn)品有激情，具有領導才能

對問題能正確而迅速地做出確定

能充分利用各種渠道和方法來解決問題

能跟蹤任務，有很好的日程觀念

能在壓力下工作

（2）構(gòu)架設計師

構(gòu)架設計師負責在整個項目中對技術活動和工件進行領導和協(xié)調(diào)。

構(gòu)架設計師要為各構(gòu)架視圖確立整體結(jié)構(gòu)：視圖的詳細組織結(jié)構(gòu)、元素的分組以及這些主要元素組之間的接口,最終的部署等。

因此，與其它角色相比，構(gòu)架設計師的見解重在廣度，而不是深度。

（3）需求分析員（與客戶業(yè)務人員進行業(yè)務需求溝通，引導業(yè)務人員進行系統(tǒng)需求提出的人員。

）

業(yè)務分析員通過概括和界定作為建模對象的組織來領導和協(xié)調(diào)業(yè)務用例建模。

例如，確定存在哪些業(yè)務主角和業(yè)務用例，他們之間如何交互。

通過描述一個或幾個用例的需求狀況以及其他支持軟件的需求來獲取系統(tǒng)功能某一部分的規(guī)約。

還要負責用例包并維護該用例包的完整性。

職責（ 對需求正確性和完備性負全責）

進行需求溝通：與業(yè)務人員深入溝通業(yè)務需求，確定軟件需求限制和軟件同其它系統(tǒng)接口細節(jié)

發(fā)起討論：與業(yè)務進行重大需求討論和確認前，應與項目組內(nèi)部干系人進行需求討論，達成一致，避免出現(xiàn)不合理需求

出具需求規(guī)格說明書：出具完整描述業(yè)務需求、無歧義、可執(zhí)行的需求文檔

維護需求狀態(tài)

解答項目組內(nèi)其他人員關于需求的疑問

屏蔽業(yè)務人員對開發(fā)人員的干擾，使得開發(fā)人員可專注于系統(tǒng)實現(xiàn)

人員要求

擔任系統(tǒng)分析員的人員應該善于協(xié)調(diào)，并且具有良好的溝通技巧

擔任此角色的人員中必須要有具備業(yè)務和技術領域知識的人才

（4）軟件設計師

設計員定義一個或幾個類的職責、操作、屬性及關系，并確定應如何根據(jù)實施環(huán)境對它們加以調(diào)整。

此外，設計師可能要負責一個或多個設計包或設計子系統(tǒng)，其中包括設計包或子系統(tǒng)所擁有的所有類。

編寫部分模塊設計文檔和代碼，檢查軟件工程師編寫的模塊代碼。

職責

定義類的方法和屬性以及各個類之間的關聯(lián)，畫出類圖

進行數(shù)據(jù)庫設計

人員要求：

掌握面向?qū)ο蠓治雠c設計技術，統(tǒng)一建模語言(UML)

（5）UI設計師

界面設計人員通過以下方法來領導和協(xié)調(diào) Web 界面的原型設計和正式設計：獲取對 Web 界面的需求（包括可用性需求），構(gòu)建 Web 頁面原型，使 Web 界面的其他涉眾（如最終用戶）參與可用性復審和使用測試會議，復審并提供對 Web 界面最終實施方案（由其他開發(fā)人員員創(chuàng)建，如設計師和實施工程師）的適當反饋。

（6）軟件工程師

軟件工程師負責完成設計師的設計意圖，根據(jù)設計文檔編寫代碼；根據(jù)設計文檔編寫單元測試代碼，根據(jù)測試報告BUG記錄修訂BUG，完成包或子系統(tǒng)的開發(fā)。

職責（對產(chǎn)品功能代碼質(zhì)量負全責）

需求溝通：與需求人員溝通需求，了解需求細節(jié)

需求評審：評審需求人員編寫的需求規(guī)格說明書，共同把控需求質(zhì)量

系統(tǒng)設計：根據(jù)需求規(guī)格說明書進行系統(tǒng)功能設計，出具可執(zhí)行的詳細設計文檔

發(fā)起評審：重大功能或核心算法，在編碼前，應主動提起設計評審，讓項目組相關人員相互取長補短，共同把控系統(tǒng)質(zhì)量

編碼：根據(jù)詳細設計文檔進行系統(tǒng)編碼工作，實現(xiàn)需求功能

單元測試：對自己開發(fā)的功能進行單元測試，確保功能的正確性

功能發(fā)布：負責正確填寫更新列表，跟蹤功能發(fā)布狀況

BUG修改：修改BUG，及時發(fā)布，并跟蹤BUG復測情況

注：開發(fā)人員享有拒絕權：

若發(fā)生需求描述不明確，或與系統(tǒng)不兼容，甚至不能實現(xiàn)等需求問題，開發(fā)人員有權利拒絕本需求的開發(fā)，并與需求人員溝通提起需求的再分析。

若接收到的BUG非系統(tǒng)功能問題，開發(fā)人員可進行拒絕處理，并根據(jù)實際情況進行解釋或提起討論分析。

（7）測試工程師

人員要求

了解被測試的系統(tǒng)，具備診斷和解決問題的技能，編程技能

職責

執(zhí)行測試，描述測試結(jié)果，提出問題解決方案

需求評審：評審需求人員編寫的需求規(guī)格說明書，共同把控需求質(zhì)量。

理解需求：深入理解需求人員給出的需求規(guī)格說明書，掌握業(yè)務需求要點

編寫測試案例：編寫能覆蓋需求內(nèi)容、且能覆蓋絕大部分業(yè)務行為的測試案例

發(fā)起評審：重大功能或核心功能的測試案例應發(fā)現(xiàn)評審，共同把控案例完備性

執(zhí)行測試案例

復測BUG

出具測試報告：給出測試過程中的bug情況，出具上線標準確認書

什么叫測試工程師：工作的責任當然是發(fā)現(xiàn)在開發(fā)中所出現(xiàn)的技術問題和錯誤，及時的向項目小組報告情況，并督使項目小組相關的開發(fā)人員解決被發(fā)現(xiàn)的問題。

一般項目的質(zhì)量測試有以下4個過程：

　1）白盒測試：就是項目的開發(fā)人員自己在平時的開發(fā)中，或者是在一個小模塊開發(fā)完成后。

測試自己的所開發(fā)模塊的過程。

其測試內(nèi)容主要是自己原代碼的完整性和規(guī)范性，自己開發(fā)的模塊流程是否清晰、邏輯正確等等。

　2）黑盒測試：由開發(fā)小組的人員互相交換或者在空閑時間干脆請公司里非開發(fā)項目小組的同事來幫助測試各個模塊。

重要的內(nèi)容是：檢查各個模塊的連接是否緊密，各個超級連接是否正確，軟件中是否有JS等報錯，表單區(qū)域中的文本筐等和用戶交互的部分是否有長度的限制？是否有超文本語言的過濾？是否有非法字符的驗證？在用戶填寫相關信息出錯的時候，程序是否有相關的處理等等。

　3）用戶測試：主要是邀請本項目外的其他同事以用戶的角色來測試項目的功能。

其內(nèi)容主要是：評價每個模塊的風格和項目的總體的風格是否沖突？功能是否能否實現(xiàn)，流程是否清晰，界面是否友好，頁面安排是否舒適？各種連接所放的位置是否舒適等等。

　4）負載測試/性能測試：當項目看來可以很好的工作了，就可以開始負載測試的階段。

項目小組這個時候應該在公司和客戶的幫助下，安排盡量多的用戶登陸開發(fā)基本完成的項目，使項目盡可能的承受長時間和高強度的測試。

這個時候往往會發(fā)現(xiàn)相當多的問題（特別是以程序為主的WEB站點）。

比如程序運行時服務器出現(xiàn)內(nèi)存溢出？CUP資源占用瞬間漲滿？兩個用戶在數(shù)據(jù)庫中查詢同一數(shù)據(jù)時造成沖突？一些查詢過程時間過長？甚至是一些客戶端腳本與瀏覽器版本不兼容等等。

　在質(zhì)量小組每完成一步測試的時候，都要詳細的寫好測試結(jié)果，測試環(huán)境以及問題描述的報告直接交給項目經(jīng)理，再由項目經(jīng)理了解大概情況分發(fā)給問題相關的開發(fā)人員并監(jiān)督其解決問題。

注1：測試人員享有拒絕權：

若開發(fā)人員提交DAT的功能有阻斷性BUG或嚴重BUG較多，測試人員可拒絕相關功能的測試，等待開發(fā)人員調(diào)整系統(tǒng)。

（嚴重Bug較多：按功能工作量，平均每天發(fā)生一個嚴重Bug）

注2：測試人員享有免責權：

若測試報告為不能更新UAT，但經(jīng)項目經(jīng)理及客戶同意，將該功能更新到UAT，則測試人員可不對測試報告中提出的不能更新的功能點負責。

最后結(jié)合自身工作經(jīng)驗，說幾點對于PM的理解與認知：

產(chǎn)品經(jīng)理的使命：協(xié)調(diào)所有的資源，通過產(chǎn)品來實現(xiàn)公司的戰(zhàn)略目標和收入變現(xiàn)

產(chǎn)品經(jīng)理的入口：從專業(yè)（研發(fā)/測試/設計、市場/運營）入手，不要搞零基礎，那樣只是害人害己

產(chǎn)品經(jīng)理的硬技能：原型制作技能、文檔撰寫能力

產(chǎn)品經(jīng)理的軟技能：邏輯分析、全局觀、數(shù)據(jù)分析

產(chǎn)品經(jīng)理的人格能力：同理心、溝通力、領導力、時間管理能力

以上大部分信息來自個人工作中的心得體會，同時也有借鑒百度/CSDN信息

如有不準確之處，請大家關注小編，留下您的寶貴意見