職業生涯2

 

只是開發，還談不上架構。

架構師原本就是程序員,只是專一於架構設計和實現而已.

 

級別初級，中級，高級
職位，職能，職責的區別與聯繫

 

================================

瞭解本身的興趣愛好，特長優點，和發展的須要，清楚本身的SWOT,而後設定1年 3年 5的目標，不斷改進。
既然是個Team leader了，看來是技術轉管理的時機 >>System Architecture

 

天賦比努力重要，選擇比天賦更重要，這一切都是相對於成功而言的。

在職業發展中，首先要了解本身的特長與特質。天賦，努力，興趣每每是一個正循環，若是你的職業能發揮天賦，那努力的效率就會更高。
儘管「天賦+努力」會讓你更快，但不必定是成功的充分條件，選擇每每比天賦更重要。每一次選擇都成爲人生的轉折點。在岔路口，要作好選擇題，
沒有選擇時，要不斷豐富本身的知識面，等待機會。

會考慮轉型到管理崗
    若是有選擇的機會，而本身剛好又有想法和意願，能夠嘗試。
    嘗試以後若是以爲不合適，或想更專一於技術自己，能夠再轉回技術崗。
技術專家與管理崗位有不一樣的要求

 

管理實際上是從親力親爲到放權，再到相互成就的過程。要用幾年的時間來適應角色的轉變，直到激發團隊來共同完成工做。
對於管理者而言，放權與推進只是第一階段，更高級的管理應該是相互成就，共同成長。
根據每位工程師的我的能力特色，分配不一樣的任務，讓他們參與到決策的不一樣環節，激發潛力的同時，能最大程度地釋放本身的壓力與時間，去思考更高層面的內容。

每一個團隊中，由於成員的不一樣成長階段，均可以分爲4種人：人口，人手，人才，人物
人口須要培養，還不能獨立工做
人手能夠起到執行的做用，作一些平常的基礎工做
人才更願意去學習與挑戰，也須要更多的成長與施展空間

管理者就是要分清這幾種人，管理者的工做就是識人善用，並爭取爲他人提供進階的機會。

沒有完美的我的，只有不斷走近完美的團隊


技術服務於業務，業務服務於用戶

 

=============================

 

我從事大中型企業的IT系統管理，和運維工做已經5、六年了。技術出身，目前也是個Team leader，管理着3、四我的。技術方面屬於相對全面型，並無在某一項技術領域裏成爲專家級別。今年28，想在這裏請教一下各方面的前輩。作爲一個IT運維管理人員，應若是規劃自身下一下五年的職業生涯

 

 

前端開發人員在跟 UI (用戶界面設計工程師) UE (用戶體驗工程師)配合的過程當中，須要咱們把絢麗的圖片切成咱們所須要的圖片，這個時候就要掌握字體轉換，圖片格式，以及將 PSD 轉換成一張張小圖片供咱們使用。這就是俗稱的切圖。

 

Team Leader

程序員

產品經理　　product manager

算法工程師、研發工程師、軟件工程師

系統分析員

系統分析員重點關注客戶的業務，將客戶的需求轉化成相似用例圖這樣的表示，從而架起客戶與系統設計人員之間的橋樑，

因此係統分析員要朝着客戶業務專家的方向發展針對現有系統在業務/數據/組織結構等方面進行合理的分析和優化等功能,

就是能指出系統中哪些東西是好的哪些有問題等等.，好比專一電信行業、電力行業、金融行業等。

 

系統設計人員

系統架構師/軟件架構師

系統架構師關注的是軟件的骨架，就像設計大樓的設計師同樣，把大樓的框架設計好，至於裏面的分隔、裝修等不是他的關注點，

因此係統架構師每每可以從系統需求（規格）書中很快的抽象出從此係統將會成爲怎麼樣的一個系統的輪廓，

而後將部件、部件與部件之間的交互用相似UML這樣的建模語言表達出來，供詳細設計人員參照。系統架構師必須擁有至關的工做經驗，

並善於從以往的項目中總結出各類設計模式並加以引用到新的系統中來。

系統架構師的主要職能是介於產品設計和開發設計的橋樑。
一、最終確認進入開發流程的產品設計或者需求。
二、給出系統的邏輯分層和層次之間的關係，這是架構設計的重點。
三、掃清技術難點，並給出解決方案。不少狀況下，都要創建原型。
四、保證和監督架構設計被執行。

系統架構師首先是技術權威，領導力卻是其次，除非兼任項目經理的職責。可是系統架構師對溝通能力要求很高，這點真的很重要。由於不但要和產品經理溝通，還要和開發人員溝通，還要與領導溝通，甚至要去說服不懂技術或者精通技術的領導。
開發語言的選擇，要有針對性的。何時用C/C++、何時用JAVA，何時用腳本語言，選擇哪一種開源項目。這些都須要系統架構師做出決策，要求系統架構師有足夠的能力去評估。拿着錘子，處處是釘子，是個大忌。
沒有最好的系統架構，只有最合適的系統架構。每一種系統架構都有他的適用背景和邊界條件。也沒有一成不變的系統架構，系統架構須要進化。

軟件架構師可細分爲應用架構師和技術架構師，應用架構是軟件自己做爲一個應用而存在的結構，技術架構是使應用可以運轉的支撐架構。就像軟件是爲社會爲生活服務同樣，技術架構是服務於應用架構的。所以，要作架構師，不能只喜歡純技術，還要學習儘量多的領域知識。

浮躁只會讓人一事無成。曾見過一些人，寫了兩月程序，就嫌寫程序低級要去作設計，剛寫了兩月設計，就嫌設計低級，就要去搞需求分析，剛搞了兩天分析，又以爲搞技術沒前(錢)途，就要去搞管理或者搞市場。也見過一些人，搞了三月嫌工資低，跳一下漲點工資，再搞三月又跳跳漲點工資。跳來跳去，開始還能往「上」跳， 到後面是隻能往被趕着往下跳了。



在軟件工程中，架構師的做用在於三方面：
一、行業應用架構，行業架構師每每是行業專家，瞭解行業應用需求，其架構行爲主要是將需求進行合理分析佈局到應用模型中去，偏向於應用功能佈局；
二、應用系統技術體系架構，技術架構師每每是技術高手中的高手，掌握各種技術體系結構、掌握應用設計模式，其架構行爲考慮軟件系統的高效性、複用性、安全性、可維護性、靈活性、跨平臺性等；
三、規範架構師是經過多年磨礪或常年苦思頓悟後把某一類架構抽象成一套架構規範，固然也有專門研究規範而培養的規範架構師。他們的產物每每也分爲應用規範和技術規範兩類。
 
那麼要成爲架構師的途徑彷佛只有如今較爲流行的軟件學院和我的自我培養了。

總結架構師自我培養過程大體以下僅供參考： 

一、架構師胚胎（程序員）學習的知識是語言基礎、設計基礎、通訊基礎等，應該在大學完成，內容包括java、c、c++、uml、RUP、XML、socket通訊（通訊協議）——學習搭建應用系統所必須的原材料。 
二、架構師萌芽（高級程序員）學習分佈式系統、組建等內容，能夠在大學或第一年工做時間接觸，包括分佈式系統原理、ejb、corba、com/com+、webservice（研究生能夠研究網絡計算機、高性能併發處理等內容） 
三、
架構師幼苗（設計師）應該在掌握上述基礎之上，結合實際項目經驗，透徹領會應用設計模式，內容包括設計模式（c++版本、java版本）、ejb設計模
式、J2EE架構、UDDI、軟件設計模式等。在此期間，最好可以瞭解軟件工程在實際項目中的應用以及小組開發、團隊管理。 
四、軟件架構師的正
式成型在於機遇、我的努力和天賦，軟件架構師實際上是一種職位，但一個程序員在充分掌握軟架構師所需的基本技能後，如何獲得這樣的機會、如何利用所掌握的技
能進行應用的合理架構、如何不斷的抽象和概括本身的架構模式、如何深刻行業成爲可以勝任分析、架構爲一體的精英人才這可不是每一個人都可以趕上的餡餅…… 

絕
大部分軟件架構師是依賴軟件程序員來實現他們的架構意圖的，這兩者直接的鴻溝是顯而易見的。設計模式的出現是爲縮短兩者之間的鴻溝所作的努力，目的是讓架
構師和程序員之間有更多的共同語言和規範。儘管設計模式讓軟件開發效率和質量有必定程度的提高，可是它始終面臨一個很明顯的侷限，那就是人的因素。人雖然
在創造性方面有絕對優點，可是在精確性、持久性、效率、質量上是沒法比擬機器的。


最近一段時間都在作系統分析和設計工做，面對的業務是典型的重量級企業應用方向。忽然發現不少以往以爲很簡單的問題變得沒有想象的那麼容易，最大的問題就是職責如何分配。論系統架構設計的最大的問題，其實也就是職責的分配，分配的合理，實現起來就會很柔性，反之就會使架構很混亂。

軟件的生命週期大概能夠概括爲四個基本的過程，分析、設計、實現、測試，固然這僅僅是一個最爲粗略的表示而已。不一樣的方法論有着不一樣的使用這幾個過程的方式。RUP使用快速迭代的過程，在這個幾個子過程當中適當的輸出一些過程製品，每次迭代都是進行相同的分析、設計、實現、測試。而在Scrum中，不提倡輸出任何文檔形式的過程製品，也一樣有着上述幾個過程，強調以人爲中心，經過溝通來解決大部分的問題。

不能用好與很差來判斷哪種方法論，只能根據目前的實際狀況綜合權衡。RUP的每次迭代中有幾個關鍵的製品對系統分析、設計很重要，能夠說是很是重要，如：詞彙表、業務規則文檔、用例、領域草圖。這幾個製品對分析、設計很重要，須要從這幾個製品中提煉出設計模型最終才能落地。這主要用在業務複雜的應用系統中。而Scrum更加的輕量級，能夠用在互聯網項目中，業務不是太複雜的狀況下。

其實我爲何要強調軟件工程及開發方法論，是由於我最近發現，作設計實際上是創建在分析的基礎上的，可是這裏面又有不少問題。大型企業級應用，並不能經過一次性分析就能夠得出準確和所有的需求，初期階段創建的需求70%都是不許確的。因此作架構須要有分析的能力才行且是創建在適當的開發方論上的分析，何時該用RUP，何時該用Scrum，何時該用XP都頗有講究。分析與設計都須要有一個執行上下文，不一樣的上下文對分析、設計的執行有着不一樣的要求。

有句話我以爲對架構者來講頗有啓發：分析就是作正確的事，設計就是正確的作事。架構跟語言跟平臺關係不大，畢竟架構是設計過程當中的子過程，我想若是你的設計不合理，你用任何語言任何平臺都解決不了問題。（這裏的架構上下文指：企業應用架構不是基礎設施的系統架構）

 

 

運維架構師

運維架構師
系統運維
應用運維


遊戲運維（頁遊，手遊，網遊的運維仍是不同的）
　　開區合區
網站運維（電商網站，門戶網站，視頻網站，社交網站的運維也是不同的）

運維過多個項目（小公司，大公司的項目）

http://blog.sina.com.cn/s/blog_81cfb986010147os.html

提到架構師，你們都以爲挺神祕的，而做爲運維領域的架構師，站在系統穩定和高可用、高擴展的角度，其承載着太多的責任和挑戰。對於運維工程師來講，運維架構師就像是一個目標抑或是一座山峯。如何成爲一名優秀的運維架構師？運維架構師應該具有何種職業素質？須要什麼樣的知識體系呢？

運維架構師一詞應該是與系統架構師、軟件架構師、網絡架構師、業務架構師不一樣的，雖然都是架構師，但側重不一樣。在一個企業的IT系統中，運維架構師更須要具有開放的眼光，各類平臺、系統、數據庫、網絡架構及後端存儲設計都能隨手拈來皆可組合，

運維永遠沒有一勞永逸的時候，無論是運維體系多麼完善，也無論是自動化運維作的多麼漂亮，咱們面臨的新問題仍然很多。隨着業務的發展，從基礎架構到高層應用，從系統擴展、架構調整、數據安全，須要架構師去思考的問題會愈來愈複雜，不斷的創新和學習，將是一個運維架構師的重要任務。

從以上的分析來看，成爲一個優秀的運維架構師，須要自我有一個良好的職業規劃。首先你能夠選擇先作2-3年的系統集成，全面瞭解各類服務器、系統部署、網絡架構、數據庫、存儲等，從具體的實施中去學習和了解系統、網絡、數據庫的特色和應用；接着你能夠選擇去知名的公司和企業作一個專業的運維，工做2-3年，並在工做中從運維工程師提高到運維經理，精深技術的同時積累本身的管理經驗；再接下來你能夠嘗試去能接到不少運維項目並作IT解決方案的專業的IT服務公司，作一名架構師，利用已有的工做經驗和積累，來具體解決各行業的IT系統架構和拓展的問題，如此發展和成長你就真正的成長爲一名運維架構師了。

 

IT經理，能夠說本身是項目經理，也能夠說本身是開發經理，可是說架構師，是否是有點偏了？

產品經理
項目經理

項目經理通常是指軟件開發項目經理，其關注點是開發計劃的編制、計劃的執行、計劃的檢查等，以按時保質開發出軟件爲終極目標，

但涉及面卻很是廣，既要有良好的技術背景，又要有與人溝通的能力（通常技術人員出身的人最欠缺的），要講究必定的方法論，

但更要掌握管理方方面面的最佳實踐。